Top 3 non-tech skills for great software developers
Top three non-tech skills for outstanding software developers
In my article If I Could Teach Only One Thing To A Beginner Developer, I mentioned that I had done a few different types of interviews.
Initially, I wanted to get general suggestions about design patterns or coding principles. Perhaps I didn’t frame my question well. Apart from all the great technical-related suggestions, I also got a lot of non-technical advice, which is accidentally fantastic.
In this article, I’ll list the top three of these pieces of advice and try to describe them a bit more with my own experience. I hope they make sense to you and can help you to grow as an excellent software developer.
You can join my free 7-Day React Clean Code Challenge to learn the Think iterating principle (the top 1 skill in my mind for any serious developers to master)in action discussed below.
Deliver customer values, not the code
We developers are supposed to be good at coding and communicating with computers. To some extent, that’s true, but that’s not the whole picture. It might not be listed on the JD, but a developer must think out of the box — I mean, understand why we would implement a feature in the first place.
I’ve seen so many cases where a developer picked up a ticket from the backlog and straight jumped into the coding without even thinking about why we would do it, not to mention whether any other cheaper approaches can do the same with less effort.
For example, the user story said we want to show a fancy error message modal when an error occurs. Unfortunately, there isn’t such a UI element yet in your design system yet. So instead of importing @mui/material/Dialog from MUI directly, try to ask if a humble window.alert would work. Or how likely an error could happen, whether we should retry under the hood a couple of times first, etc.
For a developer, when you kick off a user story, you need to understand at least a few things before coding:
Who benefits from the story?
What value does that ticket add to them?
Are there any better alternatives?
Some may say it’s a business analyst’s job, but I can’t entirely agree. It’s everyone’s job to ensure the software we deliver does add value to the consumers.
Think iterating
Because of the nature of my work content as a consultant, I get the privilege to work with different teams, ranging from startup businesses to some big brands. One interesting thing I found from most developers is that they tend to over-thinking, over design even before they start any tangible prototype code.
Software is complicated. There are many cases to consider for a normal business process: what about error handling, network offline, retry timeout and slow internet connection etc.?
My advice would be: don’t try to solve all the problems at once. You can always start from the simple path and then iterate.
Let’s say you’re building a Todo application. You can start with the add item to the list path. Initially, you might only add the item to a local array and see it worked. Then you might do some styling on top of the initial version and then save the data to a remote server.
If you have several options, like showing a loading spinner when fetching, go with the simplest one (showing a text component <div>Loading...</div>, for example).
The most important thing here is that you first need the simplest prototype to iterate on. No error handling, edge cases, or difficult alternative paths at this stage. And eventually, you’ll have the whole thing.
If you want to learn how to do this in action, I have a free 7-Day React Clean Code Challenge that focuses on gradually building a Todos Application from scratch by iterating.
The power of small
Mighty oaks from little acorns grow.
As I mentioned in my article 4 Common Mistakes You Make in Refactoring, the most common misunderstanding about refactoring is to make too many changes in one go (that’s called restructuring, by the way).
Not only for refactorings, but the same rule applies everywhere in programming. I don’t think I can describe it better than my colleague Cam Jackson:
Break the big story down into neat little checklist items that can be ticked off one at a time. Don’t try to change everything all at once.
If the tests are red for more than a few minutes and you don’t know why, then you’ve bitten off too much. Revert back to a known good state and try again in even tinier baby steps…
The real power behind the small step is that you only have to focus/think on a simple thing for a short period of time. And that helps to build the momentum to keep going until you eventually achieve the big goal.
It’s linked to the previous one in a way, but Think Iterating is more about setting up a barely minimal end-to-end process to iterate. And this one is that you do it in small chunks at each following step.
Summary
This article results from my interviews with many colleagues at Thoughtworks (and some ex-Thoughtworkers). Shout out to all the people who contributed to it. I learnt so much from the process!
A few other pieces of good advice are on the list that few people are talking about (that doesn’t mean they are less important). I’ll try to distil some insights from them and share them with you later.
You can find the technical-related part of this suggestions to beginner developers series here, and please comment below if you have other good suggestions for newbie developers.
Top 3 non-tech skills for great software developers was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.