Long time ago, in another life, I found myself at a crossroads: whether to continue working in Data Science realm or to try something new. The year was 2015, and everything was different in that time, from the global economy to future prospects: literally every single venture promised infinite growth and opportunities, and I decided to seek new green pastures under the cloudless sky. Software development was a trendy activity in those days: industry showed no signs of slowing down, prospects seemed limitless, and since I already had about 5+ years of experience creating extremely complex and sophisticated software for data analytics, trying the role of a Software Engineer in real Software Development company was the next logical step, and I gave it a try.
The transition was easy in some sense, because ML and signal analysis was the core of my multi-year project, and I could proudly call myself an expert in Python (and all ML stack): software which I created was like the technology from the future — some ideas were just well ahead their time.
The transition was difficult because my first degree was in Physics, and my knowledge of the fundamentals of Computer Science and the principles of Software Engineering was like Swiss cheese — impressive expertise in some topics co-existed with knowledge gaps in others. For example, I could easily discuss the comparative advantages of Wavelet Transformations over Fourier analysis in image compression algorithms and time series data processing. Designing and training a neural network to extract insights from noisy data was a piece of cake for me; in Astronomy and High Energy Physics neural networks have been used to automatically analyze images and track elementary particles since at least 1994, become a de-facto standard in all elementary particle experiments and Big Science projects in the 21st century, and I had a lot of both hands-on experience and theoretical knowledge in this domain. But at the same time, I struggled to build even a simple website: plain HTML, the basics of JS, plus manual “fine-tuning” of CSS files was the pinnacle of my knowledge in web design — and this was in 2015, the age of Angular, React and CSS preprocessors! I had no idea how to deploy and scale out the backend, and I didn’t really know AWS or GCP (although I had some experience with Heroku — similar cloud service, and that experience along with many books about cloud technology helped me to gradually build up my very own understanding of cloud architecture and everything around it — check out my another article about how I got certified as a Google Cloud Architect in 2022).
Another completely new experience was the realization that business objectives often take priority over accuracy and completeness in practical software engineering. By “practical”, I mean the real business that involves delivering solutions/software products to customers and users with an acceptable level of quality. When I worked on my own projects, I had more control and visibility over the trade-offs between quality and development speed; this visibility was almost nonexistent in the companies I worked for later. Deadlines were either implicit or not set at all, yet the business still expected the delivery of a sellable result within some (undisclosed) timeframe. At one point, I was on the verge of declaring a Brand New Approach/Framework to resolve such problematic ambiguity, only to discover later that it had already been invented in the form of the Agile framework.
At work, I found out the ancient wisdom that Software Engineering is not all about coding (how many times has this sentence been pronounced on this planet?), but about solving the problems, and this in its turn may or may not include the actual coding. I found that sometimes it’s better to write a software which writes other software which solves the problem, rather than attacking the problem directly. For example, React is a perfect example of such software, which is effectively a code generator library which reduces the process of building of websites to adding up and bootstrapping the already existing components. Before 2015 it took me a week to create a simple website, in 2024 it takes me less than 1 min. In the last 10 years the approach to software creation has undergone a significant transformation, and today writing software is synonymous with either code generation or finding a generic solution that addresses an entire class of problems (which means writing a framework).
All these observations have been gradually accumulating since 2015, and today, ten years later, I can compose a concise Software Engineering Manifesto (SWEM) on how to design and implement software systems in 2025 and beyond (including AI trends and its impact). This set of principles has helped me to exponentially accelerate my productivity — what others (including my past self) could build in one week, I can now accomplish in under two hours, which translates in 20x gain in productivity.
1. If you don’t know what to do — do nothing
Yes, in decision making the option “do nothing” has a right to exist. This is because there’s a chance that the existing solution (if there is one) is the best you can find in all universes; therefore, move on to the next problem. It could also be that it’s just too early to start working on the details, since there is no clarity on all the inputs and outputs, bolts and nuts. The “R” phase in R&D can be exhausting and daunting, but this process should not be rushed — architectural or design mistakes are the hardest to fix.
2. Create once — use forever
In other words, do not start solving the problem from scratch each time. There are frameworks, libraries, and already existing end-to-end solutions that can be adapted for the new case with minimal, if any, changes. And only if the problem belongs to a brand-new class, start solving it from the first principles. Ideally the solution should be wrapped into a framework/library for this specific class of problems. This not only accelerates delivery — the created software also helps AI tools to easily learn patterns and generate the solution individually for each similar case (AI is not very good in writing low-level code, but just loves structure, repetition and clarity of software frameworks and the solutions built using those frameworks)
3. Automate anywhere
The smallest tasks eat 80% of time, and automation can make them obsolete, why not do that?
The routine workday of Software Engineer is full of such tasks. Here are the most obvious examples:
4. Document everything
This includes bugs, releases, release digests, performance test reports, low-level designs, high-level designs, specs, API contracts, meeting minutes, brainstorm sessions — you will need these evidences to showcase your hard work and get promoted!
On a more serious note, building (and maintaining) complex systems is all about consistency and order, which should help to stand against chaos and malevolent forces. This is true not only about software. Ancient Rome spanned across all of Europe and existed for millennia not because Romans were especially smart or skilled, but because they had Roman Law, plus highly trained and organized regular army, and the technology to build high-quality roads for excellent logistics.
There is another, more subtle point here, which could become important in the future: documentation could be consumed by AI or used to write efficient prompts — in the future most complex systems will likely be designed by AI.
5. Optimize from day zero
Knuth would disagree, but he is not strictly speaking a Software Engineer — he is a Computer Scientist. These days companies do not have a luxury to refactor sub-optimal code, and in building scalable systems it’s crucial to write the optimal code from day 0, otherwise it’d be much cheaper for company to fire mediocre developers and instead them to hire those who can write proper software, than to pay millions of dollars in electricity bills and equipment cost to run inefficient software in production environment.
A modern highly-scalable system is the mirror which reflects and magnifies your own flaws and foibles, and this is one of the reasons why FAANG companies which have to deal with such kind of systems use 5 stages of LeetCode-style interviews in order to find people who have decent coding skills, appropriate mindset and do not make mistakes (or at least do not make them more frequently than 1 out of 6)
6. Do it or Die
Otherwise what does the company pay you such a big salary for?
But truth be told, this principle is primarily applicable to routine tasks. Any successfully completed task consists of much smaller, simpler tasks, and the big success starts with small, atomic achievements. Each task should be queued and completed on time, this maintains motivation and momentum, serves as a guide in hard times and during moments of self-doubt, and eventually helps to fulfill commitments.
7. This is a never ending journey
And that road is for you; keep going until the end.
Perhaps this final principle should be the apotheosis of the entire manifesto. Every good Engineer has their own unstoppable engine inside, which motivates them to conquer new heights. This enigmatic engine is quintessentially a mystery, and I can say nothing about it; but you should trust yourself regarding what it’s whispering in your ear, and rationally reflect about your knowledge, strategic pathway and milestones, both past and future.
Find the details about my career path here: https://www.linkedin.com/in/aliaksei-kaliutau/