Software Development and other (un)interesting things
How to be a “killer programmer”, Lesson 1
I sometimes hear the phrase “I want to be a killer programmer”, and one of the first thoughts that comes to mind is a character from some Dexter spin-off series about a software developer who, in their spare time, goes around killing people. This article is not about that kind of killer programmer, so if you’ve come here looking for tips on “going postal” because you feel under-appreciated writing second rate software for a third rate company that thinks “bug tracking” involves a microscope and a small handheld net, you might want to move along. On the other hand, if you stick around you might see that things aren’t as hopeless as you might think.
This is the first in a series of articles I’m writing, but I should highlight my own insecurity at this point and mention that I don’t think I qualify as a “killer programmer”. I’m not even sure what the definition might be; are they some kind of mythical being that always writes perfect code? One that maintains EBS (Evidence Based Scheduling) velocities of 1.0, and never has any bug reports assigned to them because their software is always perfect? Right. I’m going to tell you how to be like that. Sure.
Just in case the italicised sarcasm went unnoticed, I’m not going to tell you how to be the impossible being. Instead, I’m going to tell you a story about my past self, what’s changed since then, and what’s been learned along the way. I’m still young, so there isn’t much “past” to speak of, but here we go anyway.
Rewind nearly three years, and I was just finishing off my final year project at University. My degree course was called “Computer Video Games”, and ranged from art, through design, through programming, to project management; I specialised in programming. I heard a lot of backhanded comments about it “not being a real course” and how I “should have done Computer Science” if I wanted to be a programmer, but I persevered.
Nothing in the first two years of the course really prepared any of us for the sheer magnitude of work involved in the final year, and there were a lot of complaints made by some people about the workload being too much and that they couldn’t get it all done. We all had the same workload, and the team I was working with managed it just fine (granted we had an amazing project manager, who is now working in the games industry), so at the risk of being unpopular with those who couldn’t cope, I say this:
Degrees are hard. Especially relevant to the software/games industry, if you can’t handle the heat, get out of the kitchen. You’re taking a course to prepare you for working in one of the most stressful, competitive and fast paced industries out there, and you’re complaining about workload? If this complaint was directed at your manager at Software Comapny X who was trying to ship Product Y before Date Z, I’m pretty sure you’d soon be packing up your desk to make way for the new hire that gets things done.
I learnt in that year that when it comes to the crunch, you just have to do what needs to be done and get on with the work, which leads me to what I consider to be a very obvious lesson:
Lesson #1: Quality matters, but so do deadlines. Get things done well, and on time, and you’ll get noticed by the right people.
In my job I work very hard to make sure my software gets delivered on time, and that it works to specification. I did this at University too, it got me noticed by people with the right contacts, and I got a job.
How did you get noticed?
3 Responses to “How to be a “killer programmer”, Lesson 1”
Leave a Reply
You must be logged in to post a comment.