Thursday, April 8, 2010

Programmer? Developer? Engineer? Analyst?

I suppose this is an age-old debate; regarding job descriptions and responsibilities. One of my co-workers mentioned today how his responsibility to interact with customers and manage projects interferred with his ability to program. And yes, that makes sense, most professional programmers know that focus is key - and interruptions cost more than the actual clock-time lost for the interruption.

But what exactly is his job? And what does it entail? I can tell you I don't have an actual job description, and neither does he. The idea is to remain flexible - and that's not so bad. It has its pros and cons. Should we complain? Well that depends on what you want. Here's how I see it:

Programmer: Your job as a programmer is to program. You're given technical specifiications and you code them. No customer interaction, not a whole lot of decision-making. Not really solving problems or being creative - only when required due to insufficient specs and/or lack of communication from the creators of the specs. A "pure" programmer isn't doing much testing beyond what is done during the course of normal development (which is a topic for another day). The testing goes off to the Q/A department. So I guess we're assuming here that you're working in a company big enough to have engineers, Q/A, and programmers.

Analyst: Analyst implies you have to do some ... well ... analyzing. Probably some customer interaction here. For example, the customer may report a software issue and it's up to you to do the analysis and come up with a solution. And, most likely, you'll code that solution too. I haven't seen a place where they separate the programmer and analyst function. So in being an Analyst, this implies a broader range of responsibilities.

Engineer: Sometimes also known as an architect. These are the designers - the closest things you'll find to the computer scientists in the professional world (don't misinterpret this - I'm only implying that "true" computer scientists exist in academia). Engineers translate the business or program needs to data structures, functions, and procedures. They choose the language, platform, and whatever other technical decisions need to be made to produce a finished software product. I believe they even write the technical specifications - otherwise who would? A technical writer? It doesn't make sense to me that one person would design the software, communicate that to someone else, and that someone else would write up the technical specification. Engineers have to focus on good design principles. Following best design practices makes maintaining and upgrading software much easier in the future (also a blog post for another day).

Developer: This is the most generic term. Kind of a jack-of-all-trades, all-of-the-above kind of job description. You simply develop software - whatever that entails. For me, that entails gathering requirements, creating a design, implementing that design (with one or more developers under me), Q/A, UAT, and delivery. This is a blend of programming, customer interaction, and project management.

And ... this is what I do, and this my co-worker does. We're Software Developers. We wear whatever hat is necessary on any given day. If you enjoy pure programming - being a developer is not for you. If you enjoy working with customers and other developers - maybe a pure programming position (if they even exist - do they?) isn't for you.

This list is open to debate - and probably isn't complete. It's late and I want to go to bed. The world of being a software professional has a wide range of responsibilties, and can have a fair amount of depth. It may be different for older programmers, but this is only something I've learned through experience. Being fresh out of college (graduated 2003), I had no idea what the software industry was like. None. Haha - and maybe in another 7 years, I'll look back at this entry and think the same thing.

No comments:

Post a Comment