BREAKING NEWS
LATEST POSTS
-
-
John Cutler – The production Failure Threshold (for Start Ups)
https://cutlefish.substack.com/p/tbm-290-the-dependency-threshold
There’s a point beyond which no individual, no team, and no company can solve the dependency and constraint puzzle using brute-force methods.
Imagine a company where 10% of the work involves multiple teams, touches different codebases, requires careful coordination, and requires frequent meetings that span organizational boundaries and challenge local incentives. This situation might still be feasible.
Now imagine that this percentage is more like 25%. Very quickly, the constraint satisfaction problem becomes an order of magnitude more complex.
What might a heuristic approach look like in product development?
- Reducing work-in-progress limits
- Force ranking priorities
- Weighted-shortest-job-first
There (is) a chance that teams will miss an opportunity to find an optimal solution? Yes. But the probability of that happening is far outweighed by the likelihood that 1) bad things will NOT happen, and 2) good things may emerge.
The trouble, I believe, is that it can be incredibly hard for managers to make the case for, on the surface, doing less. Discussions about WIP limits and prioritization often devolve into debates over the actual WIP limit and precise estimates! Instead of seeing the forest through the trees, we obsess about finding the optimal answer.
-
The Three Laws of Software Code Complexity
https://maheshba.bitbucket.io/blog/2024/05/08/2024-ThreeLaws.html
- A well-designed system will degrade into a badly designed system over time.
- Complexity is a Moat (filled by Leaky Abstractions).
- There is no fundamental upper limit on Software Complexity.
-
Raw hours – If you want to get really good at something, forget about shortcuts. You simply have to inject a ton of raw hours.
Jonathan Stern Raw hours
On Twitter yesterday, @RJoads asked me how I got good at styling (CSS).
I replied: “Raw hours. I’m obsessed with how things look and feel—probably more than the median engineer. Mind you, this has not always been a positive. I’ve been wildly distracted for hours and hours on the smallest items, things that truly do not matter to the business. But that’s how I’ve gotten better.”
If you want to get really good at something, forget about shortcuts. You simply have to inject a ton of raw hours.
“Work smarter, not harder” is a common refrain these days—particularly in sophisticated circles. The thing is, for most people I think it’s bad advice. My experience learning to code has suggested you have to work hard before you know how to work smart. No substitute for raw hours.
It’s similar to what Brian Armstrong says: “If you’re pre-product/market fit, the best advice that I have from that period is: action produces information. Just keep doing stuff.”
People with limited experience are similar to startups pre-product/market fit. Of course you should aim to work smarter! The catch is that you have to work extremely hard in order to know HOW to work smart. You must first go down dozens of dead-end paths to know where the smarter paths lie.
The second catch is that in order to be able to inject a ton of raw hours in a natural, sustainable way, oftentimes you need to be OBSESSED. Otherwise – you’ll be banging your head against the wall year after year. Some people are so dogged they’re able to do it. But this is exceedingly rare and probably not worth aspiring to.
“It’s hard to do a really good job on anything you don’t think about in the shower.” – Paul Graham
Doing is normally distributed; Learning is log-normal
https://hiandrewquinn.github.io/til-site/posts/doing-is-normally-distributed-learning-is-log-normal
FEATURED POSTS
-
What causes color
www.webexhibits.org/causesofcolor/5.html
Water itself has an intrinsic blue color that is a result of its molecular structure and its behavior.
