Healthy Software Development

Reading Time: 5 minutes

As developers we spend a lot of time in front of screens solving problems and coding our fingers to the bone. I personally have spent years tapping away for my career. As I have gained more experience, there are things I have introduced which have led to better software development. Now, I suppose this is a bit of a continuation to this article. I suggest you check that out first.

#1 Put the keyboard away

When you’re faced with writing code it’s all too tempting to just dive straight in and start writing code. For small tasks this is a perfectly appropriate strategy. For larger features and whole software systems however, you need to take a step back, put the keyboard away and start with pen and paper or a whiteboard.

Solve your problem methodically and think carefully about how that will impact future software development. This pen and paper solution will save a lot of time in the long run fixing problems caused by lack of thought in the beginning. You end up with a better structure. You can also take the overall codebase into consideration.

#2 Different stacks solve different problems

Some people consider themselves an <Insert Language Here> developer. At their heart most high level programming languages are birds of a feather. They mainly have syntax differentiating them. That is perhaps an oversimplification, but the point is this. You should not try to solve every problem in a specific stack just because you have experience with it.

Different languages, databases, distros and load balancers all have their own advantages. It’s worth your time as a developer to understand what these advantages are and how you can use them to solve a problem. Especially given that languages with specific use cases will also tend to have libraries that could solve your problem quicker.

“But too many stacks will slow down software development because of context switching!” I hear you say. Yes, that’s indeed possible but if you have a NODEJS team trying to do data science then a service in Python or R just makes sense. It is important in these circumstances to write decent documentation on the project and especially marking certain parts of the project that are likely to need changes over time.

This is not to say however, if your given programming language is perfectly capable of a particular task with no great disadvantage that you shouldn’t use it. If the gains are minor then it really isn’t worth upsetting your ecosystem. Striking a balance is key here.

#3 Practice programming

As a programmer like being a musician or an athlete, you must practice your craft. Whether that be by working on passion projects or solving problems online. You must keep your skills sharp through whatever means you see fit.

There is actually a very good (albeit old) blog about this very subject called: codekata.com I thoroughly recommend you run through some exercises writing code for the sake of writing code.

I’m not going to put any specific algorithm site here but you can find many of them online.

#4 The 20 minute rule

The 20 minute rule states that after you have spent 20 minutes on a problem your thinking is stale and you need to change something. In order to change the circumstance maybe you need a walk, coffee or to grab a fellow developer.

If you think your problem is far too complex to solve in 20 minutes, split it down into smaller problems. That old proverb “How do you eat an Elephant?” the answer is one bite at a time.

I have been using this rule for a very long time and it has never let me down.

#5 There are 3124 ways of doing anything

The first programming book had this as the first sentence and I never forgot it. Now of course this is nonsense but it’s actually about thinking positively about problem solving. When one solution doesn’t work there’s 3123 solutions left and I can guarantee you’ll never get close to 0.

Being positive and proactive about problem solving is always the mindset you want to aim for. Being stressed and anxious are the enemy of logic.

#6 Do things other than software development

Life is more than just a screen and there are things adjacent to programming that can still improve your skills. Any strategy game, board game or otherwise will help keep your cognition up to scratch. Bouldering is a very physical and mental sport that requires a lot of problem solving to do effectively.

It’s proven exercise and a good diet is good for your mental health and your cognitive function. Programmers are sedentary for most of the day so getting out and about is just generally good advice even if it’s just for a walk.

#7 Ergonomic Equipment

Bearing in mind we are sitting at a desk for 6-10 hours a day, the equipment we use is so important. Using an ergonomic keyboard and mouse will help reduce joint pain and your risk of RSI. Your chair and monitor angle is also important for your back and neck. There are articles like this that give advice on specific ergonomics that will help you long term.

#8 Good code review practice

Now this could be an article on its own but I feel it’s an important part of healthy software development. The point of this is to ensure a clean code base for all and add accountability. This is not an opportunity to put down developers and make them feel bad, it is a learning experience for the coder and the reviewer.

What makes a good code review?

A good review is not a litany of comments byte shedding over code that really doesn’t matter. Instead, a review should be well detailed comments explaining good practice (links help). This is to educate the programmer and help them stick to good practice. We all come from a range of backgrounds but making sure code sticks to SOLID & GRASP principles is important for codebase longevity. Mood up has a great article on code review etiquette. I recommend you check it out here (They also have memes).

Documentation, code readability and correct tests are also really good review points for a pull request. If you have specific company code practices/styles then these should be addressed via a linter in the CI/CD pipeline.

Advice for pull request submission
Now as a programmer if you get a pull request with lots of comments, it’s important that you don’t feel discouraged. Assuming the comments are fair then you need to take the criticism on board. It’s not about you, it’s about the code. When you contribute code to a repository it is no longer your code and it is the team’s responsibility to maintain it.

Now let’s talk architecture. If you follow specific principles such as DDD or TDD. You need to make sure as a senior/lead that the other developers are able to understand the requirements of those practices in the onboarding process. If you’re unsure then don’t wait till you submit a pull request to find out, you need to research/ask.

Round Up

Software development is a strange career. You need to keep yourself accountable. Your progress is completely down to you. Finding mentors in your company will also help to keep your code clean and concise.

I hope you enjoyed this article, if you think anything can be improved from it then please do let me know in the comments.