How to be a better developer

Head over to the SilverStripe team page and take a look at Hamish Friedlander, the SilverStripe CTO. Now take a look at me, then look back to Hamish, then back to me. What do you see? I think you will see that I am not nearly as smart as Hamish.

You might be thinking: “No way! Dr. Seidenberg, you have a PhD, you must be supremely smart!” But that’s not true, I assure you, I can’t match Hamish’s intelligence, not even close. But that’s okay. Why? Well, that’s what this blog post is about.

While it is very difficult to increase raw intelligence. There is much more to being a good developer (and getting a PhD) than being smart. So, for us lesser mortals, here are some tips for becoming a better developer.

Being a better developer is about four things:

1. Qualities
2. Attitude
3. Techniques
4. Communication

1. Qualities

Humility

C.S. Lewis once said “humility is not thinking less of yourself, it is thinking of yourself less”. A great developer will act for the good of the software, not their own ego. The best ideas and the best code need to win, regardless of their origin. A great developer will listen to the even the most quiet intern who has a great idea for improving the project. They will say: “Oh, great point! I didn't think of that. Let's do as you suggest.”

Grit
After 4.5 years of researching Semantic Web ontologies, I was ready to quit. But I didn’t. I had some grit. Grit is the ability to pursue long-term goals despite numerous struggles and setbacks. I had enough grit, enough tenacity, perseverance and drive to push through and finish the PhD.

A great developer has lots of grit. You might try this self-test to see how gritty you are. Learn more about grit on this TED talk.

Enthusiasm
“Nothing great was ever achieved without enthusiasm” - Ralph Waldo Emerson

Enthusiasm is necessary. No one likes a mopping developer who complains about everything. That brings down everyone’s morale. A great developer likes technology and finds programming fun, interesting and rewarding. If you are currently not overly enthusiastic, fake it till you make it. Soon you and the rest of your team will be genuinely bouncing off the walls with enthusiasm.

2. Attitude

Desire
The first step in any action is desire. Without desire nothing happens. Ask yourself: do you actually want to be a better developer? You might be surprised that for some people the answer is “no”. Some developers are content with their current skill level. For some people, it’s enough to have a stable job, do adequate work, support their family and pay the bills. That’s a perfectly reasonable life decision for someone to make. But that’s not who this blog post is for. This post is for someone who desires to be supremely awesome at their job.

However, say, for example, you don’t have the desire to become a super-developer, but you wish you did. Congratulations! That kind of recursive meta-desire is both a good first step and a very cool concept in and of itself. The way to develop desire is to associate with others who have a strong desire already. So, find some developers who really care about improving themselves, make friends and hang out with them. Soon their infectious desire will rub off on you.

Appreciation
A good developer appreciates beautiful code. Let me give you an example. Take a look at this code sample:

Can you guess what the code is? It’s the Quicksort algorithm implemented in Javascript. This algorithm was developed by Sir Tony Hoare in 1959 and is still in use today. Just look at that code. It’s beautiful. It’s poetry. So clever, clean, and concise. I love it!

A good developer must genuinely appreciate excellent code. To be truly good at programming you need to appreciate good coding when you see it - just like a good musician naturally appreciates good music.

Ask for help
There is no shame in asking for help. Some lone-wolf developers would rather hack away at a problem for days, rather than admitting that they could use some help. Don’t be that person. Ask for help. Sometimes a second set of eyes will point out the obvious to you. Sometimes just explaining your thinking to another person will give you the critical insight. Sometimes someone doing right kind of socratic questioning on you will make you think of something you hadn’t previously considered. Great developers love asking for help.

Ownership
The difference between a senior developer and an intermediate developer is that the senior developer takes ownership of the software they are creating. An intermediate developer will do a good job working on their assigned task, competently implementing all the requirements. A senior developer, however, will discover five additional requirements the person writing the requirements document hadn’t even considered and make sure those are done, too. The senior developer takes ownership of the software.

3. Techniques

Memory management
No, not the computer’s memory. The developer’s memory. Humans can only hold 5-9 concepts in their short term memory at one time. That is an extremely limited amount of RAM we have to work with. So, while programming, a good developer always uses abstraction and interfaces to make it possible for them to understand what one aspect of the application is doing without having to remember the whole thing. A good developer constantly juggles layers of information they hold in their memory while programming. Sometimes focusing-in on the details of a particular method, other times zooming out to arrange software components at a high level.

