Diving deep on topics related to note-taking, personal information management, and software engineering, with occasional diversions to less nerdy things. 🏳️🌈
The future is becoming brighter than ever for people who love to code.
Don’t stop thinking for yourself.
Don’t stop investing in understanding.
Don’t stop following your passion.
One of the anti-skills I learned at MIT was being a hater. Every time I read a research paper I’d spend all my effort trying to find all the things wrong with it, because I thought that's what smart people did. I think a lot of infra engineers in particular can be like that. Took a long time to realize it’s way harder to turn a fledgling idea into something valuable. Still a work in progress
A weird advantage of writing by hand is that because it's so slow, I experience stuckness less. By the time I reach the end of a sentence, l've had lots of time to think about the next one.
I can type faster than I (often) think, so I often hit the end of a sentence, then stop dead, which makes the sometimes aversive not-knowing feeling way more overt. Each time is an opportunity for distraction, dissociation, etc.
If you’re not reading the code, whether explicitly or through agentic inquiry, one or more of these is true:
○ You’re a beginner
○ Software is throwaway
○ You’re prototyping
○ You have no users / revenue
○ You’re taking on debt & risk
○ Your problems are basic
And btw. All of this is fine. But the reality is that models are still not at the “full autonomy” stage yet.
They make rookie mistakes, they go down bad architectural paths. I just had the best model in the world add a nonsensical 700ms delay to “settle” something and it told me “you’re right, I was cargo-culting” 🤨
I am on the camp that this need will diminish more and more. Most code is indeed going to be assembly-like. But we also have the global internet and software infrastructure riding on these models and narrative, and we have to respect that.
As a Designer, if you care about making well-designed things, you should surround yourself with well designed things in your life.
You'll absorb more than you think.
The watch you wear, your furniture, the car you drive, the software you use... everything you passively use throughout the day becomes a reference point, or think of it as a baseline of the standard you hold yourself to in your own work.
And no, this doesn't mean only buying expensive things. Well designed doesn't necessarily mean costly, it just means well considered.
Live among things made by people who deeply cared, because its contagious (:
Software engineering hasn't changed at its core. It's still hard to learn and it still takes years. What changed is that you can now produce software without understanding how it works.
If you're early in your journey, don't outsource everything. Learn the underlying technology, what good code looks like, and the why behind the decisions. Stay curious. I know that's hard when AI finishes the task in five minutes and doing it by hand costs you a day. Treat that day as an investment. It's what lets you move faster later.
If you're an experienced engineer who's been hesitant to try AI, start with the boring stuff: tests, code reviews, small CLI tools, slides. Things you already know how to do and don't enjoy doing.
From March…
Bottom line: No matter how easy or how hard it is, most people just don't want to make stuff for themselves, no matter what it is. The economy goes round because people buy stuff from other people who are good at making those things. I know software makers have a hard time believing other people just don't want to spend all day making software for themselves, but they don't.
And this is exactly why “SaaS replaced by AI coded software” is not viable for any company that has a an ACTUAL business.
It’s a fun exercise to rebuild ticketing/o11y/feature flags etc… but do you really want to maintain it? Do you want updates, oncall etc to be YOUR problem??
The speed at which a product is developed doesn't inherently make the product better or worse. The number of commits doesn't make the product better or worse. The number of people or agents working on it doesn't make it better or worse. The number of hours you’re pouring into it doesn’t make it better or worse. Working on a weekend, or late into the evening, doesn’t make it better or worse. Talking about these things sounds like it’s talking about the product, but it’s not talking about the product.
Those are all development metrics and styles of work. They don't speak to the product itself. They're all back of the house. Important to those making the work, but not inherently important to the people using the work.
Development metrics and style say nothing about fit. They say nothing about quality. They say nothing about clarity. They say nothing about usability. They say nothing about utility. They say nothing about performance. They say nothing about how customers feel when they use your product.
It's like reviewing a restaurant by talking about how many cooks were in the kitchen, how long the shift lasted, how many orders they fired, or how late they stayed cleaning up. None of that tells you about the meal, the product, the customer’s experience.
Mistaking making for the thing you've made is like confusing the kitchen for the meal or the blueprint for the building. They're connected, but they're not the same thing. One of them matters a whole lot more than the other.
My students sometimes ask why they should memorise things in the age of Google and LLMs. But internalised facts are your bullshit filters and your raw material for creative association. Facts outside your head are inert.
Eng team: “we’re doing more with less [fewer people] this is amazing! 🔥 “
Reality for *some* products I use that are like this: there’s a lot less alignment + friction needed thanks to a lot smaller teams. The “alignment” and “friction” no longer present: customer empathy, QA…
So the eng team in this case often builds stuff customers cannot use/don’t use/don’t want to use, and far more stuff seen as buggy 🤷♂️
the problem with "spec driven development" is that most software can't be spec'd up front
software is a creative act, where you figure out what you're building as you build it
you need to get your hands dirty in the details, and react to incremental versions
it's telling that all the examples of spec driven development are sorting a list or porting thoroughly tested code (like a js runtime or browser engine), which are the exception, not the rule. the vast majority of software doesn't have a spec – or if it does, the spec was created *after*
I think beyond the live editing, support for first-class agentic workflows (esp. round-tripping line and full-file comments) would be extremely useful. Having access to an optional chat interface (BYOK) that could easily hide/show in order to interrogate/explore longer documents could be neat too.
@M2Fauzaan I was going to reply with something like "live editing," but was afraid that would be far out of scope... imagine my delight after updating this morning to discover the new Cmd+E mode! 🤩
Yall, can we recognize its silly flexing how much money you spend on tokens
I hate how much tokens cost me. I don't think its cool that a simple Fable coordinator session is hundreds of dollars. I dont value 20% productivity gains at thousands of dollars a month in additional burn.
This whole thing is silly. Its a bigger flex to crush it at solving a problem without all the bells and whistles that no one wanted in the first place. To do it on a budget. To do it without operating the most inefficient way possible.
Tho I guess congrats on discovering the secret of having more (venture) money than the other guy and making sure everyone knows about it?
Leetcode is like chess. It's a high IQ coded activity but in fact it's all memorizing patterns. People don't win at chess because they out-think you, they win because they out pattern match you. Only at the highest level does some IQ come into it, Leetcode has no such level.
Before AI, coding was 80% writing code and 20% figuring out the right code to write.
The mentally taxing part was the 20%. As long as you used a familiar language, you could get into a relaxing flow state with the other 80%. You'd need that relaxing time to recharge for when you have to deal with the 20% again.
Now you have to deal with the hard 20% all the time, and it's decision fatigue all day.
Admittedly a bit of a champagne problem, but still a problem.