141–150 of 289 posts
Being a hedgehog is useful on the journey to domain mastery because sticking to frameworks saves you time and headache compared to not having any frameworks at all. The 3 stages of domain mastery: Stage 1 - No knowledge or structure to approach a domain (everything is hard, pitfalls are everywhere) Stage 2 - Frameworks that are useful to approach the domain (Map to avoid pitfall areas) Stage 3 - Detailed understandin…
This pretty much summarizes it.
Earlier quoted context omitted.
Oh, but scp won’t update it atomically, so you should switch to a scheme that will. Then all you need to do is set cache policies correctly, coordinate with your CDN, and maybe do a staged rollout, just in case. /s Seriously though, rsync is your friend. :-)
> Seriously though, rsync is your friend. :-) Even rsync might not be atomic enough for some situations[1] since it'll update files as it goes rather than in one huge transaction at the end. [1] I worked on the World Cup 2006 site for Yahoo! and we had this issue - solved with 'rsync --link-dest' and swapping symlinks.
1. stop service 2. copy files 3. start service
Earlier quoted context omitted.
Sometimes, the features are really must-haves though. Let’s say it’s march 2020 and your boss wants you to design a mass-market covid vaccine. You have three requirements: it needs to be safe for human use, it needs to be effective at preventing covid, and it needs to be possible to manufacture. If any one of these is missing, your design is useless. I think a similar dynamic is visible in many software projects.
That's totally fine - but people need to also be aware that if something is really a must then they have to be willing to spend adequate time and resources on getting it done, instead of assuming whatever resources they have on hand will be sufficient. It's amazing the things that stop being a "must have" as soon as they have to spend more money.
"if you do not give this an ordered priority, I will resolve items as I see fit. Should we need to stop for one reason or another, there is no guarantee of which have been resolved".
Often times that is okay. I also tell them to always take the ones they're most uncertain about first. Better to front load hard problems and uncertainties.
Earlier quoted context omitted.
To be great at X you have to write the rules.
Not really, Messi is great at soccer, he didn't write the rules of the game, but he was able to do things with the tools available that no one thought possible. To be great you usually have to be creative.
This is a bang on article and I would say that more people should be less confident in general. I also love his technology substitutions: springy search = Elastic Stoplang = Go IronOre = Rust BeetleDB = CockroachDB
Earlier quoted context omitted.
I’ll add to the list: - Ceremonial unit tests for every little thing. The whole system is buggy as hell and we don’t have any confidence that the unit tests are truly covering critical parts of the app. But alas, test coverage, the god damn Pope that can never be bemoaned. - I’m not making this one up: A/B testing for an internal enterprise app.
I have seen bad unit test being introduced when engineering management starts enforcing a threshold (80% coverage). Often developers will scramble to test trivial methods, such getter and setters, but will not write any suitable tests that actually cover the business logic. It is even worse when management only enforce a 80% coverage for new changes. In those scenarios developers go out of their way to encapsulate ch…
Tetlock also found that foxes were less likely to be famous because contingent advice is harder to explain in a sound bite. Yep. Occasionally there will be a complex problem with a simple solution. More often, complex problems have difficult solutions. And unfortunately, If you're in a room discussing the problem and one person gives a simple solution and you try to start a conversation about the complexities involve…
Whenever this has happened in my experience, it's come with the monkey's-paw irony that while the solution is simple, the reason why it's a solution, or at least a complete solution, is not. That almost makes it worse - people who aren't intimately familiar with the problem will see the simple solution, think the problem must have been similarly easy to understand, and then think that there must be something wrong with the solution.
Being a hedgehog is useful on the journey to domain mastery because sticking to frameworks saves you time and headache compared to not having any frameworks at all. The 3 stages of domain mastery: Stage 1 - No knowledge or structure to approach a domain (everything is hard, pitfalls are everywhere) Stage 2 - Frameworks that are useful to approach the domain (Map to avoid pitfall areas) Stage 3 - Detailed understandin…
> All of this makes it hard to move beyond stage 2 into stage 3. Often, moving to the stage 3 is a waste of time and resources. There are a few cases if your business's main secret sauce is stage 3, but for most other things - commoditize and focus. I've seen so many teams and engineers trying to master stage 3 but no real business need and ROI. Engineers love mastering things but good leaders guide them in the right…
Being a hedgehog is useful on the journey to domain mastery because sticking to frameworks saves you time and headache compared to not having any frameworks at all. The 3 stages of domain mastery: Stage 1 - No knowledge or structure to approach a domain (everything is hard, pitfalls are everywhere) Stage 2 - Frameworks that are useful to approach the domain (Map to avoid pitfall areas) Stage 3 - Detailed understandin…