[TameAntelope]

I used to think like this, but what I ultimately realized was that it's pretty arrogant for an individual contributor to think they know best what the user wants.

Once I realized that, it made a lot more sense why I wasn't (and shouldn't!) be the one calling the shots on priority, UX, tempo. Even for things like tech debt, it really needs to be baked into the ability to deliver new value to a customer or it's very often not worth addressing.

Ultimately, I tried to get closer and closer to the users, so I could be in a position to know what they want, but as I did that, I found myself coding less and less.

It's a tradeoff. If you really love to code, you must accept you need help figuring out what to code. If you would rather build things people like, you must accept that means spending a lot of your time talking to and working with users.

You can't be a one man band.

[edrxty]

To clarify, I work embedded systems for aerospace so it's a very different world than most devs exist in. The customer is asking for something defined in a legal contract with the details spelled out for the most part. The issue is the industry is inhabited by dinosaurs so the older I get, the more I realize that *nobody* knows what they're doing. Everyone is just trying to maintain their silo so they can keep getting a paycheck. As such everyone is still using c/gcc/svn/eclipse/windows/vxworks and if you even think about changing any one of those things in the slightest you'll be inviting a firestorm of pushback as it threatens to break long established and scripted personal workflows that only the individual understands: https://xkcd.com/1172/

Corporate almost always wants faster/better/more agile/higher reuse and you see that in postings/interviews but the PMs/Principle types always dig a moat to prevent anything from moving down to Seniors and lower.

[JesseObrien]

You can't be a one man band, but if the organisation supports it, you can achieve both. In my experience, it doesn't need to be a trade off. We can get close to the users and program to your hearts content. We need the right company and environment to want to invest in that for us. There's a great loop we can get into by doing things like offering demos of new features to clients weekly or bi-weekly. What I've seen happen is that we don't need to code as much because we know the specific problems that need to be solved, rather than loads of guesswork and trying to write blanket solutions for misunderstood problems.

[TameAntelope]

If that's the route you want to go, prepare to spend more than half of your time not coding.

I personally think this is the future, and the myth of the introverted software developer who comes up for air to say 5 words in a standup is well past its expiration date, but a lot of people cling to that pretty strongly, so I expect people will prefer to code in dysfunctional teams that aren't well connected to their users for years to come.