JC's photo

JC's Writing

My personal space to publish my thoughts

Fixing the basics is not just about code

A lot of tech companies decide at some point that they need to "fix the basics", but sadly some of them just refer to rebuild their technology, not a change in the development process. History repeats itself, let's never forget about that.

This is not an article about how to do the fixing, that's different for every company, all of them have their own problems, we can't just grab a "playbook" and think that everything will go as planned, it's a challenge and one that involves more that just making from scratch your code, with the idea that this time it will go well, it's about making decisions that affect the way that you approach work, because if you don't change the way you work, why do you believe that your product will be different this time?

If you find yourself in a company that's going through a process of "fixing the basics", remind your managers, tech leads and whoever is in charge of something inside, that if we don't change our process to do delivery, the same thing will likely happen again.

I recently heard "that's how we do things here, is very relax" and that made me worried a bit, not because of the relaxing part, I really like that, but because I don't see much technical vision, everyone does things as they want, just one person know about one part of the product, so is difficult to share context between the team and there are very few moments where the team can align how to build stuff that affects the features as a whole. This is the reason that made me think about the process, if no one is accountable of the way that we work, even if we rewrite stuff from scratch, is likely that problems will occur again, having to threw away the new work at some point, not too far in the future.

Software engineering is considered an engineering career, because we follow engineering practices and that implies having to "plan" stuff before just diving in the code and hack our way around to build stuff.

I have no intentions on writing how one must do things, just trying to remember whoever reads this that we have to be responsible and accountable of what we do, if we want things to last for a long time, let's take our time to design before starting to write code.