I want to preface this post with a statement: I don’t think I’m l33t (meaning an elite programmer for the less nerdy of us). Having previously worked at a Sydney software consultancy where I can assure you the standard of the young consultants was very high such that I felt constantly in the shadow of an incredible 16 year old prodigy, an organised “old-timer” who just knew how to get things done (and fast!), or the respected industry speaker and rule maker… So the question beckons, how do developer’s talents get recognised?
In any software development team with more than a few people, you’re almost guaranteed that your manager is no longer technical… They used to be, but by the very definition of management they’ve shifted focus onto broader topics such as staffing, team morale, project delivery, process management, financial risk mitigation, and project funding. So are they a good judge of your development skills? The way I see it is that they are looking to see if you can do some of the following:
- Have the ability to d3-l33t1fy your conversations (talk non-technical)
- Are seen as a teacher or mentor
- Are social with your management team
- Can communicate with the big picture in mind
- Can understand that development costs money, lots of it
- Follow change management, timesheeting, task tracking procedures
- Contribute to collaboration and knowledge sharing
- Estimate well
- Gain industry certifications
- (Cynically) Can spin when things go wrong (which we know will happen a lot!)
But how does this correlate with what makes a good developer from another developer’s point of view? Or even a software quality point of view?
Almost certainly developer’s opinions of other developers are influenced by the personal, creative, social and technical sides of software development. Perhaps including some of the following:
- Are social with your coworkers and make them feel happy at work – you enjoy a good laugh, are fun to be around, you don’t smell, and you can go to lunch or drinks together
- Can put time aside to help when you should
- We’ve all been super focused on our task at hand to find someone whom is trying to debug your code asking you a million questions which feel unreasonable, but really they’re not. You should help them… Don’t let them deplete their life-force.
- Document your code where necessary
- Write simple code that uses chosen frameworks to their best intentions
- They know when to fix vs. when to extend vs. when to roll your own
- They use inheritance and polymorphism well
- Truly understands all code that they produce and “write“
- Gets things done with a gist for how to do things better in the future
- Did you ever notice a good coder will often leave many TODO’s in their code?
- Has a broad knowledge of system components, technologies and frameworks
- Somewhat similar to a good architect in that regard
- Continually improving old code with fresh ideas
- Isn’t afraid to throw things out
- They have a good “code smell” for dud code and don’t mind re-engineering if need be
- Develops a quick familiarity with new technology rather than a deep understanding
The reason I bring these points up is that I recently was chatting with Dr Neil about MS certifications as a resume filler and then stumbled onto thoughts about whom is your best referee when going for a job… The answer is almost certainly the 360° profile including a manager (for the business smarts), coworkers or peers (for the developer smarts), and possibly system users or peers (for the common sense/usability smarts).
The other question we should ask ourselves once we’ve settled into a job is whether the way we see ourselves in our own careers is similar to that of our managers and coworkers… (Remember, you must consider it from their view point rather than your own). Is that a problem? Does that highlight some goals you could set yourself for the next year?
What do you respect in other’s programmer skills?