Obviously the premiss is not still true, but I think the key takeaways from this talk about early GitHub are still worth considering. This was roughly 5 years after they founded, which would put it longer than the common 2-3 year jump rate I've seen among many developers. Counter point, they formed following the 2008 financial crisis. One of the unstated but likely bigger reasons was just that everyone felt like friends. This is by far one of the biggest reasons people tend to stay at companies since it's both a force holding them back and a force repelling from a new company (not knowing anyone there). You can extrapolate this when he's talking about their music culture and flying out someone else for conferences.
On the why people leave side, it's usually some combination of crappy boss, being forced to do things you don't see as valuable, and better compensation elsewhere.
For a proper framework for understanding why people leave your company, check out The Ultimate Guide to JTBD which uses a 2x2 matrix to understand why people change products. Applying that to changing jobs works just as well.
You should take your time reviewing the metric matrix in depth.
It's weird reading "The Liability Hiding as an Asset" section. On one hand, I completely agree that your source code is a liability—not an asset. On the other hand, I don't think a vibe-coded copy is the reason you should see your source code as a liability. You should see it as a liability because the source code isn't the business value. The business is valuable because of the processes you deliver to customers. These processes are encoded in software but live in the heads of your customers and the product teams, not the code. The code is a tool they've used to encode and automate those processes. That encoding is an inexact representation of the real processes. That inexact encoding is experienced as friction by your customers. You make money because people can pay you to outsource processes that are slower, less desirable, or less valuable when performing them without your products. It's also important to understand that not all processes are equally valuable; some are even costing you money.
Other than that quibble, I agree that software developers need to understand that their employment is premised on the idea that the company will make roughly 6x their salary in profit from their work every year. You get 6x because your fully loaded salary (when you account for office space, time off, benefits, taxes, and support like IT and HR) is roughly 2x the cost of your take-home pay. The remaining factor of 3x is because most projects fail to increase revenue or reduce costs, so all the real revenue gains have to offset all the losses on failures or time spent on less productive work to prevent running out of money.
That's the reality of running a business. Software development is extremely expensive. The last decade and a half has fostered many bazaar businesses and thus trained many to expect that running around doing whatever you want while being wildly unprofitable is somehow a fine way to run a business. You now have to convince investors you have a serious chance of beating bond yields to get investment money if you can get it at all. Learning to categorize work as revenue increasing, loss decreasing, or frivolous is now more important than ever.
This is exactly what I keep going on about. Some great tips in there, especially for those of us waiting for LLMs to stabilize.
Obviously not aligned on every detail, but a lot of this is just how you build software when you don't have dump trucks of investor cash to set ablaze. A skill that seems increasingly rare these days thanks to scale fever. My favourite part was reading the comments. Not everyone there is beyond hope, but I sure lost mine trying to read through those.
He's up front. You won't learn anything from this talk. It's one of those great art of the rant style talks. If anything, maybe it'll help those who haven't seen the silver bullet syndrome in action learn before they end up propagating this mistake.
I think I remember once reading that part of the reason for expanding the student loan program was to provide leverage to demand changes to the curriculums of universities. Specifically to get classes on politics, history, and civic participation curtailed by noting contemptuously that schools were indoctrinating students with classes on how to protest (reminds me of recent remarks about basket weaving). I can't find the source so I'm pretty sure it's either a lie or I'm misremembering something. That said, more people could use an education on protesting. Too many people think protests themselves change things. Let's all get together in front of a government building for an afternoon of sign holding.
Without a long term coordinated effort to change policy behind a protest, a protest is meaningless. Protests in and of themselves don't do anything. They're a tool of political action. You have to know how to properly use such a tool. This is an introduction to what that tool is and how it works. My thanks to Dr. Devereaux for all his work on his blog. It really is a modern example of what the old web's blogs were all about. Something I hope I'm helping carry forward in my own little way.
One of the keys to picking the right architecture is first understanding what the machines you're running on are actually capable of. A typical server in 2026 is an absolute behemoth. Many small to medium sized tech companies could run their entire SaaS app on a single 42U rack of hardware if they stopped fad chasing and started writing moderately performance aware software focused on optimizing their COGS.
I've not got much to add here. I guess I should point out, it's not just the United States of America like the title claims, but I assume that's fairly obvious. Welcome the next big tech hype after generative AI.
You may have already watched this video given its view count and featuring in the Summer of Math Exposition from 3Blue1Brown. If you haven't, it's definitely worth the watch.
While you can't calculate the distance along the bézier in closed form, you can at least calculate the roots as I do in my bézier visualizer using Cardano's Method. Just an extra tidbit I found hard to locate when I was doing my research for that project.
Great rundown on the problem and a number of tools to help you solve it.
We're definitely at a tipping point as an industry. Security vulnerabilities are now being routinely exploited within hours of a patch being made available. Supply chain attacks are punishing those too eager to update. We're being squeezed on both sides.
Your best defence is to narrow and shorten your supply chains. You need fewer dependencies. We just saw the axios supply chain attack. Maybe you dodged the bullet because you pinned dependencies and waited a few days. Something is going to sneak through. How much longer until something as brutal as the XZ backdoor slips through without someone managing to catch it early enough to save you?
Fewer dependencies make every other countermeasure more effective. If you think scanning is the answer, there is still a false negative rate to worry about. If this scanning is centralized at the public repository level, attackers can easily keep probing until they find something that slips through in throw away accounts before launching their attack. If there are vendor solutions, those can also be tested VirusTotal style. If you're instead focused on manually reviewing and signing off on updates, good luck having your team manually review tens or hundreds of updates a week. Every countermeasure is harder at scale. You're going to have to descale.
That said, if you've got a better idea than manual or automated review, there could be a million-dollar idea in there. For now I'm building a little tool that feeds the diff of package updates to an LLM to try and flag suspicious code for manual review. A hybrid approach run locally. It's not a great solution, but I'm also sure it's only a matter of time until the antivirus vendors catch on and offer basically the same thing but with much better classifiers and heuristics.
The problem is that every source code dependency has effectively complete and unrestricted access. I'd love it if my execution runtime could come with something like pledge(2) at the module level so I could create a list of just the allowed permissions each package is allowed to use. Then a module can only call other modules that have a subset of its own privileges. I'd even use this for my own code like I do already at the process level. Start by getting an inventory and then strictly watch that new additions are appropriate. The hard part is doing it without requiring a whole new programming language or dependency ecosystem.
In any case, a little duplication is better than a little dependency.
As someone who spends easily over 85% of my time in a terminal, it's rare for me to learn something new from one of these sorts of articles, especially those starting with simple concepts. I did not know about Ctrl-Y.
Kudos to the author here. This is the exact sort of list of everyday things I use too, so it's likely from the top of their head and not just regurgitating the Zsh manual at you. Not everything noted is a daily mainstay for me (I've never needed pushd/popd), but it's got a lot of the things I use constantly and very little else I don't use.
Here is one bonus tip: they cover cd - but didn't mention just running cd without an argument. That takes you to your home directory.
