This is the first installment of a series devoted to the various roles of IT pros. Here, Justin James, describes his job as a programmer.
This marks the beginning of a series within the Career Management blog in which I feature a short survey of a tech pro in a particular specialty. It's not a comprehensive look, just a snapshot of what the person likes best and likes least about his or her chosen profession. I'm hoping it will give a little anecdotal direction to those of you who are just starting out in IT or are looking to change direction. (If anyone wants to talk about their job for the benefit of our readers, feel free to answer the three questions below and email them to email@example.com)
Our first IT job is Programmer. I put our survey before Justin James, host of our Programming and Development blog. Here's what he had to say:What do you like best about your job?
I love it when you give an end user an application that does exactly what they want, and they never thought it could happen. It is a really great feeling to see them saving time and frustration, and it is because of your hard work. There's a balance, though. Too many development projects are conceived without doing any kind of ROI calculation, and then you feel like you are wasting your time. Sure, the user might be happy, but why spend three months working in order to save someone five minutes of effort a day? That just does not make sense to me.
Another thing that I enjoy is coordinating the technology so that it serves a person. While I appreciate "technology for the sake of technology" I recognize that it is not practical for anyone outside of a few areas like R&D or academia. In the business world, you justify your paycheck by adding to the bottom line, and programmers add to the bottom line by making it easier, simpler, and more accurate for the rest of the folks to do their jobs. There is a lot of satisfaction in seeing how your work has benefits that affect a lot of people.
Software development has a lot of drama to it; a workday can run the gamut of emotions from delirious elation to the depths of despair, over something as simple as mixing up "contact" and "contract." A lot of the programmers I know are big into unusual hobbies that tweak the emotions and senses, like extreme sports, car racing, playing drums in metal bands, and so on. I think there is a definite connection there. I got into weightlifting in 2008, and it appeals to me for the same reasons programming does: it is an intense challenge, filled with frustration, but when you break through the barriers the feeling of joy is very intense. Emotionally, solving a difficult development challenge and adding another ten pounds onto a personal deadlift or squat record feel the same.What do you dislike about it the most?
My number one pain point is when I need to work with people who are trying to drive the development process without understanding it. This is probably the most common complaint in all of IT, but it's real. For example, why would someone who does not know how to program dictate to me what to name the variables? That's like me telling Emeril what brand of basil to buy to make the best lasagna. It's a trivial detail outside of my knowledge domain. At the same time, everyone from bosses to project managers to clients to end users try to (and often are able to) dictate low-level details which are neither important nor their concern. And what usually happens, is that it becomes a giant fight which leaves long-lasting scars and sometimes can wreck a project, even though in the big picture it really doesn't matter. Along the same lines, it can be very frustrating when you have invested a lot of time in a particular approach to the task because the client was positive they knew what they wanted, and when you deliver it, they realize that while you met their specified need, they did not understand their needs fully.
Aside from that, the big frustration often is with missing or poor documentation. For example, on a project that I am currently on, I am interfacing with a system where the API documentation has no examples or useless examples. The result is that for nearly every line of code I write, I have to hit the search engines to dig up the right approach to it. The person who writes the "missing manual" for this system will probably do some brisk sales. Independent consultants in this system get to charge around $150/hour for work on projects that can last months, and a large part of that is that it takes so long to learn, due to the documentation. You see this a lot in IT, situations where consultants are needed because the systems are hard to use or poorly documented, and the situation doesn't really change because the vendor listens to the consultants, not the customers, and of course the consultants love the status quo.What education/background qualified you for your job?
I learned to program when I was in high school. During high school, I volunteered for a local home for developmentally disabled adults, and did some simple programming for them. In college, I stayed very active, doing things like building Web sites with notes and tips for my classmates, worked a job at the campus computer lab, and moved into part-time development jobs in college. I majored in liberal arts, but by the time I graduated college, I had enough experience to be considered an "intermediate" developer. The key differentiator between me and a lot of the other people I've met in this industry, is the degree of enthusiasm. I like this work enough to devote significant portions of my non-work hours programming, learning about programming, or writing about programming. When other people are watching TV, I'm programming. When other people are sleeping, I'm helping someone else with a question. And so on. The other people I've met like this are almost all very good developers, and never lack for career choices. The people I know who treat it is a 9 - 5 job, well, a lot of them have been struggling to find work during the current downturn, and were often let go in the first round of layoffs. I think there's a connection.
Get the PDF version of this post here.