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.
Think of it as a project and not a product
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:
Knowing nothing about your market
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.
Follow guide lines and good practices blindly
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:
Following trends
Sending HTML from the server-side? Nobody does that today!
Couple of years ago some people said that it needs decoupling and we should use REST API. A tone of Javascript and many frameworks later, dealing with JSON adds a lot of complexity with database intensive apps. And for simple projects, it's just bringing a plane to a marathon.
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?
Conclusion
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.
Top comments (0)