What are the most annoying work dynamics you face when building products?
Posted by thepeppesilletti@reddit | ExperiencedDevs | View on Reddit | 100 comments
What are the biggest bottlenecks or annoying dynamics you run into while developing a new feature? Things like handoffs, unclear requirements, last-minute changes, endless meetings, poor communication with product/design…
And if you could change one thing to make building products smoother, what would it be?
Dziadzios@reddit
Waterfall where every task is strictly estimated using time instead of complexity, resulting in every day being a deadline day. 3 layers of managers kept pressuring every single task to reduce the estimation, resulting in the most optimistic estimation being the expectation. It wasn't feasible to keep up.
79215185-1feb-44c6@reddit
Sales Engineers who think they're Software Architects.
berndverst@reddit
Or software architects who have never operated a production cloud service and therefore gloss over critical decisions for stability, extensibility and supportability.
79215185-1feb-44c6@reddit
Or the lack of a management structure that allows ops people to talk to engineers in any meaningful capacity.
berndverst@reddit
True.
In my team we the software engineers build the entire service end to end including cloud infrastructure. We also handle our own operations. We have no dedicated ops or QA folks - we do it all. In our case the software architect we work with focuses on our (gRPC) APIs and how we store the customer data efficiently - we work in a very particular domain / space. Everything else is architected by 2-3 software engineers in a team effort as needed. I build my own features, adjust our cloud infrastructure as necessary and handle appropriate migration paths, test everything in test, in staging (production).. roll them out to 30+ global data center regions. Update customer facing SDKs as necessary, work with the UX team to add support, write the technical docs and samples. Work with product managers and solutions architects to make sure they have a correct understanding of the functionality.. potentially train the support team on how to support the feature and build support tools for them. I might be doing this all in a span of 2 weeks. I don't work at a startup by the way.
SmartassRemarks@reddit
This sounds like Amazon right?
79215185-1feb-44c6@reddit
Yea I don't work on cloud products. All of our services are sold to customers for them to self host.
We do not get to interact with customers unless the Sales Engineer needs help. We do not receive any of the customer feedback unless it's filtered by management (management frequently messes up requirements). We have our own Ops team but they are sioloed into their own standup. We have several QA people who are sioloed into their own standup and we never get to interact with them. It's even at the point where our QA team has their own private slack channel that nobody on development is allowed to view except for the 1 ex-QA person who turned into a developer.
The feedback I've received in the past on this is that Engineers are too scary or some crap.
berndverst@reddit
Ah that would be tricky for making good software if the feedback can't easily reach you.
In my case.. if any infrastructure I depend on in any region, the on call of my team gets paged. If our own health checks fail.. I also get paged. Same if we suddenly have a bunch of errors logs, detect memory leaks, missing billing data.. and a lot of other scenarios. I constantly add new alert rules based on new incident types I am investigating. And both internal partners or tier 2 support handling external customer issues may open incidents directly against us or contact us with questions or concerns. Depending on the severity this will page us too. And we have regular syncs with our solutions engineering / sales engineering / cloud architect folks to get their distilled feedback from customers who tried our product, or can't onboard because key functionality is missing etc The feedback loop between customers and us product / service engineers is very good.
79215185-1feb-44c6@reddit
This is great until you get into an industry where your Sales Engineer does nothing but complain about bugs you've fixed 10 months ago (Because his customers refuse to take newer releases), or features you have no control over because management refuses to take action and prioritize those tasks. Management loves to actively shoot themselves and lose customers to chase customers and then wonder why we never make any real progress.
berndverst@reddit
Well, I work at Microsoft building an Azure service - as you can imagine this definitely applies to some of our customers in regulated industries, government or just simply in risk averse cultures :)
Southern-Evidence579@reddit
Totally relatable
wrex1816@reddit
I know it's popular to sit on PM, management, etc. But I've been most frustrated with devs with certain qualities:
Rude, anti-social, know-it-all, hold projects to random to get their easy on everything, treating their world like it's their own personal passion project to trial every new tool and framewo6they want to learn.
I've seen far more projects fail for those reasons than a PM under estimating a task. But devs are notorious for never seeing their own failings.
fsas182ak3@reddit
This one hit the nails .
thepeppesilletti@reddit (OP)
How would you like to see devs behave instead?
wrex1816@reddit
I think we should hold ourselves and our process to much higher standards. We shouldn't tolerate bad behavior or behavior that's not congruous with good practices should we weeded out.
Just look at this thread... Every top comment is pointing out everyone else as the problem. There's very little ability to look inward and see the problems.
Fr example, we've all met the PM who's not super technical and tends to underestimate tasks. Maybe frustrating, but the product still gets built. Bad engineering and bad engineering practices, I have watched literally bankrupt projects. If the engineers can work are a unit, with efficiency, deliberateness and high quality, a project will never be built, and no PM can fix that.
SoCalChrisW@reddit
The sales team selling features that haven't even been considered yet, and it's a huge contract and needs to go live in 3 months.
JaneGoodallVS@reddit
Late code reviews with blocking nits
denverdave23@reddit
Look up the lean mudas and their application to software engineering. Mary Poppendick has a good book on the subject.
Diassh@reddit
If you can reduce the number of decision-making layers, I recommend it. This is because at every layer, you will have some timeouts as they are busy with other tasks.
superdurszlak@reddit
Ego-driven.
I have a really hard time collaborating with people who put their egos on a pedestal and will act and respond with their ego, their position, their standing, their looking-good-to-the-managers, gaining upper hand in the hierarchy etc. in mind.
I am more of a person who is goal-oriented and driven by analysis. Add to that that I'm autistic and really bad at sensing all sorts of social contexts and you can see where it's headed.
i-think-about-beans@reddit
More often than not it’s product managers flip flopping on the requirements last minute.
thepeppesilletti@reddit (OP)
I worked only once very closely with a PM, and saw first hand what she was doing. She was doing lots of discovery calls, trying to pin point the customer pains, and each call brought new insights.
Meanwhile I started doing some work on the product, but based on the findings I never felt confident we should have invested any time on it.
I understand why requirements change, sometime it could be just a stakeholder having a tantrum, but it could also be that discovery is bringing in more insights.
I think the issue is devs being hidden from this process, so they don’t know what’s going on and then surprise! Requirement change.
i-think-about-beans@reddit
I honestly wouldn’t mind, but the deadlines coupled with flip flopping create lots of tension.
thepeppesilletti@reddit (OP)
Yep, but maybe if devs are more involved in discovery they could help with defining deadlines as well
Healthy-Use-7501@reddit
We actually have our engineers jumping on customer calls to understand + scope out individual requirements themselves, the PMs rather handle high-level prioritization and aligning on the larger roadmap with leadership and sales. Has been very effective for us so far
thepeppesilletti@reddit (OP)
Very cool! May I ask what’s the company?
DWebOscar@reddit
Coding for the certainty of unknown and unexpected changes is a very specific skill that is unfortunately not taught anywhere.
thepeppesilletti@reddit (OP)
Maybe coding is note even needed
Atupis@reddit
“Agile” companies suddenly stop being agile when releasing stuff to customers. Basically it doesn’t matter what agile tricks you do before if releasing software takes 2-12 months and needs to pass several gates.
thepeppesilletti@reddit (OP)
Gosh this one really annoys me! Unfortunately having an Agile team is pretty useless if the rest of the company works waterfall
morosis1982@reddit
Lack of understanding/documentation of edge cases from business.
Like yes, I understand this is what you want it to do on the happy path, but what can go wrong? What happens when x or y doesn't happen?
And they don't have like a list of things that they know about, you need to talk to half the team to drag half the things out like we don't talk about that, and then you go to production and a whole bunch of other shit comes out of the woodwork and they're like oh yeah sometimes that happens...
And we've now double invoiced some of our customers for a week.
I'm not salty.
dxonxisus@reddit
for me it’s finger pointing / a bad “blame culture”. we’re all on the same team, working on the same product towards the same goals. why then if somebody slips up, do somebody feel the need to make sure everybody knows who the person was that caused it and to keep focusing on that?
once an issue has been identified, the first question should be, ok how severe is this, and how long would it take for us to address it. spending so much time making sure a person knows they messed up wastes time and just makes them feel unmotivated.
a team culture where people are sl quick to sigh/tut/blame others/roll their eyes is incredibly toxic to me
thepeppesilletti@reddit (OP)
A mix of lack of system thinking and psychotic traits
KronktheKronk@reddit
Product putting no more thought into the product than "customers asked for this"
Product gets an idea for an improvement. They get together with UX and develop a solution. They bring that solution to engineering to implement, no notes allowed
thepeppesilletti@reddit (OP)
How would you change that?
Kolt56@reddit
Resume-driven development. Like DDD, but the “domain” is empire building. Everything becomes a runtime dependency, abstractions vanish, and the real outcome is justifying more outsourcing while the anti-pattern multiplies.
jeffbell@reddit
They never let you rewrite it, no matter how bad.
KronktheKronk@reddit
Rewriting it never succeeds
79215185-1feb-44c6@reddit
The solution to this is to rewrite it in your free time.
Broad_Investment7989@reddit
Ignorance of business/product side on product ownership, somehow it gets to the point that tech team owns everything product, features, business flow... Silosed org is the worst org, no aligned goals across teams and departments, and its very hard to change that type of org...
thepeppesilletti@reddit (OP)
Not sure I understand.. Do you think that tech teams being more involved in product/business is good compared to siloed orgs?
Broad_Investment7989@reddit
Product/business should be more involved and have more ownership and idea on how product works and in which direction product developlent will go. Org should not be silosed and there should be more information and alignment on overall company goals.
Also product/business should own the product and features and fully understand how product impacts business processes and how it interacts with other products...
I hope it gives more clarity.
thepeppesilletti@reddit (OP)
Got it thanks! Weird that business/product don’t do that though? What are they doing instead? lol
Broad_Investment7989@reddit
Yea I wonder the same 🙂 Product should give some clarity on business ideas and problems but instead they provide more confusion. I guess its related to constant changes in product team, knowledge not tranfered to new people...
Another issues is that only visible measurable result is software, no any quaility metrics is done on all steps which happen before we actually start with coding. There should be high quality in all steps.
I would like to see more transparency in business/product decisions like we have commits and prs in code 😃
Also I know that everything starts from business and business needs, but soon as you start writing software then also software becomes your business.
thepeppesilletti@reddit (OP)
The visible measurable part is so important. That’s practically feedback for the business, but also a way for devs to see their impact and be proud of their work. Lots of time is just ship and forget..
Broad_Investment7989@reddit
Sure visible measurable part is important I did not say that its not important. I just want to have more measurable parts in the entire process and fast feedback loop dev<->product<->business.
In many cases I have seen that product team is not adding value which might be expected. Its rare ocassion that actually Product Owner really owns a product with deep understanding.
thepeppesilletti@reddit (OP)
yep I was actually agreeing with you 😀 And I still do!
Broad_Investment7989@reddit
Sorry for misunderstanding 😃
79215185-1feb-44c6@reddit
We have a UX / PM that does not actually use the software so all of their designs are incredibly bad. When we call him out on it (basically unanimous between Sales/Engineering) he gets offended. Has actually gotten to the point where the CTO has told him that he needs to use the software to understand how to design UI flows for it.
thepeppesilletti@reddit (OP)
Designish-thinking
vom-IT-coffin@reddit
Developers not asking for guidance or help after clear architecture decisions, submitting an MR and then acting surprised when it's rejected.
thepeppesilletti@reddit (OP)
Were developers involved in the decision making process?
vom-IT-coffin@reddit
Maybe I'm off base. I'm the Architect, it's an architectural decision / security risk and not up for debate. There were clear instructions in the feature of the technical requirements along with functional requirements. Went over the pattern in refinements, I have an open door, happy to pair with anyone, etc.
There's a handful of good enough to be dangerous developers on the team, they're good, for how long they've been coding, but they're not seniors even though they think they are.
MoneyStatistician311@reddit
Being in the middle between product and design. Product wants it fast, design wants it perfect and I just want me and my team to work 😞
thepeppesilletti@reddit (OP)
Are you able to be the one that finds a compromise? I think engineers can be pretty good at suggesting trade-offs
MoneyStatistician311@reddit
I tend to push for the fast-ish approach, I want to learn as quickly as possible from users and I don’t think we should have perfect design vs good enough
thatVisitingHasher@reddit
Clear leadership. This bottoms up approach causes more issues than it solves a lot of the times. The orgs being so flat is annoying. Going a week or more without talking to a leader can be exhausting. Most people can’t take a few sentences and create and coordinate a plan from that. Leaders are so disconnected they barely know if you’re executing.
vom-IT-coffin@reddit
Careful what you ask for. Top down is a cancer. 10 product owners for a team of developers of 5.
Acting surprised when 2 features actually make the cut because of capacity.
thepeppesilletti@reddit (OP)
Do you think it’d help to have more self-sufficient teams who don’t have to rely on leaders?
thatVisitingHasher@reddit
I think we need to bring a lot more context to the conversation. Government or Fortune 500 companies are different than startups. R&D is different than creating new features in an application with existing users. Through software operating in a highly regulated environment, or considering the sensitivity of the data. I don't work on social media or startups. All my work has been in heavily regulated industries, where leadership has made promises. The devs have no idea what those promises are.
Tired__Dev@reddit
I'll put my most controversial one out there.
Quantitative tracking over qualitative. I am getting to the point having been between the business side and development that I think most metrics are garbage. I think if you need a focus on metrics you lack people skills and technical depth that can make decisions. If you lack those things you shouldn't be in the business of trying to create or consult on anything related to software development.
Metrics are used to comfort the tech illiterate. I've been on the side of leading teams in a way that is structured towards Jira's best practices and it's horrible. I've never seen Godhart's law and perverse incentives not come into play. Never. It's absolutely fucking lazy too. You'd think that it would help accountability for management decisions? Not a fucking chance because there are people that both have a bias to have projects fail and succeed and they argue metrics out of their own bias. It's performative theatre at best.
The basis of metrics has been sold by consultants by non technical people to other non technical people to foster their own technical insecurities into distrust in their developer teams. The only way to manage that as a problem is to be technical.
RowbotWizard@reddit
If Reddit determined quantitatively that more people comment in the evenings and used that to send more notifications in the evenings, is that really something that requires more technical depth?
Or how about if a team sets a goal of increasing signup rate or reducing error rate / downtime?
Identifying these opportunities doesn’t sound that inherently technical to me.
Tired__Dev@reddit
You've identified them. Now set a development roadmap for them that is consistent with what has already been developed. I can identify a range of technical issues outside of the scope of my domains, but that does not mean I can be an accurate judge of the resources around developing outside of those domains.
thepeppesilletti@reddit (OP)
I guess that’s bad if metrics is all it’s used to make decisions. They should be considered in the big picture, together with the qualitative data
sarakg@reddit
Reluctance to define an actual MVP - like a minimal product that has trade-offs they’re willing to live with.
Most recent was one where the PRD didn’t cover have complex error handling - so we clarified that there’d just be a generic error message shown to users and then log the details in the backend. Once they were mucking with an early release candidate, the PM realized that there needed to be more specific error messages, and we ended up delaying a 4 week feature by 4 weeks. And they would have wanted to fully redo a bunch of unrelated error handling in adjacent features if dev &QA hadn’t been able to convince them of the risks in that!
thepeppesilletti@reddit (OP)
I mean, de-risking is the job of a PM lol
Antifaith@reddit
40 people from 5 teams sat around reading an out of date PRD and trying to decipher wtf we’re suppose to build - 4 devs in a pod given two weeks will get whatever you need done yet we sit there for MONTHS going around in circles on requirements
thepeppesilletti@reddit (OP)
I like the new trend of pairing PRDs with vibe coded prototypes, they bring more clarity
mlengurry@reddit
Weak technical management who buckle under pressure leaving devs to pick up the pieces
Pointless political stuff that is only bad for morale
thepeppesilletti@reddit (OP)
Got an example?
shadow_x99@reddit
I would enforce the 3 pillars of software (business, ux and technical) to collaborate at all times.
When one of the pillars is sidelined, waste is created, frustration is created, pain is created
thepeppesilletti@reddit (OP)
Yep! Like “mob programming” but for all roles
im-a-guy-like-me@reddit
Did you just make up those pillars?
shadow_x99@reddit
These are the 3 forces that struggle to cooperate at every job i had for the last 25 years as a software engineer
im-a-guy-like-me@reddit
Agreed, but they're not the 3 pillars of software engineering.
There are no agreed upon pillars of software engineering. And I'd imaging anyone trying to establish some are still arguing about what they should be.
shadow_x99@reddit
I never said Software Engineering (Although I can understand why you would assume as such). I speak of software development in the corporate world, which is much broader (At least IMHO)
The Business force is really all about market fit, desirability from a business standpoint. In a nutshell, can we make money off it.
The UX force is really all about the end-user (which may not be the one that actually writes the checks), will the user desire the software, learn to love it for all it's power and quirks, having the most friction-less experience, etc.
The Technical force is really about feasibility, technical sustainability, maintainability, scalability, etc.
IMHO, you need those 3 point of view / force at the same table, properly aligned to make good software products.
im-a-guy-like-me@reddit
I dunno dude. That's a lot of asterisks.
Some guy coding micro controllers is doing software, possibly corporate, and doesn't need to care about UX or Business.
Anything is the thing when you describe it specifically enough.
shadow_x99@reddit
Good point.
The forces may be different (There could be more than 3?) when there is hardware involved, not everybody is coding a mobile app or making a SaaS.
I would be curious to hear the point of view of someone working deep in hardware, what are his/her pains.
Main-Drag-4975@reddit
I liked it 15 years ago when it was Bits, Features, Truth
walmartbonerpills@reddit
You can't code your way out of a bad management decision.
throwaway0134hdj@reddit
Absolutely true. Manager defines your work.
i_dont_wanna_sign_in@reddit
If the manager or PO ask for trash, deliver well-running trash. Keep the architecture open enough to allow the next poor saps to remedy the situation a year or two down the road when the delivered trash gets rightly rejected by those who have to use it. It'll cost a bit of time but it's worth it if you can get away with it.
The absolute WORST customers I ever had were the agile team (terrible at agile, to boot). We needed an overlay for the SaaS project management software that the VP forced the company to license despite being told no several times. It managed products fine but they wanted it to also serve as a ticketing system, which it absolutely could not do without very heavy modification. The overlay was a full on project that mirrored the SaaS system but shoehorned on ticketing. The head Scrum AH was the PO and he had the absolute WORST ideas about how it should be built. He was convinced his vision would paradigm shift the 1000s of users. It didn't. But we designed the product backend to function independently of the SaaS API. When the VP and agile teams got justifiably kicked out, we deactivated the API and had a fully functioning, home grown (free) PM and ticketing system that integrated with Jira.
throwaway0134hdj@reddit
knowledge hoarding/siloing from team mates I find particularly toxic and pernicious. Sometimes it’s not on purpose (due to how fast we build) but other times it’s for job protection. Making it like pulling teeth to get any information on how their processes work. Also difficult for any juniors trying to get a handle on the project because all the work is veiled in secrecy/blackboxed. And that ofc is permitted through bad management who is better able to control via divide and conquer dynamics.
YareSekiro@reddit
Dealing with execs/higher ups in general. The line managers can't do anything about them, and the devs essentially gets the rug pulled under them and had to start from another direction because one exec has a "brilliant idea". I have the utmost respect for my managers for dealing with this stuff on a daily basis when I am already going mad talking with them maybe once a month.
Abangranga@reddit
AI-generated JIRA tickets
ZukowskiHardware@reddit
Poor/lazy engineering practices. Constantly reminding people I need to see unit tests. Model/diagram before building. Ship first - get it into prod as fast as possible. Small pull requests. It always just feels like a race to the bottom for “speed” - which ends up being late nights and a buggy product. Basically just lack of discipline.
Antagonyzt@reddit
Project managers. Why do PMs in our industry suck soooo much!??
kutjelul@reddit
I have no product manager currently, so the PO feels like they’re in charge and the EMs should be in charge but they are simply clueless, leaving development teams to basically negotiate all big decisions by themselves. Not sure which one is better
AfricanTurtles@reddit
Business Analysts pretending they understand how easy or difficult tasks/features are. Writing bad requirements with not enough detail or missing basic edge cases.
RowbotWizard@reddit
Loss aversion leads to most of the dynamics I struggle with. It’s hard for people to pick things to say no to and they often fail to realize that each “yes” is actually a big “no” to other bids for time.
When too many doors are open and in progress, you have to keep a wide working set in memory.
When you have to support two features or needs that are at odds with one another, behaviour becomes unpredictable and complex.
When the org starts using or selling something that got deprioritized, some of the feature requests may become perceived as bugs with expected vs actual behaviour.
Just to offer a few examples.
Which-World-6533@reddit
People who spam multiple subs with the same question.
79215185-1feb-44c6@reddit
I must be lucky not being in those other subs.
Potato-Engineer@reddit
You are. I haven't muted /corporate yet, but I really should. The "recommended" posts are generic anti-corporate slop or generic "how do I brown-nose" slop.
csanon212@reddit
Handing off technical products to other teams when given management directives to do so. It's the old adage of leading a horse to water but not being able to force them to drink.
You can give the team everything. Operational handbooks, multiple recorded code walkthroughs, tabletop exercises on common known issues, Jira backlog transfers, transition periods. You can document in writing that at specific parameters, you expect certain scale to cause issues.
Guaranteed when that team gets their first real outage, they will ping you, say they weren't ready, and management will blame you, and say you need to support a product without changing your existing priorities or lightening your operational work load.
Real story that happened to me at a F500.
Careless_Detail_2318@reddit
We are a design driven company, and our design team is terrible, so there's too much back and forth with them trying to get something that will be both user friendly and look okay
conconxweewee1@reddit
Dude for me, it is without question over rotation. What do I mean by that?
Typically it’s when project managers or other managers want to sit there and have meeting after meeting after meeting of beard twisting sessions where they talk about every single little detail/edge case etc. It absolutely ensures failure of any feature in my experience.
Outline what you want, get some designs together, use common sense, put your hands on the keyboard and get the work done. The edge cases will come to you and you’ll get them done way faster once you have a working v1.
cjthomp@reddit
Write your own LinkedIn blogspam.
AlekseyVY@reddit
Ok, here is interesting case, we have legacy approach to angular forms, someone basically wrapped each input into self containing reactive form and in order to build form you must use inputItem which is obgect that holds several callbacks and passed to that reactive input, so we have now an input which is reactive form, and object that used as Input to that component and holds callbacks, callbacks are used to mutate parent which serves as form, lol. And now except from that we have hundred of lines like new InputItem and fooItem.inputCallback = someCollback, we can't validate single form, because we don't have it) and building bycicles on top of that solution. So I proposed to adapt those inputs to ControlValueAccessor and use them in parent reactive form, but current frontend lead wants to stick with old callbacks approach, because of consistency)))
Achrus@reddit
If we’re talking annoying, I get asked constantly why we didn’t use LLMs or if we have plans to try a GenAI approach. Not project killing but maybe death by a thousand paper cuts big picture. Definitely annoying though.
amendCommit@reddit
Tech management making back of the envelope decisions overriding my own, expecting me to write whitepapers when I want to change anything of importance, all while claiming that I "always had the lead on the project, ".