10 tips to become a better programmer

 

 

I have been lucky enough to be around many great programmers in many teams. I started seeing patterns in how they work to be better. It's not about taking great leaps, but instead and what I love most, is people that work every day to become a little better than the day before. I'm sure I can make a list that goes beyond 10, but this is a good start. In no particular order:

 

1. Educate yourself

Spend time learning new tricks. Just getting better at what you already know and do is not good enough. What you don't know is more important than what you know. Read books on languages and frameworks (online, not the paper ones, they age quickly). Read them cover to cover, not as a manual (Use it as a manual afterwards, when you know where to look). I know only 3 programmers that do this (they are all on my team). Get yourself on that list.

 

Listen to podcasts, watch the endless stream of recordings that are available from conferences around the world (it saves you a long distance flight and you help save planet earth while at it). Learn new languages, not to become an expert per se, but it will teach you new techniques, new patterns, new ways of thinking that you might be able to apply in the language that you work in day-to-day.

 

Show and tells are my favorite way to learn (and share for that matter). They are the most condensed form of learning. If they turn out to be boring or useless, they are short enough to take the loss.

 

Another great idea: on Friday, around 3 o'clock in the afternoon:

• Hook up one of the devs in your team / company / whatever to a big screen
• Grab a beer
• Watch him work

 

This is the same fun as watching gameplay videos (which I don't get, but I'm trying to reach the younger audience here).

My point is, don't stay where you are. Always keep moving. Emerge from the chrysalis as a new butterfly, if you will.

 

2. Analyze and design

Programmers program. That's what they do. But that doesn't mean that jumping into programming is the first step. Don't just run off to start doing what you are assigned to do. Think about it a bit more before you start. Analysis and design are skipped too often. 

 

I can recount more than a few stories where even the tiniest bit of up-front thinking would have saved a tremendous amount of time, money and frustration. If only people would have taken the time to 1) understand the problem, and 2) assess the proposed solution to the problem [1]. That's the simple definition of analysis and design.

 

First: listen, read, learn. Ponder about possible solutions, pick one, let it rest, evaluate, ditch it, try again. You will know when you are done. Some ideas or solutions age well, while others fade away over the course of a few days.

 

Here's a technique that I saw used once (and note to self, I will start using more): When you are debating possible solutions, (this works best when combined with #10 Work as a team) and you are in the heat of the moment defending the greatest idea ever (because it's your idea), switch roles. Let someone else defend your idea and start shooting holes in it. Very refreshing and very effective. 

 

3. Leave a trace

Maybe it's just me, but when I read code from a year ago or sometimes just a few days I forgot about the why. It may still look like great code, but there was probably a reason why it ended up like this. There was a reason to pick a certain approach, perhaps a limiting factor or a constraint of some kind. You can't read that from your code. Leave a trace, for yourself and others. There's more than a few excellent ways to do that:

• short comments in your code;
• elaborate comment sections in your code;
• additional notes in the issue tracker that can be traced back from a commit;
• an elaborate commit message in your vcs of choice;
• documentation in a wiki;
• architectural decision records (adr) [2].

 

I'm gaining experience with adr's lately and I'm liking it. It's markdown, it's close to your source code, easy to read and to write.

 

Leaving a trace in your code may take a bit of time and effort, but we all know it's the breadcrumbs that saved Hansel and Gretel.

 

4. Embrace technical debt

What? Technical debt is bad, isn't it? Always!

 

Well, yes and no. Technical debt is a healthy muscle strain for your work. It has to be slightly painful, or it might be a sign that you're not going fast enough. Work, learn, improve and maintain, but don't polish. Try to go faster without injury. Take this blog for example. If you count the duplicates of what I'm saying, you can probably condense this list. Don't try to be perfect.

 

Try to balance between going fast enough and delivering high-quality work (maybe not perfect, but the stuff that you won't be too ashamed of in a year or two). It's all about balance. A balance between delivering new functionality and doing maintenance on the older bits. A balance between applying your knowledge of the latest and greatest and sticking with a proven design. 

 

5. Get to know your tooling

It does not matter too much which tooling you use, as long as you know it by heart. Learn shortcuts, read release notes, upgrade to the latest version. Maintain the knowledge of your tooling. And oh, combine this with #7 Peer Review and #10 Work as a team and you will reach great heights.

 

If I had to list a few tools that are essential and you should know by heart, it would be an espresso machine, vim, and regular expressions :-). But that's my list. Pick your own.

 

6. Get into the habit of shipping

No matter how good you are, if you don't ship, you don't add value. I have seen brilliant coders gold plate their pet projects. The code got better and better until it was too good and too late. So get into the habit of shipping early and shipping often. Here's my 3D model for this: derisk, deploy, deliver.

 

