Day 1

Honestly, I don’t think I’ll be logging my activities everyday, but heck, why the hell not try.

So, let’s see… This morning, I woke up earlier than I wanted because Mobi kept whimpering to be let out of the room. After watching some random tv, Seppo and I went to lunch with Hoa and Sean at Vik’s Chaat. Man, those lamb cholles are so damn good!

After that, we went to the Apple store so I can obsess over which Mac-produced laptop I might get through the refurb shop. Seppo figured it would be important to get my hands on them and see what the differences were.

I am a terrible decision maker as far as purchasing technology because of these two conflicting facts:

• I am really, really cheap when it comes to buying stuff for myself. I never feel right spending a bunch of money on stuff solely for me, even though I don’t mind throwing down for food or gifts for family & friends.

• I have severe tech-envy and always want the fastest, shiniest, brightest, top-of-the-line, bleeding-edge things and fully intend to keep whatever it is until they roll over and die.

Usually, because of the former fact, I rarely pull the trigger on the latter impulse.

So, I’m still mulling over things.

Seppo was/is feeling pretty sick, so I dropped him off at home and ran over to the drug store to pick up some cold meds for him. The rest of the afternoon/evening/night involved dozing on the couch, two walks with Mobi, cooking dinner, and watching a buttload of “How I Met Your Mother” Season 2 dvds.

Oh man, I almost forgot to mention that last night, Seppo and I watched the premier of The Next Great American Band. It was made of 100% awesome, braised in awesome, and finished off under a hot broiler of awesometasticness. Yeah, I know that people think I’ll watch anything on tv, especially if it’s a competition, but honestly, it was great in a way that I had not foreseen. Maybe I’ll post a video clip tomorrow.

Wow, boring entry. Everything that happened after having lunch with the always funny/awesome H/S combo was pretty boring. This is how I’ll look back on my life. 😀 Well, at least I’ll know I was being honest about my day. You couldn’t make up more boring stuff.

And it’s so perfect and exactly what I wanted for my vacation.

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.