Codrin Băleanu proudly calls himself “lazy.” An Engineering Lead at Levi9, Codrin says he wants to minimize the time it takes to write code or deal with issues. He wants to solve problems as quickly and efficiently as possible and especially avoid having to revisit the same issue five times across five different sprints.
Lazy, as Codrin defines it, rhymes with highly effective. It’s not about cutting corners or avoiding work, but part of a concept he calls “engineering mindset” that focuses on getting stuff done. Here are the key traits of the engineering mindset.
Avoid unnecessary complexity
“Simplicity is a great virtue, but it requires hard work to achieve it and education to appreciate it,” Codrin quotes Dutch computer scientists Edsger Wybe Dijkstra. After writing code for years, he has realized that the industry is obsessed with complexity, sometimes against its own benefit. Developers juggle dozens of technologies, systems, and libraries daily. They settle into well-defined systems and frameworks that are almost impossible to change. “But the more complex something is, the greater the cognitive effort required to understand and modify it becomes.”
“When I say simplicity, I don’t mean trivial,” he clarifies. Good software design is no unlike Nordic architecture: clean lines, easily understandable structures, and elegant simplicity. But this approach often means pushing back against the tendency to add more layers of abstraction or unnecessary features.
No framework is a religion
“Any programming language is a tool. Any library we use is a tool. It’s a tool to get us somewhere. Don’t believe too much in them.” Codrin warns against becoming too attached to certain technologies or methodologies. Just like a religious zealout, you might want to seek others who share your faith or start preaching about it.
Instead, recognise tools for what they are. “There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity,” he emphasizes, quoting IBM legend Fred Brooks. “There is no silver bullet.”
Stand on the shoulders of giants
There is a time to start writing functions from scratch, and there is a time to use whatever libraries exist. In Codrin’s experience, sometimes developers are proving their abilities by writing code for problems that have already been solved. He warns to not let ego get in the way of efficiency. “Good programmers know what to write. Great ones know what to rewrite (and reuse).” He advises against simply delegating tasks to ChatGPT or blindly copying from Stack Overflow, but rather finding a balance between being responsible for what you deliver and being more efficient.
Use free time to meddle about
Simplicity and efficiency come with the gift of time. You can use it to do nothing while being happy that you’re getting paid, or you can use it to better understand the project and improve your previous work. According to Codrin, the first choice is a downhill slope. And you don’t want to go downhill when technology always climbs uphill: “There are always new concepts, new tools and we need to stay relevant.” You can do that by choosing to invest your time in meddling about: learning new tools, updating libraries or improving a process. “This is how you can stay above the curve.”
Fail fast
The engineering mindset embraces failure as a learning opportunity. “This comes from startup culture,” Codrin explains. “They have to do this because they have limited money, salaries to pay, and can’t spend too much time on an unsolved problem.” But even in established organisations, failing fast helps save time and find new approaches in front of stubborn problems. “Technical debt often propagates because we’re reluctant to change; we don’t want to cut evil at its root. We tolerate things,” he warns. This tolerance leads to accumulated problems that become harder to fix over time.
Be ready to let go
Failing can be too paralysing for developers that are too attached to their code. Codrin remembers developers not being willing to abandon their work, even when better solutions exist. “I’ve seen people say, ‘Look how hard I worked here; look how I spent a week on this,” and refuse to let go of their work. This attachment can get in the way of progress and growth. When you have an engineering mindset, you are ready to let go of code you have written, especially when better options come up.
Driven by curiosity
Another key trait of the mindset is to look beyond day-to-day responsibilities and understand the broader ecosystem. “Don’t say, ‘I don’t do CI/CD; that’s not my job,'” Codrin advises. “Yes, maybe you just need to push two buttons to deploy. But I like to understand what happens behind those two buttons. How does this thing work? Why are the scripts written this way? Maybe one day I’ll need to change them.”
Deliver value over process
When a junior asked whether it was worth pursuing a career in IT given the rise of AI tools like ChatGPT, game developer John Carmack had this to say to him: “Keep your eyes on the delivered value and don’t overfocus on the specifics of the tools.” Codrin quotes Carmack, who is now working on Artificial General Intelligence (AGI), to underline that the core of being a good software engineer is not mastery over a specific tool but rather understanding value and what the final result means.
For juniors who might have a tough time introducing new ideas into already established systems, Codrin suggests finding less critical modules or areas where they can implement their approach. “Find that task where you can do it your way. Show what you can do, and maybe others will see it and want to follow.”
Make it work, make it right, make it fast
The engineering mindset could be summed up into “Make it work, make it right, make it fast,” a principle that gets lost in modern development processes. While it sounds straightforward, it might clash with rigid organizational structures. “How do you describe this in Jira?” This is the perfect example of the disconnect between engineering mentality and an inflexible methodology. “This is not the way,” Codrin says, mirroring Mandalorian’s famous tagline.
Processes and frameworks are helpful, but they shouldn’t override the fundamentals of software development: first make it functional, then improve its structure, and lastly optimize its performance.
