A long time ago, someone asked me in an interview: “What is the biggest problem in software development?”
It was a broad, open-ended question. I gave an answer at the time, though I honestly cannot remember what it was. What I do know is that I would not give the same answer today, being older, having seen and experienced more.
The biggest problem I can see now is poor end-to-end quality management.
As a software engineer, I don’t want a digested problem presented as “requirements.” I want the raw problem itself.
A common mistake I often observe in software companies is product managers taking on the role of managing teams and dictating requirements.
Software teams don’t need requirements; they need clear problem statements. The role of a product manager is to identify and articulate the right problems to solve.
The team will then collaborate to analyze each problem and design a solution.
There are a few Rustaceans (the silly name that Rust cultists have now given themselves) who keep posting against those “dinosaurs” who still use C or C++ and refuse to bow to the undeniable superiority of Rust and be assimilated.
As usual, a potentially valid message is completely undermined by the messengers.
I do not know Rust, but one of my goals this year is to gain a good understanding of it. The issue is that these zealous and almost fanatical behaviours do not help, especially when coming from people with only two or three years of experience.
I have a deep appreciation for Dr Neil deGrasse Tyson, astrophysicist, author, and science communicator.
He has spoken about the immense challenge of sending something into space, particularly the need to overcome Earth’s gravity.
When trying to break free from our planet’s gravitational pull, weight becomes a disadvantage. Space-bound artefacts must be made as small and light as possible.
This challenge drives miniaturisation, which has a significant impact on other fields, such as medicine and materials science.
I’ve tried for a long time to resist diving headfirst into this incredibly boring discussion about whether or not AI will replace software developers in the future.
I keep reporting the countless posts flooding my LinkedIn feed on the topic, but since it’s a platform that works terribly, they inevitably show up again the next day.
I said it before: my opinion is that the world of programming will change. It’s technology, and technology has always gone through evolutions. That’s how it’s been since the Stone Age.
Agile is not opposed to planning.
One of the biggest misunderstandings about the Manifesto for Agile Software Development is the interpretation of “responding to change over following a plan”.
Some take this to mean that planning is unnecessary or even discouraged. But that’s not what “over” means. “Over” does not mean “instead of”. It means “we value both, but we value the one on the right more”.
Planning is essential. As Eisenhower put it: “Plans are useless, but planning is everything”. The real danger isn’t planning itself, it’s planning in a way that resists change. If we can’t adapt based on new information, we lose the battle before it even begins.
