What's common knowledge at your workplace, but blow the rest of our minds?

The reply from "Tech Recruiter @ Facebook" is probably of interest to a lot of people on HN.

As a programmer/analyst I do a lot more than just program. Or did when I worked from 1997-2001. I had to do the work of other people, communicate with them, and troubleshoot a lot of issues.

I'm not always at my desk because people need my help elsewhere.

Help Desk gets issues with my programs that are basically tech support issues a technician should be able to handle. Like MSCOMCTL.OCX is missing or invalid errors. I have to go to each user's PC and download the latest version of that file from the server and then run regsvr32 on it to activate it unless it doesn't require activation.

I'm often found near QA were I go over bugs as they try and replicate them for me so I can track them down in my code and fix them. I often get asked by a QA worker to come over to their cubical to look at a new bug they found.

When the DBA messes up on SQL Server, I have to fix it for them and teach them what went wrong and how to fix it. Most of the time it is an index problem or they used the wrong foreign key. As a result on Linkedin I get more sponsoring for Databases than I do with Programming because people remember that I fixed the database a lot.

The Business Office uses VBA and MS-Word and MS-Access and when they can't get things to work they call me to come down there and fix their VBA code or data, etc. They do data entry work and enter null into records, which my code has to check for before it is processed to avoid invalid use of null errors. Don't know the client's name on an account, enter null for the first and last name. Don't know the billing attorney, enter null into that area.

I also have to attend meetings with managers and supervisors who want new features and programs designed.

I have to do analysis of data and create reports for it. Managers want the figures to be correct and the correct fonts used on the printers. I use Crystal Reports and they use a form of Ada in the scripting language that my co-workers don't understand but I took Ada in college.

Just because you don't see me at my desk doesn't mean I am not working. Most people judge a programmer/analyst by how many lines of code they write per day, not how many coworkers and managers and supervisors they help out, how many problems they solve, how much documentation and reports they write, how many different departments they work with in a team environment, how they work with QA to fix bugs, and even the occasional employee who tracks you down to ask what computer to buy for their son or daughter who is attending college, etc.

I actually delete more lines of code than I finish shipping with. I always find better ways to do things and often have to rewrite stuff. If I can use fewer lines of code to do the same exact thing it saves RAM and runs faster. So less is more actually.