No matter what they tell you, it's a people problem (2008)

https://blog.codinghorror.com/no-matter-what-they-tell-you-its-a-people-problem/

by mooreds • 2 years ago

86 34 2 years ago

blog.codinghorror.com

wirrbel• 2 years ago

Sometimes I feel like the industry has just given up on solving people problem and is trying to fix stuff with Dockerfiles and yamls..

AtlasBarfed• 2 years ago

1990s:,use consultants but don't pay your people.

2000s: outsource to India rather than pay your people

2010s: hire cheap web devs out of school rather than pay your people

2020s:layoff everyone until something breaks, and certainly above all else, don't pay your people

2030sAAAAAAIIIIII wht have people at all

r2_pilot• 2 years ago

2024: just use Claude 3.5 Sonnet

jandrese• 2 years ago

mid 2020s: outsource development to AI rather than pay your people

I've always been amazed at the kind of money companies will throw at not having to hire a developer. Salesforce is a quarter of a trillion dollar company because they tell management that they won't need to hire any developers and then charge outrageous rates to accomplish simple tasks in the most complicated way possible.

BiteCode_dev• 2 years ago

I love this trend, every time they fail, it costs them a lot of money, and then I make bank after a few years of destruction because they look for a safe bet.

Then the cycle restarts.

jterrys• 2 years ago

"we can't figure out why this thing restarts so we seamlessly made it restart with no downtime by having a load-balancer/backup that kicks in when it kicks down"

nradov• 2 years ago

And in the tech industry we actually have it easy. Anyone who thinks it's hard to manage "people problems" with software developers has obviously never managed production workers in a factory or restaurant or something like that.

drewcoo4• 2 years ago

You just plan for things differently. The workers you mention are commodities, so it's easier to plan for them.

My father needed to design assembly lines that were safe enough for tweaked out workers who may not have slept for days to work on. Those were just his design constraints. True story.

rozenmd• 2 years ago

"The hardest parts of being in business long term are all people problems." - Alex Hillman

tibbar2• 2 years ago

I'll say this much: People problems are behind the majority of failures I've seen in my career. A project isn't delivered on time, and no one knew it was going poorly? People problem. A team spends three months building the wrong system, because they didn't work out the details with the right stakeholders? People problem. A critical person is fired, and the processes they manage predictably catch on fire a month later? People problem.

There is a category of problems that, I think, are mainly engineering problems (a few examples below.) You could argue that these, too, are people problems, because the team lacked experience and someone should have hired better engineers. However, given how difficult and unpredictable hiring is, I think it's better to treat questions of engineering design as primarily engineering problems, since that's a much easier problem to address. Some examples:

* An analytics system without tests that generated incorrect results silently.

* A project management system that ran out of memory when usage increased and couldn't be fixed without completely re-architecting it.

* An accounting system that wrote the same value in two places which frequently got out of sync.

giantg23• 2 years ago

"An analytics system without tests that generated incorrect results silently."

I've noticed that test coverage and quality is largely a people (budget) problem. They want the system now. They want that value delivered number going up and the cycle time going down. Tests are some of the first cuts.

convolvatron• 2 years ago

i think thats too simple. i'm older, and when i go into shops its not that everyone realizes they need testing and it got cut, its that no one even has any notion that testing is useful or interesting. an entire generation of developers propping up systems without any real systemic validation that they do what they are supposed to.

organizations spend a huge amount of resource keeping 'cicd' propped up, but when you look at whats inside - its a build, and some random unit tests and mocks.

to be fair, testing in an environment where everything is internal and external services laced together with json isn't easy. what i find really odd is just that no one is willing to acknowledge it as a real problem.

bunderbunder• 2 years ago

I've seen tests cut for that reason. But I've more often seen tests get cut or skimped on or slip through the cracks due to internal team dynamics problems.

If QA and engineering staff are organized into separate verticals, rather than being direct teammates that share a manager, then time that could have been spent on testing instead gets spent on bickering over who tests what and how.

If different team members have different opinions on testing strategy, and dig in on their respective positions rather than coming to an understanding, then tests will slip through the gap between them.

If senior team members don't think it's their responsibility to mentor (not browbeat!) less-experienced team members on good testing practice, then the correct tests won't get written.

If the people in charge of architecture don't recognize the outsize influence they have on the cost of designing and implementing tests, then testing can indeed become too expensive.

If people don't recognize that test cases are, first and foremost, a way of communicating and memorializing design specifications, and not just a clever way to run code in isolation, then the cost of maintaining them will go up and the value of maintaining them will go down, until people start to forget that there was ever a baby in all that bathwater in the first place.

etc.

esafak• 2 years ago

