Unfortunately software development is full tradeoffs - performance vs readability, time vs quality, time vs performance etc. One would be forgiven to think that at some point development becomes nothing but a balancing act. Here I want to share a few rules that can make these tradeoffs somewhat more bearable for me.

When in doubt - ask!

One of the biggest problems, that seems to plague modern programming is the so-called analysis paralysis. We’ve all been there - stuck on a 15 way crossroad between seemingly equally good options. When you’re not sure which way to go just ask another team member. Could be anyone. Don’t hesitate to use someone else as your human rubber duck! It often is more difficult than it looks, bug simply voicing your concerns to someone could make all the difference, and if it doesn’t they might provide some insight or advice that might tilt the scales. Most of the time you know exactly what you need to do - you just need that little push.

Avoid ambiguous criteria

Programmers seem to really enjoy justifying their decisions with household terminology. There is a whole book about a particular word, and don’t get me wrong - it’s not a bad book. Unfortunately, I’ve found that “clean” code is in the eye of the developer - not many devs have actually red “Clean Code”, or watched Robert C. Martin’s lectures, but everyone seems to intuitively know what “clean” should look like. The term seem to be a justification for imposing your own personal preference onto the codebase. Something that “feels” clean to one developer might actually be very “un-clean” to another.

Usually, something feels clean when it’s easy to read and understand, but it’s also easy to change. However, while certain changes might be easy, others might be very hard. A good way to get away from ambiguity is to explicitly state what kind of change will be easy to make in each case and see how that aligns with the bigger picture. If you’re not aware of the bigger picture - see above.

Avoid using the existing codebase as justification

Codebases are really weird pieces is of “engineering”. They are really not like anything any other engineers… um engineer. Bridges, roads, skyscrapers, planes - all of these are built to be robust and stand the test of time and the elements. Code, on the other hand is this viscous substance that is always subject to change. Now this one, I admit, can be tricky. We’ve all been the “new guy” on the project and in this case I would advise to follow established convention at least until you are certain you understand the reasons for why things are done the way they are. However, if unchecked, this instinct can often mutate into complacency and your team will end up copying the same poorly implemented pattern all over the place.

Note, that I’m not talking about reusing vs copying chunks of code, or using different style guidelines. This is a whole different story altogether. I’m talking about patterns - a more abstract ideas in code, that can’t easily be “reused”.

I’ve had developers justify mediocre code with the fact, they saw a similar solution in the same codebase, written by me no less. There is a reasonable argument if favour this, actually: if the code already exists, then it must have been reviewed, tested and approved. However, I think it’s much better to program defensively - trust no one and suspect every single line of code.

Err on the side of principle.

SOLID is generally a good set of principles to follow. Nobody should be a slave to principles but if something you’re doing is very brazenly violating those principles you are likely doing something wrong. You might not write your best code if you follow SOLID blindly, but you definitely won’t write your worst. If you don’t like SOLID for some reason, you might have your own set of guidelines that you follow when writing code. In any case some set of principles can be a useful light that illuminates the right path forward.

There is no principle “solid” enough.

The opposite of the above is also true: Every principle has exceptions - you might just be writing one. This is kind of similar to the codebase justification problem. In that case we’re using the codebase as a principle against witch we write code.

Try to avoid blindly following patterns, my experience is that they rarely work right out of the box. A solution that worked well for a similar problem before, might not work now. So, try to reason more about why you’re using a particular approach.

My advice is to try and go beyond the principle. Not just “This violates DRY!”, but try to elaborate why this is an issue. Maybe it will turn out it’s really not a big issue - maybe it’s just a couple of lines of code. Or maybe you expect to change these lines of code the most in future, so you better have them only in one place. How does the principle apply to your case?

Avoid personal preference as much as possible.

This one is very annoying, but unfortunately there is no room for personal preference in code quality. At the end of the day, we’re engineers, not artists - we don’t have “styles”. Of course, there are definitely biases, and ways of structuring code that are closer to one or another way of thinking. However, a developer should be able to articulate while exactly one decision is better than another in a particular scenario. Otherwise we once again delve in the land of ambiguity (see “Clean” code).

Disregard the personal preference of others.

If you work with people that have a lot of unchecked personal preference, you might find yourself preemptively writing code, that conforms to their vision without that explicitly being needed. Code reviews should not be about conforming your code to the views of your reviewer, even if they are somehow your superior. Just as a developer needs to justify their decisions, so does a reviewer need to justify their requests.

“I am the Lead and whatever I say goes” is a terrible justification.

Test every advise in the real world.

Even though I’ve tried to avoid personal preference as much as possible these are still my own opinions, that have distilled over the years. Obviously, this is not an exhaustive list by any means. There is probably a ton of good advice out there can is useful. I encourage you to test any of these so called “rules” and anything else you find for yourself and see if it’s any good.