I would also recommend adding copious amounts of comments to remind oneself what one was thinking when one wrote a particular class or method. That makes zooming-in so much quicker.

Plan
It’s so tempting to dive in and start coding right away. Don’t do it! Any programming task can benefit from a bit of up-front thought. Maybe draw a little diagram, maybe sketch something out on a whiteboard, maybe write some high-level pseudo-code, maybe just think about your approach for an hour or two, whatever you do, do some planning.

ToDo is a NoNo
Have you written a comment something like this before?

//TODO: This is kind-of a hack, it might fail in a way that is unlikely to happen, but will totally break production when it does, and it will be impossible to diagnose. We should refactor this sometime.

Don’t ever do this. No one ever goes back through all the random todo comments in a codebase. I find there are two reasons why developers add todo comments:

1. They are lazy and can’t be bothered to implement something properly.
2. Doing something properly will genuinely take too long at the current stage of the project.

If you find yourself in scenario #1: easy, don’t be lazy! With scenario #2: don’t use a todo that no one will remember. Instead, use your project management software to write a task and make sure the Project Manager knows about it and why it is important, so they can prioritise the task appropriately.

Take a break
There is some false bravado in working long hours, hacking away at a problem. But the brain works in mysterious ways. Our subconscious is often much better at solving a problem without our conscious awareness, certainly better than our haze of sleep-deprived, caffeine-fueled forced-thinking.  It happens to me all the time: I’m faced with an impossible problem, spend the whole day working on it, get nowhere; then, after a good night’s sleep, I solve the problem in 10-minutes flat.

Sometimes the most productive thing you can do is to stop working. A good developer will know themselves well enough to know when they should work and when they should relax.

4. Communication

Teamwork
The productivity of the team is more important than one’s own productivity. A great developer will gladly spend the entire day helping team members who are stuck, even if it means they get nothing done that day themselves. This highly scientific formula explains it: (One developer working + five developers stuck) < (one developer getting nothing done + five developers working).

Talk
Talking in-person is a great way to communicate. Talking in-person allows people to communicate rapidly and use non-visual cues to focus on the exact knowledge that needs to be communicated.

Introverted developers like to focus on their computer, maybe occasionally using instant messaging, or email to communicate. But written communication is slow and easy to misunderstand. A good developer will know when it’s time to stand up, walk three meters to the next desk and talk to their fellow developers.

Pair program
Awesome developers have a secret superpower. It’s a power one level up from the awesome “talking in-person” superpower. Pair programming is this power.

Pair programming is something all developers should do when faced with a difficult programming challenge. Two developers working together can solve a difficult problem much quicker and much better than one developer working alone. Two developers can talk with each other, sharing understanding and vocalising their thoughts, they can keep each other focused on the task at hand, giving the task far more concentrated attention than a single developer could bring to bear, and they can constantly be checking each other’s work for bugs or oversights. Finally, at the end of the endeavour, both developers have a detailed understanding of the solution. It’s also just plain fun. So, be a great developer, use the pair programming superpower.

Get in the zone
Watch a Starcraft tournament sometime. Starcraft is a serious sport with the top players (all Korean) winning hundreds of thousands of dollars in prize money and sponsorships. As you watch a Starcraft game occasionally the camera will show the players’ faces. The players are ultra-focused on the game. They are some of the most concentrated people you will ever see in your life. They are in the zone.

If you have experienced the zone, then you know it is blissfully absorbing. Your attention is completely taken away from other things. Your mind detaches from your body. You are fully in the moment, not conscious of the body, outside reality, or the passage of time. The zone produces an inner clarity where the activity you are doing becomes its own reward and you feel fantastic.

Needless to say, programming in the zone is super-productive. The best developers try to get into the zone as often as possible, and a long time period with no distractions is a prerequisite for entering into the zone.

So, if you want to enter the zone, arrange your day so all the meetings are clustered together and you have a big chunk of uninterrupted time. Also, use an obvious visual cue, like wearing big headphones, and explain to everyone around that it means: “if you value your life, don’t interrupt me unless something is on fire”. Then relax and enjoy your amazing zone-level programming productivity.

Conclusion

You don’t need Hamish-level intellect to be a good developer. Just develop excellent qualities, adopt the right attitude, practice good development techniques and communicate well; and soon you’ll be developing with the best of them. Good luck!