I've been mulling around the theory that people gravitate toward needing the "smartest" model for all their tasks because to recognize that they don't need the "smartest" model ends up damaging their ego. I don't mean that in the way most people think when talking about "ego". I mean it in the way that id, ego, and superego are meant. Ego is our self-identity. When we as programmers and other "smart" individuals come across a problem that in the past has needed our unique experience and intelligence, we reach for a "smart" model. This is because realizing a "stupid" model could solve the problem just as well is something that impacts how we view our own intelligence and place in the world. Does it lead to full on ego death? No, but it's something that we are not fully prepared for at all times. Sometimes we really do need the "smart" model. But there are plenty of times we avoid the "stupid" model for no other reason than ego. We just don't even realize it, though.

The related notions of "behind schedule" and "scope creep" are fundamentally wrongheaded. It's 50-year-old thinking that many of us have abandoned because it doesn't work. "Behind" implies an accurate estimate of a large, detailed specification. That is, you can't be "behind" unless you have a fixed "done" date. Similarly, "scope creep" implies that we can accurately predict exactly what needs to be built. (Sometimes that's true, but not often.) The problems with this approach are legion, of course. Our specifications (and thus, plans) are always wrong because nobody knows what they actually want until they get something in their hands. "Scope creep" implies that we won't learn anything as we work, that we'd rather be done 'on time' than implement the changes necessary to build something our customers actually need. There's a fundamental contempt for the customer built into that attitude. It also implies that the world will not change while we're working. Finally, both assumptions imply that product development is ever done. It's not. This approach has rarely, if ever, been effective. It's better to first identify just enough to get started. Build that, get feedback, and adjust. We discover what to do next by doing the current thing. There are strategic goals, but decisions about what to build are ongoing. Given that we're releasing every day (or more often), it's not possible to be "behind schedule." With that thinking comes major changes in things like budgeting. For example, we need to fund the teams, then dynamically allocate the teams to the work as needed, as compared to "project" thinking, where we budget the project, not the teams. Of course, I say the above knowing that many will respond that the "real world" doesn't work that way. Many of those comments will come with a certain fatalism that arises from knowing that the "real world" systems don't work, but that individual engineers have no power to change things. Some of that fatalism is justified (large corporations won't adapt), but not all of it (an agency can sell a different way of working as part of the client-acquisition process rather than letting the client dictate how the agency must work). However, if it's possible to improve the way you work, it's worth the effort.

For the "I'll just vibe code and trust the LLM folks," here's an interesting page: [clocks.brianmoore.com/]. The prompt was "Create HTML/CSS of an analog clock showing ${time}. Include numbers (or numerals) if you wish, and have a CSS animated second hand. Make it responsive and use a white background. Return ONLY the HTML/CSS code with no markdown formatting." I'm sure these things could be beaten into submission with some judicious prompt wrangling, but the unpolished-prompt output is informative. It would be interesting to try it again with the current set of LLMs and see what happens, but it's a good, simple, comparative test of LLM capability.

Spreadsheet interface for Postgres databases github.com/mathesar-foundati…

Turns out with claude code, my decades long strategy of NOT deeply learning: - regexs - sql - nginx confs - elaborate shell commands - advanced shell scripting - any javascript framework - perf optimization - webpack, cdns, bundlers - 1000 other things ...was entirely correct.

There’s a belief that execution is a junior employee skill and that senior people should focus on strategy™️ No - you can always learn to execute faster and execution is where your ideas meet reality.

As we lurch into a place where AI-assisted programming becomes possible, it's ironic that actual documentation (in well-crafted English) is now becoming extra important, especially for APIs. LLMs do not "understand" what code does—what it's supposed to accomplish. They're pretty good at "understanding" English, however. Consequently, we need to provide a smooth path for the AIs to discover how our systems work so that they can modify, test, or otherwise interact with those systems. That is, we need to provide documentation for the AI. This is important, not only when we're writing a system that we expect third parties to access from the outside (which is a critical use case), but also if we want the AI to help us with our own code. An LLM can infer how to interact with our systems from looking at code, but unless that code is well-commented in clear English, the odds of it being able to infer correct code are minimal. The LLMs are trained on GitHub and its ilk, after all, and that's not exactly a hotbed of pristine production-quality code for it to emulate. When our own API documentation contains well-written nontrivial examples, we are helping the AI use our interfaces properly. So, as we move into an AI-assisted future, it becomes critical for programmers to learn how to do something they've avoided learning to do for three-quarters of a century: to write well-crafted expository prose. Maybe you should have paid more attention in those undergraduate English composition classes after all.

Adding a "10x" programmer makes you slower. What matters is the speed of the entire system, from idea to delivery. Speed cannot be improved by introducing one faster person. We're a group walking single file on a narrow cliff path. The person in the middle might be the fastest, but they can only go as fast as the person in front of them. Also, if 10xers work at 10x, they're doing nothing but piling up inventory (money spent that is not generating revenue) downstream. That inventory is money wasted. The downstream teams can't possibly catch up—they're already moving as fast as they can. Moreover, people will defer more and more work to that 10xer until they're completely overwhelmed. They can't possibly handle the workload, so the system slows even more. They become a bottleneck (or "constraint"). The system's speed is constrained by the bottleneck. The only solution is to relieve the bottleneck by making literally everyone a 10x programmer. The most productive thing a 10x person can do is teach everybody else to be as good as they are. If they're actually doing the work, the system as a whole slows down. If this thinking is new to you, I'd suggest reading Gene Kim's "The Phoenix Project," which explains concepts in a software context, or Eliyahu Goldratt's "The Goal," where the ideas originated. Goldratt calls it "The Theory of Constraints."

Writing software, especially prototypes, is becoming cheaper. This will lead to increased demand for people who can decide what to build. AI Product Management has a bright future! Software is often written by teams that comprise Product Managers (PMs), who decide what to build (such as what features to implement for what users) and Software Developers, who write the code to build the product. Economics shows that when two goods are complements — such as cars (with internal-combustion engines) and gasoline — falling prices in one leads to higher demand for the other. For example, as cars became cheaper, more people bought them, which led to increased demand for gas. Something similar will happen in software. Given a clear specification for what to build, AI is making the building itself much faster and cheaper. This will significantly increase demand for people who can come up with clear specs for valuable things to build. This is why I’m excited about the future of Product Management, the discipline of developing and managing software products. I’m especially excited about the future of AI Product Management, the discipline of developing and managing AI software products. Many companies have an Engineer:PM ratio of, say, 6:1. (The ratio varies widely by company and industry, and anywhere from 4:1 to 10:1 is typical.) As coding becomes more efficient, teams will need more product management work (as well as design work) as a fraction of the total workforce. Perhaps engineers will step in to do some of this work, but if it remains the purview of specialized Product Managers, then the demand for these roles will grow. This change in the composition of software development teams is not yet moving forward at full speed. One major force slowing this shift, particularly in AI Product Management, is that Software Engineers, being technical, are understanding and embracing AI much faster than Product Managers. Even today, most companies have difficulty finding people who know how to develop products and also understand AI, and I expect this shortage to grow. Further, AI Product Management requires a different set of skills than traditional software Product Management. It requires: - Technical proficiency in AI. PMs need to understand what products might be technically feasible to build. They also need to understand the lifecycle of AI projects, such as data collection, building, then monitoring, and maintenance of AI models. - Iterative development. Because AI development is much more iterative than traditional software and requires more course corrections along the way, PMs need be able to manage such a process. - Data proficiency. AI products often learn from data, and they can be designed to generate richer forms of data than traditional software. - Skill in managing ambiguity. Because AI’s performance is hard to predict in advance, PMs need to be comfortable with this and have tactics to manage it. - Ongoing learning. AI technology is advancing rapidly. PMs, like everyone else who aims to make best use of the technology, need to keep up with the latest technology advances, product ideas, and how they fit into users’ lives. Finally, AI Product Managers will need to know how to ensure that AI is implemented responsibly (for example, when we need to implement guardrails to prevent bad outcomes), and also be skilled at gathering feedback fast to keep projects moving. Increasingly, I also expect strong product managers to be able to build prototypes for themselves. The demand for good AI Product Managers will be huge. In addition to growing AI Product Management as a discipline, perhaps some engineers will also end up doing more product management work. The variety of valuable things we can build is nearly unlimited. What a great time to build! [Original text: deeplearning.ai/the-batch/is… ]

Eventually, the time that was not spent on learning skills will catch up with you, and the fall will be painful.

This is absolutely true, but the risk is that when you ask people who are great at what they do to no longer "do", they become depressed. One answer is to eliminate the manager role as a full-time position: world.hey.com/dhh/we-once-mo…

When it comes to embracing the meaningful burden, nobody articulates the purpose and the challenge better than Peterson. His best bits on self-improvement, becoming formidable, accepting hardship, and carrying on are life affirming. youtube.com/watch?v=Y5Hu_UZ9…

"Stability leads to instability. The more stable things become and the longer things are stable, the more unstable they will be when the crisis hits." -Hyman Minsky

Mistakes and failures are precisely your means of education. They tell you about your own inadequacies.

At the end of every year, I conduct a Personal Annual Review. It's a transformative exercise that everyone should try. 7 simple questions that may change your life: (bookmark this download the PDF template) 1. The Key to Success: When I interview the best in the world on The Knowledge Project Podcast, one factor correlates more toward success than any other. 2. An Honest Audit: Success is simple but not easy: Do more of what works. Eliminate what doesn't. 3. Maximize Focus: Excellence demands elimination. 4. Create Momentum: Procrastination moves in silence to kill dreams. 5. Structural Edge: The goal isn’t to be well-rounded. It’s to amplify your uniqueness and build a life where your weaknesses aren’t holding you back. 6. The Inner Circle: You become who you spend time with. 7. Easy Mode: The best performers seem to have an unfair advantage: they're playing on easy mode while others struggle on hard. 8. Rules: Most rules aren't natural laws- just accepted patterns. The best know how to use rules to their advantage. 9. The Action Plan: Plans without timelines are just wishes. * Download my Annual Review template and make 2025 the best year yet fs.blog/annual-review/

Repeated failure will toughen your spirit and show you with absolute clarity how things must be done. In fact, it is a curse to have everything go right on your first attempt. You will fail to question the element of luck, making you think that you have the golden touch. When you do inevitably fail, it will confuse and demoralize you past the point of learning

Low performers are a tax on everyone and your best performers won’t be willing to pay it for long

You must avoid at all cost the idea that you can manage learning several skills at a time. You need to develop your powers of concentration, and understand that trying to multitask will be the death of the process.

So many scary things, that also can be fulfilling: startups, writing, marriage, kids. To guarantee failure, don’t even try. Don’t start. To guarantee failure, quit as soon as it becomes difficult. Success isn’t guaranteed, but certain failure is in your control.

Interesting data: Most small business owners make about the same as they did as employees. Proves that we’re doing it for the autonomy, not (only) for the money.