[bluehatbrit]

I'm not sure this is what the parent commenter meant. I think they meant the OP should get to the point where as a developer they can anticipate business needs.

That could manifest through areas like suggesting architectural changes that'll save money or open up doors in the near future, or finding pieces of the business that can easily be automated to generate / save money.

[johnnyfaehell]

I think I've been misunderstood, I'm not advocating people to quit being a developer. I was pointing out that what the person was originally suggesting is actually start doing non-development work.

> where as a developer they can anticipate business needs

The thing is, a developer isn't normally in the business meetings where these are discussed. It's not a developers job to be in on a meeting about using X pricing model over Y.

A developer is a doer job. Developers do things. They don't decide things other than the technical details. If you're going to learn the business properly, you need to start entering other areas. Such as product management, start defining problems with the product and what can be changed. That a developer can start doing, but sitting here pretending it's not developers work is just lying.

Too often I read on the internet and hear at conferences that "every developer should do X for their company". Guys, I'm going to break it to you guys. X is literally another person' job, if I start doing it, they're going to get pissy real quick (or they're lazy and will just take credit for it) For some reason people seem to think developers are swiss army knives of businesses. It's not our job to find problems with the product, that's the product managers job. We can start doing it but we're going to start moving away from development work and towards product work. That's not a bad thing per say, it is just what is.

[zebraflask]

... not to belabor the discussion, but have you ever run across a scenario where one of the non-technical people tried to insist on something absolutely boneheaded from either a business or technical perspective? Who gets blamed if the dev just shrugs and does it?

Hint: not the person who insisted on it. The developer.

I've seen that play out too many times. Expanding out of a strictly coding role isn't just good for career progression, it's a necessity for career self-preservation, too.

[johnnyfaehell]

Yes, refusing to do things that are technically bad is a technical matter hence a developers job. And what happens if you say no, they either go find a developer who will do it (seen that so often) or they go to the CTO/Engineer Manager/etc to try and get them to agree. In both cases, a developers job is to give technical feedback such as "Sorry but that's a security threat, you'll need to figure a new approach. Maybe try Z." not, "I think it is a better idea to work on X instead because it's going to generate Y". One is technical feedback on their idea and the other is a product/business idea.

> Expanding out of a strictly coding role isn't just good for career progression, it's a necessity for career self-preservation, too.

The first part is pretty much my point. To progress in a career in IT you have to stop doing technical work to progress. Development is a dead end job, just a reasonably well paid one. The second part, for the most part, I've never really seen. Most developers I've worked with haven't been held accountable for anything in such a long time that they get offended when you point out 500 servers going down in 20 countries because of one Redis server is embarrassing and we should work on stopping that from ever happening again and give excuses why it's not.

[zebraflask]

I was just typing out a reply suggesting the same thing.

The "trap" in development is in having non-technical roles view your role, essentially, as one in where they make all of the business decisions, and you as the coder take their orders to implement them.

That's no good for career progression or effective development, either. I'd deliberately cultivate some of the same PM and business analytics skills alongside your technical skills.

[bluehatbrit]

I completely agree that it's useful to cultivate PM and BA skills, if anything just to help with empathy across teams and enable you and the team to work better.

There are more and more companies slowly developing career pathways with technical only routes, but it's definetely not enough places.