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 ✨
Top comments (36)
Is there a "right way" to prepare a meal? If you are very good at cooking spaghetti and your hungry, will you first learn French cooking, just because it´s better? And not everybody will be Paul Bocuse. Maybe finally your spaghetti is better than you "Coq au vin".
It´s the same with programming...
Agree!
This is a really interesting post! Thank you so much for sharing. 😀
Also, I very much agreed with your takeaways. There's no use getting frustrated when things aren't going "our way."
One thing this made me think about is that if there was one "right way" of doing things, everybody would be doing things the same way. Wouldn't that stifle creativity and progress? I'm not condoning doing things the "wrong way" but sometimes mistakes lead to novel ideas!
Also, some bits of your post, for instance:
Check out the video below but note that there's some bad language in it:
Anyway, I think when we catch ourselves being "Right Way Guys" we need to laugh at ourselves cause we all do it from time to time!😅
Good point on creativity! I also was wondering on that - we are looking for instructions, the right ways, ready-to-go steps but when we'd have them that would probably kill creativity (cause we wouldn't have to look for these). And looking for our 'right ways' is the space for creativity in my opinion
Vue is better than React. Why doesn’t EVERYONE write frontend in Vue? Haha :D
:D
No 🤣
Svelte is faster.
Vanilla JS is even faster.
Just do everything on the server.
Agreement between devs is the right way. That said, there are some principles that held for years and decades (solid, clean architecture, DDD patterns, general software patterns, preference for immutability everywhere applicable -functional bits-, ...) and research done (accelerate book) that explains what attributes good architecture has (architecture if just software too) and what practices work (dev ops).
That software should be easy to understand it's probably the universal truth. If you need to learn a framework (react, angular, custom things) to understand the software, a part from the programming language (which is unavoidable) means that is harder to understand.
But above all agreement between devs is the right way. The more people can collaborate the better. That's why a collaborative attitude is more valuable than knowledge. And hopefully you'll go for the right patterns to achieve your goals.
So true!
2018.03.18, The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model
Reference
2018.03.18, The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model
The unification of OOP, FP and Warehouse/Workshop Model
Traditional IT theory (OO, FP and hardware architecture, etc.) VS. Warehouse/Workshop Model
Success Story
The there is the right way. I knew it :D
Honestly still one of my favourite "frameworks" ever.
Good thoughts here, mate.
I'm 50 but only 3yrs on programming.
So, I never though about right way but solving way.
I mostly work with legacy, before any statement about old code I just try to understand, after I try to fix the bugs I have to work on and mostly of the time we need to keep the 'code style' to avoid creating more bugs.
That's life,that's all that people say...
Good article by the way, gave me insights.
thank you!
As a teamlead I dream of fighting tech debt, but business wants new features... fast. At least we are able/allowed to use bleeding edge techs. The art imho is to stick to sanity and not to kill people during review 🥲
Thanks for sharing. Great article!
thank you! Yeah... tech debt is always there. But new features is what brings/keeps new customers so this is understandable
You are on the right track. Focus on yourself, not others, work as you are one team business which collaborating rather than demanding
Thanks for your input :) I know Extreme programming (I've been even working in extreme-programming way of work for a while in a team), that's an interesting idea. The points that are mentioned in the article were there to show that new things that I discovered on my learning way, became 'my right ways' for a while. But then I discovered other things. And started thinking that they might not be one right way (this is what I was expecting first)
To me, the "Right Way" is clean code that's easy to understand and update. No matter the tech stack it's written in, if it's not "simple" then it should be refactored.
Thanks for sharing, this mirrors my journey. I'd like to give me of 5 years ago what for about some opinions. But, then again at least we can look back and know we're learning.
That said there are things that need to be done on long running projects:
We shouldn't care what people are using to do this (as long as they're not actively slowing others down). Why must you do these things? Because they enable you to pass your work to the next guy. Whether that's your colleague because you need help, or you a year from now when you get to come back and add features to an existing codebase.
Why isn't everything automated-tested? Maybe because we like our manual QA team and we don't want to get anyone fired.
Ruby is a happy language!
This is a great tech, and human, article.
If we focus more on building the right team, we will find the team's right way, and re-build it in a constant creative process. What do you guys think?
Definitely... in the end of the day is all about communication and understanding the problems that we are solving with our software
Thank you so much for your input on this subject.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.