What I learned in 2017 about writing good software
I started my career as a software developer with ThoughtWorks in 2017. I worked with and learned from some super awesome folks, and I’ve learnt several lessons have helped me grow as a software developer and human being.
I figured I’d be selfish if I kept this all to myself, so I’ve listed the key lessons I’ve learnt in 2 blog posts:
- Part 1: What I learned about writing good software (you’re reading it now)
- Part 2: What I learned about learning (here)
Many great books have been written on writing good software, and what do I have to add that is not just an arbitrary selection of lessons from these books? Answer: it depends on who’s reading this. For folks who are steeped in the ways of agile/DevOps, you can probably skip this article. Otherwise, I think this article summarizes several key principles in agile and DevOps, and I’ve listed some resources/books/videos as pointers if you’d like to explore further.
Lesson 1: Feedback is the secret to good software
Feedback can come in many forms — a failing test, a red build, user feedback, production issues, etc. All these things tell us that some code we’ve written is not working as we had expected, and it prompts us to do something about it. The shorter the feedback cycle, the better. If I change a line of code, I immediately want to find out whether it works, and not when it has reached production.
When we develop a feature, it’s much better to do user testing first to get feedback on how users would find such a feature (is it useful? is it confusing? do they care?), than to spend days and weeks on it only to find out that the users hate it (Someone once said “the final form of hate is indifference.”)
Another practice that I find tremendously useful is story kickoffs. Before we pick up any stories, a dev pair would grab any available teammate and a client dev or business user and go through the story — what it’s about, what it should (not) cover, what’s (not) needed, and so on. It’s much better to bring this feedback forward, rather than to find out that the client didn’t actually need this feature or want it this way after spending hours and days on it.
(The DevOps Handbook goes into much richer detail on feedback cycles and I encourage you to read it if you haven’t.)
Lesson 2: Build an agile and DevOps culture
In 2017, I learnt that innovation and differentiation is not about how good an idea is, but about how fast we can take an idea from paper to production. This is done not through one fell swoop, but through iterative development and validation, and agile and DevOps gives us several principles, practices and tools to achieve this. (wait — what is agile? what is DevOps?)
I like how Josh Kerievsky summarizes agile in 4 principles:
- Make people awesome
- Make safety a prerequisite
- Experiment and learn rapidly
- Deliver value continuously
Just be wary of Agile with the big A. A tell-tale sign of this is rituals — standups, sprints, retros — but still the team is not delivering value continuously in a safe environment.
Lesson 3: Do one thing at a time
When I’m programming, my biggest enemy is overhead. Overhead can come in many forms — multiple tabs in my code editor or web browser, too many uncommitted changes, multiple (unwritten) tech tasks in a story, my buzzing phone, etc. Whatever we were doing is now n times harder because our working memory has been reduced.
There are things we can do to reduce overhead: close unused tabs, write down tech tasks, separate tasks into another story to be addressed at another time, don’t add functionality and refactor at the same time, make small commits, don’t be distracted by social media, and so on.
Lesson 4: Ask yourself, “what would this give us?”
From time to time in our everyday problem-solving, I would encounter some problem and I’d talk to my team and describe some code that we can write or some tool that we can use. I’d describe how we can do it, what are some potential difficulties, and so on. One of the devs on my team would always ask us, “what would this (solution) give us?” I sometimes find myself eventually realising: not much. And this would save us hours and days of unnecessary effort.
Moral of the story is — it’s easy for us to get detracted by yak-shaving and solve lots of fun technical problems that don’t actually create any value for our users. Before writing any code, we should think (i) what are we trying to solve? (ii) what value does this create? (iii) what value does this really create? (iv) do we have to shave this yak?
Lesson 5: Know your tools
A carpenter cannot be effective without a set of well-maintained and well-understood tools.
This was one of my hardest lessons learned. My code editor (IntelliJ) wasn’t properly configured and I couldn’t run unit tests using the editor, so I would always use our shell script for running tests. It took much longer because I had to switch windows, scroll through bash history to locate the right command, and when test(s) failed, I couldn’t go to the failing line in one click — a feature provided by the code editor. I procrastinated and sat on it for several weeks, and when I finally configured it properly (it took just 20 minutes), coding was much easier and faster, and I had less overhead to deal with.
The lesson I learnt is — Investing some time to get/know the right tool for the job will make us exponentially more productive. If you have a pain point, invest 10–20 minutes to find ways to address it so that you can focus on creating value.
Lesson 6: Read
Books let us stand on the shoulder of giants. I’ve never been to a culinary school but I’ll bet that the students there would be training with recipes and books rather than freestyling/reinventing whatever they were asked to serve.
Here are the books that I’ve read / half-read / 10%-read which I found extremely useful:
- DevOps Handbook
- Continuous Delivery
- Refactoring to Patterns
- Head First Design Patterns
- Clean Code
- The Pragmatic Programmer
- The Passionate Programmer
- 97 Things Every Programmer Should Know
- Hands-on Machine Learning (if you’re into machine learning).
Books that I want to start in 2018:
Conclusion
I hope these 6 lessons have been / will be useful for you. If you have any thoughts or comments, please leave them below! I’ll be happy to hear your advice/tips/techniques on writing good software.
If you enjoyed this article, check out my other post (“what I learned about learning”)!
Special thanks to Seth, Will, Jon and Jon for giving me feedback on these posts!
