What 10k Hours of Coding Taught Me: Don't Ship Fast
sotergreco.com
What 10k Hours of Coding Taught Me: Don't Ship Fast
1–10 of 116 posts
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#2The refactoring piece is a great advice. That is the only way to keep the codebase sane and relatively free from tech debt. And if it is not the part of the process, it would never get prioritised.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#3The refactoring piece is a great advice. That is the only way to keep the codebase sane and relatively free from tech debt. And if it is not the part of the process, it would never get prioritised.
Tidy first!
Make the necessary change easy to make
Then make the necessary change
I’m paraphrasing Kent Beck
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#4Do ship fast until it is known what the application will even be and what the feature-set is and what needs the user actually has and not just what it is believed they need.
Don't sink a bunch of time into "cleanly" exploring the fog-of-war. Gather as much insight as possible as soon as possible. Only then will you be equipped to actually architect for the domain as it actually is rather than what you the developer think it might actually be.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#5So much of our “ship fast” culture is based around end-user application development, where it’s a reasonable and defensible approach.
But the further away you go from end users toward libraries, then internal services, then even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements, and getting it right pays dividends. Or more realistically, blasting something half-baked out results in drag on your organization that you end up having to support for forever.
On a slightly different axis, APIs should be built with more thought and care than internal implementations. Backward-incompatible API changes are hard. So start out by building an API that expresses the logic your consumers want to implement. README-driven development works great here: literally write the README that showcases how people would use your API to do a variety of tasks. Then you can iterate as many times as necessary on the code, while having to iterate on the exposed surface area far less than if you just exposed today’s internals as the API (which is sadly the norm).
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#6When I program something new and challenging, whether I want to or not, I follow Kent Beck's pattern[0]: “Make it work, make it right, make it fast.”. It seems unavoidable.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#7So much of our “ship fast” culture is based around end-user application development, where it’s a reasonable and defensible approach. But the further away you go from end users toward libraries, then internal services, then even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements, and getting it right pays dividends. Or more r…
This, exactly. Rapid iteration on user control surfaces is good; rapid iteration on public APIs is bad.
Edit to say — rapid iteration of UX is good as long as it’s goal-aligned and has an endpoint. Set a goal, iterate and measure until you achieve it, then leave it alone.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#8So much of our “ship fast” culture is based around end-user application development, where it’s a reasonable and defensible approach. But the further away you go from end users toward libraries, then internal services, then even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements, and getting it right pays dividends. Or more r…
Mjeah. It is our goal at work to enable our teams to deploy changes to their systems in production within minutes. And this works and the teams utilizing it get commended for it.
But I also need to plan and execute a major database upgrade with ~250 applications depending on it. I will be very happy if I can have a solid, generally accepted plan in a month or two. It will just take 1-2 person-days to eventually execute the updates, but it will take 6 - 12 months to get there. And from what I hear from colleagues and customers, that's fast.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#9One of the great things about working from home is that I often don't do anything. As in, I'm not even by my computer.
I'm still thinking about what to do, but I'm not implementing anything. I'm not typing stuff, I'm not waiting for a compile, I'm not outwardly moving the project forward.
But the project is moving forward.
Inside, I am considering the tradeoffs. I'm thinking about what the business needs, and what things will look like when I'm done.
Now and again, things come together and I write the code. It's a lot less frantic than 20 years ago when I started. I throw away fewer things, and there is less time wasted. Any bugs that I write tend to be superficial, easy cleared up. Back when I was younger, "bugs" would be architectural decisions that were made in the frenzy of an office, and would require a lot of work to fix.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#10Agree that the repository/service pattern is a good way to adhere to separation of concerns and make refactoring and readability easier.
That said, I really disagree with any precommit checks. Committing code should be thought of as just saving the code, checks should be run before merging code not saving code. It'd be like Clippy preventing you from saving a Word document because you have a spelling error. It's a frustrating experience.
I can make sure my code is good before I submit it for review, not when I'm just trying to make sure my work has been saved so I can continue working on it later (commit).