Deisbel (Sr. Software Developer)

Enthusiastic Developers: Do you want the secret for saving yourself 800 bugs, 1800 headaches, 2800 hours of work, sleepless nights, and probably saving your job? There you go: - Don't touch what is already working! Unless absolutely necessary, don't change the code working in Production. Localhost is an environment that often has nothing to do with Production, especially in systems that allow customizations or adding plugins on demand. When changes must be made, they should be made, but avoid the temptation to make them out of enthusiasm.

My company's Project Manager decided to dedicate a full sprint to reviewing the error logs for all projects. The idea seemed excessive to me: a full two-week sprint looked like a waste of time. Was the Project Manager wrong, or was I wrong? But first, some relevant conclusions: It's incredible how good we are at logging errors, but terrible at checking them. Checking logs is one of the most hated tasks because if the software works, who cares about all those thousands of lines of warnings and "errors"? And you might think, 'You have terrible developers.' Well, no, we're outstanding (modesty aside). Bugs that cause your software to crash are easy to detect, but silent bugs are tough: they don't bother you, but they shouldn't be there either. So, it is time to answer the main question, but changing it a little bit to save my self-esteem: Who was more wrong? Well, me!, because we didn't need a whole Sprint, but possibly more than one. My three tips for you, Product Owner or Project Manager: 1- Every 6 months, allocate a significant portion of your resources to cleaning up the error logs. 2- If the errors you see aren't critical, then don't log them: change the type to "Info" or delete that line from the log. 3- Refrain from mixing other tasks with this one; otherwise, we, the developers, will dedicate our time to those tasks and avoid bug purging as much as possible. I must admit it, in the end, it was an exciting Sprint.

We will need more Backend developers in 2030 than Front-end developers. The UIs will be simpler than today. There will probably be microphone icons everywhere that receive voice commands and send them to the APIs on the backend. What other scenario do you foresee?

This week, one of my team members used ChatGPT suggestions to significantly improve the performance of a database query, but another got a completely opposite result. Be extremely careful when accepting optimizations from code generation tools. This is why seasoned software engineers will be highly demanded in the near future.

As a Software developer, which one do you pick and why? 1- Zero Modesty 2- Modesty 3- False Modesty I will pick 1.5, something between 1 and 2.

Days ago, I detected a query in a system in development that immediately triggered an alert on me. I communicated this finding to the team but wasn't firm enough to force an immediate change or fix it. I deeply regret it. This is what happened later: When multiple users tested the App concurrently, the database collapsed and everybody went desperate looking for the cause. This reminds me of a rule: Do not delay any fix to your database design or queries. If you see a query "smelling" bad, believe me, it will transform your whole application into a real piece of shit.

Stop whatever you are doing and listen to my advice: If you have a database in the cloud, go right now and add an alert to notify you when the DB reaches 80-90% of the assigned storage capacity. Sooner or later, it will go to full capacity. It will only take 5 minutes, and it will save you and your customers several headaches.