Product mindset

Everything should start from a correct mindset.
A perfect data model
I don’t think spending 3 weeks just for the data model to try to cover all scenarios is a smart way. We can finish them all in 15 minutes.
Trying to imagine all scenarios can happen before coding is kind of sucks. We never know what the users actually want until they use it. Instead, we should think about what happens when something crashes, when the configuration is wrong, and what’s the best way to handle when errors happen. No matter how perfect we design the system, errors will happen.
Holding back the team because of a pull request review because the leader or CTO doesn’t read all the dev discussion documentation is another stupid thing. The team lead (actually “leads” nothing) wants to make sure everything follows their idea. Then the CTO comes in and asks stupid questions because he didn’t read all previous discussions. Now it took one more week to explain to him. During that time, people release tons of new applications due to AI power. And we still fucking around with discussing the field should be fucking_very_long_but_make_sense_with_somebody_variable_name
instead of variable_name
or asking why we should need a field that seems redundant to somebody.
What’s the worst case of having a redundant field in the data model? Does it harm user experience? Does it cause critical issues in production when deployed? Does it break anything?
From my point of view, the worst case is a waste of time for those things. We can finish everything in 10 minutes, observe the production in 10 minutes and even better, all tests will cover the critical bugs if we have. Even if we have bugs, it just took 2 minutes to fix. All this whole flow should take no more than 30 minutes.
One ridiculous fact is, that we always have tons of tech debt but still have a nonsense mindset everything should be perfect from the beginning.
MVP
People say MVP stands for Minimum Viable Product.
That concept is stupid to me and it should never be a good way for software development. We are trying to make happy cases and call that MVP. This is the typical way to develop a low tolerance system, we didn’t think about the error-handling process from the beginning.
For me, MVP should be a Minimum Viable Process.
We should have a process to handle something that happens, not something that looks working. The problem with users is, that no matter how happy cases work smoothly, they will complain when they see a bug.
Dirty code
Till now, nobody has ever answered for me what “clean code” means. The truth is, they are trying to say what seems “clean” to them. Comment in code is dirty to some people, I don’t know why. The value of comment to me, is NOT explaining code, it tells the story. For sure when we look at our code 1 year later, nobody is ever sure what the hell is going on here. The comments may be outdated with the code but it will tell us why, at that time, we decided to do that. We usually don’t document decision-makers at the code level, that’s the problem and comments solve that problem.
Usually, my team “lead”/CTO puts a change request to my PR to ask me to remove some logs. I know logging has cost, but that story is for millions of requests per second system. The bad thing here is, that they requested changes and after I updated the code instantly, they went away and got back after 1 week with another question, about something else. Just like the redundant variable or very long variable name, we waste tons of time on those shit and hold things together for no good reason.
Premature optimization early is the root of all evil.
Micromanagement
Steve Jobs wouldn’t be a legend if they told the developers what should they do. He became a legend because he lets their employee do their fucking job.
Micromanagement is the best way to kill creativity. Ridiculously, nowadays managers still have the mindset to hire talented people and tell them what they should do. They hire talented developers, treat them as robots, and then complain to them why not be reliable, and creative, but like a robot.
Subscribe to my newsletter
Read articles from ShinaBR2 directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

ShinaBR2
ShinaBR2
Enthusiasm for building products with less code but more reliable.