This is the typical “just world” rant of the junior to mid-range devs. Did this exact rant back in my day.
I’ve been in those shops that “consider the philosophy, history and discipline of code”. Your counterparts in those organizations? They’re ranting against the waste they see going on.
The reality is more nuanced. If you were handed a multi-thousand developer organization, business goals, and a fixed budget by the BoD via the CEO and CIO, your theories of “how it should be” won’t make it past the first fiscal quarter.
This is the next level awareness of what Brooks meant by “no silver bullet”. He wasn’t just talking about coding tooling, he also meant these kinds of diatribes we all evolve through in our career.
We aren’t paid to only cut code. We’re paid to help deliver an outcome. Outcomes at the business level are not evaluated by the same criteria you personally use, despite what your immediate business liaisons tell you; you need the C-to-upper-management perspective to start to understand the real decision factors. Before you make assumptions about companies not knowing at industry aggregates level how to pay developers, first go manage a multi-hundred to multi-thousand person engineering organization with balance sheet and P/L LOB insight into their real impact as crunched by the finance wonks. Then you’d know the real cost benefit you currently assume the finance people in aggregate don’t know.
We absolutely can and must do better as an industry, and I see us every month making incremental progress (this is much more difficult to see in the first half of your career because you struggle to get a feel for what is and isn’t progress that business cares about). That doesn’t preclude us from obtaining useful outcomes given prevailing conditions (including pay as a very small factor).
I’ve been in those shops that “consider the philosophy, history and discipline of code”. Your counterparts in those organizations? They’re ranting against the waste they see going on.
The reality is more nuanced. If you were handed a multi-thousand developer organization, business goals, and a fixed budget by the BoD via the CEO and CIO, your theories of “how it should be” won’t make it past the first fiscal quarter.
This is the next level awareness of what Brooks meant by “no silver bullet”. He wasn’t just talking about coding tooling, he also meant these kinds of diatribes we all evolve through in our career.
We aren’t paid to only cut code. We’re paid to help deliver an outcome. Outcomes at the business level are not evaluated by the same criteria you personally use, despite what your immediate business liaisons tell you; you need the C-to-upper-management perspective to start to understand the real decision factors. Before you make assumptions about companies not knowing at industry aggregates level how to pay developers, first go manage a multi-hundred to multi-thousand person engineering organization with balance sheet and P/L LOB insight into their real impact as crunched by the finance wonks. Then you’d know the real cost benefit you currently assume the finance people in aggregate don’t know.
We absolutely can and must do better as an industry, and I see us every month making incremental progress (this is much more difficult to see in the first half of your career because you struggle to get a feel for what is and isn’t progress that business cares about). That doesn’t preclude us from obtaining useful outcomes given prevailing conditions (including pay as a very small factor).