3 ms·

My thesis: Sometimes some of the developers who "get shit done" and ship on time are the most destructive of all. Creating huge inefficiency savings for relati

by nly 3y ago

My thesis: Sometimes some of the developers who "get shit done" and ship on time are the most destructive of all. Creating huge inefficiency savings for relatively modest savings in the short term. Spending an extra day thinking about the system you're writing when you know it's going to take weeks, before you write it, costs you a small %. The inevitable rewrite could take weeks. 90% of my time as a developer is unfucking previous kludges and weak designs

hobofan 3y ago
I don't think that there is any correlation between time spent "thinking about the system" and likelihood that it needs "unfucking". If there is any at all, it's probably the inverse. When I think back on all the projects that needed fixing, they were usually systems that were over-engineered the hell out of and that someone spent a lot of time "thinking about", where a much simpler solution would have sufficed. I think part of the problem here is that (some) engineers (sometimes) spend the time "thinking about" the problem, and then think that their solution has to match time spent thinking in terms of complexity. And that time is often spent aimlessly "thinking about" the problem rather than understanding and breaking down the problem and doing structured engineering.
- arcbyte 3y ago
  We want more thinking about business complexity and much much less thinking about accidental technical complexity. I agree that I've seen people build monstrous things full of pointless technical abstractions to do the simplest business requirement possible. I've also seen people build the stupidest collection of logic into a maze of rules in one simple but massively long class to accomplish what is actually a trivial business problem that could have been clearly solved in 5 lines. I would rather they spend a bit more time thinking about how the business problem and whether they are solving it appropriately.

by nly 3y ago

hobofan 3y ago

I don't think that there is any correlation between time spent "thinking about the system" and likelihood that it needs "unfucking". If there is any at all, it's probably the inverse. When I think back on all the projects that needed fixing, they were usually systems that were over-engineered the hell out of and that someone spent a lot of time "thinking about", where a much simpler solution would have sufficed. I think part of the problem here is that (some) engineers (sometimes) spend the time "thinking about" the problem, and then think that their solution has to match time spent thinking in terms of complexity. And that time is often spent aimlessly "thinking about" the problem rather than understanding and breaking down the problem and doing structured engineering.

arcbyte 3y ago
We want more thinking about business complexity and much much less thinking about accidental technical complexity. I agree that I've seen people build monstrous things full of pointless technical abstractions to do the simplest business requirement possible. I've also seen people build the stupidest collection of logic into a maze of rules in one simple but massively long class to accomplish what is actually a trivial business problem that could have been clearly solved in 5 lines. I would rather they spend a bit more time thinking about how the business problem and whether they are solving it appropriately.