| Random Link ¯\_(ツ)_/¯ | ||
| Nov 23, 2025 | » | Thinking Like a Strong Engineer
13 min; updated May 16, 2026
Strong EngineersStrong engineers can do things that weaker engineers just can’t, even with all the time in the world. Some examples of capabilities:
At the top end of strongest engineers, capabilities become something like “improving the SOTA for LLMs”. Regular engineers make the bulk of most companies. They solve 95% of bugs (normal, non-cursed bugs), deliver most JIRA tickets, and unstick themselves from dev env issues most of the time. They help. They do the work. They’re just not burning with ambition to excel at the next promo cycle. Probably have other things going on in their lives. ... |
| Nov 24, 2025 | » | Playing Politics as a SWE
1 min; updated Nov 25, 2025
Macro-Economics: Interest Rates and YouIn the 2010s, interest rates were near-zero; investors borrowed a lot of money and spent it on tech companies hoping for outsized returns. Companies desired to attract and retain talent; “literally anything” is worth spending money on to accumulate engineers. In 2023, interest rates rose to ~5%. Tech companies now need to make money. If your work isn’t clearly connected to company profit, then your position is unstable and on the whims of an executive that personally values your work. ... |
| Jun 6, 2022 | » | Perspectives on Software Engineering
8 min; updated Nov 24, 2025
On the Clean Code MovementGood enough is good enough. The architectural choices and bugs in the implementation tend to be more impactful, so focus more on those. Be conservative in what you consider technical debt. It should be something that slows down current/future changes, and not code that doesn’t “feel nice”. A code base that is free if technical debt is likely over-emphasizing polish over delivery. Abstractions and indirections in the name of future-proofing tend to be wrong especially when treading new paths, where you can’t reliably predict the future. A lot of value is in knowing the design guidelines well enough, that you know when/if to deviate to better suit the current problem. ... |