1) Derisk: get all the risky stuff out of the way really early in your task at hand. By now you must know how much time there is left to finish your work.

 

2) Deploy: shortly after you want to get the first version of what you are crafting outside the safe zone of your laptop. Is it working outside your bubble? Great!

3) Deliver: finish it and deliver.

 

And then?  Derisk, deploy, deliver, again.

 

7. Peer Review

I am not the biggest fan of peer/pair programming. There are arguably good arguments to do it and for some, it might be the best thing ever. For me, not so much. But we can scale it down and take the good parts of it: spend time reviewing your code with someone else. And not just via a pull request. Sit down next to someone else, preferably someone that is better than you and listen. Argue? Maybe. But listen. And learn.

 

8. Improve your soft skills

Develop habits for working well with others. Treat development as a social activity. This is very remote for a large part of the developer community. Some programmers are really introverted. This happens, but try to work on it. There are lots of books, training programs, online courses, etc to help you to improve these skills. There is also your team. They are really close to you and they really want to help.

 

A bigger problem is programmers that are very hard-headed. This might not be so easy to overcome. If it's you... change. Be open to criticism and suggestions. Unlearn the word 'but...'. Decision-making should be about more than your personal opinion and preferences.

 

In general:

• Learn to show empathy. Start with something positive now and then
• Communicate clearly, but most important: listen
• Sometimes you have to agree to disagree, but stick to the decisions that you make as a team
• Be approachable and helpful
• Apologize when you mess something up and take responsibility for it

 

In general, taking responsibility for your own actions is a good habit to develop. If not you, who else will take it?

 

9. Take time off

Are you wondering what took me the longest to learn? It's taking time off. I'm not there yet, but I have great people around me that remind me when I need it. There is no way that you can stay productive when you keep going and going. Work hard, but rest well afterwards. All-nighters are not fine, they are bad for your health and bad for your code. Only really devastating production outages could warrant for a late night job, but even then... Also, when you go on vacation, don't read emails or watch the endless stream of conversations your team will always have. Be gone. If it's really necessary that you are needed in certain events, make the agreement that you will be contacted.

 

This not only goes for outside your work, but also in your work. Rich Hickey's video that I referenced before also talks about hammock time, which is highly recommended [2]. The best example I have seen was a team that carefully looked ahead in its road map and started planning hammock time sessions long before the start of the actual work. Together with #2 Analyse and Design, this results in thoughtful and elegantly simple solutions. 

 

10. Know when you are done

Only once in my life have I seen a programmer get up from behind their desk and say: it's done. I'm going home. It was not even the end of the workday!

 

We think we are never done. There's always room for improvement, for better performance, nicer code. Add a little documentation here, sprinkle a little love there. Write one more test. Maybe add that little feature that we think our users will appreciate. I call this anti-pattern: "Season season season...". Too much salt, people! It will leave a bad taste no matter what: You spend too much time on your project and you are losing money on it. Or, you end up with all these nice little extra's, but now you have to maintain them.

 

It's good to know when you are done. Your project must have a definition of done, your sprint must have a definition of done. The issue that you are working on must have a definition of done.

 

You must ask your team members during stand-up: "when is it done?" Or, even better, don't ask when, but ask "what defines done for this thing you are working on?" If you don't get a swift answer, somebody is wasting time: either his/her time, the team's time, or the customer's time.

So get into the habit of thinking about what it means to be done with something. Always take the shortest path to your goal, be effective and efficient. But don't take shortcuts, don't dilute your beliefs, quality or values.

 

11. Work as a team

Underpromise, overdeliver (that's 12 actually...). I can't help but adding this. In this blog, you have seen 'team' mentioned more than once. You are not alone. 

 

All of the above works better if done with / in a team. Did you ship? More fun to celebrate as a team! Analysis and design are done better as a team than by yourself. A team becomes more than just a collection of people when a strong sense of mutual commitment creates synergy, thus generating performance greater than the sum of the performance of its individual members [3]. Where I see synergy, I also read energy. A good team is full of energy and fuels its individual members. A team buzzes like a beehive, there is always something going on. What should be going on? Check the list above.

 

If you are on the right team, you don't want to win by yourself, you want to be better as a team.

 

Works cited:

1 https://youtu.be/f84n5oFoZBc?t=378 [Accessed May. 22, 2018]

2 https://adr.github.io/ [Accessed May 12, 2018]

3  http://www.businessdictionary.com/definition/team.html [Accessed Apr. 18, 2018]

Did you like this blog, but want a better / different version? I enjoyed https://jlongster.com/How-I-Became-Better-Programmer a lot.

If you think that these 10 tips are a good start, I suggest reading https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/ (I don't necessarily agree with all of them, but it's a nice read)