[PragmaticPulp]

Ship code that works, do it quickly, and do a lot of it.

A common mistake is to focus too much on the technical aspects and not enough on shipping. It’s easy to get lost in over-engineering the hypothetical perfect system that doesn’t ever shift to customers. You don’t want to be that person.

Instead, focus on simplifying implementations and shipping simple, trustworthy code as quickly as possible. A reputation for getting things done will go a long way.

Beyond that, focus on area under the curve. The more code you ship and the more tickets you work through, the more experience you’ll acquire. Cut through the time wasters and get coding as much as possible. Over a decade you can accumulate multiple times more experience than someone who moves slowly and puts in the bare minimum. This doesn’t mean kill yourself by working 50+ hour weeks, but it does mean you need to learn how to cut through the slack in a workday and eliminate procrastination and distraction. Learn how to get down to work and focus efficiency. It’s a learnable skill.

[andher]

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...

[PragmaticPulp]

> that's a great point and reminds me of the 'quantity 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.