Taken to the extreme, this says nothing because humans are ultimately behind every decision. If a cosmic ray caused a bit to flip and trigger an error, you could call it a people problem because humans failed to account for it.

gertlex• 2 years ago

Yeah, this is take is easy for the brain to start down. I blame the word "people". A more accurate term that maps to the examples in the previous post is perhaps something like "inter-team coordination problem".

drewcoo4• 2 years ago

I think intentionally misunderstanding Weinberg is a people problem.

giantg23• 2 years ago

The main problem I find is that the people who want you to build a technical system are unable to explain how the existing business system works.

tmcdos• 2 years ago

I face the same problem with about 70%-80% of my clients. And there are 2 reasons: a) they really do not know how their business runs - maybe some parts but never the whole "machine" b) they do not know how to properly express their thoughts - it is a combination of art and skill but it can definitely be learned to a certain degree either at school or later by self-education

tibbar2• 2 years ago

There's a tension here which I can't quite put my finger on, but perhaps it is: If everything is a people problem, why do we need engineers at all? And if the business can't be run solely by MBAs and project managers, and we bring on engineers for that last part, is it really just a people problem they're solving?

gwbas1c• 2 years ago

A business that's all MBAs and no one who actually knows how to do the work has a serious people problem.

avmich• 2 years ago

If everything is a people problem, why do we need engineers at all?

Let's look at it as a bunch of people solving a problem which is too big for any one of them. Those people are different, they contribute different parts of the solutions - engineering, managerial - but they all have to cooperate to solve the problem, at least efficiently. If they don't, or don't do enough, for whatever reason, the solving suffers, possibly up to not happening.

francoisdevlin• 2 years ago

As a tech manager with twenty years experience, I can assure you, in fact, engineers are people. And they interact with those MBAs, project managers, etc. The really good product/project people understand this as well, and make a point of doing their very best to be effective when interacting with the engineering team. They know how expensive we are, and try to bring our our best.

To the point of this article, the best product people were in fact respected by the tech team, and it made all the difference.

marcosdumay• 2 years ago

why do we need engineers

To design stuff. That's what engineers do (on the case of software, designing is also called "building" and "developing").

Engineers do not fix the problems of your organization. At least not while wearing an "engineer" hat.

MBAs and project managers

Non-technical MBAs and project managers are patently unable to solve a lot of the organizational problems of engineering organizations. But well, usually yes, the MBAs are the ones tasked into solving them. I dunno why you included project managers.

alexashka• 2 years ago

Yes, when people will throw money at you to pick low hanging fruit, it is simply a matter of not squandering the incredible opportunity.

This very quickly becomes not the case due to the limited availability of... low hanging fruits.

This is of course not mentioned because why let reality get in the way of a good story.

Folks love a good fortune cookie - 'it's a people problem' - it only has 2 words! :)

jkaptur• 2 years ago

I think this is basically true in moderation.

I certainly agree that a lot of problems (including a lot of very difficult problems!) are not amenable to purely technical solutions.

But sometimes you have a difficult, technical bug to fix, and the "people problem" is making sure that someone has the knowledge, context, time, and incentive to fix it. This is not necessarily easy!

... especially if enough people have bought into "everything is a people problem", because then the technical work of fixing the bugs isn't valued or incentivized. Why would it be? It's not solving a people problem.

I think the viewpoint "everything is a people problem" can create a feedback loop that leads to poor incentives - which, ironically, is a people problem.

mattgreenrocks• 2 years ago

This type of post is practically a trope at this point: technical blogger who digs deep into tech inevitably has a grand epiphany that it's really all about people, not tech, and that's what we should really be interested in.

Maybe this is the unofficial CTO creed or something.

drewcoo4• 2 years ago

This type of post is practically a trope at this point

No, but software engineers in aggregate have the memory and attention spans of goldfish.

Relearning again is the new learning again.

cynicalsecurity• 2 years ago

How many lines of code will your team write?

That's how you know the article is pure nonsense.

drewcoo4• 2 years ago

Weinberg didn't say there was a correct answer.

He wrote the questions back during the bad old days when a lot of shops tried to measure developer productivity in KLOCs.

Understanding the context, something similar today might be "How many story points will this take your team?" and if the answer is anything specific, the project is in trouble . . .

Hope it makes more sense to you now!

qujine• 2 years ago

If you aren't working with people you like, people you respect, people that challenge and inspire you-- then why not? What's stopping you?

God I wish the world was like this again. I know so many people that don't have jobs and can't land anything because there isn't enough open.

inglor_cz• 2 years ago

As Stalin said, no man, no problem.

Nevertheless, this observation is too trivial to be useful, with the possible exception of "design things so that some automatic mechanism, independent of humans, is able to detect errors".

No matter what they tell you, it's a people problem (2008)

Related Stories