Software is about people, not code

Dear new developer,

Your code is a means to an end: delivering value to the business paying you.

When I was a new developer, I thought that software development was all about code. After all, code was most of what I worked on.

But the writing of code felt like the most important part of my job. It was the most tangible and fundamental. After all, if the software doesn’t exist, all those other tasks won’t matter, right?

I wanted to be better at writing code; I thought this was the same thing as getting better at developing software.

However, I soon learned that people were more relevant than code to the overall success of a software project. I saw interesting codebases abandoned for lack of a market or other business flaws. For example, I joined a startup building an application which let people browse real estate data on their phone—in 2004, when the user experience of phone apps was miserable. No matter how good the software was, a poor deployment environment doomed the codebase.

At the end of the day, code is a general-purpose tool, like accounting or legal contracts. Lovely software isn’t an end in itself. Instead, software must solve real-world problems of real people.

Sincerely,

Dan

Outcomes over output

Mark Sawers has been practicing software engineering for almost 25 years, as a developer, architect, and manager.

Dear new developer,

As a software engineer , it’s easy to take our eye off the ball. The ball we really want to pay attention to isn’t the stuff we focused on in college. The ball is improving business/organizational outcomes. There isn’t a course of study or advanced degree on this, because it’s bespoke and custom to every organization.

You are on a team in your organization’s grand game to help the underserved, make money for shareholders, find some cure, save the planet, or whatever its mission. A software-intensive system improves information access, automates tasks, entertains, and so on. You pair with your business discipline in conceiving, building, testing, and operating systems that advance the game.

Your real value to your organization is in improving outcomes—not directly in how well you wield language X, tool Y, or process Z, and not in how many features you add in a sprint, how many bugs you fix in one day, how much code you reviewed yesterday, how many answers you posted in Slack, how many documents you wrote last month, and so on. Those are just a means to an end.

Yes, we need to constantly develop and hone technical skills (analysis, modeling, diagramming, programming, unit testing, etc.) and tool knowledge (languages, frameworks, utilities, operating systems, etc.), but don’t mistake this for the endgame.

Yes, we should measure productivity ; we do care about efficiency and throughput. But more product features, the latest tech, continuous deployment, two-factor authentication, and so on are not the goal. More is usually less, in my experience as a user. Isn’t that yours as well?

The goal is not output; the goal is outcome. The outcome is more revenue, more profit, more users, more product availability, happier users … right?

So, wait, isn’t that someone else’s job? What do you know about forecasting and measuring profit, anticipating user needs? Isn’t that on the product owner? The product manager? Marketing? And isn’t uptime the operations team’s responsibility? And finding problems the QA team’s responsibility?

You are on a multidisciplinary team. You have at least one vital role to play on this team. Engineering is your trained discipline, and likely you focused purely on development. The smaller the company/business unit, the more hats you will wear. Yes, your main contribution is technical, but in service of the bottom line. Don’t stay in your lane! Different perspectives are essential to this game.

Your product owner doesn’t have a patent on designing end-user features. And they may not be thinking about measuring success. Help them define the metrics and build those collection and reporting tools into the product. After you deploy a new feature, assess its success; don’t immediately move on to the next feature.

Okay, so do I eat my own dog food? I try. The tech side requires lots of cognitive space, and so outcomes are easily short-shafted. Also, I have found this holistic perspective difficult to practice in large organizations. There is a lot of specialization. It fragments responsibility. Incentives are set along discipline silos. My suggestion is to play your organization’s games (don’t leave that bonus on the table!) but bring your enlightened perspective as best as you can .

Good luck,

Mark

Business process crystallization

Dear new developer,

Software freezes business processes and makes them less flexible. This influences how nontechnical team members think about software and developers.

What’s a business process? These are the series of steps and interactions which are “how things get done” in an organization.

For instance, let’s consider the business process of selling custom software, as you might if you worked as a freelancer.

This is a fluid business process. If I learn I need additional requirements or have questions after I have started coding, I send an email and ask.

There are also constraints on this process, which dictate what can be accomplished when. For example, client sign-off blocks subsequent steps—I won’t move forward without it. Not all steps of a process need to be completed, either. If I can’t write COBOL, but the application is written in that language, the above process will not be completed, at least not by me. I won’t be deploying a code change if I can’t make it. All parties to this business process work within those constraints.

