I am now very old and wise (do I?) and thought I could share a bit of wisdom with fellow devs. This post is not about how to become successful with your project or make sure your company (or the one you work for) thrive thanks to your work.
It's more a collection of wrongdoing to avoid if you want to make sure other devs won't jump ship and/or the project accumulate technical debts.
No matter what you do, you should focus on the end-user, not the code. When you are asked to develop a new feature, make sure you know:
- who/what is it for
- how it will be used
- and then! What's the best approach/architecture/technologies to do that
There's so much jokes about people making huge scalable apps with fancy technologies when the end-user is just a small market who just need a bulletproof, reliable monolith.
Which leads directly to the second point:
There is a saying in programming:
Recruitment for tech tools is easier because they can hire their customers
Why is it so perfect? Because a customer will tell you what she and you both, need. So you will have a good view on what people are craving for! You will also avoid developing features that no one needed.
Bonus: Always challenge decision makers saying things like "this is what people want" when it seems based on nothing. Those people are usually misleading with their vision of a market they think they know very well.
There is some very interesting articles on the web about IDE's linters which can take you on a formatted path that you will never challenge.
Yes, it's very convenient to install a new environnement and not having to change anything because you are used to it.
And yet, can't you think of a better way to work that by following someone else's rules? We always assume that good practices are dictated by people who really thought hard about a solution. But no. Sometime it's just convenience, laziness and shortcuts.
And most of all: does this really apply to me?
One of my main battle? Abstraction. People tend to add many layers of abstraction because "this is the way" and then it leads to to-many. Where you need to change 20 different files because you removed a property on your class.
If you apply separation of concern too high, you end-up with sayings like
if we change the database, we won't have to change anything in the app.
Ho, really? Let's try right now and see if it's true.
If you think you can change your database technology without changing a big chunk of your app, you are delusional.
Which leads to:
Sending HTML from the server-side? Nobody does that today!
To fix this, let's send back the front-end to the server for rendering... Yes, the front became so bloated that we now need a bare-metal server to run it. https://www.gatsbyjs.com/docs/glossary/server-side-rendering/
The next step? Probably going back to when PHP was sending you your HTML page => https://github.com/hotwired
Again, asks yourself: Is this relevant to me? What's really the shortest path from A to B?
I am not advocating any technology or methodology here. I just think that every project is different and should be treated as such.
Every considerations you can bring beforehand could save you.
Every recipes you use "as is" can hurt you.
Do your research and you will find many people going against the flow and bringing so much to the table.
Thanks for reading. I could write a second episode when more ideas come to me.