In light of my first work experience, I've been grappling with the question - what makes a good programmer? I know there have been so many articles written on this subject, by people much more knowledgeable than I am, but I'm still trying to figure out the answer.
Of course being smart helps. Having good knowledge of algorithms, being able to optimize your code for time and space. That's what most interviews test.
But, at least at my internship, I've rarely had to code optimized solutions for space or time, so maybe I'm not qualified yet to conclude anything. But I have noticed traits of my co-workers that I admire and would like to emulate.
One of the interns I'm working with is one of those people who has a host of time-saving programs and techniques at his fingertips - I've never heard of Auto Hot Key before this internship, but it's a program that almost makes your mouse obsolete. You can type in any customized shortcut and open any program you want. Think of all the productivity gains! It's just one example of the many techniques he uses to save time and make navigating around a computer easier. I think that's one of the traits of a great programmer - constantly looking for ways to reduce tedious manual work, and generally making things easier.
Good people skills are much more important for programmers than most would think. More than almost any other profession, programmers get the rep for being introverted to the core and socially inept. But I honestly have not met this person yet. Ultimately, the job of a programmer is to produce good code - and maybe that's where the stereotypical programmer excels. But in the real world, people must work in a team and therefore must be tolerable at minimum to work with. My co-workers are more than tolerable - they are delightful, and it makes coming into work every day that much easier. They are always happy to help me, willing to point out my mistakes, and quick to give praise. You just want to work with people you like. You're happier when you work with people you like. And you don't want to let them down, so you really try your hardest.
And I guess - self-sacrifice? I've been doing a bit of that. Interns are specifically told to work 40 hours a week and go home after that. I know I put in more than 40 hours a week - I was the last intern put on my project so I've had a lot of catch-up to do - I came to work earlier than most and left later than most for the past two weeks. There's another intern I know - she stayed til 9 a couple nights last week to finish all of her work. I heard of another developer who once put in 120 hours a week during project development. That's 17 hours a day, including weekends! I heard that the project he was responsible for had only two bugs in production. While I feel like putting in 120 hours a week is extreme, and not a sustainable way to live, I admire that programmer's determination to pursue quality.
There's another developer I've heard of that everybody says is one of the best ones. He's very introverted, but on the few occasions I've had to talk to him he was very nice. Everyone says he's very nice. I want to know what makes him such a good developer, and if I'm missing any of those characteristics on my list I'll add them. I feel like, as a developer, I'm at the most malleable stage of my career and most receptive to new ideas - I'm still at the point where I'm in awe of how much everyone around me knows. I hope I never lose that.
edit // I feel like this will be a continuously growing list, and will update whenever I see fit. Seems like these edits are more geared towards being a good employee in general, but it relates to the theme of this post
7/1/2013 - I forgot to add "following directions" to my list earlier. I had an instance a couple weeks ago where I was downloading material for tutorials and I spent a day working with the wrong version and wondering why NOTHING was working. Although it was confusing because I was required to download an outdated version of the software, I was still told which version to download and I somehow missed it. I forced myself to stay later at the office and come in earlier all week - it wasn't overtime, it was making up for a mistake that I couldn't blame on anyone but myself. Just reading the directions would have saved me so much time and trouble. I've always had a hard time following tutorials because I always think I've got the idea and go off on my own - I often regret this impulsiveness and I'm learning to be patient and read every line thoroughly, as someone out there thought it was important enough to include.
7/2/2013 - I also forgot to add a technique that I use multiple times, every day. When asking a question or a favor, I've learned to always start it with, "Hey, when you get a free moment ... " instead of "Hey, help me right now". Of course the bluntness of the second is exaggerated but it illustrates my point - approaching someone directly for help often forces them to drop everything they are doing because they feel bad saying no, most times. I learned this at my previous part-time job at school - I noticed that when I phrased my questions differently my team lead was much more receptive to helping me. Indicating that you understand the other person's priorities - that your request for help comes AFTER the current task they are working on - seems much more respectful.
7/6/2013 - Self-commenting code and good variable names! I enjoyed this article - especially this sentence: "[Write-Only-Code (as opposed to Really Obvious Code)] is, effectively, a love letter between the coder and the computer - full of inside jokes and pet phrases that are meaningless to those not part of the relationship." I can say that when foraging through millions of files (not really but that's what it feels like), good variable names can make deciphering the madness a lot easier.
