zlacker

[return to "Most technical problems are people problems"]
1. woodyl+X6[view] [source] 2025-12-05 13:47:33
>>moored+(OP)
100% agree. Sadly, I have realised fewer people actually give an F than you realise; for some, it's just a paycheck. I am not sure what has happened over the decades regarding actually being proud of the work you produce.

I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down, and so want to make sure you don't end up in that position again. Covers all areas of IT from Cyber, DR, not just software.

When I have moved between places, I always try to ensure we have a clear set of guidelines in my initial 90-day plan, but it all comes back to the team.

It's been 50/50: some teams are desperate for any change, and others will do everything possible to destroy what you're trying to do. Or you have a leader above who has no idea and goes with the quickest/cheapest option.

The trick is to work this out VERY quickly!

However, when it does go really wrong, I assume most have followed the UK Post Office saga in the UK around the software bug(s) that sent people to prison, suicides, etc. https://en.wikipedia.org/wiki/British_Post_Office_scandal

I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect.

◧◩
2. Hendri+Sb[view] [source] 2025-12-05 14:10:43
>>woodyl+X6
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.

Simple:

1. People lost ownership of the things they work on. In the early 1900s, more than half of the workforce was self-employed. Today, it is 10% in the US, 13% in the EU.

What you produce is not “yours”, it’s “your employer’s”. You don’t have ownership, and very limited to no agency.

2. People lost any tangible connection to the quality and quantity of their output.

Most workers don’t get rewarded for working harder and producing more or better output. On the contrary, they are often penalized with more and/or harder work.

To quote Office Space: “That makes a man work just hard enough not to get fired.”

3. People lost their humanity. They are no longer persons. They are resources. Human resources. And they are treated like it.

They are exploited for gain and dumped when no longer needed.

◧◩◪
3. parpfi+jq[view] [source] 2025-12-05 15:18:21
>>Hendri+Sb
One weird thing about software jobs as opposed to other crafts is the persistence of the workpiece.

A furniture maker builds a chair, ships it out, and they don’t see it again. Pride in their craft is all about joy of mastery and building a good external reputation.

In most software jobs, the thing you build today sticks around and you’ll be dealing with it next month. Pride in your craft can be self serving because building something well makes life easier for future-you

◧◩◪◨
4. chemot+MY[view] [source] 2025-12-05 17:40:03
>>parpfi+jq
I think this ignores the codebase churn in Big Tech. The code you write today probably won't be there in ten years. It will be heavily refactored, obsolete, or the product will be outright canceled. You can pour your heart in it, but in all likelihood, you're leaving no lasting mark on the world. You just do a small part to keep the number going up.

Tech workplaces are incredibly ephemeral too. Reorgs, departures, constant hiring - so if you leave today, in 5-10 years, there might be no single person left who still remembers or thinks highly of the heroic all-nighters you pulled off. In fact, your old team probably won't exist in its current shape.

If you build quality furniture for your customers, chances are, it will outlive you. If you work on some frontend piece at Amazon, it won't. I think the amount of pride in your workmanship needs to scale with that.

◧◩◪◨⬒
5. jama21+D71[view] [source] 2025-12-05 18:19:33
>>chemot+MY
Well said. I’ve always also thought that writing code and craftsmanship is a forced metaphor. At most, the product is the craft, not the code. And a product is exactly as good as people’s experiences of using it and how well it solves their problems. The underlying code quality is correlated with these things, but let’s be honest a badly designed product that doesn’t meet the customers needs can have PERFECT code and zero tech debt and still be a bad product because of it.

Also you know what, some code is disposable. Sure, we all want to craft amazing sculptures of metaphorical beautiful wooden chairs that will last a lifetime, but sometimes what the customer needs is a stack of plastic chairs, cheap, and done next week. Who cares if they break after like 1 year.

So, sometimes when I accept that my boss wants something rushed through, I don’t complain about the tech debt it’ll cause, I don’t fight back about how it should’ve designed to have wonderful code… not because I have no pride in my work, but because I understand the businesses needs.

And sometimes the business just wants you to make plastic chairs.

[go to top]