Great software engineers understand more than code

Hiring good software engineers is notoriously challenging. Evaluating someone’s ability to do the job based on their current skill level and previous experience can be difficult, especially if the code they’ve written in the past is proprietary and therefore unavailable for you to assess. One of the ways companies often address this challenge is by giving candidates code exercises and tests. While these tests and exercises may provide a glimpse into how well a potential hire knows a particular programming language or understands principles of code logic and software organization, they often fail to reveal how well the person understands business logic and whether or not they’ll quickly learn the necessary details of your particular industry. Some software teams may not care about that, but we at Mailprotector believe understanding business logic and knowing the industry our software serves is just as important as coding skills for software engineers, perhaps even more so with the rise of AI coding agents.

Why business logic and industry knowledge are so important#

For software applications, business logic is the what and why to the computer code’s how. It answers the questions of what should the software do and why should it do that (as opposed to doing something else). The how—the actual code that is written—is certainly important, but only after determining the what and why.

Some companies have product managers who make decisions about what and why and then draw up detailed requirements that are passed to the programmers who then build it. Everything is laid out in detail for the programmer and they simply write the code to make it happen. We don’t operate that way at Mailprotector. Our software engineers are responsible for making decisions beyond just the code level. They are vitally involved in decisions about how to approach the problems our software is trying to solve. That means they need to understand not just the logic of computer code but also the logic of our business decisions.

When we receive feedback from our partners about problems they’re trying to solve and challenges they’re facing, we don’t simply turn that feedback directly into feature requests for our software. We seek to understand the root of the problem itself by asking a lot of questions: where specifically is the pain-point, what situations are causing it, what is the current process for working around it, what is the desired outcome, etc. The answers to these questions, and any other details we receive, are all evaluated from a business logic perspective first, before we ever consider how the solution might be implemented in code. This is especially critical in an industry like email security where many official and unofficial protocols exist for expected behavior and a few very large companies have established precedents that often dictate those expectations (you can probably guess who those companies are).

A software engineer who can write well structured, clean, organized, descriptive, beautiful computer code in the abstract but struggles to grasp the underlying business logic of the software application and its real-world uses will be a liability rather than an asset. Real software is never written in the abstract. Creating and maintaining functional software requires concrete decisions about how to handle concrete data to produce concrete outcomes. At Mailprotector, we care deeply about well written code, but we also care deeply about making sure that code accomplishes its intended purpose for those who use it, and that fundamentally comes back to business logic and industry understanding.

The how of writing software#

Earlier I said that business logic is the what and why of writing software, but I need to correct that. Even the how involves business logic in addition to decisions about what the actual code will look like.

Data storage and relationships

Questions about how to store data are also fundamentally about knowing the specific industry for your software. Deciding on the relationships between objects (data) in the database is as much about business logic as it is about code structure. How do we keep track of emails that arrive with multiple recipients? How do we store BCC recipient addresses, which show up on the SMTP envelope but not in any of the headers (which only show TO and CC recipients)? What about attachments, results from scanning, and decisions on what to do with the email? How do we keep track of where a recipient wants certain messages delivered? How do we store preferences for various email authentication results (SPF results, DKIM results, etc.)? All of these questions are certainly coding questions, but they’re also business logic questions and getting these right is crucial for our software to function the way users want it to function.

Data transformation

Software in general, and email software especially, is not simply about storing and retrieving data but also about examining, evaluating, and transforming data (in order to do things like remove tracking pixels or safely preview attachments, for example). All of that involves numerous decisions about what to do to any given email (accept it, bounce it, put it in the user’s mailbox, put it in junk, etc.), and when to do it and when not to do it (what conditions should trigger each of those results). These questions are again fundamentally not just about the code itself but also about how we approach email security from an industry and business logic standpoint.

A note about AI coding agents#

All of these points were already true before the massive growth of AI coding tools, but they are even more true now that AI tools are so adept at writing the actual code. Many software engineers, including those at Mailprotector, are embracing a new workflow that focuses the human effort on planning and design for what the code will do (in other words, focusing on business logic) in order to provide the AI coding tool the best possible directions for how to organize and write the actual code. Then the output of the coding agent is reviewed by the engineer to ensure it fulfills those requirements and delivers the right solution. If the code needs revision, the engineer’s input usually comes from understanding the business logic and industry, not from a better grasp of code syntax or language best practices (where AI coding tools can now outperform even the most experienced software engineers).

We can think of the software development process comprising three layers: a planning and design layer where decisions are made about what to build and why, an execution layer where the code is actually written, and then a follow up layer involving review and assessment to ensure the software delivers what it’s intended to deliver. In this model, the first layer involves significant business logic and industry understanding, with some considerations for code structure, and the third layer also requires skill in both areas. The middle layer is the one that is focused most heavily on coding skills, but it is also the layer that is more and more being handed over to AI tools (see this section of a paper by Arvind Narayanan and Sayash Kapoor for a more detailed discussion of this layer model).

What this means for hiring#

It’s common for software companies to emphasize coding skills when looking to hire new developers or evaluate current employees. Some even give coding assessments that are completely detached from the real-world software they actually build. While it is helpful to evaluate whether or not a potential new-hire software engineer can actually write good code, it’s also crucial to evaluate whether or not they can learn industry specific business logic as well. Admittedly this can be harder to determine, but there are ways to assess this ability and it’s important to continue to emphasize growth in this area as new hires gain experience in the company.

Perhaps an analogy will be helpful in making clear what I’m trying to say. Writing software might be compared to another type of writing, that of the persuasive paper. The software engineer who writes well structured, clean, and beautiful code in the abstract but struggles to grasp the underlying business logic of the software application and the industry it serves is like the person who writes a persuasive paper that is well structured with beautiful, descriptive words, proper grammar, and flowing sentences but doesn’t actually say anything of substance in the content of the paper or, even worse, says contradictory things. Ultimately, the form doesn’t matter much if the content isn’t right. The same is true for software; the code doesn’t matter if the business logic isn’t right.