Five tips that helped us become better dev-humans

July 31st, 2020

In a combined past of over 30 years professional development, we have learned some lessons that we would like to share. They go from technical to personal but affect us daily. We hope they could work for you as well. In no particular order, five tips that we would print out and hang above our beds.

Think before you act

Have you ever been so eager to start coding that you just start? If it doesn't sound familiar this is the thought you could have: "I know this part! It's just a fix here and there.". Narrator: the fix did not work out. You might face the downsides of eagerness early, like obvious performance issues, or years later when you are fighting the foundation of your software application. There is no silver bullet for this problem and thinking before you act is easier said than done. But a heuristic that works for us is to not start coding immediately. Instead, grab a pen and paper and start writing things down. Leaving the familiar domain of code and computers behind us helps with getting an overview of what actually needs to be done.

Another thing that works for us: disconnecting from the computer world. This not only frees up your own processing power it also allows for creative thinking. This processing resource is not shared between thinking of all the different solutions, part of it is spent on enjoying the world outside (a walk outside as an example of doing something else) and the majority is spent on problem solving.

Know your business

We often sit down and think of a solution after being given a set of problems or instructions to follow. Familiar? Right, it was to us. If we simplify the act of solving a problem based on instructions we get something like the Tree Swing Cartoon. A cartoon only tells us so much, this video shows us what happens when we are given a description of the problem and have to re-tell our colleagues. What we see in the video is a back writing communication game. Your colleagues and yourself sit down on chairs all facing the front of the room. The last person in the row is shown a drawing. This person has to draw the image on the back of the person in front of them. This continues down the line until the first person in the row gets to draw it on a piece of paper. The final drawing shows diverse results even amongst the different rows. Compared to the original drawing, the results are ehm... different. This exercise shows how hard it is to convey even the simplest messages. Even when the assignment is as clear as draw a smiley. The next person interprets the specification differently.

We personally don't deal with a lot of smileys during the day other than in our team communications. So how would we tackle this problem of business telling us something and ensuring we have the right understanding.
First off talking, communicating and breathing the business domain you work in helps. If you don't have to wonder if the circle they are talking about is the same circle you are talking about, you can talk about the different variants of eyes you can use. You don’t have to become an expert in the field of finance but to know there’s a difference between a monetary value in stock value and amount paid on invoice does help a lot. The differences are seldom talked about because they are a natural part of the business. By talking with the business and making it an immersive experience you learn of these subtleties.

There are methods bridging the software world and business world gap like Domain Driven Design, Extreme Programming and Responsibility Driven Design.

Solve first, beautify later

Let’s set up that shiny new website! Let’s equip it with load balancers, a CDN layer, fancy AI to do stuff and let’s put it in containers. Server costs are at an all time high but at least we will be able to serve millions of concurrent users. Can someone order millions of users? We currently only have three online.

This, dear people, is a case of “over-engineering” that you wouldn’t consider to be common, but we have seen it happen. Our tip in this case would be: don’t take this road. See what you need and adjust over time. Prove you need load balancers and other fancy stuff. A proverb we like to repeat is "the proof of the pudding is in the eating". Though we have to admit we usually put our proof in the pudding instead of the eating. The original proverb means you had to try out food in order to know whether it was good. The same goes for software programs. Try out if a minimal viable stack works for you but monitor and proof it actually does. In most cases the small stack holds up for years.

There’s also over-engineering on the code side of things: you’re thinking of all the things that might happen in the future and therefore, you prematurely adjust your code to it. Ten years later however, nothing you had thought of actually happened, and you’ve bloated your application with dead code. Code that in the worst case even introduces more problems than it was intentionally meant to solve. A trick we used is to start out with the absolute bare minimum you need to finish a certain task. This could mean as little as writing a single global function that does the job for you. The project you are working on will have a different coding standards and global functions are a big no-no for the project. So a logical next step is to move it too a class that does it for you. It's slightly better now and we are still adhering to the project's standard. Slowly but surely you can introduce certain standards up until the point when you have covered all the standards and still adhere to the issue.

Don’t take it personally

Take this fictional and exaggerated bit of roleplay:

Getting comments about your code is rarely fun. They are meant to correct you and any flaw in your review is a flaw in you. No matter how silly stating this sounds it’s how we often felt and sometimes still feel. You most likely spent hours working on something only to be encountered with comments on how bad things are. But these aren’t personal. Especially when textual reviews are concerned it’s hard to convey the intention, maybe even impossible. So as a guideline, comments are there to help you learn something from the reviewer and the intent is rarely bad. If, however, the intent does seem malicious, you should take a look at the team dynamics because something might definitely be wrong. An open and caring environment is for us part of a normal work environment.

To err is human

It’s natural for human beings to make mistakes. In the past mistakes were often seen as something bad. Remember “failure is not an option!”? Nowadays failure is part of our toolbox. We proactively look for making mistakes to prevent them in the future or use them as a learning opportunity. An example of this is the pre-mortem technique or challenge cards. In our personal experience we noticed when we allow ourselves to fail, our ego gets tempered. This makes life in general a lot easier, having less of an ego leads to less frustration, less anger and less problems.

Conclusion

In a nutshell, our five tips for becoming a better dev-human. There’s so many things we want to talk about and share with you like shifting from software design in solution space to designing in problem space (Object Thinking by David West from the Object Guild) or building Radically Candid relationships (Radical Candor by Kim Scott). The heuristics we gather for dealing with situations are different from yours. We would love to hear how you deal with the world on a daily basis. You can contact us here.