3 ms·
All code? Nah. Other people's code? Of course. /s Most code? Yeah, I kind of think so, actually. The demands of business will always be at odds with engin
by ravenstine 5y ago
All code? Nah.
Other people's code? Of course. /s
Most code? Yeah, I kind of think so, actually.
The demands of business will always be at odds with engineering, and everyone is at different levels in their coding journeys, and everyone's got different opinions on what code should be. It's a tug of war where no one actually wins but everyone gets a consolation prize that hopefully makes it worth it.
Code sometimes surprises me, in a good way, and it also disappoints me a lot of the time. I can't really say that My Way TM is better. The disappointment mostly comes from a lack of will from the rest of an organization to not take steps to make things better, even when the writing is on the wall that they will have to sooner or later.
In short, yeah, it's kinda bad, but it's also not so bad. Something we all need to do, I think, is accept that what we were taught that coding would be like is fantastical. I guess I was influenced early on in such a way that I believed that one day the code would actually get better. With a handful of exceptions, it usually doesn't. Unless one is lucky, our job is to make it work and to figure it out when it's not working.
- chadanon 5y agoI like Uncle Bob's lecture on what it means to be a professional. We have to make time to mold code and recaftor it without buy in - make that time built in to the estimates you give. Another thought... At some point there's going to be a software caused disaster with very large human cost of life such that the governments of the world will demand and force regulation and certification. Software "Engineer" will have the same hoops and red tape every other engineering profession has to deal with and over the long run we may all be better off if it's not to late. If the transhumanists give birth to free willed laser-beams-for-eyes robot hybrids... probably too late. As dark as this sounds I hope a software disaster comes sooner than later.
- bradlys 5y ago> We have to make time to mold code and recaftor it without buy in - make that time built in to the estimates you give. The problem is that often management has been technical at some point in the past and will want a full breakdown of why something costs more time than they think to implement. Soon as you detail having to refactor X or do some other “non-essential” thing then it gets put on the cutting room floor. I’ve experienced this a lot. It’s often people who have escaped having to write code that are the biggest backstabbers.
- TheCoelacanth 5y agoIt's often a principal-agent problem. It's usually in the manager's best interest to deliver a feature faster even if it results in future features taking longer, because their bonus/promotion is dependent on delivering the current feature, not on the long-term impact.