Not All Solutions Involve Writing Code

As a software developer, you spend a lot of time studying, thinking about, and writing code. It’s in the name, right? There’s nothing inherently wrong with that. There is, however, a problem when you actually start doing the job.

You aren’t paid to write code (despite what you and, likely, your boss think).

You’re paid to solve business problems.

You get the job by proving that you can code. You do the job by solving pain points for the business, helping open new markets, improving operational efficiency, etc. When you’re more junior, that almost always involves writing code. As you get farther along in your career, you start looking at things more strategically (or at least you should).

Some bosses are of the opinion that you are just there to write code and that they are paid to come up with all of the answers, so you need to sit down and be a brain attached to a keyboard. Those bosses are incredibly wrong about a lot of things (as well as potentially harmful to your career and even your health). If you run into one, get out as quickly as you reasonably can.

So, working on the premise that your job is to solve business problems, what does that entail?

It involves a lot of communication and collaboration (apologies to those of you who got into this line of work to avoid dealing with people). You have to understand the problem in order to help solve it. You also need to understand the reasoning behind why the problem needs to be solved, if there is a threshold for time/expense where a solution becomes impractical/untenable, and (ideally) how this solution fits into the wider ecosystem that the company operates in.

That sounds really complicated, but it can be translated into plain English as – what is the problem? What does it keep us from doing? What’s our budget (both money and time)? How does this work with the rest of the business?

You also want to make sure that the problem the business wants you to solve is actually the problem and not just a symptom of the problem. (Trying to solve symptoms instead of the real problem happens a lot more often than you’d believe)

As you work through this, you may find out that the solution to the problem in front of you doesn’t actually need to involve code (or at least not nearly to the scale that everyone thinks at first).

Sometimes you find out the problem is a one-time issue that can be more effectively done by a manual process (Heresy, I know, but even Google admits this. One of the exceptions is in highly regulated environments where literally everything has to be automated in order to have an audit trail). Would you spend days, or even weeks, automating something that can be done manually in 20 minutes and only has to be done once (or maybe once a year)?

Sometimes you find out that the problem can be easily solved by tools that you already have – a spreadsheet is a good example. You don’t necessarily have to make a slick new site with a whizbang frontend if all someone needs is a table of data to look at for reporting purposes (sometimes it makes sense to go all out, but again, weigh the cost vs benefit). If you can write a couple of lines of SQL and dump the result into a spreadsheet, why would you spend weeks writing a page used by one or two people?

Sometimes you find that the problem doesn’t actually need to be solved. It may be that it’s a vanity project for someone higher up (in which case, you may still end up having to do it – costing the business money and costing you sanity. Hopefully you get to work with some cool new tech to add to your resume.) It may be that they misunderstood the problem and this comes out during conversations around how to address it. It may even be that, given the time and budget constraints, that it doesn’t actually need to be done because it doesn’t provide a benefit that outweighs the cost.

None of these things are always going to be the case. In fact, most of the time, the business problems you solve are going to involve writing code (which is good, because writing code can be fun. At the very least, it looks good on your resume – but so does delivering business results). Just enter into this as a stakeholder instead of someone who simply acts as a unit of output (that doesn’t look good on your resume, and it’s not a happy place to be eight hours a day).

At the very least, going through this process can lead to better outcomes for both you and the business because you will all actually understand the goals you’re trying to achieve and the benefits they bring to the larger organization.

, , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: