Well, I did not build a new feature. Most of my tasks were client-facing, focused on solving client issues. And the client had many issues. Things were escalated, and escalated again. Now the trust that I had built with higher management is kind of gone. The autonomy that I was offered is also kind of being rolled back. I am not getting that tech lead promotion. The biggest worry is getting fired, lmao.
I feel you can only put the blame on process to a certain extent. At the end of the process, there is always a human. I have learned a lot and gotten good at using AI for coding. I feel Anxiety Driven Development is the root cause. The thing is, if you are a good developer, you can also be good at Anxiety Driven Development. Alas, the whole experience did hurt my self-confidence. I don’t have answers right now. The astrologer said this year would be good for me professionally, but as it seems, it has been a not-so-good patch.
Okay, this is turning into a feelings-based blog. Ahahah. But I try to inculcate some career-building things too. You have to preserve trust. You will be given multiple chances, but you have to make sure that expectations are being met. At some point, the stress became too much to handle and I kind of unfolded. I still need to learn how to detach life from work. Work affects my life too much.
So what did I fix? The report format. You remember I was working on report generation? Yeah, the format of the report was incorrect and a few sheets were missed. Product gap. I missed a whole thing :(. So I worked at warp speed to fix it. That might have introduced some bugs, read two bugs. Fixed them too. Modularisation is your best friend. We added a lot of logs too. A lot.
Over-logging can sometimes be a problem, but when your client is asking questions and you don’t have answers, you log everything. Never trust a third-party vendor. Keep a parallel process to verify their data, like with webhooks. You receive a webhook and say, very good, nice. But verify. Use their API at some point to cross-check your system’s data integrity. Get good rate limits. 100 requests per minute is too little when you are dealing with a lot of data. Trust, but verify. Nobody knows what it means. Eh.
To handle heaps and heaps of data, which will only increase in the future, you have to be careful. Things can spiral out of control at any time. Your database gets full, your database crashes, etc. You need to keep a script ready to synchronise your system with third-party data. I also helped some colleagues with their tasks. Not a big deal, you are supposed to do that. I also took some interviews.
When you know the data is going to keep increasing, you have to plan accordingly. You have to design your system so that the amount of data never becomes a bottleneck. Will your system slow down when data becomes 10x or 20x? Yes, there are chances of that. Then you go and optimise things. Premature optimisation never helps anyone. You design your system around the data. Never plan too much for the future, because there is a good chance that the future you are planning for no longer exists.
If you are an engineer, your best bet to survive the AIpocalypse is to build product sense. You should talk to customers and understand their point of view. Sometimes you build what you think is correct. Most times, you build what is correct for the client. You have to keep the client aware of the system, but also not show them the entire system, including errors and internal details. They shouldn’t get confused. The features you build should speak for themselves.
Now that coding is automated, deciding what to code has become more important than ever. Every time a layer abstracts out coding, more code is written. My opinion is that a lot more code is about to enter servers.
Personally, I can only work on a maximum of two tasks in parallel with AI. Otherwise, I lose context and miss things. You also have to be specific with the AI about what to build. But I also feel you have to give some leeway to the AI to make its own decisions, like a coder. A software engineer should never be overly constrained. AI should be constrained, but not too much. Otherwise, it will follow your orders word for word and still introduce bugs just to please you :P
Testing is the key to success, especially testing that is deterministic in nature. The AI will not have full context about your business, so you have to be kind towards it and also make sure the context is sufficient to arrive at good solutions. Context, but not too much. AI doesn’t need to know your name. I love how it generates commit messages though, and how it helps me with sequential commands to resolve Git branching issues.
Solving client or customer issues is not just technical. It also depends on how well you can communicate and how easily you can make things understandable for the client. If they don’t understand, you have to make them feel like they understood. Most clients don’t care about technical details. They care about what went wrong, how you are going to fix it, and how you will make sure it never goes wrong again.
They are paying you to abstract the system for them and show only what drives ROI, not the mess behind the curtain. Customers love it when you fix issues quickly. It drives trust and happiness. You also have to set SLAs. Otherwise, every problem becomes high priority, and that is how things get messy and flow breaks. If everything is a priority, then nothing is a priority.
Automate everything. Your data integrity checks should be automated. Your deployments should be automated.
I added a Celery worker to the infra repo, which uses Argo CD to deploy things, and now most of the infrastructure is just YAML. You write YAML and bring infrastructure into existence. I am a simple man. I like SSH-ing into a server and deploying things. But automated deployments are cool. Automatic rollbacks are cool. Autoscaling is cool too. But all of this depends on your scale. To serve 10 users, you don’t need Kubernetes. Just SSH into your 8 GB RAM server and do what you want.
Simplicity is your best friend. Never overcomplicate solutions. If something can be solved easily by introducing a process change, do that instead of writing code. Some problems are better solved by not writing code at all.
Well, this blog was more of an update on my professional life than something technically cool. Maybe if I build a cool feature next, I will write about it. As of now, I am just resolving bugs and making sure the client is satisfied.
Okay, bye.