The goal of using software to automate business processes is to make them faster or cheaper. For example, using mail merge saves time when printing out form letters. Automating processes with software has costs, however. Mistakes happen faster as well. People’s ability to handle ambiguity and make human decisions is removed from the process. Processes also become more difficult to change. Instead of changing a document or checklist, a developer must be involved.

So, what happens when a business process should change but has been encoded in software? People are more flexible than computers, so they adjust to the automated process, even if it is partially or completely obsolete. It may force employees to take extra steps or use workarounds. However, if it isn’t worth the investment to change, the software “solution” remains, clogging up the business processes it was meant to assist.

Software can handle vast amounts of data with few errors at superhuman speeds. But it also crystallizes business processes, making change harder. If, like me, you think software is the solution to most business problems, realize that nonengineers understand the downsides and are justifiably wary of software panaceas.

Sincerely,

Dan

Businesses spend money to make money

Dear new developer,

Businesses usually spend money to make money . This is why a business hires you, why it rents that shiny new office building, and why it spends money on tools to help you do your job. It is even why business pays severance. It’s sometimes cheaper to pay employees to leave than to keep them on the payroll; in the long term, the company will make more money by paying people to leave now. In all these cases, the organization writes checks because someone, somewhere, believes that doing so will help the company make more money. Even if you don’t have a voice in any spending decisions, this fact illuminates how and why such decisions are made.

Unlike personal spending, which is rarely an investment that offers a return, business spending is about finding leverage to increase profits. But such spending is always uncertain. If a return was guaranteed, others would notice, step in, and bid up the price of the opportunity. For example, if a business could spend $100 on search engine ads and acquire a new customer worth $110, the company would buy those ads all day long. But other companies would soon bid up the cost of the ads because they’d want to acquire that customer. So taking informed but uncertain bets is part of running a business.

However, making money is not the only reason businesses spend money. Sometimes the CEO wants to burnish their public image. Inertia or unmanaged growth can lead to spending. Whether that poor cash management harms the organization depends on revenue and expenses. For instance, when you are starting up, it makes sense to watch every penny. When a business is established, spending a thousand dollars a month on cloud servers so an engineer can do their work is worthwhile.

At times, it can be hard to know if an expense will lead directly to revenue. If the company donates money to a local charity, will that spending result in valuable publicity or be ignored? No one knows.

What does this mean to you, new developer?

When you join a project or company, consider the economics. How is it going to make money? What are the assumptions? Is there a way to spend money to accelerate delivery and/or revenue? Ask team members how this effort will generate revenue. Asking these questions helps you understand why the project exists; it’s no fun to work on a pointless piece of software. You’ll also get a feel for the kind of bets that this organization takes, including scale, preparatory work, and target market. Finally, you’ll be better equipped to make decisions on the microscale based on macro understanding .

A developer who can execute the details while understanding the big picture is more valuable than someone who can only do the former.

Sincerely,

Dan

Understand the business model

Dear new developer,

A business model is jargon for “how a company makes money in a repeatable profitable fashion.” When you are an employee, your code is written to help execute against this business model. Learning about this lets you make smarter on-the-ground decisions.

To learn about the business model, ask about how your company makes money. Every organization needs revenue, even nonprofits or universities. Make sure you understand what is being sold, whether a product or a service. For large organizations, there may be multiple sources of revenue; in that case, focus on what your department provides.

If no one can explain how the business makes or will make money, then the organization is either nascent and hunting for a business model, or it is in a heap of trouble. The former presents great learning opportunities, if you can handle the risk. The latter should be avoided. Differentiate between the two by asking how many employees the organization has. While there are exceptions, as a rule of thumb, a company with more than ten employees and no business model is firmly in the “heap of trouble” category.

After you know what is being sold, ask how it is produced. Crucially, you want to know how software helps sell more of the product or produces it at a lower cost. This, new developer, is where your skills will be applied. You produce software. By knowing how the business uses it, you can understand what type of problems you’ll be working on.

Identifying the domain in which the business operates also helps you understand what you need to learn. When I was employed by a real estate brokerage, I learned about that business—what is involved when a house changes owners, who owns and distributes housing data, what is the typical flow of a real estate transaction, and even what jargon is used. If your company sells GIS software, learn what GIS stands for, who buys it, and what a customer uses it for. Immerse yourself in the sales and marketing materials for your company and products.

