10-10-2021, 02:34 PM
If there are any other developers or former developers around here, I'll just leave this semi-rant for what it's worth.
I have no real regrets that I've focused for the past 25 years or so on the Microsoft dev stack. The tooling is generally excellent. Except ...
Except that Microsoft has a really bad habit of pushing something to be adopted that's the Next Great Thing and Final Answer, and then suddenly deciding that it's not.
One I remember from awhile ago was .NET Remoting. If you needed to do IPC, it was Da Bomb and SO superior to its unmanaged predecessors. Until it wasn't. Then it became, IIRC, Windows Communications Framework. Remoting would be supported as to bug fixes for an indefinite time, but this utterly different API meant that I'd have to convince clients to completely rewrite solutions I'd provided based on Remoting, if they wanted to not have difficulty maintaining code that now, some 15 years later, no one remembers or understands anymore.
One of my responses to this kind of thing was to style myself as mainly a back-end guy. There's enough churn there, without dealing with all the crazy conflicting approaches on the client-facing side of things. But now the trend is "full stack development". Employers, as usual, want it all, so they insist you know the front end. Angular, React, Vue, jQuery, etc etc etc as well as platform-specific architectures.
So I just spent six joyless months figuring out something that used to be pre-MVC ASP.NET but is now slathered with proprietary JavaScript and XML, which translates to basically nowhere. And now I'm being moved to a team maintaining ASP.NET MVC v5 with a side helping of jQuery, that they want to move to .NET 6 in coming months, so yay -- except now that I look at it, Microsoft has decided that the way forward is something only vaguely compatible that requires significant refactoring to move your code base forward, called "ASP.NET core with MVC".
I miss the days when you could just focus on solving problems for people instead of keeping up with someone else's committee and marketing-drivers vision of how your architecture should work. I would say that since unwillingly re-entering the corporate development world, some 60% of my time is spent either on migrations like this or figuring out something that's stuck in the past. Neither is any fun at all, apart from how occasionally some small aspect of it resolves a chronic pain point.
It's one thing to take someone else's poorly written code and make it great. It's another to break everything in the service of your vendor deciding to rename stuff and move it to different namespaces and changing former best practices.
Is it any better on the open source side? I'm doubtful. Too much in software development is fad-driven. It's as much about the promise of bright shiny new playthings to placate management about why things aren't Moving Along at the desired pace, as it is about engineering.
Thus enders the rant.
Curious what other's experience or coping strategies may be here.
Mine would be to have sole responsibility for an app or system and just do what I felt was best and be held responsible for results. That has always served me well. I don't see a way to do that anymore. It is all about chanting "no blockers" in scrum standup meetings and working tickets.
I have no real regrets that I've focused for the past 25 years or so on the Microsoft dev stack. The tooling is generally excellent. Except ...
Except that Microsoft has a really bad habit of pushing something to be adopted that's the Next Great Thing and Final Answer, and then suddenly deciding that it's not.
One I remember from awhile ago was .NET Remoting. If you needed to do IPC, it was Da Bomb and SO superior to its unmanaged predecessors. Until it wasn't. Then it became, IIRC, Windows Communications Framework. Remoting would be supported as to bug fixes for an indefinite time, but this utterly different API meant that I'd have to convince clients to completely rewrite solutions I'd provided based on Remoting, if they wanted to not have difficulty maintaining code that now, some 15 years later, no one remembers or understands anymore.
One of my responses to this kind of thing was to style myself as mainly a back-end guy. There's enough churn there, without dealing with all the crazy conflicting approaches on the client-facing side of things. But now the trend is "full stack development". Employers, as usual, want it all, so they insist you know the front end. Angular, React, Vue, jQuery, etc etc etc as well as platform-specific architectures.
So I just spent six joyless months figuring out something that used to be pre-MVC ASP.NET but is now slathered with proprietary JavaScript and XML, which translates to basically nowhere. And now I'm being moved to a team maintaining ASP.NET MVC v5 with a side helping of jQuery, that they want to move to .NET 6 in coming months, so yay -- except now that I look at it, Microsoft has decided that the way forward is something only vaguely compatible that requires significant refactoring to move your code base forward, called "ASP.NET core with MVC".
I miss the days when you could just focus on solving problems for people instead of keeping up with someone else's committee and marketing-drivers vision of how your architecture should work. I would say that since unwillingly re-entering the corporate development world, some 60% of my time is spent either on migrations like this or figuring out something that's stuck in the past. Neither is any fun at all, apart from how occasionally some small aspect of it resolves a chronic pain point.
It's one thing to take someone else's poorly written code and make it great. It's another to break everything in the service of your vendor deciding to rename stuff and move it to different namespaces and changing former best practices.
Is it any better on the open source side? I'm doubtful. Too much in software development is fad-driven. It's as much about the promise of bright shiny new playthings to placate management about why things aren't Moving Along at the desired pace, as it is about engineering.
Thus enders the rant.
Curious what other's experience or coping strategies may be here.
Mine would be to have sole responsibility for an app or system and just do what I felt was best and be held responsible for results. That has always served me well. I don't see a way to do that anymore. It is all about chanting "no blockers" in scrum standup meetings and working tickets.
![[Image: SpaceMouse-Enterprise-main_header_image.jpg]](https://3dconnexion.com/uk/wp-content/uploads/sites/1/2019/07/SpaceMouse-Enterprise-main_header_image.jpg)



