Comment by alphazard
3 days ago
The answer, of course, is that the taste-making apparatus inside the typical tech company is now entirely imposters (non-technical, non-power-users), who continue to LARP as visionaries.
The people who notice broken or degraded behavior (devs and power users) and conceive of good designs are not in charge of what goes into the product. So you shouldn't expect it to get better, only to continuously change so that the imposters can point to a difference that they were responsible for, knowing that upper management also has no idea whether that difference was actually an improvement.
The solution is to gut your product org, replace management with leading engineers, and hire some of your most fanatic users. They don't need to do anything other than give their opinions, and use the product every day. Put them in a room with your top engineers, and the software will mysteriously get better.
All of this was obvious decades ago, but now everyone wants to have a do-nothing job at a tech company, and to help their friends get one too. The result is imposters everywhere; "imposter syndrome" was brought into the vernacular to normalize a lack of expertise. "No one knows what they are doing, it's okay to not know how to do your job". That's what your (product) manager tells themself in the mirror each morning. Turns out: skill predicts quality, and an org ships quality proportional to the skill of the decision makers.
> The solution is to gut your product org, replace management with leading engineers, and hire some of your most fanatic users.
It’s not surprising that this sentiment is popular on a message board filled with engineers but I’m not so convinced by it. Nor do I think the current state of tech companies is acceptable, to be clear. But there needs to be some level of management outside of the engineers themselves. A lot of talented lead engineers I know are terrible people managers, or ineffective project managers. And that’s fine, because there are other people to do those tasks.
If your utopia is a bunch of engineers given freedom to do whatever they want, however they want to do it… I suspect the dream and the reality will not match up. In the scenario you’ve outlined I strongly suspect you’ll have infrastructure on its third rewrite, full of power user features and tweaks… and near-zero adoption from newcomers. Product fit is a thing that needs to be managed!
The OP is right most production code is full of errors, and suffers from code bloat and feature creep that impacts UX.
Is this really the best we can do? It strikes me as unacceptable to ship errors to production, yet it's commonplace.
Code quality matters, and being in touch with users/dogfooding matters. But that can only address the underlying problem by eliminating the low-talent developers who win by numbers.
How to solve the relevant problems is not something hiring and recruiting teams can assess. So, hiring process uses proxy metrics like having a HS and CS degree, years of experience, brand name companies, list of tools, "best practices", trends, etc.
Teams of self-congratulating code monkeys using all the latest 'industry standard' libraries and tools, don't accept responsibility for their errant code. Instead, they blame (the user, his browser, the library), make excuses, minimize "all software has bugs". They can't fix the bugs they've created for themselves, but it can't be their fault, after all, they're doing what everyone else is doing.
The answer is to send them packing. Hire by talent, not by proxy of a hiring team (who don't know how to think/use the aforementioned proxy metrics to gauge talent).
Intelligence cannot be taught, but it can and is discriminated against. That is another problem with these faux 'team-player' follower types. Anyone on the team pointing out the code is a disaster and an attitude to fix it is not going to last. He'll be fed pushback of the same crap excuses for why things must be done the way they're done.
When a talented developer does deep dive analysis to identify root causes, most on the team don't get it. The scary bugbear of coherence is too hard and threat to the team's shared narrative.
Again, the only way to solve that problem is to send them packing.
Yeah I hate that you’re right. Blender is an example of OSS software which is actually a joy to use and they have product designers. But I think there is a massive gap between good and bad product people. No product person would be better than bad ones, but for truly great software you probably want some good ones.
That being said lots of good OSS exists purely built by engineers so I think it’s really the case that good product people help a lot and bad ones hurt a ton.
Some developers also take an active interest in the design and feature set of the product they're developing. IME those developers can often produce good results once a general direction is set if they have access to real users to collect feedback. But it's important to recognise that these are essentially two completely distinct skill sets and mindsets and it just happens that some people have both.
It's not really any different to the old arguments when continuing a career beyond senior dev level meant moving into management but there was no guarantee that just because someone had been a competent developer they would also be any good at managing anything. Some were and produced great results - in some cases informed by their understanding as former developers about what would be possible and what it would realistically cost - but in other cases the Peter Principle hit early.
I'm not totally convinced by OP's whole point, but I want to point out an issue with this argument of yours:
> lot of talented lead engineers I know are terrible people managers, or ineffective project managers.
A lot of people who can read are also terrible manager, but that's not an argument to put illiterate people in charge. Not every engineer has what it takes to be a good manager, and that's fine since you don't need this many manager anyway, but I'd argue that for a management jobs, understanding the craft of the people you're managing is as important as literacy, because the most important role of a manager is make decisions and you cannot make good decisions about things you don't understand.
That being said, engineering is only half the takes in software, the other half being Design and you cannot have a manager that is merely an engineer without design skills (otherwise your product is going to have the user-friendliness of Arch Linux).
The problem, as I've experienced it, is that companies don't try to determine what engineers also have managment aptitude. They simply promote whatever engineers are good at writing code.
8 replies →
> A lot of talented lead engineers I know are terrible people managers, or ineffective project managers
Ok but non-technical “managers” are way worse.
Has more to do with role focus and hours in the day. I would rather have a dev dedicated to PM than a “manager” larping as one cringily trying to keep up with us totally ineffective to lead a technical team.
Tech companies are anything but technical anymore since they got rid of all the talent.
The real.answer is that people stopped making things with care and genuine interest.
Everything should be delivered in the fastest way possible, in the shortest time possible, on the tightest budget possible.
This is a recipe for creating a mess, in which AI has now pushed the limits and we are seeing how failure is now per-default embedded and shipped to users, who are now beta-testing products continuously.
> Everything should be delivered in the fastest way possible, in the shortest time possible, on the tightest budget possible.
because companies that did this is rewarded with more users and more revenue (than a hypothetical competitor that didnt). Darwinian natural selection is about survival of the fittest, not survival of the "best looking" or "best performing". And the determination of fitness is by the actions of consumers, not what they state verbally.
This happens because of capitalism.
In a few years will have a cemetery of software and products locked behind DRM or requiring a remote connection to a server that won't exist anymore, because it's too expensive to maintain. It is already happening, the effect will be much more amplified sooner
1 reply →
We have been beta-testing the outcome of incompetent software production processes long before AI. But LLMs do accelerate the slop production. And if what you're shipping is going to be a bloated buggy mess anyway, then LLMs really do make you more "productive".
> The solution is to gut your product org, replace management with leading engineers, and hire some of your most fanatic users. They don't need to do anything other than give their opinions, and use the product every day. Put them in a room with your top engineers, and the software will mysteriously get better.
I feel like there's this one random comment on HN that should be adopted on its merits alone, but everyone will ignore for no good reason. This will never happen because entrenchment and bureaucracy will strangle every product organization and every organizational reboot attempt.
It's probably the right solution, but the resistance built into organizations assembled by bad decision makers cannot be overcome. Maybe the best you can do is try to find a legal way to spin-off a competitor with a truly fresh start.
I've worked with good product people. They come up with good ideas, have great suggestions, leave latitude for implementation issues to guide some of the design, and work well in the constraints. It is kinda amazing because you might be given a good idea/ticket, and it just flows smoothly and naturally (building on top of existing good product design of course)
Having them around is like 100000x better than having just random engineers be doing product design. And "oh just listen to your power users"... come on folks, surely we know about designing our software into a corner right?
I'm saying all this but am very sympathetic to the pain brought by bad product people (or just like ... mid product people. It's a hard space)
I started using the term “opinionated software” a little over 15 years when I was starting a new company. I built what I wanted as a participant and a fan of the sport.
Lots of other people had their opinions on it (“you’re doing it wrong and everyone wants it this way,” “you must have this feature” which barely anyone actually uses… the power users), but I held fast with my opinion (did usability testing to prove the it was easier to achieve the goals to back up my opinion) and I’m glad I did. It changed an industry for the better.
Excellent usability and functional design that achieves a goal better and easier will win people over.
I also built it with an API so that people can build their own versions of it with the same data, because others also have strong opinions, and I whole heartedly respect that. Some interesting things have come from it that are more targeted for specific users and situations. Pretty cool to see what others make.
While I don’t know how opinionated the guys that created Dark Sky were with it, I would guess that it’s a good example. It was different from all the other apps in their category in the way it surfaced information. Their new app is good (not quite as great as the original), but they’ve really spent a lot of time making a really usable and functional system.
Edit: About that same time in my life, I also realized that I no longer just wanted functional, I wanted both functional and form. I wanted well designed functional stuff. Turns out that people like that too.
1 reply →
> replace management with leading engineers
Wasn't this the whole point of agile and self organizing teams?
Then managers with 10 different PM* acronyms in their email signature got hired in, with no engineering experience, to lead product and software teams?
I don't know if that's what agile was supposed to do, but replacing management with "anyone but leading engineers" is exactly opposite of what GP proposed.
> I feel like there's this one random comment on HN that should be adopted on its merits alone, but everyone will ignore for no good reason.
Because it's populist slop, just like how every long enough discussion about government incompetence will lead to someone proposing all political leaders should be paid minimum wage to fix the problem.
Don't forget, the entire Web 2.0 winner ecosystem of companies that make up our modern Internet was founded by Engineer GodKings who leveraged their product prowess to gain a distribution advantage: Facebook, Dropbox, Slack, Stripe, Github, Whatsapp, Instagram etc. They were also the ones who transformed their companies to what they are today, nobody forced them to do this. Contrary to populist opinion, it's not because they were stupid or brainwashed, it's because the proposed scheme has known, predictable downsides that a leader actually has to reckon with while internet commenters only have to worry about preserving their egos.
Taking out the trash is not populist slop. If you have a bad product org, the right thing to do is replace it. If you have a bad engineering org, the right thing to do is replace it.
It is difficult to draw any conclusions other than you like to keep things broken.
Don't blame it all on entrenchment and bureaucracy. Rather show me the engineers who want to become management.
I have thought of the same solution myself before and came to the conclusion that I, for one, wouldn't want to be leading anything even if I had some ideas on why the product sucked.
> Rather show me the engineers who want to become management.
You're talking to one. Wanting agency and responsibility and having the drive to put in the work (for potentially brutal hours) is not exactly a common trait. It's a founding engineer attitude. It should be no surprise that I'm a founding engineer of an LLC of one. I understand that it is not for everyone.
But I'm pretty confident that the blame is well placed.
> The solution is to gut your product org, replace management with leading engineers, and hire some of your most fanatic users. They don't need to do anything other than give their opinions, and use the product every day. Put them in a room with your top engineers, and the software will mysteriously get better.
This will just lead to massive selection bias. If all you care about are power users go for it. Otherwise you end up with a complicated system that is going to put off new users.
You can even have different power users who likes different parts of the software. Now it's totally possible to end up with extensive subsystems that don't really gel with each other
My anecdote for this is the the recentish redesign of Musescore. Tantacrul, the ux designer/product manager for Musescore has an hour long video on how he redesigned the interface and UX of the software. He is also a musician so you can call him a power users if you want but that was not the users he had in mind when redesigning the UX
https://youtu.be/Qct6LKbneKQ
> This will just lead to massive selection bias. If all you care about are power users go for it.
Simple things should work. The types of errors described in the article about feature creep and errors with simple user flows are all too common.
Just surf the web with the developer console open. It's not just "an error was thrown", but the kinds of errors and how they manifest. A rejected promise after localStorage access was blocked, after user clicked a submit button on a form that went through twenty seven delegation calls of Angular js using backspace-escaped method names to handle invalid HTML, and now the form can't submit because they did it using the latest tools, as per their resume. Crap like that. The level of quality of production web code is the cause of the poor user experience and outright failures. It is unacceptable and its cause is directly traceable to the design decisions and skills employed in its production.
There are good PMs out there watching in horror as their peers make changes and features that are obviously doomed (to anybody with a functional brain). I also write as much code as the median engineer on my team (skews junior). Please don't write off the entire profession based on many (most?) being awful - if you work with a good PM some day I promise you will find there is an important point to the job.
I want to agree with this, but I’ve watched the PM discipline, in concert with the even more dastardly MBAs, ruin everything I hold dear.
I think it's a question of integrity - I have reached a comfortable ceiling in my career, but doing the dumb shit would have got me further, faster. I don't begrudge the peers who have sold out when the delta is $1m+ a year but I personally got into CS for the art, not the money.
A lot of people know the exec bandwagon things are going to fail and do it anyway because of incentive misalignment.
Part of me wants to agree with you; I've seen a lot of lousy PMs in my career. But when placed in the driver's seat with the same mandate to bring in more customers and revenue (or else), I've also seen developers drive products straight into the ground just as hard.
It's a nice fantasy about nerds being able to do better at everyone else's but that's all it is, a fantasy.
Yup. This is basically what Steve Jobs argued throughout the 1980s and 1990s, and championed as a philosophy. Adopting it, took Apple from being a struggling tech company on the verge of bankruptcy, to the dominant personal consumer technology maker it is today.
Why would engineers as a class be better at product than product people as a class?
A reason is different performance metrics. One bonus depends on "make number go up". The other realizes that making "number go up" degrades the experience for the product as a whole.
An example. I worked for many years at a major satellite TV company. The customer support department were spending a lot of time and money handling customer calls due to signal loss because of inclement weather, and they wanted something done about it.
Department X pushed for removing the 1-800 support number from the on-screen-display, because of the "quick win". No visible phone number means some customers would just give up. Who cares that this would frustrate customers even more.
Department Y pushed for reworking the UX flows around helping the user troubleshoot the problem, point them to their DVR recordings or alternative shows on broadband if connected, and automatically rebook the interrupted shows.
That's a function of choice of "better" metric.
Traditional engineers are "better" at making things work in a functional sense (eg: aircraft) whereas product people are optimised to make "better" selling products (eg: Labubus - functionally useless but Black Friday riot desirable)
Devs and power users create something like libreoffice or thunderbird. They are incredibly resistant to any change for any reason and hang on to what they already know rather than what’s best.
The reality is most people actually like the stuff Apple and such are putting out and like modern UX more. The only bad stuff is deliberate enshitification which is pushed by financial incentives rather than product people being incompetent.
The financial incentives draw incompetent people.
It’s happened with finance, law, management consulting, and now software.
But software has been lucrative for very long time at this point. Can you say that the quality went downhill more than a decade ago?
I personally do agree that when I see an update I feel something between annoyance or dread (what is broken this time?).
Mostly agree and would add that product managers should be responsible for the commercial success of their products. That means spending more time deciding what market to be in, how to differentiate, how to price, how to drive adoption.
For the most part these are not strengths for devs and power users.
Are they not? Where I work PMs are closely tied to and own business outcomes.
If software is solved then the power users can be in charge because there is no technical moat. Competition should thrive as imposter-ware flounders, but it doesn't seem to be the case.
I've actually had the opposite problem much more often: Managers who were promoted due to their skill as a developer who have no skill in management or leadership.
I see where you're coming from, but my experience says (TLDR): lack of dogfooding.
In my current job, I'm building a system which has replaced the "SaaS" we used before. Not only was it fairly expensive, and sluggish, it was also not good, and in some parts even bad. And that fits a pattern I've seen before: that SaaS product, a survey platform, was built by a company that builds software, but doesn't use it. Engineers nor management are involved in making actual surveys and processing the results at any scale. The result is a system that requires bizarre hacks to make the system do what you need it to do. OTOH, I work right next to the people that use my software, and some of which have a lot of experience. We're small, independent, there's not much management involved, and everyone is aligned, and we all talk to each other.
Not knowing what your customers actually need is one of the big faults of software engineering, and in large companies, architects, engineers, and management can be quite far removed from their customers' experience.
I love this comment.