Once you know the domain, the software you write will more directly address the problems of that domain. If problems are common, pattern match to recommend other solutions. For instance, almost every business needs customer relationship management software. An easy way to learn the domain is to create a glossary to ensure common terms are used by both business and software teams. In addition to informing you, such a glossary avoids misunderstandings when a word means different things to different organizational units.

Learn about the problems the business teams face: how do they acquire customers? How do they keep them happy? Offer software techniques to help solve these issues. For example, when I worked at that real estate company, I took a statistics course and researched machine learning libraries because we were building a home value estimation product based on our access to real estate data. The product would have helped us find new customers. Knowing the business domain and needs led me to research appropriate software techniques and technologies.

Another reason to understand how the business incorporates software you build into its revenue generation model is, frankly, a bit gruesome. When the business is under stress due to a recession, you want to be attached to a part of the business that makes money. Knowing the business model and understanding how your software is connected to it allows you to guess how likely it is that you’ll be part of a cost-cutting measure—a layoff. For example, if you are part of a team building the core product, you are less likely to lose your job than if you are working on a research and development project.

Understanding the economic model of your employer will help you communicate with and thrive in a business.

Sincerely,

Dan

No company is a monolith

Dear new developer,

When I was new to the business world, I thought that companies acted rationally and with singular purpose. Boy was I wrong. Businesses are full of people with all the messiness, politics, and unpredictability of any group of humans.

I remember when an old-timer at my first job talked about empire builders. His perspective was that above a certain level in the corporate hierarchy, there’s not much interest in accomplishing company goals. Instead, people want to accumulate more power—budget, headcount, influence. This causes turf wars that can be confusing to people at a lower level in the organization.

I was skeptical when he first mentioned this, but I have seen absurd behavior best explained by this desire with my own eyes. At one point in the mid-2000s, I was hired as a contractor for a relatively high rate. I showed up bright-eyed and bushy-tailed ready to work. But there was nothing to do.

I asked my contracting company what I should do. The answer was “bill 40 hours a week.” I tried to ask my manager about the situation but couldn’t find him—he was in meetings all day long. I asked employees on my team what to do—no one wanted to give me any tasks. To be fair, this was in the middle of an economic downturn. I never found out exactly why I was hired when there was no work for me to do, but I believe the manager was maintaining his budget and headcount. As for me, I spent a lot of time browsing the Internet. I remember browsing a dating site and having a fellow contractor advise me to at least turn my screen so it wasn’t visible from the doorway. I have never felt more useless in my life and left after three months.

Above a certain size, there are factions in a company which affect how you can do your job. By the way, there are factions when an employer is under that size, but the infighting is less frequent, either because there is more cohesion or because the survival of the company is uncertain. Smaller companies have fewer places for people who aren’t pulling their weight to hide. I can’t give you a firm size beyond which factions begin to impact employees, but I do remember a colleague mentioning that at 60, bad apples found hiding spots.

What does this mean for you, new developer? Since companies are composed of people, the interactions between them impact hiring. You may be ignored for reasons entirely unrelated to you or your skills; perhaps the hiring manager is being transferred or losing influence.

If you are an employee, learn the various factions and players. Observe relationships and ask your boss questions, delicately, about the politics of the company. You may want to associate yourself with a faction; a rising camp seems to me to be the best, but fortunes change fast. As you observe these relationships, you’ll start to gain insight into why one project might be funded and another starved.

I should mention an alternative I’ve chosen: avoidance. I have no patience for this kind of stuff. I’d rather find a trustworthy boss and work hard to make him or her look great. That’s probably why I’ve spent most of my life at small companies. But if you’re working in a larger organization, be aware of the existence of internal politics.

Sincerely,

Dan

Where do developers fit in?

Dear new developer,

As a new software developer, knowing how software is used at your employer helps you understand the business. The larger the company, the more likely it is to span categories, however. Certain types of companies will allow you to learn new technologies. Others will provide the opportunity to gain deep business domain knowledge.

