I Thought Code Would Be the Hard Part
When I first started learning software engineering, I thought the hardest part of the job would be writing code. I imagined myself spending my days solving difficult algorithms, designing complex systems, and debugging mysterious issues. And to be fair, those things can be challenging. But after working in the industry for years, I realised that code is often the easiest part. The harder part is people.
Every Feature Starts With an Idea
Every feature starts with an idea. Usually, the idea does not come from the engineers. It comes from product managers, department heads, business teams, or leadership. They identify a problem, see an opportunity, or have a vision for something they want to launch. The engineering team then figures out how to make it happen. Most of the time, these discussions are productive. Stakeholders explain what they want to achieve, engineers explain what is technically possible, and together everyone works towards the same goal, in theory.
When “Simple” Isn’t Simple
In reality, things are rarely that straightforward. Sometimes a feature sounds simple until we start digging into the details. A request that looked like a two-week project suddenly reveals dependencies, technical limitations, data problems, legal considerations, or infrastructure constraints that nobody anticipated. This is where good stakeholders make a huge difference. The best managers and product leaders I have worked with do not immediately demand answers. Instead, they give the team space to investigate. They allow engineers to research, reason through the problem, map out risks, and propose alternatives. Rather than asking, “Why can’t this be done?” They ask, “How can we make this work?” That shift in mindset makes an enormous difference.
The Problem Nobody Talks About: Ego
Unfortunately, not every challenge is technical. One topic people rarely discuss openly is ego. Talking about personalities can sound negative. It can sound like complaining about colleagues or criticising a company. But if I am being honest, some of the biggest obstacles I have encountered in projects were not technical problems. They were people problems. Sometimes individuals become attached to their ideas. Sometimes feedback is taken personally. Sometimes decisions become less about finding the best solution and more about proving who is right.
Technical Problems Have Solutions. People Problems Often Don’t.
The interesting thing is that technical problems usually have solutions. You can redesign a system. You can improve performance, rewrite code and build workarounds. People problems are often much harder. A project can have brilliant engineers, great technology, and a clear roadmap, but still struggle if people are unwilling to cooperate. Good attitude, humility, and a willingness to work together are often more valuable than technical brilliance.
Too Many Cooks
Another challenge I did not expect was how long product decisions can take. There is a saying: too many cooks spoil the broth. I have seen this happen many times. A team starts with a simple idea for a minimum viable product. Then feedback starts arriving. One person wants another feature. Someone else wants a different workflow. Another person wants additional reporting. A fourth person thinks the design should change.
None of these suggestions are necessarily bad. The problem is that when everyone contributes ideas, the original goal can become buried under endless revisions. Instead of shipping something quickly and learning from real users, the team spends months refining something that may never prove its value. Sometimes the fastest way to learn is to release a simple version and improve it later.
Nothing Stays Urgent Forever
Then there are priorities and deadlines. When I was younger, I assumed projects followed a predictable path. Requirements would be defined. Engineers would build the solution. The feature would launch. Everyone would move on to the next thing. In reality, priorities shift constantly. A stakeholder changes direction. A business opportunity appears. Resources become limited. A production issue demands immediate attention. A new request suddenly becomes more important than everything else. Projects that seemed urgent last month can become irrelevant today. At first, this felt frustrating. Over time, I realised it is simply part of working in a business.
Building the Right Things at the Right Time
Companies are constantly balancing opportunities, risks, resources, and market demands. Engineering is not just about building things. It is about building the right things at the right time. Writing code is still an important skill. But after years in the industry, I no longer think it is the hardest part of software engineering. The hardest part is aligning different people, priorities, opinions, and constraints towards a common goal. The code eventually gets written either by human or now by AI.
If you like my articles please like, comment and share, I’d love to hear your feedback. See you in the next post!
Leave a Reply