3 ms·

I'm still learning too, but I think that something I'm trying to develop is a sense for the longer-term costs and implications of apparent defects. - Is this a

by jka 5y ago

I'm still learning too, but I think that something I'm trying to develop is a sense for the longer-term costs and implications of apparent defects. - Is this a component that every engineer is going to interact with and that will stay with the company for decades? - Can this technical decision be reversed easily? Either in the sense of an individual commit revert, and/or in terms of a series of code changes? - Is this change likely to remain isolated to this part of the codebase, or will the pattern infect or be copied to other locations widely? It's super challenging -- and also intellectually rewarding when you can master it and gather team consensus and alignment.

hinkley 5y ago
> Can this technical decision be reversed easily? One of the most exhausting failure modes that I've had to deal with is deciding not to decide. Some people will build elaborate Rube Goldberg machines so that they "can change their minds later" but in fact what they've done is decided that choices are now everybody else's problems. There's a whole hell of a lot of rewards to having the maturity to be able to say "I was wrong" and move on. Writing code in a way that you could rework it to use a different library to accomplish the same thing is making a reversible decision. Creating a rules engine to let a config file make the choices and leaving a cartesian product of states (75% of which are invariably illegal, which you are just supposed to know) is definitely, definitely not. Just pick something, man.