|
|
|
|
|
|
by andher
1765 days ago
|
|
|
Thanks, that's a great point and reminds me of the 'quantity trumps quality' parable[1]. I've found necessarily more of my time goes in reviewing code, reviewing design, setting up collaboration and proposing work (vs being able to ship more code). Any good ideas on dealing with this change in the nature of work that has to be done at more senior levels? I've also found, as I ship features fast, I don't always retain all the new stuff I learn until I've touched it a couple more times. Maybe this has something to do with how I've been learning, but any suggestions there? [1] https://blog.codinghorror.com/quantity-always-trumps-quality... |
|
|
Quality versus quantity is a false dichotomy. You actually need both quality and quantity (or more accurately: speed of delivery). Don’t ship bad code for the sake of shipping code because this will damage your reputation.
The actual tradeoff most people are up against is speed versus complexity. If you find yourself in endless process meetings or talking about new architecture changes over and over again but it takes forever to actually write code, then you’re stuck on the complexity end of the spectrum. Complexity feels good in the moment because it feels like you’re doing the right thing and reducing risk, but the more complexity you add the less product you actually ship.
Learning how to simplify to the bare minimum, reduce process overhead, and ship quality, minimal code quickly is the art you want to learn.