| > A lot of them expect you to tell them how, but they will refuse to ask for help until too late. Software is an industry in which people are criticized frequently for doing things differently than how others would've done them. This results in devs (that are less confident with that type of confrontation) over-asking how a company wants something done, and then feeling anxiety around getting it wrong and needing to ask for help. It might not necessarily be the responsibility of the direct manager to define _how_ things are done from a technical perspective on that team, but it's certainly someone's. "I expect you to know how to write software in our codebase" kind of falls apart, given the infinite options for how problems are approached within a given problemspace. If you're seeing this type of behavior, your org might have trouble with A.) responding to aggressively with developers building something differently than expected, B.) valuable criticism. Pull requests are exhausting, in my experience, because they oftentimes turn into theoretical debates about the validity of different approaches. Pull requests are the correct time to offer actionable criticism on submitted work. Pull requests are not a place to complain about an implementation strategy, or to suggest the developer should've done something totally differently. If the submitted solution is so far away from correct that that type of criticism comes up, your workflow has already fallen apart (as a developer was able to build and submit a solution without realizing their work wouldn't pass review). > When I was on the other side, the opposite was true too, I has bosses that expected me to do things their way, even if I could demonstrate that there were better. I think ultimately either is "fine" - things just need to be defined appropriately. If a developer is given the freedom to basically do whatever they want, they need to be told so, and that ideal has to be supported through the entire dev lifecycle. Meaning your team's culture has to have the restraint to not complain about implementation details. In my experience, almost no org is actually comfortable with this method though. In my experience it's best to literally define "how" a team solves the problems it is tasked with. |