8 ms·
You'd think this is non-controversial, but have worked at places where product and UX act as gatekeepers and don't want engineers involved with the problem solv
by gedy 3y ago
You'd think this is non-controversial, but have worked at places where product and UX act as gatekeepers and don't want engineers involved with the problem solving. They'll "figure it out for you" and then spoon feed Jira tickets and Figma mockups to devs.
- JodieBenitez 3y ago> They'll "figure it out for you" and then spoon feed Jira tickets and Figma mockups to devs. Been there... never again. If I can't speak to the people that use the software, I'm out, period.
- ahepp 3y agoI also agree that I prefer to work this way, but it's crazy to see how many developers have an "I just want to code, I don't want to think about business problems" mentality. In some ways I respect their devotion to pure technical craft. Personally, I'm not talented enough at the technical aspect to make up for ignoring business needs.
- toyg 3y agoOften it's because getting involved on the business side means doing a lot of politics. Is this problem more urgent than that problem? Who will take credit for solving this problem? If I solve this problem, will they fire half the people who currently solve it manually? If I solve that problem, will it empower a certain scumbag VP who's been clamouring for it? Etc etc. Codemonkey doesn't want to be involved with all that shit.
- creshal 3y agoRequirements engineering can be extremely draining regardless of it. What's that? We're three years into this six months project and you just realized again that you don't understand your own job, don't understand the legal requirements placed on you, nor your position in the overall organizational architecture? Of course we can rewrite everything from scratch for you, again. What do you mean there's no budget and it has to just work?
- rob74 3y agoI don't think GP means getting involved with business side decisions, just understanding the "business logic". Where "business logic" is a generic term for anything, it could also be the rules of a sport, how the competition(s) are structured etc. if you are building a sports website...
- BOOSTERHIDROGEN 3y agoWait, I'm no programmer, How could programmer build if they don't understand that minimal business logic ?
- punnerud 3y agoSpoon feed JIRA tickets on what to do
- rob74 3y agoIt boggles my mind how someone can think they can build anything useful without having a basic understanding of what the thing they are building will be used for... that's a sure-fire way to software that will be a nightmare to use (and support).
- jon-wood 3y agoMy biggest frustration is the people who refuse to get involved with any of the process of defining requirements, but then when the requirements arrive moan about how they're stupid requirements and won't get the job done. You can't have it both ways.
- vsareto 3y agoIt's because defining requirements is someone else's job, so if you get involved, you will be doing part of their job while you might already be working at your capacity. The Agile style user stories that often lack technical details because the author doesn't know enough about the technical details means the developer is the one actually writing the requirements (usually as they are doing the work).
- tlb 3y agoI've experienced this too at a bigco. A well-meaning group of UX people took on the role of conducting all user observation studies. And the studies were high-quality and statistically valid, but it took months to get observations I could have seen directly in minutes. So the recommendations were mostly about things I'd already fixed or changed. It's much better to just talk to users and watch them work. A same-day feedback loop beats any improved study quality.