💰 Code with Purpose: Business Value Is definitely Your Job as a Software Engineer 🔧

⏩ Introduction

I read this article this summer: Business Value Isn't My Job and it was so painful to read that I immediately planned to restart the newsletter today with some reflection on the topic.

I invite you to read it, but here is a quick recap just to set up the stage for my thoughts: the author, Bryan Finster, talked about a conversation he had with a developer stating that a Software Engineer only needs to bring to the table their technical knowledge, and if a company need a domain expert they will hire one.

Bryan expressed his pain on hearing that, and I couldn’t agree more than that with him: the fact that some experienced developers might think that is very sad.

A couple of other very bad things that this person said to Bryan: “If the business tanks and you’ve fulfilled your role as efficiently as possible why would you care? The market is begging for good SWEs.” - or “As a software engineer, it’s not our job to drive business value.”

Go to the article to read it all: if you suffered like I did when reading such things, you will love Bryan's reflection on that - and hopefully also mine once you are back here.

🎨 Once you understand the business value, your value is 10x

You know what they say, right?

The operation was successful, but the patient died.

If you are perfect technically, and then the business doesn’t work, it’s (also) your responsibility to understand why and how to make it work. It just is.

That is actually the real job!

We bring our technical knowledge to the table, yes - but only to cooperate with the skills of the others so that the company makes money. This has multiple consequences, and while some imply how we should technically approach the job, some others actually imply that we must become a domain expert on our company business and the way our company is trying to make money in that business.

On the technical side, for example, we should be able to develop software in a way that lowers the risks for the business to the minimum possible: This includes, for example, being able to build MVP in a short time, or making experiments and A/B testing very cheap. This can all be conducted by having code that is easy to change - and I immediately think of Test-Driven Development, Continuous Integration, Continuous Deployment, Trunk-Based Development, Domain-Driven Design, etc.

All those amazing, top-notch practices have one thing in common - the same thing shared by Lean, XP, and Agile in general: they are not just practices to make the life of developers better or make the job more fun - they are practices that maximize the competitive advantage that business has with its own technology; they enable business moving fast, adapting to changes in real-world, spending just enough needed in a feature, etc. They are a smart choice to support the business, not just because of technicalities.

But that is not enough!

It is fundamental to understand how business works to be successful: you need to know which business you work on, how important it is for people and for society, who are your customers, how much money is involved in that business, etc.

Why is all that information important? Because they should impact your decisions!

Imagine you work for an e-commerce company selling shoes: the type of shoes you sell is a fundamental thing to know. If you sell baby shoes, the actual customers of the shop are the parents. If you sell only shoes that cost thousands of euros, your customers are very rich people.

This information will impact all the company parts, software engineering included:

• marketing will focus on communication and advertisements for parents/rich people

• UX in the first case will probably need to be simple, while in the second you might want to test something that makes people feel to be in an exclusive, premium shop because rich people are used to feeling special

• products we offer will probably have different materials and costs, since baby shoes need to be comfortable but will be used for some months, while premium shoes must last all life and might not even be used once

Let’s come to the impact on software development and imagine the cost of a bug coming to production: we can assume that in both cases, bugs will not have much impact in real life, because people will be fine if they can’t buy some shoes due to a bug; on the other hand, the impact on the company success will be different due to a different cost and profit for the two type of products, that will be higher in the premium shoes example, meaning more money lost due to the bug.

In both cases, the basic technology behind is fairly standard: just e-commerce. But if we try to imagine 10 years for the two companies, while the baby shoes shop could live with a no-code/low-code solution for its entire life, the second one could probably need an internal codebase at least for a part of the shop, to enable the chances to offer Premium features to rich people that are so addicted to being treated as VIP.

The miscommunication of this information between the management and the product team on these kinds of topics is one of the biggest causes of problems in a company. But don’t make the mistake of thinking that “if they don’t tell me, it’s their fault”: If you accept that, and do nothing to make them understand how important it is for the team to know such information and daily communicate with the stakeholders and customers, then you are part of the problem.

