To kick off this blog, I think that I need to state the following:

I am not the best developer in the world.

I know a lot of the things that you need to learn in order to become a great developer, but just knowing these things doesn’t make it happen. Head knowledge is good, but that’s the easy part. Putting it all into practice… that’s what’s difficult. I'm still a work in progress!

So in order to become the best developer in the world you're going to have to ask yourself a pretty serious question:

"what level am I at?"

To work this out, you might compare yourself to a couple of job ads. If you start poking around the internet for software developer jobs, you’ll find things like this:


terrible job ad

Notice how they advertise "3 years XP"? Unlike other crafts, software development does not have a well-defined methodology for working out how good a programmer is. All we go by is “years of experience” which is a pretty bad methodology - you can sit on your bum for five years, not learn anything, and you're suddenly a mid-level developer. It doesn't really mean anything. Instead of years of experience, what we need to know is competency.

Have you seen the programmers competency matrix? It's a great list, but I feel like it's missing a bunch of things.

As an alternative I'd like to propose that as an industry we adopt the Guild system for determining the level of someone's skillset:


Apprentice -> Journeyman -> Master -> Grandmaster


Apprentice


An apprentice's job is to learn from the master. They're trying to learn the basics and spending a few years getting some experience under their belt. At the bare minimum, I would expect them to learn how to:

  • Write code that works
  • Use version control
  • Manually tests their code for invalid values
  • Write code that the customer needs, not what they ask for
  • Fix bugs in their own code and in other people's
  • Do basic UI design. Not graphic design, UI design
  • Implement global error handling across the application and have a consistent error handling approach
  • Logs info messages, warning messages, debug messages and errors consistently
  • Mitigate against all items in the Owasp Top Ten
  • Write code to unit test your other code
  • Follow coding standards so all code written is consistent
  • Do Effective Code Reviews Without the Pain and have your code periodically reviewed
  • Write code that doesn’t repeat itself


After being able to demonstrate those competencies to a certain level, the next steps would be...



Journeyman


  • Know the principles of data modelling - data is the foundation for your application. Get it wrong and you’re in trouble
  • Practice separation of concerns - each class should concern itself with one thing and do it well
  • Performance - understands typical performance problems and mitigate against them
  • Keep up to date with newer frameworks and libraries and know why and when to use them
  • Write reusable code - code written should be reusable by other developers on the team
  • Follow the YAGNI principle - don't over design the solution but only code what is needed at that point in time
  • Clean As You Go - fix up code as you implement new features or when bugs are fixed
  • Read other code - check out some larger open source projects
  • Write and use automated UI tests
  • Organise code - logically group/name files and folders so that things are easily found
  • Setup a CI server to checkout, build and test your application
  • Automate deployment
  • Log issues, bugs & features all in the one place
  • Writes down important documentation (algorithms, configuration) things that other people need to know
  • Mock up new features before coding them
  • Implement analytics so that you can see what’s going on in your app
  • Write applications that are accessible

If you can do most of the above steps you're already doing very well. But will all of this knowledge help you deliver a project on time and in budget? Probably not. They'll make you a super efficient coder, but they won't make you an awesome employee.

What you need to learn is all the other things that "aren't your job". Were you hired to do these things? Probably not. Will you be an awesome programmer if you do them? Absolutely.



Master


  • Know how to effectively push back on management and head off problems before they become major issues
  • Lead other programmers and organise a team to be more effective
  • Project planning - come up with a project plan and stick to it.
  • Negotiating - learn the art of negotiating and how to trade off features for time
  • ROI - understand return on investment and why you’re doing the project, and what affects it
  • Estimating - estimate (relative!) time taken to implement new features
  • Requirements - clarify and discover new user requirements
  • Meetings - run meetings to get a desired outcome
  • Testing - organise a full end to end test of the application to ensure it does what it should
  • Perform user demos of new features as they are implemented
  • SDLC’s - understands the pros and cons of different SDLC’s and can implement change to gain efficiencies
  • Big Picture - understands the big picture and can communicate it with anyone at their level


Well, now we are getting somewhere. But the issue with the above list is that it's mostly technical. If you can't communicate with your boss and listen to your users then you are never going to be the best developer in the world. What other skills do you need to cultivate?


Grandmaster


  • Adapt - are you able to learn new skills, new technology and adapt? Is your way the only right way of doing things? Are you stuck in your technology world and unwilling to consider or learn something else? If so then you haven't mastered the art of adapting yet.
  • Listening - can you actively listen to users and management? Can you repeat back to them what their issues and concerns are and have them confirm that you understand them?
  • Inception - can bring new ideas to management and get them up and running?
  • Arguing - do you know the pitfalls of arguing and instead know how to persuade?
  • Motivation - do you understand people’s motivations?
  • Respect - do you show people their due respect even before they have earnt it?
  • Admitting wrongs - able to admit when you're wrong?
  • Friendly - are you rude, surly or unapproachable?
  • Caring - do you ask about other people are?
  • Psychology - do you understands different personality profiles and know how to communicate with them?
  • Stereotype Fighter - do you know the “software developer” stereotype and how to work with it?
  • Communication - can you communicate with your boss, your users, and non technical staff effectively?


Hopefully we can all agree that learning the above skills will make you a better developer :)

A resource that I strongly recommend is the masterful How to win friends and influence people.


Lachlan’s handy hints

While we're on the topic, here's a few bullet points that I wish someone had told me 15 years ago when I was starting out.

  • Use deodorant. Deodorant is like a firewall. It needs to be on ALL THE TIME.
  • Don't be a "negative Nellie". When a customer asks you to do something, don't immediately say no. You could say "yes, but it'll take 6 weeks". If this isn't enough time, show the timeline, budget or manpower and explain what they can do to get it changed
  • Email - the first line of the email is the most important
  • Doesn’t look bored when bored (apparently this is a crime)
  • Dress good - don’t look like a slob
  • Don’t just talk about work
  • Don’t just talk about computer games
  • Go to lunch/coffee/beer with people and ask how they are



ARGH

Yes, this is a pretty big list. Realistically you’re only going to be able to work on one or two things per month. If you’re brave, ask your friends what your weaknesses are… and ask them to tell you nicely :) They are the ones you want to work on!

References