Job description meme

Ok, so I had a thought for a meme. Basically, I find myself completely astounded by how little I know of my close friends’ careers. I know their titles and I vaguely know what their industry does, but I have no real idea what role they play in a company and what they do on a day-to-day basis. So here, I offer to you guys a description of what I do, sans any specific details that would violate NDAs or give out corporate information in any way. I encourage you to do the same either here, or on your own blogs.

What I might do in any given project:

• Go to meetings to discuss and give my input on how features should work. For a completely generic example, if our Generic Product X needed a screen that could only show three pieces of information at any given moment, what pieces of information might be displayed for various scenarios? If the user could take two distinct actions on any given screen, what actions should they be? A lot of these talks also happen outside of meetings throughout a project.

• Go to meetings to discuss and give my input on what technologies we need to use to make those features work. Ditto on the talks happening outside of meetings.

• Research and analyze competitive products and see where they are doing things right and where we can improve. It’s always interesting to compare the difference between what a user has grown accustomed to versus how to most effectively and intuitively accomplish the same action.

• Come up with new ideas for making the product better/fixing existing problems.

• Write documentation detailing the design and technical details of how we plan to write the feature or product or fix. Keep in mind that my code might be used by thousands of concurrent users (or by one user on a system with very limited resources), so efficiency is key.

• Give input to QA so that they can figure out plans for how they are going to test the crap out of the product once the engineers are done writing it.

• Write the dang code. Test the dang code. Repeat a bajillion times. This is when things are going well.

• Rewrite or otherwise modify existing code. Read weird, outdated comments. Wonder why certain changes were made. Wonder why certain changes were not made. Wonder if changes were actually made but the comments were not updated, or vice versa. Wonder what this completely inscrutable variable is supposed to represent. Pull out hair. Test the changes. Pull out more hair. Repeat a bajillion times. Try not to go bald.

• Report back on progress for certain pre-determined milestones. Try not to fall asleep when others are reporting their progress. More importantly, try not to fall asleep when I am reporting my progress.

• In between the above “real” tasks, juggle the usual hurdles of tools I may not like, programming languages with strange limitations, platforms (Windows? mobile devices? website as viewed on a Mac with an outdated version of the Opera browser?) with other limitations, project scheduling constraints that I may not like, and most importantly, people I may not like. Luckily for me, I’ve worked with great people most of the time, so I don’t have too much reason to grouse about the last item.

What I might do on any given day in the middle of a project:

• Sit in front of my computer with the code open in an editor (can be something fancy, but it can be as simple as the Notepad program that comes on Windows).

• Read the code and figure out what is happening in the code.

• Make the changes I had planned out when I last sat there and stared at the code.

• Compile (and link) the code. For non-software engineers, some programming languages need a step to make the text you wrote down turn magically into something that does something. For instance, I write code in text, using the keyboard and using numbers and English letters. But you’ll notice on your computer that there are programs that you can just double-click and it’ll “run”. Compiling (and linking) is the step between writing text and having a program that the computer knows it can “run”. Sometimes, this step can take like an hour or two, depending on how big of a project I am working on. Sometimes, it might only take a minute. During this time, I might websurf answer emails do further research to hone my craft.

• Test the code. This means I act like a regular user of the program and see if things work the way they were planned. Sometimes, you have to do really weird things to try to replicate a problem you are trying to fix. In my past job, this sometimes involved a microwave and trying to click keys faster than one would have thought was humanly possible. For real.

• Repeat until the problem is completely solved. I joke about testing a bajillion times, but in a best case scenario, the initial investigation and planning should have gotten me 99% to a solution for 90% of the cases. The repeating comes in when there are extreme, previously unexpected scenarios. The better an engineer, the fewer the unexpected cases, because the idea is that we should be planning for all those cases, leaving very few stones unturned.

The above is, as I noted, for the “middle” of a project, after most things have been planned, major decisions have been made, and major deadlines have been agreed to. It’s also before things get closer to ready for human usage and enter the official testing and shipping phases.

If you are someone that just does this above part, I think you’d be called a programmer or software engineer. It’s the additional stuff (from the first list) when you get involved with the decisionmaking process and bring your expertise that makes you a senior software engineer or other loftier titles (I think my next title at my old job was going to be Distinguished Member of Technical Staff — hee!).

Like many other jobs, software engineers have planning meetings, internal checkpoints/milestones, research and development, and random corporate annoyances. I’ve tried to write my answers with as little jargon as possible, but reading over the bullet points show me that I’ve failed at that. Oh well. I hope some of my non-software engineering friends know a little more about what I do now.

Now, I want to know: what do you do? I really have no idea what most of you guys do on a day-to-day basis.