The “product team” is not a company team working on product knowledge - is a team of people working on a specific product; it’s cross-functional, including stakeholders, PM, Marketing, UX, Dev, Ops, etc. Everyone should be on the same product team. Companies should organize themselves into product cross-functional teams, not in Marketing/Product/Tech, etc. People with similar tasks should find other ways to align on how companies do things in their skill context but work daily with other members of the product team.

Remember this: if you are able to have a visible impact on business with your job, you will be irreplaceable - no AI can get your place because it’s your unique impact as a human being that makes a difference in the team and the company, not just a technical skill.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

You probably all know already what I think about our job: we are problem solvers. Code is just one of the tools in our toolbox - no-code and low-code tools can be another, like AI, but also communication, the ability to get feedback quickly, etc.

I know that a lot of developers start this job because “they prefer machines to humans” - the fact is this is movie stuff. In real life, we build applications for people: we need to solve their problems so that they are happy to use our tool; we also need to communicate well with our teammates, stakeholders, and customers continuously.

If we don’t do this, the company will not make money and will not be able to pay the salaries and eventually, not even survive. Or if it will, it will be supported by bad practices and bring problems, extra hours, pressure, stress, etc.

I think that working only on technicalities is acceptable for juniors/middle developers - but once you gain seniority and want to level up your impact, you need to consider the business context in your daily work.

Too many developers want to work only on technicalities and ignore the impact or success of the business; this is very bad, and in my experience, there are 3 main problems that led us to this situation:

• Bad tech management and wrong incentives

Did someone say Leetcode? Or measuring developer productivity in lines of code or time spent in coding? Those two are the perfect examples of how to NOT evaluate a software engineer. I’ll repeat once again: we are problem solvers, not code monkeys.

If a stakeholder just comes to us and tells us what to develop, we miss a lot of opportunities: a stakeholder does not have enough knowledge of the system and the technology we use to support the business, so his solutions will be limited. They also have their own point of view, while the product team is serving probably multiple users/stakeholders. At the same time, a great software developer has a great ability to split a problem into smaller ones and reduce risks.

To reach success in a smooth way, a company needs to give trust, autonomy, and responsibility to the product team, and let them discuss directly and continuously with customers and stakeholders so that they can add value daily.

• Bad storytelling on what software development actually is

There is a lot of content out there, and to create content you just need to know a bit about something. Take me, for example: I’m no genius or expert - I’m just passionate about Agile practices and methodologies, and realized how much game changing are; I was one of those who didn’t know about those practices, so now I talk about them to help people know them.

But I think that it’s important for anyone to always remember that this is a field where you never stop learning, there is always a better way to do things, and solving problems often has counterintuitive solutions.

Still, it seems to me that people forget this and give up on the fear of changing: when I mention Trunk-based Development, I’m looked at as an alien; the same happens when I say that TDD is much more than just “writing tests before” and is a multiplier of impact for a software developer.

A lot of skepticism is still there - and sometimes I also feel we are a bit spoiled: one of the biggest criticisms I hear about Pair/Mob programming nowadays is that when working remotely, async first is fundamental. I strongly disagree, at least when it comes to software development.

Basically, all the “best practices” of async work are against the Agile manifesto: documentation is useful, but if we use it to avoid conversation even with team members (for example throwing documentation to someone new as onboarding) we are not favoring “Individuals and interactions over processes and tools”, or “working software over comprehensive documentation” - actually we are doing the reverse. Documentation is needed, for sure, but not in replacement of speaking to each other.

Coding, and developing software in general (from creating an MVP to measuring the success of a feature, getting feedback, brainstorming ideas, etc.) are all things that work best in sync - at least most of it. A retrospective is one of the easier examples: we can collect topics of everyone in async, that is good and optimizes time waste; we might even push this and collect short videos that explain the topics, and also have the team vote for the topics in async. But then we need to have the conversation between all team members, which is the actual value of it - and that should happen in sync, otherwise, it would just lose effect.

