I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.”
1. They assume they know more than everyone else. Got a guy who has had a problem for 5 years and tried 20 different solutions? The engineers will spend 10 minutes thinking about it, come up with a solution (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot. I've done it myself (which I'm embarrassed to admit), and I've seen it at every level from junior to Staff/Principal in companies large and small. The lack of modesty in software engineering teams is perhaps my #1 peeve with the industry. As a result, they often end up designing terrible solutions.
2. Once they understand a problem and a solution, they are frequently awful at thinking through the solution from the user perspective unless they themselves have experienced the problem. This isn't unusual, it's hard to build detailed empathy for how something should work unless you try it yourself. It can be very challenging to get buy-in for a UX or a UI from engineers without it, so sometimes it's useful to get them sat in the chair trying to do the work themselves.
I'm a TPM (former engineer and engineering manager), who has to regularly wear the "product manager" hat. I can not understate how hard it is to get engineers to read a scope document, understand it, accept that the thing needs to be built, that it needs to be built a certain way from a functional perspective, and while they have free reign on architecture and how it's built, it is not their job to rip each detail to shreds assuming the users, PMs and everyone else involved up to that point isn't a completely brainless moron.
This solution is relatively elegant. He got them to talk to users about the software they built and made them realise they were focusing on the wrong details. That's good. It doesn't mean the engineers can become product managers though.
You still need the PM to own the product long-term, and to deal with the customer relationships as the thing gets built. I will also guarantee that those engineers proposed changes the PM had to push back on because of constraints outside of the engineering team's heads (legal, compliance, needed by customer X, and so on).
Edit: read down into the thread, and this company doesn't have product managers. So he's just hoping engineers can figure it out. Fair enough, the only way to develop that muscle though is to get them in front of customers regularly.
Ironically, it is hard because it doesn't consider the user. Scope documents likely seem reasonable for the author living in their own little bubble, dismissing it as something "trivial", but if they actually had to use it like those on the receiving end they would soon realize how horrid and ill-conceived it is. Much like was learned in the original link, once you stop with the bad practices, things become much easier.
This PM eventually found the way to push their engs, as described in the article. So I think PM achieved the goal pretty good.
He clearly adds value, he has his secretary take down requirements from the customer and then he personally walks them down the hall to the engineers.
Not sure why you’re not getting this?
/s
The moment you have stubborn engineer who knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster.
From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.
I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault?
I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire.
That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.
1. Professional software engineers that can listen to learn about the problem space and are willing to come to understand that. This takes humility.
2. The people experiencing the problem. They might not write perfect code and it might not be maintainable long term. But their understanding of the problem and pain points is so good that they can solve just that and not write 90% of the code the professionals wrote...
I've seen this over and over again and can only tip my hat to the people that fixed their own problem. Just like for a dev, that means going into an unfamiliar domain and teaching yourself
Glad I'm at a place where i can talk directly to people instead of having to go through layers of indirection. I takes away from my engineering time but now i'm always building the right thing, so it is much more productive.
- The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements.
- The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear.
In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.
In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.
In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.
They think PM's don't provide value, so they ignore what PM's say.
It's only when they hear from customers directly that they go... oh, so these needs are real? I thought it was just PM bullshit.
In a healthy workplace this doesn't happen. But sometimes engineers need to talk to customers to trust that the stuff their PM has been telling them is actually true. And then the relationship becomes more collaborative and trusting.
I call this the load-bearing 'just' - as in, 'oh, why don't you just...'
If I catch myself saying or writing that word, I kick myself and think about why I'm doing it. Usually I stop and reapproach my input.
Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion?
In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?
Does support have a procedure for this or is it ever part of any training or meetings? Otherwise I hesitate not to call it a management issue, no offense.
Or maybe the next thing after LLMs arrives in 2026 and it's actually better than everyone at everything and can feed itself in a loop, but I doubt it.
sometimes it's a lack of accessible escalation procedure (no, a bug report is not the same thing as "this feature sucks to use and needs to be revisited), and sometimes it's just the unfortunate fact that those support reps most capable of clearly explaining these issues (or better yet, understanding the underlying mechanisms that cause the issues) get promoted out of front-line support roles (hi)... or move on because they're not satisfied with remaining in support (hi).
obviously there are a ton of exceptions to this rule but i've personally covered just about all those bases throughout my career. i would have loved to have seen engineers get involved with the burden of support, but maybe that's just because i came out of dysfunctional shops... not that they're not all dysfunctional in one way or another.
That’s been my experience all my tears in industry.
The result, which you often see in companies with 300+ employees, is that engineers have far more experience building products than their PMs, what engineers usually lack is knowledge of the customer and their pain points, and a roadmap that leads to successful outcomes. In other words: a real product manager.
It's not enough for PMs to throw around cliches like "I represent the customer" or "the product has to be built around customer needs" if they don't understand how to actually build and ship software.
Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product. And, of course, people in those roles tend to hire others who look like them, with similar experience. One day their CEO realiseS their product isn't selling, customers aren't happy, or engineers are left to figure out what to build.
To put it in perspective, imagine a company making a lawyer their Engineering Manager and asking them to build an engineering team. What are the chances they'd do better than a computer scientist or an actual engineer? Pretty slim. Sure, there are exceptions, but what usually happens is their engineers aren't motivated and complain about the lack of coaching, vision, purpose, and the poor quality of their tools, processes, code, and work environment.
Bottom line: companies need to audit product leadership roles as a priority and figure out who's really in charge of the product. Run an internal survey to check whether your CPO, Director, Head of Product, and Product Managers have studied business or have actual expertise in it. If not, you're in trouble.
Neither answer is necessarily wrong, you just need to make a choice.
My mom can use gmail, but she doesn’t even know about its hotkeys and accelerators, or Labs and whatnot
I find if you sit engineers down with whoever is doing the operational work, you very frequently find you don't need PMs and everyone is much happier.
PMs can be incredible, but my experience is that they tend to be both very territorial and know surprisingly little about either the engineering or the customer side of things.
Where can I find this hamster and is it available for adoption?
First, from their perspective if they are able to solve an issue by following their script, even if it took 20 convoluted steps, everything is working normally. People are used to occasionally dealing with workarounds so it's not a big deal in their mind.
Second, it's not in their interest to report UX issues. They are measured by the number of tickets they close, so the issue that gets a lot of inbound support and they know an easy workaround for is nicely boosting their numbers. Eventually these things get fixed by product and they move on to doing the same thing with other tickets.
An errant autocorrect a little too correct to correct.
Where would people skills rank then in your hierarchy for product managers?
When I design a UI, it's clearly a programmer's UI. But I try very hard to make things as clear as possible and I'm usually wrong. When I see people struggling to use a tool I made, it means I have failed at design and need to fix it.
It's my belief that if you grab a random person off the street and they can't figure out what your product is or how to do even the basics, you have failed to design your product. In 100% of cases, a user should be able to walk up and figure out the basics after a few minutes of poking.
If a user needs to check documentation before they can accomplish any task, your design is bad and you should feel bad. If a user needs to inspect every tooltip every time, ten million years dungeon.
This fallacy is at the heart of the failure of modern software.
Making things work for the median user is almost entirely about defaults and intuitiveness. If everybody is sending messages all the time, there should be a conspicuous button for sending messages.
Making things work for power users is about allowing those defaults to be changed. It's fine if this is five deep in a menu somewhere. It's fine if there is an option for "advanced mode" that opens up a bunch of menus that are otherwise hidden. It's fine if this requires you to write your own filter rules etc., as long as that's available. What's not fine is to make the limited interface the only interface.
Simple things should be easy and complex things should be possible.
I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for. They might even clob several different tools together in an unholy abomination to get it to do what they actually want instead of having a tool built to do precisely what they want (and once that tool has been built - people will inevitably misuse it to do things other than what it was designed for and then complain about its poor UX for doing those things).
Is your company hiring? Because I've spent 30 years being this engineer and nearly everyone looks at me like I've got horns growing out of my head.
That's not where most engineers find their job satisfaction, more's the pity. And they think they know better than users. There's a reason UX has been around for at least four decades longer than DX. Developers think both are made up.
Dell at one point pulled the plug on outsourcing their tech support. They spotted this moral hazard partway through the process and decided it was better to keep it in house.
Product at every company I've worked for only ever cared about prioritizing shiny new features or bugs that have people screaming at them.
Isn't that the point? In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. In the open source world it's more reasonable and common to design a tool not predicated on the predominant models and workflows. And every once in a awhile those experiments result in something very valuable that helps to break predominant paradigms. But in the commercial space solving customer's immediate problems in a manner that is intuitive for them is paramount.
I love this.
Building on this thought: When you are starting to build something, you have very limited resources. Focus only on making simple things easy and forget everything else. Once you have product market fit expand into making complex things possible. This applies to 90% of all products.
The way I've typically solved this is by keeping an eye on the support inbox myself. It takes just a few minutes every day and I've caught some pretty low-hanging fruit with this that really does make the product better. Sometimes it's as simple as just adding a permalink somewhere.
Person1: "thing doesn't work?"
Person2: "yeah it doesn't work for me either"
Person3: "it's always something I have to work around"
Person4: "I work for <company> as a customer support outreach social media community engagement executive. Can you go and jump through hoops and open a support case?"
Not raising it internally, not getting anything changed or fixed; suggesting the customer do more work to tell the company about the problem. A person who works for the company and is paid to read social media and has read the complaints, is not only apparently ignoring them but annoying the customers as well.
Alternate Person4: "<sigh> I work for <company> as a technical employee and we've been begging to get this fixed for years. As a workaround you can <xyz>. Email me directly if you need more help, and if we get a patch to fix ever, I'll let you know".
Doesn’t matter if you drive VS Code every day though, because that means You Know Better (tm), and to hell with the discovery process.
I actually wouldn’t have a problem with pulling engineers into those discovery exercises directly, except when I have, they’ve just refused to engage. Come out without asking many questions and seemingly haven’t listened to a thing.
It’s like engineers just think it’s all beneath them, (and I accept I was a bit like that when I was engineering), so forcing them to do the calls isn’t an awful idea.
A joke exists about how developers will never be displaced by AI because that would require clients and/or project managers to accurately describe what they want the AI to build. On one hand that is extremely egotistical of developers. On the other it is also factual.
To my understanding of the story the developers had designed what was being communicated to them by someone who described what customers asked for and not what the customers actually wanted or needed. Nothing to do with what the engineers thought customers wanted and everything to do with what project managers had expressed to the engineers about what customers wanted. Speaking with the customers directly gave them a better idea of what was actually being asked for. So they built that instead.
My takeaway from the story is to fire the project manager. Not to make devs call clients.
The closer you can get the engineers to the users, the better your product will be, and this goes all the way to the backend and architecture.
This is true no matter how skilled and well-intentioned are the PMs or sales reps.
I've seen one single layer between the builders and users to help modulate high and constant user demand can help.
Beyond that, even two layers can strangle a project. One project my company was doing for IBM was moving along nicely with the developers talking to the actual users every few weeks as progress was made & delivered. I moved off the project, then IBM inserted a manager to "consolidate the communications" (take all the users' input and boil it down), and a manager at my company (not the engineers) talked to him. The project became one of those endless slogs of feature creep, yet no great success — ultimately deployed for some years, but not the resounding improvements in workflow efficiency they hoped and saw in the beginning.
Absolutely EVERYONE on both teams was competent and really wanted the project to be a great success. But adding the intervening layers, while it seemed more efficient, had only the opposite effect.
Seriously, it ALL happens where the rubber meets the road. Get your developers as close to the end-users' keyboards and screens as possible. Talking directly to the users is great. Even better if you can arrange to have them BE a user for a day or two.
Engineers work micro features which are sliced out of micro picture epics with maybe a vague Northstar.
Sitting engineers with users is a key thing I'm driving at my work since we're on internal tooling. Pretty much to a tee every participant comes out and goes "Wow... I had no idea that's how people were using our product"
Building user empathy results in greater connections within our organization, puts names to faces in our support channels, and results in more well rounded engineers who develop software with both technical and end user experience concerns in mind.
I mean, there's a reason most software interfaces are still shit, and often physical products too. It's cause we take tons of input from people who haven't extensively thought about user experience a day in their lives
Give an engineer a clear understanding of the end need, and you have a tremendous gain in efficiency. I think there is a 10X benefit here that's similar to the 10X benefit from stronger engineering skills.
You still need PMs, though it's a different job that passing papers back and forth.
This is fine if coupled with a dose of humility. Coming up with obvious solutions then researching why they don't work (or asking an expert) is a good way to understand the domain.
> (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot
This is obviously bad, but engineers often have imperfect people skills. I like to think they're aiming for the first but accidentally end up doing the second.
> it is not their job to rip each detail to shreds
It is an engineer's job to ask questions during planning when they're confused. This feels like it might be bad people skills again, because "ask questions" and "rip each detail to shreds" are in the same direction.
All software is ill designed in the first place. Even software I write to solve my own problems will usually do a poor job of solving that problem on the first iteration.
There is a reason old engineers say: "Plan to throw the first one away. You will anyway."
On Linux we enjoy flexible systems that empower us to change the things we don't like all by ourselves without any need to involve any "project managers" at all.
And it's completely fine if Linux systems are built around the needs of programmers and power users. It's not like normal users are paying us. Linux users should focus exclusively on themselves and their own needs.
Playing along with this analogy, what I think we see a lot of in product development is the customer going to the PM and saying they need the cone to have a cover. The PM and the customer iterate over the specifics of the cover. PM goes to the engineer and tells them the cone needs a cover that meets x, y, and z requirements. Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.
I know not everything comes across in a short HN comment, but that truly sounds like a "Why don't you just...?" solution. What does the user of your work actually need?
> It’s like engineers just think it’s all beneath them
Well, are they wrong? You seem to recognize — and I wholeheartedly agree — that when an engineer throws a "I just did..." solution in front a customer and the customer finds it to beneath them to use, it is the engineer who has failed. The customer is completely justified in pushing back on something that isn't right. They shouldn't have to accept slop just because that's what you delivered. But it seems you aren't willing to hold yourself to the same standard?
I don't think that's entirely accurate. We tolerate steep learning curves if the result is an increase to our power. That's why we are power users.
Vim, for example. Some of us put effort into learning it because it's a powerful and efficient editing language that will enable us to easily accomplish hard things.
Caring about the system itself and being willing to put effort into it are what separates power users from normal users. We don't do this because of masochism, we do it because we want to increase our power.
Normal users want the system to just do what they want without any thinking or effort at all, as though it was a highly specialized tool for their exact task rather than a powerful programmable general purpose computer.
Personally I don't care at all about how "less experienced users will tolerate or adapt". This unceasing focus on the wants and needs of normal users frequently hinders us. Developers typically reduce the complexity and feature set of a piece of software in order to turn it into something a normal user can deal with. We want more power, not less.
Normal users don't really matter unless they are directly paying our salary. We should all favor ourselves unless we're getting paid to focus on someone else.
I was right with you until the last sentence of this. As an engineer-turned-PM who is still very much technical, I can count on one hand the number of technically competent PMs I've known in my life, and have plenty of fingers left over. Having experience developing products can easily be a liability, because while delivering software is important, you're mostly expected to be an advocate for the business, which means that you live in the world of corporate politics and can't be perceived as too in the tank for the tech staff.
What I see is the exact opposite of what you've described: the PM that gets ahead is invariably someone with a background in business or marketing, and the technical background is deemed almost irrelevant. If you spend too much time focusing on technical issues, someone swoops in with the theater of "data-driven decisions" and "rapid iteration" -- you can justify virtually anything by cherry-picking statistics, and it's always possible to criticize the development speed of a team when you don't involve yourself in the details -- the role quickly becomes about spinning a compelling story to upper management.
Basically, a huge percentage of PMs understand little more than the first few chapters of The Lean Startup.
That’s the kicker. They know what the customer _wants_ not what they _need_
The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!”
I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been to use X.
A good PM doesn’t say “this is what the customer needs” because most of the time the fucking customer doesn’t actually understand what they need.
The engineer knows that holding the ice cream cone upside down means they’re trying to use the product in a way it was never intended, so they push back.
A good PM would ask “why do you want to hold the ice cream cone upside down, customer?”
“Oh well we don’t actually want to hold it upside down, we just get frustrated that sometimes when we put too much ice cream on/in the cone it falls out. So if you can make the cone hold the ice cream while upside down, the problem is solved!”
“Oh, so what you actually need is a bigger cone that can hold more ice cream?”
“Oh, yeah that would work too”
meme about Spider-Man facepalming, where Spider-Man is the engineer
Because I’ve done this enough times, they’ll listen to me and we won’t waste time on it.
You should try it, instead of designing soggy ice cream cone caps.
"Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. Some companies go even further and promote an engineer with project management experience to Head of Product. But most have little to no background in business, marketing, economics, or product development."
I haven’t used the products of any company I’ve worked for.
1) Exactly what you wrote: power users don’t even realize they clicked through five things in ten seconds any one of which would have derailed a weaker user, because they’re so used to bad UI that it’s almost invisible to them.
2) Zero care given to what’s most natural for the platform, for cost of development & maintenance, or what’s easiest for the user, when (bad) designers and (bad) “product folks” get involved and are way too into the wrong kinds of “consistency”, especially brand and cross-platform consistency (yo, I’m not sure it’s worth spending extra money fucking up contrast and platform norms on your inputs so your fucking radio buttons are “on brand” or whatever, like, I’m deeply skeptical of the actual business value of that kind of thing, though I can see the PowerPoint presentation value… and that’s why it happens)
Right now, the Product Manager is seen as the CEO's delegate, making sure the product follows business strategy, while the Engineering Manager is the CTO's delegate, making sure the product follows technical strategy. One represents business the other represents technology. But IMO since both are building the product together, the title Product Manager creates competition instead of collaboration.
The software needs the customer just as much as the customer needs the software. That's why I think the roles of Engineering Manager and Customer Manager make more sense, working together to build the best product possible. The product isn't managed by one side, it's managed by both.
However, the real problem isn't the role title, it's the qualifications of the person in the role. Companies don't hire lawyers as Engineering Managers, so why do they hire musicians as Product Managers?
> Commenter: Sounds like you have no product managers [...]
> OP: haha we don't :) we pride ourselves in not hiring any product folks until after we raised our series A. this helped us stay super lean, move fast, and build exactly what our customers want. our platform is definitely not dead simple. but in the early early days, we did rebuild our product 3 times and the 3rd rewrite scaled us to where we are now
It's totally fine to have an opinion on UI/UX if it is informed by cognitive psychology and other relevant HCI subfields, in the same way that it's OK for UI/UX to push for designs so long as they are also informed by business and engineering.
Even when you have good ones, they can't scale up to all of the things that I'd want them to own, meaning that engineering fills a lot of gaps.
This ends up being uncomfortable and necessary. I'm still learning how to make it work.
I have no words! Except that I really want to know the organizational dysfunction that ended up creating that policy.
E.g. I know this guy leading sold-out Product Management workshops in Silicon Valley, who understands nothing at all about actually taking any product to market, about competition, marketing, etc. ... never mind satisfying actual customers.
>Customer Manager
That sounds weird. Product managers do not represent customers interests, they represent business value which is not always in making all customers happy. E.g. conversion optimization brings no added value to customers, so it’s not a great name choice. If the role defined as it us now, „product manager“ is the most appropriate name.
"I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.”
Working with customers now and then simply translates to better products and also less maintenance issues, which is _better_ for said developer.
For me, the title Product Manager sets the wrong expectation, it makes it sound like they own the product, which clashes with other roles. In reality, they don't own the product, they own alignment: customer needs, business goals, and engineering feasibility.
I've heard many YC founders say that the CEO (or CPO) is the only one who truly owns the product, and I agree. The PM should never own it, they are interpreters who take the CEO's vision, combine it with customer insight, and help the team make the right trade-offs.
The real problem, I believe, starts with companies hiring anyone with people skills as a PM. They don't understand their role and responsibilities, it's common to hear PM say "I own the product." But that's not really true. According to successful founders and CEOs, they are the only ones who truly own the product, and that's an important point for leadership to establish. PMs thinking they own the product creates power struggles with leadership, engineering and design, while a title like "Customer Experience Manager" makes it clear the role is about representing the customer's needs, aligning them with the CEO's vision, and making the right trade-offs.
Business people with knowledge and experience always put the customer at the centre and focus on aligning customer value with business value. In other words, if you're the CEO of Uber and your PM isn't driving a taxi once a week, then, IMO, you hired the wrong person.
That makes it look like it's the PMs' fault. Yet I bet you wouldn't want a car designed by engineers who never drove one and never directly spoke with someone who did, either. It's that simple.
When I ask 15 users for their input, only 3 will speak up, and their needs and views don’t fully overlap.
Photoshop is a great example of a product that was extremely complicated and difficult to use but dominated the market for many years.
Microsoft has continually made updates to its products over the years, making it basically do the same thing but with unnecessary and frustrating changes, and people keep buying it.
Yes, UX is important, and A/B or similar evolutionary testing is important. Yes, devs tend to overcomplicate things. But, there’s no magic simplification bullet.
We talk about stuff, we plan stuff, I chip in and people listen. Whenever I see devs complaining about how terrible their project management is I think to myself that the dev is probably at least partially responsible.
Maybe I'm just lucky to have good colleagues, but when I talk about software engineering topics people listen and take it seriously. I think that's a big part of our job as developers, we know the tech and we guide our managers just as they guide us. We're a team, we work together.
I've worked as a Manager so I've had to deal (and collaborate) with this kind of misunderstanding, but it truly gets tiring when developers complain about users trying dumb things (for developers) over and over again, yet they themselves have learned nothing from previous encounters with this phenomenon and complain instead about stupid users (or PM, or company, or whatever).
I’ve also had great success dropping engineers directly in front of customers. I think it’s just because it humanizes the person behind the ticket
Classic problem with us eningeering types, right? When you're in the weeds it is easy to see the differences. Humans are always biased to forget how difficult it was to learn something, judging on level of current (subjective) difficulty. For me a big change in framing came through Linux. I'd convince my friends to use it and then as the years went by I saw how much easier it became to do so. Now, for the most part it is much easier for an average person to use. There difference isn't "holding it wrong" so much as "it's hard to hold" (or "it's hard/unintuitive to hold correctly"). Even just with the more recent rise of TUIs. Even us terminally terminal types are loving the new TUIs and ultimately that is a frontend thing. It's just frontend for backenders, allowing us to stay in the environments we are efficient in, maintain our power and flexibility, but also get some aesthetics (which has functional utility! I bet you use syntax highlighting, and not just because it is pretty).
There's a strategy to writing backends that I think helps both backend and frontend: write flexible code. It draws from the unix philosophy, where functions (or small programs) should be containerized or focused. Then the complexity happens by putting the things together (there's a hierarchy to this). Helps write backend code so it is easier to maintain, reduces repetition, allows for quicker feature development, and ultimately makes it far easier to read. It's a little more work up front, but it sure pays dividends. It helps front end people because ultimately they are towards the... *front end* of that hierarchy. Makes it easier for them to pull pieces together, wrap things, and communicate with backend types.
Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. Why is there always time to do things twice but never enough time to do things right? It all depends if we're running a sprint or a marathon. A sprint is all about speed, but a marathon requires a lot of strategizing. A marathon requires some sprinting, but you can't sprint the entire thing. We like to drop sayings like "don't let perfection be the enemy of good" but truth is it's not about perfection, it is about different ideas of what is "good enough." Which, is ultimately an issue of communication.
[0] I'll still argue backend is more important ;) because that's the foundation. Your building can't stand, let alone be pretty, if it doesn't have a solid foundation and skeleton. All that is invisible though. Maybe that's why these arguments occur.
> Honestly, I think the biggest roadblock to this strategy is the constant push for rushing.
I think another important part of "running a marathon" is having excess time. It is hard to predict disaster, but you can prepare for it. You don't want the exact number of lifeboats so that each passenger on the ship has a seat on a lifeboat. You need excess because in a disaster it is likely a lifeboat will fail. The lucky thing with time is that if you finish ahead of schedule you can just go onto the next thing. It's always better to finish ahead of schedule than behind. But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.
> It is hard to predict disaster, but you can prepare for it.
> But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.
running without slack means every bump in the road adds a delay which makes the manager's troubles even worse when they have to report the inevitable delay (which leads to a negative spiral of rush-and-delay)
> running without slack means every bump in the road
Sure, a rally car isn't as fast as nascar, but which environment are you in? Super smooth road with only left turns and is built to allow you to go as fast as possible? Or literally anything else.
yes, and the real issue is, there are no smooth roads (ime anyways)
> Super smooth road with only left turns and is built to allow you to go as fast as possible?
whats interesting is, from a high-level perspective, riding with shocks (slack) can feel more like nascar than rally even if the day-to-day has bumps.
and of course, aside from slack, there are other things that help get to "nascar" such as good specs, good/easy architecture, low-interruption/async communication, and good management, but even then its just reducing the likelihood of bumps...