Earlier quoted context omitted.
Unpacking that: > Code is an expression of a business solution At some very high level that may be true. The person who makes the final decision on what code I work on (who happens to be the brother of the CEO, poor fellow!) may have to consider "business requirements", but only lightly. We implement what we are told to implement. I am a worker. > The meat of any application is in the business rules it enables and en…
You’re not unpacking anything in what I said, you’re just disagreeing with each point, and each disagreement is mostly rooted in a misunderstanding of what I’m saying. My point is that the code, and all it’s material constructs that you pointed out (loops, allocation etc), do not exist apart from the business, because it’s the only reason those things exist in the first place. I’m not sure how much experience you hav…
What else is that true for? All the way down. Biology, chemistry, physics, quantum physics.... All that we work on exists in those contexts too. Yet we just swim in the sea and ignore the water. The same is true of business matters. They are the ocean I swim in
> I’ve seen devs waste literal months on things that, had the primary stakeholders known about it, they’d never have agreed to.
That is poor communication. Communication is a necessary skill for all cooperative endeavours.
I am a cog in a machine. Unusually for some one in my position I actually have a good understanding of business (studied it for years) and I prefer computer programming. Having computer programmers stick their oar in over financial matters, unasked, is not good. So I do not do it. I know my place, I like my place.