Software product companies sell software, typically to other companies—restaurants, other software companies, housing manufacturers—or to individuals: editors, task management systems, bingo card creation for teachers. As a developer in this company, you will learn the intricacies of the customer domain. For instance, I worked at a company which had a software system which prevented texting while driving. I learned about automotive data collection hardware and telco sales cycles. If successful, these companies often have a business model that allows for high margins, which can lead to good salaries and benefits. However, you may find working in the same domain for years to be boring. If established, these companies often use older technologies. Legacy systems make money.

In contrast, consulting companies, which sell developer hours, often move developers between domains. You will get a variety of experience with different business models, customers, and problems. There are often new, “green field” projects to work on which usually mean new technologies to learn. An hour worked for a client is an hour billed, so your efforts are directly related to revenue.

If you are looking to eventually start your own company, consulting businesses have low barriers to entry: no overhead and no up-front investment in building a product. You only need a laptop, an Internet connection, and someone willing to hire you. However, if this business model seems attractive, be aware that until the company attains a certain size, your revenue is tightly coupled to your time, which can make vacation hard to take.

On the other hand, as an employee of a consulting company, know there is no exit strategy for the founders and that the value of the business is often tightly coupled to their skill sets, especially if the company is small. While some consulting companies have products to sell, there is usually limited recurring revenue. This means that the business goes through cycles of growing and shrinking as client needs change. Because of this sales cycle, the company may take on less exciting projects to pay the bills, projects that you may have to work on. Many consulting companies I’ve been part of have tried to specialize, but few have had the cash position to turn down lucrative projects when payroll was due. Consulting projects can have tight deadlines which may lead to excessive hours.

And then there’s all the rest of the companies. These companies use software. It may even be core to their business, but as an enabler, not as a revenue-generating product. Examples include service companies like real estate brokerages or vinyl banner manufacturing companies. These businesses are often stable and profitable. Software quality and process tend to be less mature, though this obviously varies. If the process quality is lower, introducing better ones will be a competitive advantage. Unlike consulting companies, you’ll be immersed in the business domain and will learn it well.

However, if developers aren’t directly tied to revenue generation, they won’t be as highly valued—or paid. Software engineering teams can be viewed as an expense rather than an asset. If the company is small, you may be alone, limiting your capacity for growth. Leadership may not understand or care about the difficulties of software development.

Knowing how your business uses software will help you understand how they view developers. This reveals the challenges and opportunities awaiting you.

Sincerely,

Dan

Hammers

Dear new developer,

I was talking to a friend the other day about differences between small and big company life, and he used a metaphor so good I’m going to steal it.

Imagine a problem is a rock. Your employer is a hammer with which to carve said rock into a beautiful sculpture—that is to say, to solve the problem. As an employee, you can join a small nimble company, which is like a brick hammer, or a large, slower-moving organization, more like a sledgehammer.

The smaller the hammer , the easier it is to pick up, manipulate, and reorient if you need to approach the rock from a different angle. In the same way, a small company can choose different approaches to their problem and quickly rework processes.

If one, on the other hand, chooses the sledgehammer to shape the rock, there’s a lot of force in each swing, but not much precision. This power makes progress easier if the initial approach is correct. But if change is required, it’s more effort. The weight of the hammer makes it harder to reorient. Large companies can solve big problems but don’t shift direction easily.

Certain problems are amenable to bigger hammers—anything that requires a long sales cycle, large amounts of capital, or extensive research and development. Other problems are suited to a small hammer—small markets or uncertain domains where nimble experimentation is rewarded.

The larger the business, the more leverage and power can be brought to bear. I’ve worked at big companies, and I can tell you they were working on problems of tremendous size and scope. However, a lot of time and effort was spent coordinating those endeavors. Process changes required navigating bureaucracy and red tape.

At a smaller company or a startup, teams I was on didn’t have bandwidth to take on multiple projects. Doing more than one or at most two projects was a recipe for distraction and inefficiency. However, it was easy to try different approaches and incorporate customer feedback. This flexibility extended to my job definition as well. At a smaller company, I’ve been expected to perform a variety of roles and adapt to changing situations. I worked at a startup where I had two CEOs and four different jobs in eight months—with not a formal job description in sight.

Both big hammers and small hammers chisel a rock; both big companies and small organizations solve problems. The type of a company affects how they go about doing so .

Sincerely,

