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.
> 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.
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.
> 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.
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.
There are more and more companies slowly developing career pathways with technical only routes, but it's definetely not enough places.
Doing the other roles is a way to learn about some business. By doing them you'll have a better understanding of what happens behind the scenes, and will interact better with those roles.
Do you think your scrum master is done after the stand up? Oh no, there's a lot more to do.
You know scrum master doesn't do development, they do project management work. Their entire job is to make sure the project is not impeded.
If you love being a developer/programmer stick with it. You will love what you do and will eventually earn more.