The personality of a programmer
Author: will | Filed under: comments, creativity, engineer, engineering, job search, personal information, programmingI’m not the type to fill in those “what type of X are you” surveys, but when Sean McNamara wrote about his programmer personality type I thought I’d give it a shot. The output is similar to the Myers-Briggs Personality Test but I think the questions are a little too simplistic.
Anyway here are the results of my programmer personality test.
Your programmer personality type is:
DLTB
You’re a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.
–Will here. The alternative to a doer is the planner. I will plan but sometimes a prototype is needed to make sure that you are doing the right thing. Personally I’d do after I make sure the requirements are in place. And that’s just the prototype that’s willing to be changed. I suspect I’m right on the edge of the two states in this case.
You like coding at a Low level.
You’re from the old school of programming and believe that you should have an intimate relationship with the computer. You don’t mind juggling registers around and spending hours getting a 5% performance increase in an algorithm.
– I’m comfortable with high level coding and scripting but that last 5% is a bit on the mark. There is an old quote which goes “Art is never finished, its just abandoned”. The same is almost true of software. The almost is because software has a “next version”. Getting something working out there is one if the basics of rapid prototyping. Technology changes, requirements change. Having said that, there is a point when a new feature shouldn’t go in, but become a new tool. Keep an eye on that.
You work best in a Team.
A good group is better than the sum of it’s parts. The only thing better than a genius programmer is a cohesive group of genius programmers.
– I like working with people. Solo works for me when I’m deep in a function, doing that 5%. The rest of the time I like to be able to bounce ideas. Software needn’t be lonely.
Besides, I do believe in code reviews. You tend to be too close to the code to see something is missing or wrong based on the reqs. Other eyes make sense. That way you can ensure the comments match the code if nothing else, see below.
You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We’re not writing on paper anymore so we can take up as much room as we need.
– This is a mix of a learned and an acquired taste. Write a piece of un-commented code. Leave it alone for six months (or six days). Then come back and look at it. Unless you’ve written very accurate function names and variable names, the code will take a while to sink in. Its better explaining in the code (as comments) what you want it to do, in case someone else thinks its meant to do different, and how it works. Its the team programming thing mixed with the big bus theory (which roughly goes as “Splat! Oh noes, that’s the only one who can fix the code”.) And remember to change the description if you change the functionality of the code.
Its also that if you are indispensable, you can’t be promoted.
If you are a coder, or a tech person who has to write at least one script, give the test a shot yourself.
