I recently read an episode of "Computer Things" newsletter by Hillel Wayne with advice for beginner programmers, and one remark made me pause for a while. Here it is:

"At some point you will discover the Right Way to program, the thing which makes this all make sense, and you’ll be convinced that the whole field would be so much better off if everybody else programmed the Right Way, too."

And the author continues:

"I’m not going to tell you to not get swept up in the Right Way, because that’s pretty much impossible. And honestly it feels really great to discover the Right Way and life’s too short to not feel good. Just be mindful of the fact you’re getting swept up and try not to make your identity the Right Way Guy. Eventually the honeymoon will end and you’ll learn that programming is frustrating and messy regardless of which Right Way people use, and that you can also make great software without doing it the Right Way. Over time you’ll learn fifty other Right Ways and learn to mix and match them to the problem at hand."

It was supposed to be so beautiful…

It reminded me of the times when I discovered my Right Ways.

💥 Number one: React is better than Angular. Why doesn’t EVERYONE write frontend in React?

💥 Number two: tests. Why does part of the code NOT HAVE tests. Why doesn’t EVERYONE write tests for EVERYTHING? (Well, I still think this one is right).

💥 Number three: refactoring. Why did someone add new functionality in OLD code without REWRITING it the new way? It’s already known that this is NOT how it’s done, why do we keep such OLD code.

💥 Number four: code coverage. How do others EVEN function WITHOUT IT? It would be enough to CHECK code coverage by tests, add what’s missing, and that's it.

💥 Number five: functional programming. The code is short, simple, pleasant. Why doesn’t EVERYONE code this way?

I could go on because there were many such things. You probably have a list of such Right Ways if you’ve been programming for a while. Over time, I learned that a programmer's life is not black and white. It’s not always possible to use the Right Way. Heck, sometimes even others think that this way is not the only one. Nor right. And you, heartbroken, agree with them.

Because it depends on code's specifics, the project, the client's requirements. Because, primarily, the code has to work, a new feature needs to be added, and sometimes the Product Owner doesn’t really care about the fact that adding e2e tests to a particular section might take a week (oh, I was in such a project!).

I'm not advocating writing bad code, not refactoring, or not writing tests. I'm more about the fact that not everything depends on us and knowing some new way of doing something cool and useful doesn't always mean it should be used everywhere.

And then the ideal broke…

I remember at one job interview when asked what I would do if given a legacy project, I answered without hesitation "first I would rewrite it using newer technology." Today I laugh at myself. And I laughed too, later adding lines of code in Backbone (if you know, you know). My approach to refactoring has changed over the years. Usually, I actually follow the rules I’ve gathered in this article. Will I ever change the rules I follow? Probably.

What a few years of programming have taught me is mainly that there really are no universal ways. Sure, we can apply certain principles, techniques. Yet, code involves many variables and when entering an existing project, we can't control many of these variables. Getting frustrated then that something isn’t written "our way" makes no sense.

A pretext for reflection today is the Right Way. Got yours? Do you treat it like the bible? Or are there things you once believed in, but are no longer relevant today? I’m really curious how you approach this! Share your thoughts in the comment section below ✨