Hacker News Reader

Comment by techdmn | Hacker News Reader

In my experience few things sap developer motivation quite the same way as being forced to support, but not allowed to fix(!), a low quality product. The business rationalization makes a certain sort of sense. If we burn, say, 4 hours a week manually cleaning up after bug X, but it would take 80 hours to fix it, maybe the return on investment doesn't compete well against other initiatives this quarter. But in my experience, it often sends a message that we don't care about our users or our products. That isn't something engineers can be proud of at the end of the day, and it makes it difficult to care about your work. This can obviously be overdone in the other direction as well, but I often find the analysis to be penny wise but pound foolish.

View on HN

> "being forced to support, but not allowed to fix"

IMO that's a super important point. Having accountability without control is probably the fastest way to burnout and dissatisfaction in my experience. It doesn't matter the amount of hours you put in, it doesn't matter how much vacation you have. It's the difference between a feeling of accomplishment vs the learned helplessness and Sisyphean feeling of endlessly pushing a stone uphill.

And productivity suffers the most. This situation negatively affects the whole system, naturally.

> Having accountability without control

My manager: I want this in X days

Me: It is unlikely to finish in X days given x,y,z. It is also likely to cause outages.

My manager: If it causes outages, we will throw you on a PIP.

Me gets burned out.

Lesson learned. If a manager forces me ever again, I am going to let the project and the manager fail.

It sucks when you're in that situation, but sometimes a paper-trail and a dose of failure is the only way people learn.

The real problem is too much power to management without accountability. If the team suffers due to management decisions, how about we yank the management first?

But also: There is often zero practical need for rushing things, or for having some complicated vanity feature. This way there is a lot of risk and accountability as far as the team is concerned, but there was nobody up the chain asking for it.

The game of Chinese Whispers of features (and deadlines!) is probably the most inefficient part of software development.

The inconvenient truth is that the business exists not to provide engineers with work they’re happy with or proud of but to make investors money. The good news is developer happiness is associated with increased productivity and reduced attrition which usually factors into the business calculus in a much bigger way.

> The inconvenient truth is that the business exists not to provide engineers with work they’re happy with or proud of but to make investors money.

First that’s not always technically true because not all businesses have investors.

But assuming that the primary purpose is to make money, even that’s not precise since there’s a massive difference on optimizing for ROI tomorrow vs next quarter vs when you retire and hand your business over to others. Or different metrics altogether like market share or “engagement”. Those are all conflicting goals and have changed a lot just in a decade.

But even if you decide precisely which metric to aim for, there’s still a giant difference between primary purpose and only purpose. Simple things like a circuit breaker or a nail might be single purpose. But as soon as you step up almost everything is multi-purpose. A car, a house, even a hat have many degrees of freedom. A business has many unquantifiable components.

Anyway, the point is that giving carte blanche to decisions labeled with “business reasons” is at best lazy, and at worst legitimizes a sort of pseudo religious cargo cult worship of the “business truths” of the current year.

The truth is that nobody sits on magical predictive abilities, neither the 10x engineers nor the MBA grand poobahs. But it’s also clear that the companies with technical leadership and/or a high degree of engineering agency have been so successful in the last two decades, to the point of redefining the nature of business itself.

> not all businesses have investors.

If I form a business and take no outside money, I am the investor, particularly in the context of GP’s point that “[businesses exist]…to make investors money.”

So in that case, you're investing your time in return for money/happiness? Sounds like the same proposition as employees.

And money to get the company started. Even before a dollar of revenue comes in, lawyers, accountants, and the state need to be paid, and someone has to front or pay for the real estate. And employees are guaranteed a wage, unlike founders. These differences are often overlooked, seemingly out of convenience for the argument.

It continues:

> But assuming that the primary purpose is to make money (...)

Non-financial businesses generally exist to provide goods and services. If FedEx stops delivering packages and provides no other goods or services, does it really need to exist?

If Fedex stopped making money, would it have any reason to continue?

If it stopped making money, it would have no ability to continue - at least, not for an indefinite time.

what about nonprofits?

Nonprofits still need to break even or raise funds (membership fees, donations).

What part of that involves making money for investors?'

How much profit are nonprofits expected to make?

I know it's ridiculous, but I will use my own time to work on some problems that officially we're not allowed to fix. I make that issue my hobby project and use my time to learn some new tool/technology (that looks good on a resume). For example, right now I'm learning Rust to fix [a hairy build problem]. Taking on the problem gives me back some that developer motivation. Using it as a learning opportunity makes me feel like I'm personally growing.

It's not at all ridiculous but at the end of the day it turns out that our excitement for our craft is turned against us (as in making us work more hours for no extra pay or anything at all really except a little better resume as you said; and the cases where the resume gets enriched are IMO super rare).

Yet if you make that argument to the business itself, they'll say "but we're making record profits and customer satisfaction is up!", confusing the quality and longevity of the product for their ability to market said product and craft customer surveys.

If raise your prices, cut R&D, and all your disgruntled customers leave, customer satisfaction & profits will go up in the short term!

After 10+ years of working as a QA engineer I accepted that every project, every piece of software is a crap, is full of bugs, many of which are not going to be fixed.

The difference is only how shitty it is. Internal software of huge corporations are total crap. Software which is facing paying customers is better.

Reply on news.ycombinator.com