A long time ago, I was in Barcelona attending an API workshop with our teams there. On the second day of the workshop, the discussion got a bit sidetracked, but it was one of those sidetracks that leads to insights that are more valuable than the main theme of the workshop. I remember the group CTO at the time declaring “Developers write code, Software Engineers solve problems!". For some reason it struck me as such a profound statement, that I still remember it to this day as the main idea of value I got that day.

Now, to many that might sound like a trivial distinction worth no further thought, but all of a sudden I could see the impact into so many patterns of behavior that we engage in as Software Engineers, and which fundamentally impact how effective we are at our job. These include all of the classic trade-offs we find ourselves troubled by, including:

• Extracting business value vs. controlling technical debt
• Features vs. non-functional requirements
• Mature vs. cutting edge technology
• (True) Agility vs. Efficiency

To illustrate by example, I'll share a different incident, that also stuck in my memory: When I was at eBay, I remember a discussion ensuing between the developers of a product, and their product owner, regarding the remaining bugs in the product. The developers wanted to do a concerted effort to remove the remaining last few known bugs, and put in place automated tests to prevent them from reappearing. The PO had different priorities - he wanted to focus on the product UI. He finally found the way to express why:

“Look, when something goes wrong on the site and we lose money, it's almost never because of a bug. In the majority of the cases, it's because of user error, due to the fact that our product is confusing, or allows too many opportunities for the user to make a mistake. If we want to help the business reduce losses, we can have much more impact by going after those opportunities for error, than by going after the bugs!”

When you reduce the issue to its core, the developers were trying to optimize for a well-coded application, but would have been addressing the wrong problem. Instead they followed their PO into a path that solved the revenue loss problem (and IMHO became true Software Engineers).

Stepping back a little to see the big picture, Software Engineers need to reduce their focus on code. Yes, it is still how we get things done, and, at the end of the day, our most concrete output. But we actually need to concern ourselves with much more than that. Not just the (by now) cliché of knowing the user and how they use the product, but of knowing a little bit about every role that we come in contact with. We need to understand a bit about the cost of running the business, the value chain we are part of, the competitive landscape, how our product is sold, how is marketed, how it is implemented, and how it is supported. We don't need to be proficient at these topics, but we can't ignore them with the indifference of “It's not my job”. If we do so, then the people whose job it is will expect to be able to make the decisions that impact all those objectives, even it restricts us as engineers. Conversely, if we expect to be allowed to make those decisions just because they are technical, then we need to be able to reason about the objectives we are impacting, and negotiate with the people who are held responsible for them.

I guess when all is said and done, one could argue that either of those options is viable, and it is merely a matter of personal and organizational preference. With that said, I think that being a contributor of very narrow applicability (however capable) is of lesser value than being able to solve problems for the business you are part of. I, certainly, would prefer to learn more than just coding, and be able to have a wider impact. How about you?