Async pull requests bring a lot of issues, compared to pair/mob and working together continuously. The first approach to Trunk-based? Work with branches, but give yourself the objective to make it last only one day - when the time for merging has come, you will need to understand how to merge something releasable, and you will need a quick PR, that is only possible if we have a trustable test suite and we are continuously talking to each other so that everyone is aligned on what we are working on and review is quick and easy since it’s small - even better if done in pair.

But then people tell me: “ok, but if we work async I can go to the gym at the time I want”. I understand that it’s hard to lose this kind of benefits, but let’s think about it:

1. First of all, we are still working, so is our responsibility, to be professional, and to at least be aware that working async is a big trade-off - we lose effectiveness in favor of some other benefits

2. If we apply Agile top practices, it means we work in Trunk-based and Mob programming as default: when mobbing, there are team breaks, but still, everyone who is not at the keyboard can leave the room for any reason whenever they need to (and the driver should change very often) - so there is no impact on freedom, in fact, it’s actually the reverse

3. Applying those practices, unplanned work will be very very limited, removing most emergencies from the table

But this approach requires skills, willingness to improve and collaborate, being responsible and professional… a lot of hard things - but hey, it’s work, and we are paid well because it’s hard so we should strive to do our best. And that brings me to the last point…

• Not everyone is willing to put that much effort into the job

Let’s face reality, not everyone approaches his job with the desire to become great at it - and software development makes no exception. Someone might argue that a lot of people do this job because they love it and it’s their passion: this is true for sure, but it also becomes a trap sometimes. I’ve seen a lot of developers that want to focus only on what they like, no matter if it’s the best for business or not. But if trying a new technology is more important than making the business succeed, we are failing as professionals.

Also, especially in recent years, people are now coming across this job just because there are a lot of chances and possibilities, and they lost their job or had an unsatisfying one and want to change their life. This is totally fine, and is actually cool, IMHO, how many possibilities this world is still offering - but we can’t expect that a person approaching a job with that mindset will have the desire to improve that much. Sometimes, understanding that you can ask for more money if you master such skills is enough - but sometimes people are just fine with what they have.

So, what can we do? I think we need to inspire people to do better, and also be patient on all the resistance they might have. Lead by example, by proofing the benefits and then make people try! It’s a long journey, but it leads to success!

Years ago I took for granted that all software developers had the passion and willingness to improve every day, without any prejudice.

That’s not actually the case, in reality, but it’s true that software developers mostly share a growth mindset: let’s keep focusing on that and help each other be the best software developers we can be.

Go Deeper 🔎

📚 Books

• The Clean Coder: A Code of Conduct for Professional Programmers - In The Clean Coder: A Code of Conduct for Professional Programmers, legendary software expert Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing. It covers much more than technique: It is about attitude.

• Professional PHP: Building maintainable and secure applications - a very great book, focused on examples in PHP but valuable in any language if you are able to abstract from the language. The book is structured as a tutorial and will guide you through the steps of building a modern web application from scratch.

• The Pragmatic Programmer - Brings together pragmatic advice on everything from personal career fulfilment to more effective architecture.

📩 Newsletter issues

• Why most software teams are inefficient [Craft Better Software newsletter by Daniel Moka]

• Clean Code Takes Priority: Choosing Readability Over Speed [I code it newsletter by Juntao Qiu]

• Why Should Anyone Care about Clean Code Development? [Clean Code Development newsletter by Ralf Westphal]

📄 Blog posts

• Business Value Isn't My Job - the post that inspired this issue

• 12 Essential Habits to Learn to Become a Professional Software Developer

• On Being a Professional Software Engineer

• Continuing Learning In Software Development

🎙️ Podcast episodes

• Habits of Successful Software Engineers - Getting to Code Quickly and Model Thinking [Developer Tea podcast]

• How to Learn Efficiently in Software Development [Simple Programmer Podcast]

• Beyond Becoming a Software Engineer [Think Like a Developer]