Code is cheap now. So what actually matters?
- Communication and System Design are the skills that will set tech professionals apart in the coming years
- Code Review is losing relevance because code itself has become cheap
- Spec Review is the new most critical moment in the development cycle
- Fundamentals endure through the speed of change, trendy tools don't
- This moment demands a permanent student mindset without forgetting what doesn't change
Have you ever felt overwhelmed by the sheer amount of information hitting you every single day?
Maybe you're confused and would like to get your feet on solid ground to figure out what you actually need to know or do in this moment of transition.
I'm confused too. Anyone who says they aren't, be suspicious. We're in what is probably the most disruptive moment of the last 100 years.
But I'm increasingly convinced that there's a small set of skills that will separate those who ride the wave from those who drown when it passes. And that's what I've been focusing on.
Two skills that won't deprecate
Communication and System Design.
"Your success will be determined largely by how well you speak, how well you write, and the quality of your ideas, in that order." Patrick Henry Winston
I'm not talking about being a great public speaker. I'm talking about being able to understand and be understood clearly and efficiently, by both humans and AI.
I'm also not saying you need to be Martin Fowler. But you need to know how systems work under the hood, even at a basic level. Know how to design a solution before implementing it. Know how to evaluate trade-offs. Know how to communicate technical decisions to non-technical people.
If you already have these two skills, congrats! You're already among the professionals who will be most sought after (and consequently, better paid) from this year on.
Being vulnerable here: I need to improve my communication skills. A big reference for me is Emilio Mesquita, who was my leader in recent years at will bank. He helped me a lot in understanding the gaps I had to grow in this area.
"But I need to learn technology X, Y, Z..."
Easy. Breathe.
I can almost hear you saying: "Marcel, I need to learn about model A, B, and C, framework X, tool Y..."
There's no point in being an expert on the latest LLM model or the hottest tool on the market. In two months, everything will have changed. That's how fast things are moving.
Of course you need to experiment with these technologies and techniques. Don't spare experiments! But keep in mind the things that don't change as fast: the fundamentals and principles.
My suggestion: put your student hat back on and go back to the classroom. Now is not the time to think you know enough.
Stop focusing on Code Review
Code is cheap now. But software is still expensive. And by software I don't mean files in a repository. I mean processes, business knowledge, decisions accumulated over time, and above all, the product working in customers' hands.
Isn't that what we became Software Engineers for?
If we used to spend most of our time debating the best implementation or syntax details in Code Review, the landscape is shifting. Like it or not. With LLMs generating code faster and faster, the "how" of writing code is becoming too accessible to remain the center of the conversation.
"Code Review itself should have minimal human intervention. Every human in the path becomes a bottleneck."
When the context is well-crafted, the latest models already deliver impressive accuracy. The problem is that AI doesn't know the nuances of your business as well as you do.
Start focusing on Spec Review
That's why your time needs to go to before the code exists. Reviewing the spec, the context, the solution design. That's where business errors are cheap to fix. By the time they reach the code, they cost orders of magnitude more.
The development cycle is inverting:
- Before: most effort went into writing and reviewing code
- Now: most effort goes into defining the problem, specifying the solution, and validating the design
This doesn't mean code doesn't matter. It means that the skills around the code (communication, system design, specification, business understanding) are what will define the quality of the final product.
"But Marcel, what about security, scalability, resilience, and..."
Folks, we're still Software Engineers and all of that is included (or should be) in Software Engineering. Now we can focus on that instead of focusing on coding and pulling tickets.
What to do with all of this
If I could summarize it in concrete actions:
- Invest in communication. Write more. Document decisions. Practice explaining complex things simply, for humans and for AIs.
- Study System Design. Not enough to pass FAANG interviews, but enough to design solutions before implementing them.
- Shift your focus from Code Review to Spec Review. Spend more time reviewing specifications, diagrams, and design decisions than lines of code.
- Experiment with everything, but don't get attached. Test the new tools, the new models, the new techniques. But remember that fundamentals are what lasts.
- Put on the student hat. This is not the time to think you know enough. For anyone.
I know it sounds like motivational speaker stuff, but this is truly what I've been focusing on and how I've been keeping my sanity. And I think it's working... We'll see!
Subscribe to the newsletter to receive links, insights, and analysis on software engineering, architecture, and technical leadership straight to your inbox.