Quite some time ago, I’ve come across a question in stackoverflow by Jon Skeet.

What’s your most controversial programming opinion?
Jon Skeet

As Developer’s, there comes a point in our life where we start questioning a bit more, and you realise – these things that these guides and principles that we’ve been taught doesn’t quite work for our problems – this is an awesome moment, this is the moment that you have become more pragmatic with your approach, you’ve formed your own opinions based on your experience, and you know that it works.

Here’s a list of some of my favourite answers from the stackoverflow question.

1. Design Pattern isn’t always the answer

Design patterns are sometimes a way for bad programmer to write bad code
“when you have a hammer – all the world looks like a nail” mentality. If there is something I hate to hear is two developers create design by patterns: “We should use command with facade …”

As a Developer – in my earlier years, I did things that everyone probably does at some point, try to find design patterns that try to solve the problem at hand, and we try so hard to fit the design pattern we thought was the correct way of solving it that it gets solved badly. The main reason for this is that at the point of thinking of solving with a pattern, you decide to switch your thinking to “how do I apply this pattern to this problem”, rather than “how does this pattern really help me solve this problem, and is it really the best way of solving this”.

Think for example of a big chain of switch-case statements, being replaced with a strategy pattern … Nowadays, when I see a big chain switch-case statements, I would normally leave it, sure, it’s not great, but it’s definitely better than 6+ added classes that are scattered all over the place that abstracts too much – that’s the cost of applying such pattern.

2. You shouldn’t always think in Objects

Object Oriented Programming is overused
Sometimes the best answer is the simple answer.

Some Developers can have a very strong view of “everything must be an Object” mentality, I call them “Object-Oriented Purists” – they are some of the most difficult people to work with as they seem to have been never exposed to other programming paradigms – code is a means of getting things done to solve a problem, adding extra complexity has its costs, keeping code as simple as possible to get the problem solved is the best outcome for both the programmer and the business.

3. Knowing Good Enough

Realizing sometimes good enough is good enough, is a major jump in your value as a programmer.
Note that when I say ‘good enough’, I mean ‘good enough’, not it’s some crap that happens to work.

When I was first taught the importance SOLID and code robustness and flexibility, I obsessed about it – to the point where I started thinking about how everything will interact, and how each piece could be reused.

I obsessed so much that something so simple that needs to be able to handle x situation can now handle x, y, z and throw appropriate exceptions for a, b and c. I wrote code for pretty much all possible cases, including edge cases that no one probably even thought of, that I spent an entire day just writing one simple class. This thing was so robust that it could never break, and if it did, you would know exactly why it broke.

I went even further, I started thinking of flexibility, “what if we want to re-use this for x, y and z scenarios? we need more state” – I found problems that didn’t even exist, or at least not yet.

There was one big issue though, the value of all that effort comes to zero. In fact, it’s even worse – it had a negative value because of the time that I had spent, instead of actually building an application, I built multiple libraries that didn’t solve any of the problems that I had and the application was incomplete and only used less than 10% of the code that I had written.

Keep it simple, and most importantly, keep it only as complex it needs to be, no more, no less.

4. OOP is a bad first language / paradigm to learn

OOP language is the worst first programming language to first learn
For one, I believe that first programming language should be such that it highlights the need to learn control flow and variables, not objects and syntax
For another, I believe that people who have not had experience in debugging memory leaks in C / C++ cannot fully appreciate what Java brings to the table.
Also the natural progression should be from “how can I do this” to “how can I find the library which does that” and not the other way round.

5. Keep your solution as simple as possible

The Simplest Approach is the best approach
Programmers like to solve assumed or inferred requirements that add levels of complexity to a solution.

YAGNI and KISS are your friends. Do only as you’re required – it will save you thousands of uneeded lines of code/complexity and all the headaches that come with them. Let your code naturally grow.

6. Good Architecture is grown, not designed

Good Architecture is grown, not designed

This isn’t something that I 100% agree with – I’ve covered this topic briefly before in a post “Why We Accumulate Technical Debt”.

However, I do agree that our understanding of a problem becomes better over time, and this allows us to have a better judgement. The main reason I don’t agree is that, this new found wisdom sometimes requires complete re-architecture that doesn’t allow for changing small parts one-by-one gradually allowing it to evolve.

7. Use Static Conventions in Dynamically Typed Language

Well-written code in dynamically typed languages follows static-typing conventions

I don’t agree with this 100%, as dynamic languages exist for the purpose of being more productive – allowing you to write things quicker by not being restricted with types – this has both good and bad sides.

I do agree however that design should follow (for the most part) static conventions – imagine functions or objects that behave differently depending on the types passed to it.

Let’s see quick (not really terrible) example, jQuery (still the most popular JavaScript library) allows both .css('visibility', 'hidden') and .css({'visibility' : 'hidden'}) – I would personally would prefer the latter to be the only way of doing this as you’re only exposing one version of the API that achieves the former and more.

8. We’re Software Developers – We Solve Problems

We’re Software Developers, not Web/C/C#/PHP/Java/JavaScript etc Developers

I very much identify with this statement, sure, we’ve invested heavily in the technologies that we use, but that’s not what we really do, we solve problems with various tools. These are tools that are best for the job. I produce applications and distributed systems that do various bits that make a business work, we write SQL, C#, JavaScript, some form of a message queue, pub/sub messaging etc. to solve these issues – we solve problems, whether it be business or technical (usually both).

9. Single Exit is non-sense

SESE (Single Entry Single Exit) is not law

Back in 2012, I attended an interview, and my code was criticised for not making use of SESE. It was one of those methods where if there was no result, I would immediately return an empty list.

So, I had to refactor so that this list gets assigned and returned at the very end of the method. This didn’t make any sense – mistakes can happen whereby conditions are wrong and the empty list becomes a populated list, or worse, an exception gets thrown. Why play with fire? Immediately returning also meant that your intent is noticed instantly instead of having to go through the entire method’s code.

10. Readability above all else

Readability is the most important aspect of your code.
Even more so than correctness. If it’s readable, it’s easy to fix. It’s also easy to optimize, easy to change, easy to understand. And hopefully, other developers can learn something from it too.

You hardly write any code from scratch – and if you do happen to write code from scratch majority of the time, you’re doing something wrong.

Nicholas Zakas did a great talk on maintainability, definitely worth a watch if you need convincing as to why readability is your top priority.

To summarise, don’t follow best practices blindly. Think. Be pragmatic.