Dan

Starting a company

Dear new developer,

Later in your career, you may want to run your own company. I would not advise doing so as a new developer, because running a business is at least as complicated as writing software. If you are learning both at once, you’re setting yourself up for a world of stress.

Eventually, if you decide that you want to build a software company, you may decide to self-fund the effort. Self-funding means you only spend money that you have saved or that the business can earn. The other path is raising funding from investors, but that’s riskier in some ways. By accepting outside money, you now have to satisfy both your customers and your investors.

If you do start a company, with success you’ll move away from coding day to day. One of the benefits of building a company is that you can scale up and work on bigger problems. But to do so, you’ll have to accept more distance from the actual writing of software. Over the years, I’ve seen many companies grow from founders to tens or hundreds of people. In almost every case, the founders moved toward management or a strategic role and away from the code.

Sincerely,

Dan

Learn from your customers

Dear new developer,

I love to learn from customers who buy or use the products I make. It’s a great opportunity for me to interact with folks whose lives my work is improving. Well, hopefully improving—if not they’ll tell me. Having direct feedback from them will help me build better software.

Now, the ways you can do this differ based on the size and type of your company. If you want feedback, ask your team how they get it now. Participating in customer support and reaching out and proactively talking to customers are great ways to get insights.

In the past, teams I have been on have used ticketing systems such as Zendesk or a common email inbox to coordinate customer support. I got an account on these systems and answered emails or closed tickets. This gave me a feel for the rough edges of the product and helped build empathy for users: “why couldn’t they see that to do task XYZ, you just click here and then here and then… oh, that’s why. Oh. Ohhhh.”

If you do this, you will also learn the surprising ways your product or service is used. This may reveal flaws or bugs—those you can file and fix to make the experience better. Even if you aren’t fixing support issues, simply reading them will give you an awareness of problematic areas of your offering. However, you will get a biased view of your customers if you only look at support tickets; very few happy customers open support requests.

For an alternative view, consider scheduling a monthly meeting with customers. Aim for 15 minutes to an hour in duration. Having this meeting lets you hear directly from them what they like about the product and, more importantly, what is missing or broken. Customers also enjoy direct access to a developer—this may be a new experience for them and can enhance customer loyalty. If you are in a meeting, take notes or, with permission, record the call. This will let you go back and review the details of the feedback when needed.

When I did this, I rotated between different customers; getting multiple viewpoints helped me triangulate. If an issue was common across multiple users, it was higher priority. Capture the feedback in a tracking system, even if you don’t address the issues raised immediately. These in-person calls also let me inform customers of new or relevant features. Frankly, at times I found this meeting exhausting because of the offhanded feature requests. When combined with my engineering mindset—as soon as I hear a problem, I think “what would it take to implement that?”—I often felt overwhelmed. Try to avoid that mindset and be an open listener. Focus on the problems mentioned, not the client’s proposed solutions.

If you seek out direct customer feedback , you’ll deliver less code. However, you’re more likely to deliver useful functionality. Don’t get defensive when your product is criticized. Customers pay you money and want the product to work for them. Remember to seek out customers with a variety of perspectives. You don’t want feedback only from new customers or power users.

Don’t commit to anything during your interaction. It’s better to have such suggestions proceed through the normal planning process. Especially as a new developer, you may not have the authority to make such commitments anyway. Check with your team to see if you can share the product road map if the customer asks.

Finally, when seeking feedback, ask the customers about their pressing problems, even if beyond the scope of your solution. In this way, you’ll gain insight into problems they may have that are adjacent to your systems. This can lead to interesting new directions for your software.

Customer service requires different skills than developing software. I find it choppy. You encounter folks who are having a rough day and who might take it out on you. But customer service also makes sure that you, the person helping build the software, understand what your customers and users experience .

Sincerely,

Dan

In conclusion

As a developer, I find it easy to get wrapped up in code. After all, I like to write it. It appears to be the fundamental deliverable of software teams—no code, no value. I find software engineering, and the related disciplines of architecture and software design, mentally engaging.

However, it’s worth remembering when you are slinging code for an employer that they have larger goals. Learn about the business, including domain terms, strategic objectives, and decision-making processes. Knowing how the business works allows you to write software more effectively and to lower the communication barrier between teams.