Lessons from 2025: Career Mistakes, Over-Engineering, and AI Reliance

بسم الله الرحمن الرحيم
احييكم بتحية الإسلام السلام عليكم ورحمة الله تعالى وبركاته

Hi it’s a while wince my last post Mastering Multi-Tenancy Architecture in Spring Boot but here we go again with some learned lessons from 2025 here I’ll share with you some mistakes that make me lose a lot of money, time and experience.

Know your worth and don’t compromise

It’s all about business is business relationship between you and freelance/part-time projects. It’s governed by mutual benefit; the client needs a functional product, and you need 💸💸.

My mistake was falling in love with the idea of SaaS, multi-tenant, platform, subscriptions, payments, and large user base management. Wow, what a catchy terms which adds weight to a resume and LinkedIn personal branding! Based on that I made some compromises because of my intense focus on this project, thinking it would translate into recognition. But that’s not necessary. I wasn’t forced into anything; I agreed by myself. Over time, the pressure led me to feel burned out and unappreciated, as if my contributions were an entitlement.

This isn’t an issue with stockholders; it’s my problem. I overestimated the project, dedicating countless hours and days to technical improvements that weren’t noticeable to the client but were obvious to the engineers who are working on a scalable projects.

So where is the problem?

The problem was that I doubted myself and my ability to complete the project because I saw so many aspects involved (development, testing, deployment, security issues during testing and production, and documentations). I was doing all of that under the umbrella of development completely forgetting that each of these aspects is a different job, or doing them all together would cost significantly more. I realized this after looking at the market and the team -I’m not claiming to be better than anyone, but this is just my perspective for clarification. Thank you-

Speak client language

Another mistake I made, related to the first one, was that I didn’t speak the client’s language—the numbers and values ​​they were presented with.

The client isn’t interested in:

• Your data caching, which decrease the response time by x%.
• Whether you store PII as plain text or encrypted.

What the client cares about is that the project delivers what they need. They don’t care if you’re performing N+1 queries in the background, or if you’re using clean code or SOLID principles, as long as the invoice page displays invoices correctly.

I don’t want you to misunderstand me; I’m not encouraging you to be lazy about delivering the best possible version of your work. But keep in mind that the client isn’t concerned with all of that. All of that effort is appreciated, but what matters most to them is why we’re delaying feature X.

So, while I don’t agree with this approach —because I’m crazy and don’t learn from my mistakes, haha— you should be able to offer the same service with varying degrees of efficiency based on the project management triangle.

• High quality and fast delivery? Okay but with a higher cost.
• Lower cost and fast delivery? Nice but expect low quality.
• High quality and lower cost? No problem but we need more time.

The work is part of your life not your whole life, You are spending the most valuable resource of the universe your time.

Keep It Simple Stupid as F*n (KISSF)

I’ve come to believe that the more experience you gain in a field, the more you tend towards simplicity.

As I mentioned earlier regarding the trendy and catchy technologies in the tech community, during and before working on this project, I was influenced by this trends. I wanted to try everything new; I simply wanted to be like the more experienced people. I wanted to know Docker, Keyclock, K8s, Redis, RabbitMQ, Kafka, and other technologies that are popular today.

This turned me into a resume-oriented engineer. I wanted to learn or use technology X add it to my resume. But did I really need this technology? Was I’m ready to solve its issues that would arise once I used it? Was I truly proficient enough, or had I become just a user with its default settings?

Here is the problem: I started importing new problems just to try something new. Why would I need RabbitMQ when I already have Redis and can use it for queuing? The situation didn’t even require RabbitMQ in the first place. My problem is that I always wanted the best solution, not just the most suitable one. This is a huge problem, as I mentioned, and it exposes me to unnecessary issues, given the project’s size and scope.

My advice to you, the reader, is not to be a resume-oriented, especially now. No one needs superficial knowledge anymore. There are AIs that can answer any question you have about any technology. But is this technology the most suitable? Are your settings the most suitable and secure? Are you prepared to bear the cost of this technology, both in terms of resources and money, if it’s paid? These are the questions you need to answer before adding a new technology to your project.

Put my brain in the power saving mode

During periods of high demand and when delivering required features —I was reaching one feature per week— I relied entirely on artificial intelligence. I would explain the problem to it randomly and wait for the results, continuing in this cycle until I had a new module let’s say invoices, that executed exactly what was required. If a problem or new requests appears after a while, no problem. I would explain it again to the agent, and then the feature would be delivered working as requested.

I was aware of the consequences of this approach: the difficulty of debugging or tracing the code, and the inconsistencies in how the code was written between me and the agent. I didn’t have a standardized implementation plan and rules. However, I could rely on the AI ​​again to solve any new problems that appears, and I wouldn’t need to modify the code myself —which is a mistake, by the way— But the biggest problem here is that in the year and a half I worked on this project, and in my daily work, I stopped learning from the tasks I worked on. In all of that time, I didn’t learn Redis properly, even though I used it regularly in my work and freelance projects. I worked for over a year in my job and didn’t learn ReactJS, even though I was working on a full-stack project.

I used to jump straight into execution before thinking or designing, thinking that I would ask the AI ​​for the best design and the most suitable architecture for the project to function efficiently for, say, 10,000 users. I completely forgot that even if the project worked well, were I truly proficient and aware of what I had done?

Ultimately, it’s been a year and a half of work with a level of experience that doesn’t match the timeframe. Of course, I’ve learned a lot, and not all knowledge is technical, but there’s a gap between what I’m doing and what I’ve actually mastered. There’s a quote I read on Facebook that said, “The two months I feared the book would take have already passed… and the book is still unread.” Time will pass anyway, but will I remain stuck in the same place?

Document your work

You should always document your work. Unfortunately, I didn’t do that, thinking it was obvious what I was doing, but as we said above, it doesn’t matter. I worked overtime but didn’t record it. I attended meetings that could last a long time and didn’t count that as work time. I kept receiving annoying, repetitive requests from the team, which weren’t really a problem at all. I would debug them but didn’t record them or mention them in meetings, which burdened me with unnecessary effort and wasted time.

I admit it’s a simple problem for you, but unfortunately, as I said, I fell in love with what I was working on, and now I’ve learned. You should document everything you work on with a clear timeline. For example I’m currently working on task x. Did a problem arise with task y? No problem. Task x will be postponed until the problem with y is resolved, and that’s part of the work. Now you have proof of why I was late in submitting task x.

The most suitable solution to this problem is to create a Brag Document. There are many templates available online that can be used to record and track what you do at work. They are very useful to you in all circumstances, whether you are a freelancer or full-time employee. You may forget what you did, but the document will always remind you.

Conclusion

In the end, it was a stressful experience, but I learned a lot from it. Not all benefits are financial. I’ve learned and gained experience, and I had to pay the price for that experience.

In conclusion, I hope you benefit from what I’ve written above, and perhaps it will help you avoid such mistakes that may seem trivial and obvious to you, because I’m only pointing them out. If you were in my position, they might not be obvious at all, influenced by emotion, a misconception, or an inaccurate calculation.

وشكرا 🩵.