So I’m not talking about a great computer scientist here - when I say software developer I don’t mean someone who is vying for the ACM Turing Award or who wants Knuth to write them a check for finding a bug; I mean someone who wants to crank out great code, consistently, in a team of software developers. And I’m definitely not writing this to talk up myself - this is just a post about what I’ve noticed about great people who I have worked with.
(this is a linked image, find the whole swagger of these Knuth checks here)
What I see most commonly is that the habits which make someone a great developer have nothing really to do with software - they’re just basic traits which can be developed if you focus on them. These are explained down below.
Now of course there will be exceptions to the rule (and I’m cross posting this on HN so I’m prepared for blowback) but having worked in a bunch of different development teams with a bunch of different working styles I can confirm that some traits consistently shine through as being positive with respect to cranking out code. Of course this list is not exhaustive but without further ado:
Look at how a great chef works: methodically laid out tools, all in their correct place. If you’ve had the pleasure of dining at a Thomas Keller restaurant you’ll notice they’re spectacularly clean. In his book, Keller sums up the basis of this cleanliness like this:
Good organization is all about setting yourself up to succeed. It means getting rid of anything that would interfere with the process of making a recipe or preparing an entire meal. If you are in the middle of preparation, you don’t want to stop and find the proper pot, or dig around in the cupboard for an ingredient: that opens you up to distractions and errors…
Being the same way with your workspace in software develpment is much the same.
- Lay out projects so other people can easily interpret their structure.
- Write code in a manner which is uncluttered so you and your collaborators (both present and future) can understand what the code is doing.
- Make nice git commits so someone can look at your repo and pick up your project and start working right away.
- Consider whether clutter in your physical workspace (desk etc) is hampering your workflow.
The thing is that if you’re clean, you will have to think less to do the same amount of work. This frees up your brain cycles for making better software.
(Keller has even consulted on the occasional kitchen movie)
Being ahead of the 8 ball (preparation):
Procrastination is a bitch. Some sicko decided when coming up with the design for the human brain that it would be a great idea for us to enjoy putting stuff off. Don’t. The best people I have worked with have jumped way on top of stuff, way in advance. Have a new SDK for your development platform coming out? Cut a git branch which is built against the beta. New devices just announced by Apple? Start designing for them now. You’ll see time and time again the same people who have fallen behind are paying the price by not having acted in advance of coming requirements. Don’t be one of them - do stuff today so you can be prepared tomorrow.
Have you been in this situation? A product manager comes to you and says “We need this incredible API-inversion-of-control-augmented-reality-dependency-injection-animation feature”. Great software developers I’ve worked with don’t blindly just do whatever someone asks - they ask why it should be done that way and whether there might be another way which it can be done which is better for everyone. Assholes push back just for the sake of pushing back. Great developers push back because they think it can be done better which will be of benefit to everyone in the long run.
Being able to talk to people goes a long way in this gig. We’ve all seen the person who locks themselves away in a corner doing their own thing and not being responsive to the team as a whole. If you want to crank out good software you need to communicate. Answer your emails (hopefully you don’t get many though as email is a terrible communication method - more on that in another post). Get on Slack (or HipChat, or Jabber, or Google Hangouts or really any kind of real time collaboration tool). It’s really not the most important thing in the world that you can invert a binary tree - it’s better that you don’t take 2 days to get back to someone when they have a pressing question about a defect in PROD. Be contactable. Be communicative.
Happily reusing code (letting someone else do the work):
Now I’m not advocating blindly dropping 3rd party code into your project like it’s 1999 (I once cracked open the project on a job only to learn their app was based around an ancient iOS library called three20) and having been forced to use the Wayback machine to access library documentation before I can assure you I’ve seen both sides to the 3rd party code equation. But the people I see who really get stuff done don’t have huge egos and really don’t want to reinvent the wheel. They’ll use external dependencies where it’s useful (and not detrimental to the longevity of the project) and they’ll focus on moving a product out the door rather than coming up with their own next best networking library extensions or Monad binding library.
So that’s my take. Like I said, there are exceptions to every rule and of course this is neither an exhaustive nor authoritative list. But it’s just something to think about, as I guarantee that if you adopt these ideas, you will become a more valuable member of your software development team. And that means you will ship more code!