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...
For further actions, you may consider blocking this person and/or reporting abuse
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
Svelte is faster.
Vanilla JS is even faster.
Just do everything on the server.
No ๐คฃ
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
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!
Honestly still one of my favourite "frameworks" ever.
Good thoughts here, mate.
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
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.
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)
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.
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
Why isn't everything automated-tested? Maybe because we like our manual QA team and we don't want to get anyone fired.
Thank you so much for your input on this subject.
I liked the article until I read 'frontend' and 'test... everything'. That made me think you still have a lot to learn to find the right way of coding.
Manual/automated e2e tests before deploying on prod? Yes please
Unit testing the button? Please don't
If your frontend has complex logic, it usually represents totally wrong way of solving the problem (I think it must've been backend dev who wrote it)
Most projects would have much much less bugs if devs spent more time writing good (=simple) code and improving the codebase than writing useless tests
Yeah I never share this opinion with HR ๐
in the right way, the problem to fix, the bug to squish etc., I'm highly conscient that the common word is wrong.
they're many ways to go, many aims to achieve, many different parties to make happy.
all different. keep life interesting.
Itโs an awesome article. Iโll like to add that it also depends on who are you working for/with.
An employerโs is -almost every time- the right way. Iโve heard a lot of stories from colleagues that โbossesโ donโt agree with any โotherโs right waysโ.
While a freelancerโs way (struggling to do everything) could sometimes be the only way.
Thank you for your writing. Very interesting.
I'm too tired to discourse about it, but let us go.
All projects I've participated I have to cope with different style even if that style was style guided (including code format, lint, etc). These things may vary each project, including the all-fragmented microservices which may be written in vanilla javascript (ew) or typescript. Well, sometimes I just follow the flow, or if I am able to refactor that, then yes I'll do that. Like He said, it depends on a variety of things.
What a joke. "Right way"?!? React?!
React may be a slight bit easier to read than angular but compared to literally everything it's is the slowest front end. Using react is a gimmick. It's likely done so amateurs can use libraries to cobble together and app of some sort at great detriment to the end user.
If you're.making a choice that is probably not needed that you need a framework go with vue or svelte. Go with react of you want to use a bunch of premade slow a$$ code and pass your lack of programming skill on to the user by bogging down their device.
The whole point of this article is to show that there is no right way. I thought that React is the right way when I discovered it (I was using Angular then). But of course, everything depends on project, needs, customers, etc etc. Every framework is good for the particular use case, there is no one framework that does the work (and, suprise - even Vue and Svelte have drawbacks ;))
The right way is to program make sure you understand what you're doing.
that's true! I have the article on that about dev mindset - check it out here: dev.to/joannaotmianowska/dev-minds...