Great Ideas from Terrible Jobs

As long-time readers might know, I tend to resist talking about specifics of my life and career on this blog. I do this partly because I don’t find those anecdotes useful outside my social circle swapping stories, partly because I don’t want to become a gossip, and partly because I’d just as soon not subject readers to me working through my emotions. I try not to say anything about former (or current) employers and colleagues, because sloppy phrasing on my part or a misinterpretation on someone else’s part makes me look irresponsible or malicious, or makes those colleagues look bad, and I don’t find either outcome acceptable.

That said, sometimes I (partly) regret that policy, because I sometimes find gems buried in the garbage. As a result, I want to talk about some of the best guidelines/advice that I’ve gotten in my career. By purest coincidence, these ideas have come from some of the worst jobs that I’ve ever worked, which amuses me.

As always, I won’t identify the team(s), but I do want to make the point that even a terrible job can have some occasional benefits…

Understanding Sales

At one office, our manager announced at a meeting that from then on, the entire corporation would follow the management process of an enormous software company. It sounded like a joke, since we didn’t have nearly the workforce or revenue of the role-model company, and published management processes always fight the battles of the previous decade instead of the current one. We certainly didn’t have enough work to warrant a formal management structure. But we had to pass a quiz to stay employed, so I read through the material.

Side note: I will say that I didn’t need to read the material. You wouldn’t need to read the material, either. Any of us could have taken the multiple-choice quiz and figured out the right answer by ruling out the answers that sounded like jokes.

Anyway, one idea in the literature grabbed attention, as I read through everything. I paraphrase, but they mentioned something like this, as one of their principles.

Every employee is a salesperson.

At first blush, that sounds counter-intuitive. I, a software engineer, don’t sell anything. Certainly, nobody pays me a commission for every purchase.

However, they meant that every decision in the organization influences the customer’s decision of whether to spend money. As developers, we make implementation and design decisions, we prioritize bugs, and we hit or miss deadlines, and all those choices can chance a prospective customer’s decision in any direction.

Moreover, people who don’t directly touch the product influence those who do. The IT team, the maintenance workers, the office manager, and others—when we work in a shared office, at least—can make it easier or more difficult to make the choices that have a direct effect on things.

It might not always seem like it, but at work, all of us interact with the customers all the time, even if we never know those customers.

Return on Investment

At another job, still fairly green, I proposed a dramatic change to how the product worked. My manager gave me a straightforward directive on that idea, neither accepting nor refusing it.

Write up the cost of doing it your way, against the expected change in revenue.

When I admitted to not knowing those numbers, the manager instructed me to come back after I found out.

You can probably see where this story goes, already. Every effort takes up somebody’s time, during which they could have worked on anything else. And because every decision affects who buys the product (see above), every effort also affects how much money we have available.

Notice that “revenue” actually overstates things. You actually want to consider revenue and savings.

Consider some examples, since that all feels extremely abstract.

Example #1 — Rewriting Code

If I want to rewrite ten thousand lines of old C code in JavaScript, we have to take the following costs into account.

• Developer time: The best estimate that I can find looks like an average programmer writes an average of ten to twenty-five lines of code per day, depending on the language, after accounting for time planning, going back to debug problems, testing, and otherwise not writing code. Assuming that JavaScript lives on the generous side of this, we’d need to allocate about five hundred days of engineer time: Two years, if we only assign one engineer.
• Developer cost: We don’t only have to pay salary, but benefits, which—depending on economic conditions—can equal or surpass salary.
• Opportunity costs: You can no longer assign the developer(s) assigned to this project to anything else, like the feature that some prospective customers say that they need to see before spending money.

And we could try to calculate the benefit for making that expenditure, which usually includes something like this.

• Will it sell? Rewriting something that already works doesn’t sound like a selling point.
• Will it increase the price? Again, people probably won’t get excited for “does the same thing, but now costs more.”
• Will it save money? Rewriting old code often means creating new bugs that the old team already dealt with, which increases the maintenance costs, rather than decreasing them.

This project, then, fails miserably.

Example #2 — Aggressively Refactor a Feature

Maybe instead of rewriting, I only want to reorganize the code so that it better matches the mental model that the team uses to talk about the system. We have the costs:

• Developer time: This can have an arbitrary limit on it, since “half a refactor” doesn’t make anything worse. Also, that time can move a lot forward, with modern analytical and refactoring tools.
• You always have the same developer and opportunity costs, for any given duration.

And the benefits?

• It won’t sell anything new.
• It won’t increase the price.
• Maintenance costs should go down, if the plan for refactoring takes customer needs like throughput into account.

Notice how different these to projects look in this light. And now onto a third and final.

Project #3 — Add a New Feature

Lastly, we want to add some random interesting feature. We have the costs:

• Developer time: While I didn’t bother to describe the feature and so can’t give a real estimate, I wrote a post about how to estimate work, which we can apply.
• Again, for any given duration, the developer and opportunity costs look the same.

We then need the benefits.

• The marketing team should probably have an estimate of how many new customers a given feature will bring in.
• If no competitor has the feature, that could make a good time to raise prices.
• Maintenance costs will probably go up, as the team finds bugs in the feature.

Again, this looks radically different from the other projects. We can rule out the first possibility (barring extremely specific circumstances), whereas the other two have no clear advantage over each other until we have actual numbers.

Still Selling

Notice that a lot of this interacts with the “everybody works in sales” aspect. A good work proposal takes into account what the marketing and sales teams know about the product and customers, as well as what the development teams know about keeping the product moving.

People

You might have already guessed this, and I don’t have a quote or paraphrase to make the point, but…everything in software revolves around people. It seems ironic, in a field that many people enter to avoid people, but while we need to do technical work, it gets dwarfed by the people-oriented work. Consider the following.

• When you start a project, you spend a lot of time figuring out what your predecessor(s) intended when they wrote or organized things in a particular way.
• While you work, you need to provide feedback to ensure that everybody who cares that you haven’t drifted off the schedule, and accept feedback graciously.
• You also need to understand the requirements of all the various stakeholders in your project.
• When you have an idea, you need to sell your peers on it, and keep them on board.
• The user interface needs to make sense to users, requiring understanding them, too.

And maybe most importantly, without the people, the software doesn’t matter. Nobody writes software to have software. If they did, we could replace every engineer and manager with AI today. We write code—we make anything—because it solves a problem for people…

Overall

You might notice—if you didn’t, don’t worry, because I only did as I wrote this—the advice looks a lot like “treat business work like business.”

One of the reasons that we often laugh at people with less experience (usually) has almost nothing to do with their skill at their job. It almost always centers on their not knowing or seemingly caring about the context of their solutions. They, as we all did when we had less experience, assumed that solutions made sense if we wanted to do the work, rather than if it fits the project’s needs. They, as we all did when we had less experience, assumed that “I can’t understand this” provides sufficient motivation for changing how the organization does things, rather than providing an opportunity to learn the new environment.

Also, though, if you don’t think about your work in terms of people, you won’t produce the quality work that you could.

---

Credits: The header image is PostIt Advice by Alan Levine, made available under the terms of the Creative Commons Attribution 2.0 Generic license.