Comment by koonsolo | Hacker News Reader

Comment by koonsolo | Hacker News Reader

Parent Full thread

> developers are like "machines working in a factory"

After I worked a few years in the industry, I came to the following conclusion: The main difference between a factory and a knowledge business is that in a factory, the smartest, most knowledgable people are at the top (not completely the case, but mostly). In knowledge work, the smartest (=experts) are at the bottom. If you move up as a smart person, you will for sure lose up-to-date knowledge.

This has a few consequences of course. In knowledge work, managers should not say "First do this, then do that". Managers should be at the service of their team, making sure they get the focus and freedom to work on their stuff.

Now back to the factories: I'm no expert, but one of the key elements of Lean Manufacturing is that the people on the floor are able to provide feedback to the upper layers. Why them? Because they have the hands-on knowledge and see things management can't. So even in factories, either you listen to the lowest level employees or you're not optimising your process.

And finally, if users and employees can be replaced, so can companies, products and services. The thing is that having great retention in users saves you a lot of investment on acquiring new ones. And having great retention in employees saves you a lot of investment in hiring and training. The leaders that realise this will outperform anyone that doesn't.

This is known as the theories X and Y of management: https://en.m.wikipedia.org/wiki/Theory_X_and_Theory_Y

The personality of the leadership will determine whether they think of workers as self-motivated (will actively look for work) or externally motivated (will wait for work and try to avoid it). Those who don’t think workers are self-motivated will build management structures where people are discouraged from thinking beyond their station and have all kinds of reporting and incentives to make them do their work.

I was for a long time hard in the self-motivated camp, but eventually realized that’s me and not everyone, and maybe not even most people. A multi-modal management approach that leaves room for both works better but is harder to pin down.

Very interesting link, I didn't know about this one yet.

Thanks for the info, fellow Flemish guy (your name gave it away :D)

This is a good point. A team might have a few people that will actively get their work done and find more while communicating what they're doing with management, so they can redirect if necessary. Others essentially need a babysitter. A good manager let's the hard workers do their own thing and supports them when they rarely need something, while spending more time working with the ones needing babysitting without dragging the hard workers into the mud.

> maybe not even most people

My experience tells me you should just assume everyone is going to need the external carrot/stick arrangement.

You'll save a lot of pain by realizing that no one cares about the product as much as the people spending 14 hours a day on it.

Have you ever worked in a factory? Because I can imagine that factory management could also lose touch and make decisions that would leave the people on the "factory floor", who have better knowledge about what the machines can and can't do, bewildered. There are however several things that make this less likely: first, some companies have a policy of management having to actually work on a production line (or as a worker in a restaurant, etc.) from time to time so that they know the basics of what's going on there; second, the technology of a factory is maybe easier to grasp and doesn't change that fast as in IT. But still, if you want an example, I bet many of the problems Boeing is having is because their management is (or was until recently) located in Chicago, while their factories are in Seattle and South Carolina.

The failure mode for a factory is usually “bob continues to assemble widgets” - they may miss out on an optimization because Alice has to half disassemble the widget later, but it all still works.

Programming can fail much harder.

Really? If there are safety issues unresolved, the factory could burn down or people could die… programming rarely puts people in similar life or death situations

Every mode of transportation except for biking runs on software nowadays. Every bridge is designed with software. All of our lives are to some extent threatened by bad software.

"Safety-critical systems now usually rely on software" is a distinct and largely independent statement from "software is now usually safety-critical". The former is true, the latter is not. (This is actually a pretty clean example of the "Affirming the consequent" fallacy.)

This is exactly what can happen with factory management. The best factories have a pipeline between management and the warehouse workers. In fact, OSHA explicitly recommends that frontline employees are heavily involved in management-included safety meetings.

If this communication goes wrong it can result in deaths and giant profit leaks until eventual bankruptcy.

> So even in factories, either you listen to the lowest level employees

If you listen to programmers, the app has technical debt, and needs to be rewritten on [next tech stack needed on the developer’s resume]. I’ve hear that on a 6-month-old app written in SpringBoot/React in 2020.

Leader-blaming is a nice sport, but actually working together with full responsibility on both sides is a much rarer skill. Including being fired with damages if you summon KubernPyKafka in Scala and your team doesn’t produce features during 6 months.

> summon KubernPyKafka in Scala

Getting flashbacks from my own time working on what I like to call Cthulhu Architecture. KubernPyKafka in Scala is probably the most reasonable part of it.

The parts that needed to be fast were in python. The parts that could afford to be slow were in Go or LuaJIT. Ops in C++. And the parts that required well defined carefully controlled business logic to be encoded were in JavaScript if you were lucky, but more likely embedded in a DSL constructed over YAML. ACID built over top of NoSQL. Still only scratching the surface of the insanity. I’m sure there are many of us carrying these scars; some of the intent on bringing this dysfunction into their next organization.

The factory analogies only work so far. Factories are subject to the same problems as everywhere else. There's a lot to learn from how factories (or your CM's) operate.

  > And finally, if users and employees can be replaced, so can companies, products and services.

Yep. And now maybe reddit's number is up, and it's time for it join Myspace, Friendster and Twitter?!

Reply on news.ycombinator.com