A few of us were talking to one of the summer interns at work about age: Someone: How old do you think Kev is? Intern: [with all the confidence in the world] 50? I turn 42 in August. FML. 🤣 Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .
Matt asked me a question recently about the end of my People and Blogs run. The question was if I always thought I was going to hand it over at some point, and it’s an interesting question worth expanding on, which is why I told him I was going to write a post about it, rather than simply answering via email. I started and ended more online projects than I can remember at this point. I bought a dozen domain names, coded way too many sites, only to have them all inevitably bite the dust, sometimes months later, sometimes years later. But I don’t think I ever started a project with a set deadline in mind. All the projects were open-ended, always. Back in September 2021, I posted about the shutting down of my thegallery.io , a site I ran for almost 7 years, and in that post, I wrote Once the passion is gone, it is gone. There's no point in dragging things until you reach some random date in the future. When I started People and Blogs, the plan was to run it for a single year: 52 interviews, that was the plan. But then the end arrived, and people enjoyed the series, so I kept going. But at some point, I crossed the imaginary line that separates doing something because I enjoy it, and doing something because other people enjoy it. If you do something long enough, you almost always end up inevitably crossing that line. There are exceptions—there are always exceptions—but that’s what my experience taught me. And it’s weird how the process of realising that something is done works. Because at first I was simply carried forward by the momentum, by the established routines. I was sending emails, posting updates, and scheduling interviews. But the moment I considered the possibility of stopping, it was almost as if a seed got planted in the depths of my brain. This process kinda reminds me of the plot of the movie Inception. And once that seed was planted, it’s incredibly hard to eliminate. And it’s almost as if deep down I already knew the right thing to do but was too busy dealing with the routine to realise it. So to answer the original question, no, I didn’t know from the get go I was going to pass the series to someone else. But a part of me enjoys this process of seeing projects changing hands. I was happy to receive blogroll.org from Ray , and I was equally as happy to hand over peopleandblogs.com to Zach . It’s one of the many good qualities of this corner of the web I love to inhabit. The lesson I learned this time around is that projects need an endpoint! I’ll keep that in mind for the next time I inevitably start something new in a few years from now. Thank you for keeping RSS alive. You're awesome. Connect via email :: Sign my guestbook :: Support for 1$/month
Software engineers are often told to “start playing politics”, but most engineers have no idea what that means. Their reference point for “playing politics” comes from fiction like Game of Thrones. Are they supposed to raise an army and depose the CEO, or poison each other at team lunch? Should they book Zoom calls with each other and plot schemes? All of that is obviously ridiculous. In terms of Game of Thrones, software engineers are not lords and ladies. We’re the soldiers and workers of the realm. So you should think about “playing politics” in the way a castle guard would, not one of the major players. The castle guard are not going around poisoning people or forming coalitions between the great powers. They are largely keeping their heads down. But in order to do that, they have to stay aware of the political currents, or they’re liable to do something catastrophically stupid: for instance, making an enemy of a powerful courtier, or arresting somebody who’s on an important mission for the king. Given that, the basic principles of playing politics are something like this: As a software engineer in a large company, you will not be a powerful person . Powerful people are typically in senior management: VPs, directors, and so on 1 . However, not everyone in senior management is powerful. Some are killers who have the active support of the CEO, while others are confused incompetents. How do you know which is which? If someone is clearly ferociously competent, they’re always going to have some power, since upper management tend not to ignore useful tools. But you can’t rely on competence as your only guide. Some managers are powerful for other reasons: they’re friends with the CEO, or they have strong relationships with other groups like legal or sales, or they’re simply willing to do whatever upper management wants done. One signal is who’s leading the important projects. Read your CEO or CTO’s internal updates and pay attention to the projects that are called out by name. Organizations tend to give key tasks to trusted lieutenants. If a manager is leading an area that’s never under the spotlight , they probably don’t have enough clout. Another signal is hiring. Is a manager’s team growing or shrinking? Particularly post-ZIRP , headcount is a rare and precious resource. A manager who’s able to get it is likely a powerful manager, or at least is reporting to a powerful director or VP (which often amounts to the same thing). First, you should try not to make any enemies at all. Most software engineers who get “playing politics” wrong do it by needlessly alienating people: by being rude, unhelpful, abrasive, making non-technical people feel stupid, and so on. This post isn’t really about that. I’m assuming that you can figure out how to be a generically pleasant person on your own. However, competent software engineers will make some enemies . If you’re out there making projects happen, some people aren’t going to like the way you do it, and won’t be a fan of any compromise you offer. I wrote about this in Big tech engineers need big egos : the only way to avoid making enemies is to change nothing, but that’s incompatible with doing the job. Given that, be selective about which enemies you make. If you’re making a technical decision that’s either going to require work from team A or team B, and neither team wants to do it, you should try to pick the team with the least political cover. If you need a powerful VP’s team to do something they won’t like, try to be maximally respectful about it: get that team’s core engineers on-side if you can, or book a meeting with the powerful manager and explain the situation, or (better yet) ask the powerful manager sponsoring your project to go and talk to the other VP for you. (If you don’t have a powerful manager like this, consider abandoning your project). Give way to powerful managers when at all possible. Every so often you really do have to stand your ground — if the system will truly collapse otherwise, or a major customer will have an incident, or if the technical decision really is entirely bone-headed — but almost all cases are not like this. The best advice I’ve ever gotten about playing politics came from a manager I worked with long ago 2 : This is not the hill you want to die on. When I’m about to pick a fight or say something argumentative, and I’m not 100% convinced it’s necessary, I ask myself: is this the hill I want to die on? And it never is. The three rules about disagreeing with powerful people are: Disagreeing in private rarely hurts, if you follow these rules. In fact, it can help. If you can manage to disagree with a manager, get overruled, and then follow their plan without complaining, that can be the best way to gain a powerful friend. But if they think you’re going to keep griping about it, or worse still, complain to the rest of the team and foment some kind of rebellion, there’s no quicker way to make a powerful enemy. If you have powerful enemies at a company (for instance, the CTO or an influential VP doesn’t like you), quit . It’s really that bad. I have never seen this situation turn itself around, except in the very rare case where the CTO or VP is already looking for greener pastures and jumps ship. You cannot recover the situation: they have no incentive to give you the chance to change their mind, and they have almost unlimited ability to screw you on promotions, raises and layoffs. That’s why this piece of advice is second in the list. If you aren’t helpful or if your contributions are invisible, you can work on that and fix it. But if you’ve made powerful enemies, you’re done for. Just as it’s fatal to make powerful enemies, it’s very useful to make powerful friends. How can you do this? Remember you’re a palace guard, not a great lord: you make friends by doing your job . However, you can choose to do your job a little more proactively and diligently when you’re doing it for someone with political clout. One obvious application of this principle is that you should answer Slack messages from powerful people immediately . If you see an ordinary Slack question pop up while you’re doing some task, it’s okay to get to it when you get to it. In fact, it’s ideal not to respond to all questions immediately, so you don’t set unreasonable expectations (and so you don’t seem like you’re sitting around doing nothing). But when a VP comes in with a question, don’t make them wait: answer the question immediately. If the question requires research, send a “let me look into that right now” message, then do the research. This is the easiest way to get a reputation for being helpful 3 . Another way to do this is to lean in on important projects . Suppose you do ten projects in a year. Eight of them are normal, low-priority projects, and two of them are high-profile (say, finishing some big feature before your company’s yearly conference). It’s a mistake to allocate your effort equally to all ten. I wrote about this at length in Doing nothing at work : you should be operating at 80% capacity (or less), so you can then ramp up to 120% when it really matters. Pay attention to the narrative that powerful people are trying to push. Here are some potential narratives: You don’t necessarily have to jump in and start cheerleading, but you should at least not do anything that you know is going to make the narrative look weak. For example, on that last point, it’s foolish to openly argue that the project really was fine all along. Bring it up privately, not publicly, or you risk ruining some clever piece of propaganda that the manager in question is trying to push on the rest of the organization 4 . Finally, an underrated way to help powerful people is to offer them social support and information. Slack messages and planning emails might seem unimportant to you, but powerful people often live in that environment: their primary tool is writing messages like these, just like your primary tool is writing code. Reading and responding (in a supportive way) to these messages is something that most engineers don’t bother to do, but it goes a long way. Likewise, dropping a senior manager a line now and then (say, a heads-up that a particular project landed successfully, or that you got good metrics about some feature) is surprisingly helpful. Senior managers live in an information-poor environment: for them to learn something about a team’s work, that information has to bubble up through several layers of interpretation and summary. In my experience, they’re appreciative of being drip-fed the occasional piece of information, so long as you keep it brief and relatively rare. If you’re directly responding to a VP’s Slack messages or DMing them information, they know you’re the one doing it. But if you’re just doing your job and working hard on projects they care about, they might not notice. Being invisible is probably the most common way engineers fail at playing politics. Fortunately the fix is simple: tell people what you’re doing. If you fix an important bug for a launch, write a message in that launch’s Slack channel saying “hey, I just fixed this bug”. What if you don’t like bragging? Get over it. You have to be comfortable publicly telling people what you’ve done. You should also keep a brag document so you can repeat all of this at review time. Another, subtler way to do this is to gain the trust and respect of the powerful engineers in your area. Senior managers will always have a few trusted engineers they rely on to assess technical questions. They will ask those engineers what they think about you, and will broadly trust those answers. The good news is that if you’re competent and useful, those engineers will already value you, so you don’t have to do anything special: just be good at your job. Is playing politics all about sucking up to senior managers? Basically, yeah. A less cynical way to describe it would be “aligning with the values of the company”. If you think your company is doing good things, you should want to do that anyway! In any case, what that comes down to is figuring out what the people in charge want, giving it to them, and making sure they see you doing it. However, there’s still some scope to get what you want out of the deal. I said earlier that software engineers do not wield organizational power. However, that doesn’t mean you’re powerless. Technical ability is a source of real power, if a delicate and unreliable one. The movers and shakers in tech companies are utterly dependent on technical people to implement their vision and to give them clear answers about the system. There are many subtle ways you can leverage this. One I wrote about in How I influence tech company politics as a staff software engineer is to wait until important people at the company want to do something (say, improve reliability), then offer them a technical plan that does it your way. Another one is to become so useful that you’re actively in demand to lead projects, and then run the project how you want. You probably won’t be able to change the company’s grand strategy. But how that strategy is implemented has a lot of specific technical detail, and you can put yourself in a position to decide on those details. Playing politics isn’t about plotting and scheming, and it isn’t just about being a friendly, likeable person (although that helps). It’s about figuring out how your company actually operates: who makes the decisions, who gets consulted, what behavior gets rewarded, and so on. The most basic way to do that is to figure out who is powerful, get out of their way, and (if you can) help them get what they want . Obviously the exact titles depend on your company. One person I’m deliberately leaving out is your own manager. In general don’t think your relationship with your own manager counts as “playing politics”: that’s just you getting along with another human being. An exception to that is if you report directly to a powerful director or VP. Ironically, this manager struggled to take his own advice. Note that you actually have to be able to answer their question accurately in order to do this. If you’re not competent enough to be useful to powerful people, you will struggle to befriend them. For instance, maybe the CEO is convinced that the project was in bad shape because of something he heard, and the manager in question knows it’s easier to sell “yes, but we turned it around” than “no, you misunderstood, everything was always fine”. If you complicate that process, you risk the CEO thinking that the project is still bad and cancelling it. Be aware of who’s powerful and who’s not At all costs, avoid making powerful enemies Help powerful people as best you can Make sure they know you’re helping them (without annoying them) Make sure you do it in private When they overrule you, stop arguing immediately We’ve had a lot of turnover and reorgs lately, but we’re all starting to pull together as a team now Isn’t it great how focused we all are on reliability work after last month’s incident? The conference this week is the most important thing, so we’re all being very careful not to break anything We’re an AI-forward team that’s looking for the best ways we can leverage LLMs into our team processes Although this project had a rocky start, we’re now all aligned on the way forward Obviously the exact titles depend on your company. One person I’m deliberately leaving out is your own manager. In general don’t think your relationship with your own manager counts as “playing politics”: that’s just you getting along with another human being. An exception to that is if you report directly to a powerful director or VP. ↩ Ironically, this manager struggled to take his own advice. ↩ Note that you actually have to be able to answer their question accurately in order to do this. If you’re not competent enough to be useful to powerful people, you will struggle to befriend them. ↩ For instance, maybe the CEO is convinced that the project was in bad shape because of something he heard, and the manager in question knows it’s easier to sell “yes, but we turned it around” than “no, you misunderstood, everything was always fine”. If you complicate that process, you risk the CEO thinking that the project is still bad and cancelling it. ↩
Two and a half years ago, I found a piece of paper in our parcel box, asking if anyone would consider becoming a governor of a local primary school. I ummed and aahed about it, and decided to express an interest. Within a few minutes I had arranged a visit to the school, and within a few days, I was a governor. I did a lot of training, and spent the first 12 or so months trying to work out what on earth was going on. Being a school governor, and in particular understanding school accounting, was unlike anything that I had done before. Being a governor is a lot of responsibility, and it is - or, at least, was for me - a particularly challenging role, given how much a school has to do with so little money, particularly with an increase in the number of children with additional support needs. Frankly, a completely inadequate amount of money. In addition to general governor duties, I took on responsibility for data protection, chaired the policy committee, and helped improve numerous policies and processes, and stepped up whenever the school needed a lawyer-like person. Tonight, that came to an end. One of my many flaws is that I agree to do too much. I love helping people, and I have a pretty useful set of skills and experiences. The outcome is that I put my hand up too much, and thus stretch myself too thinly. Sure, I get to do some fascinating stuff, and work with some lovely people, but it comes at a cost. I’ve had too many days recently where I’ve done more pro bono / volunteering work than I have done paid work. When I found that I was turning down paid work that I actually wanted to do because of volunteering commitments, I decided that I had got the balance wrong. And, in stretching myself too thinly, I don’t always have the time to give a role the time and attention that it needs. Perhaps, sometimes, doing at least some of the job is better than doing none of the job, I was increasingly nervous about taking that approach to being a school governor. Whether I give up any of my other voluntary stuff, I’m not sure. At times, it is certainly tempting. But, if nothing else, giving up governorship should mean I have a little more time to spend on my other commitments, for as long as I have them. I enjoyed my time as a governor. I certainly learned a lot, and I was pleased to be able to make numerous, and in some cases quite significant, contributions to the life of that small primary school.
Look at the past history of this blog. There are many blog posts about programming with AI, a few of them date back to January 2024 (like this: https://antirez.com/news/140). I’m a relatively well regarded programmer, after all. I don’t have the need to still be in the “loop” as a old man that seeks for relevance, I recently rejoined Redis, and now I also am developing a new open source software for local LLM inference that received a good welcome in the community. Why I keep doing this, of saying what people don’t want to hear? Why I keep announcing how future programming will be by default? Because I feel the urge of lowering the impact for people less prepared to the change than me, often younger than me, and that, unlikely me, didn’t see many of those things coming (In 2022 I published, before ChatGPT existed, a book preannouncing many things that now happened and other things that I believe *will* happen, so I feel like I can say this without sounding egocentric). So mine is a trick. People feel more and more programming is completely modified by AI and don’t know what they should do, if they can really start coding in a completely different way, without looking much at the code as their main output. They feel like they are betraying their own field. So my intention is to arrive and say “look at me, In can write code, you know, I’m not hiding behind AI: yet, things changed, it’s not your weakness, it’s not that you are AI-pilled. It is just that our field is evolving in an incredible *and* painful (but also joyful) direction”. This is why yesterday, on X, I said that I believe many programmers at this point have less impact they could have because they look at the code. I truly believe into that. And note that this does not mean to vibe code something just asking for the final product. The point is: if you control the ideas of your software, looking at the code itself is suboptimal and often pointless. For the following reasons: 1. You can now generate a lot of code, even *not* accounting for the LLM code verbosity (that is also effect of not being able to instruct them well, for most of the part). How are you supposed to review 5k lines of code every day? 2. LLMs are very good at writing locally optimal code, and are worse (but improving) with big ideas. What’s the point of scanning function by function, line by line? Instead you should prompt the design you have in mind, sometimes ask “how is exactly the design of that part? How does it work?”, and evaluate if it is the right model. It is much faster. 3. The working day is 8 hours. If you read the code, it is a tradeoff. You are doing less of what today is the most important part of your job, that is, asking yourself: what I’m doing with this software? What are the new directions I want to take? And also, think at new ideas, features, optimizations tricks. And doing a lot of QA. Controlling the ideas. Do you remember this phrasing from the Mythical Man Month? Well, a book from the 70s tells us more things about the current software era than many of the things that were said from 2000 to 2020. Why people that now protest against AI were not horrified by the state of software in the last decade? The level of slop we touched during recent years, before AI, is unbelievable. I’ll say you another thing. What is slop? With DwarfStar I implemented an inference for two LLMs (DeepSeek v4 and GLM 5.2) in a completely automated way, but: try it yourself, you will discover you can’t just say “implement XYZ” and see it working. You have to understand how things work, what is the best design, how to reach a certain level of performance. Then I compared the implementation, for correctness, to other systems, finding that other implementations sometimes contained more errors. I researched more, and found that the local inference world is full of subtle errors that accumulate and damage the model output, issues in the attention implementation causing performance slopes after the context is over a certain limit because indexed attention implementations are broken (do more work than they should, for instance), and so forth. This is the result of a domain that is very complicated to handle, fast changing, with models that are slightly different one from the other in the inference graph being released every day. It’s an unfair game for developers. Well: AI helps a lot with that. There are many domains where rigorous engineering (in the design side) and testing is *far* better than writing a GPU kernel by hand (or reading it). So are we sure most of that resistance it is not ideological? Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. Yes, I do, but this is, at this point, something I *need* to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is *far worse*, and not since they are not good coders, but because it is a matter of taste. I write very clean code since I want it to be readable, so during the implementation of Redis Arrays I operated changes. I’m doing it again for the 50% memory saving optimization of Redis sorted sets, a PR that I’ll submit soon. But I do not feel this is useful anymore. Nobody should anymore look at this code, but only at the ideas the code contains. I continued to do it out of respect for users. Redis is at this point a commonly useful thing, and many programmers will open files and modify stuff by hand. But if I had my hands free, you know what I would do, instead? Use all the time that the review is taking me to do more QA, to think at the next optimization idea and apply it, and to use LLMs to write a DESIGN.md file where each data structure is described in human language, with the ideas it contains, the implementation tricks, the design. That, in the future, is going to be much more useful. Do you want to modify sorted sets? You open the file, read the design, then you own the ideas. You can open your agent and ask it what to do with the right mental model. This is a lot more useful than reviewing the code. Fable and GPT 5.6 reviews to the sorted sets memory saving are going to spot ways more errors and subtle race conditions that my review is going to uncover. Yet I’ll do it. But for the majority of software projects, all this does not make sense anymore. Focus on controlling the ideas, instead. Focus on quality, testing, and having an idea of the software you want to ship. The world changed and it is painful, but also full of opportunities to improve a software world that was already completely rotten. I have a doubt only regarding young programmers that don't have enough experience, and can't build a mental model. We don't know, yet, if they will require or not to understand very well how a given piece of code works, but I believe they should learn how to write programs. Yet, I'm not sure checking the LLM output is the right thing they should do. It may be a lot more useful if they learn some programming language and implement a small interpreter, a small database, an hash table and so forth. Reviewing some Javascript stuff of some web site for a customer? Hell, no, don't lose time with that shit. Comments
As a software engineer, how well do you have to understand your own codebase? My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness ) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”. These are two largely different ways of programming with different methods, practices and cultures 1 . However, the first group is over-represented in online discussion about software engineering 2 . I want to defend the second group against the first. In many software engineering environments, there’s nothing wrong with being in a state of partial understanding. In fact, in large systems a partial understanding is the best you can do. The best articulation of the “you have to understand your codebase” side is Peter Naur’s famous paper Programming as Theory Building . I like this paper, but I think it goes too far in that direction. Naur’s core point is that when programmers work on a program, the code is really just a by-product, and the main product they’re working on is their “theory of the program”. That’s made up of their intuitive sense of what’s happening and why, which can only be partially captured by code or documentation. If they lost the code, they could rewrite the program easily. If they lost their understanding (say, if the team experienced 100% turnover), they would struggle to make sense of the code. So far, so good, but Naur goes further than this. He says that the theory should not be reconstructed from the code. According to Naur, you’re better off scrapping the program entirely and having a new team rebuild it from scratch , building up a new theory in the process 3 : reestablishing the theory of a program merely from the documentation, is strictly impossible … [therefore] the existing program text should be discarded and the new-formed programmer team should be given the opportunity to solve the given problem afresh Anyone who’s been an effective software engineer at a large company knows that Naur is dead wrong about this. There are at least two reasons. First, you simply can’t rebuild large software systems from scratch . Sufficiently large systems (if they have users) contain thousands of weird cases and quirks that cannot be reimplemented. Even a team that’s intimately familiar with the system couldn’t do it: there’s just too much stuff to juggle. Successful rewrites always start by carving out the existing codebase into small isolated chunks, then rewriting one chunk at a time. In other words, rewriting a software system involves making a bunch of changes to the old system. If you can’t change the old system, you certainly can’t replace it with a new one. Second, abandoned systems are revived all the time . In a tech company with hundreds of millions of lines of code and thousands of engineers, it’s not uncommon for a codebase to have nobody left who’s familiar with it 4 . All it takes is a few people to quit at the wrong time, or for a codebase to be unmaintained for a year. Not only have I seen other teams do this, I have personally taken ownership of abandoned codebases, figured them out, and gotten to a point where I could effectively work with them. It takes time, but building a new theory of the codebase is possible. You start by understanding one flow end-to-end, then slowly branch out from there, making careful changes as you go. In sufficiently large codebases, everyone operates with an incorrect theory of the program . The defining feature of modern software systems is that they’re just way too big for anyone (or even a whole team) to keep in their head: nobody understands it all . To be effective, you have to figure out a way to work with a merely partially-correct theory. This is why I keep going on about taking a position and confidence . If you’re not sure about something, you can’t just sit back and wait for someone with a perfect understanding to come and give you the answer. If you’re a competent engineer, that person is you . You have to grit your teeth, make your most educated guess, and then deal with the consequences. To be generous to Naur, it’s possible that in 1985 the average size of a program was several orders of magnitude smaller than today, and that when Naur writes about “large programs” he’s not talking about tens of millions of lines of code. Naur’s first example of a large program is a 200,000 line industrial monitoring program, and his second example is a compiler. In 1987, the first version of the compiler GCC was about a hundred thousand lines of code; in 2015 GCC was over fourteen million lines. I can believe that rewriting one or two hundred thousand lines of code is relatively straightforward, particularly if you get to reuse existing tests. Not so for one or two million. LLMs are often cited as a tool that’s bad because it impedes the ordinary process of theory-building. I think this is overly simplistic. Like many software tools, LLMs are a double-edged sword: they make it harder to construct a detailed mental theory of the software, but they allow you to build a partial theory quickly and they can help you leverage that partial theory more effectively. This is a complex tradeoff that I’m still thinking about. Setting LLMs aside, I’m confident that it’s silly to say that anything that interferes with your theory of the software must be bad. Here is a partial list of other things that make it harder to maintain a theory: Like most things in software, “maintaining a theory of the codebase” is one value among many. Sometimes it’s the most important value and you sacrifice other values for it; other times you trade it off for speed, or legal compliance, or for political reasons 5 . Almost all engineers — particularly “pure” engineers — prefer to maintain an accurate mental model of their software. It’s more fun, less stressful, and feels more like “real engineering”. That’s why many engineers take up open-source projects in their spare time in order to work on small codebases by themselves: in order to do engineering work where they can maintain an accurate Naur theory of the codebase. I don’t think there’s anything wrong with that. However, at work you are paid to do a job . In other words, they pay you money to adopt their set of engineering values. It’s hopefully well-understood that however much you might personally care about performance, sometimes you have to write slow code at your job (for instance, to get a project done on time, or to accommodate some awkward requirement). Maintaining a theory of the codebase is the same kind of thing. I wrote about this at length in Pure and impure software engineering . I think many of the repeated arguments we have in the software industry are caused by the pure total-understanding culture coming up against the impure partial-understanding culture. Open-source engineers are more excited to blog about their work, the raw engineering content is typically more impressive (because coordination problems dominate big proprietary systems), open-source projects can be legally written about while proprietary systems can’t, and even if you could do it legally, writing about large codebases is impossible because it requires too much specific context . I re-read the relevant chapters of Ryle’s The Concept of Mind (which Naur cites throughout) and I think Ryle is more generous about theory-building. For Ryle, theory-building or know-how automatically happens as you do things. It’s fully consistent with Ryle to think you can pick up an existing codebase just from the code, purely by puzzling it out. Naur says: “Lest this consequence may seem unreasonable, it may be noted that the need for revival of an entirely dead program probably will rarely arise, since it is hardly conceivable that the revival would be assigned to new programmers without at least some knowledge of the theory had by the original team.”. If only! Some engineers might say that maintaining a theory is the core value, because without it you can’t fulfill any of the others. I disagree. You could say the same thing about readability, or maintainability, or correctness, or a bunch of other engineering values. We trade off “core” values like this all the time. Other people being allowed to write code in your codebase Having to implement legally-required features like accessibility and data protection Allowing your colleagues to quit their jobs or move between teams Having to upgrade software versions for security patches Bringing in libraries or other dependencies I wrote about this at length in Pure and impure software engineering . I think many of the repeated arguments we have in the software industry are caused by the pure total-understanding culture coming up against the impure partial-understanding culture. ↩ Open-source engineers are more excited to blog about their work, the raw engineering content is typically more impressive (because coordination problems dominate big proprietary systems), open-source projects can be legally written about while proprietary systems can’t, and even if you could do it legally, writing about large codebases is impossible because it requires too much specific context . ↩ I re-read the relevant chapters of Ryle’s The Concept of Mind (which Naur cites throughout) and I think Ryle is more generous about theory-building. For Ryle, theory-building or know-how automatically happens as you do things. It’s fully consistent with Ryle to think you can pick up an existing codebase just from the code, purely by puzzling it out. ↩ Naur says: “Lest this consequence may seem unreasonable, it may be noted that the need for revival of an entirely dead program probably will rarely arise, since it is hardly conceivable that the revival would be assigned to new programmers without at least some knowledge of the theory had by the original team.”. If only! ↩ Some engineers might say that maintaining a theory is the core value, because without it you can’t fulfill any of the others. I disagree. You could say the same thing about readability, or maintainability, or correctness, or a bunch of other engineering values. We trade off “core” values like this all the time. ↩
Hello RSS reader! This post contains an interactive feature. Please visit the canonical web page for an optimal viewing experience :) At the risk of pissing on people’s chips I figured it’d be helpful to illustrate the three classes of AI user I’ve identified in the slopageddon. You might be thinking: “Hey, those personas are all negative!” — and you’re absolutely right! Believe me, I’d love nothing more than to shut up about “AI”. The thing is, not a week goes by without one of my peers crying out in abject despair. Until the grifters cease spitting in my face and threatening my career, please allow me to extend a middle finger their way. I’m working on more positive plans that I hope to announce soon(-ish). Makes sense to be more proactive and spend energy where it matters. Not that this post didn’t! I enjoyed a few technical challenges artworking the page. Images used with modifications: Chalk Outline by Simon Child from Noun Project (CC BY 3.0) Hand by Elisa Pintonello from Noun Project (CC BY 3.0) Zombie by Hamstring from Noun Project (CC BY 3.0) Previous Next Thanks for reading! Follow me on Mastodon and Bluesky . Subscribe to my Blog and Notes or Combined feeds. The Grifter Dabbles with free chatbots Chuckles at social media slop Forced to endure a work mandate Never consented to any of this Helpless to the human toll Bends the knee to Big Tech Lives by “AI is inevitable” mantra Anthropomorphises their chat box Ignores self-inflicted deskilling Gambles with house money Flogs AI and AI paraphernalia Will not take “no” for an answer Dehumanises the effect of AI Idolises the techno-fascists Revels in gaslighting
Today, we're releasing the second season of the Now Go Build documentary series. Five episodes featuring technology leaders from around the world solving the hardest problems in healthcare and education.
Now that I’ve been working on Spinel Cooperative for a full year already, I have finally managed to write the very first post I meant to write about the entire situation: What is Spinel? Who is Spinel? Why is Spinel? Read on to finally receive the answers to all these and questions and more. Head over to the Spinel Cooperative blog to read Meet Spinel .
Pretty grim day of news in the industry today, with Salma Alam-Naylor stepping away from developer relations work permanently , Josh Comeau taking a sabbatical from making courses and GSAP’s once-vibrant forums descending into a ghost town . The reason your token guzzler “produces” anything that could be described as “good” is because of the years of hard work from people that actually care deeply . The reason what we do was fun was because of the soul that these great people — along with many, many others — brought to the table. They inspired us to better ourselves and make genuinely good stuff. That’s increasingly no longer the case as these people nope out of the industry. Anyway, enjoy your gruel. It’s all you’re gonna be getting.
First half of the year has passed, only half of the year left. 2026 is a difficult year for me so far. At the end of 2025, I wished for more rest this year. I didn’t do that yet. I pushed harder in different ways and I just can’t keep doing that. For 1.5 years now, I have been going extra hard in everything I do - I asked for more work at work, I created new opportunities and roles for me there, I blogged longer informative posts that took a lot of my knowledge and research, I completed more exams in my part time degree than ever before, I started and finished the certificate to be a data protection consultant, I attended conferences, I started volunteering, I went harder on my fitness, and so on. I do that to make up for my severe illness in 2024 and because of how a chronic illness turns everything into a pressing matter (fear of relapse, fear of no longer getting to do something, urge to maximize good times etc); and I can no longer keep it up. I need a longer break where I can just exist. I need to allow myself to do less in my part time degree and accept that it will postpone my graduation, I need to stop doing court case summaries for a month for noyb, I need to stop blogging for a while so I am not always working on some big essays and reading sources and running to keep up with articles and papers, and so I don’t always have a full inbox with like 50 emails to answer. I need to stop reading my web reader (RSS) and the Discover page. I can’t scale back work, so it has to be everything else. I want to enjoy life for a while and not always feel like I got something to prove, something to chase, something to keep up, something to get back to as soon as possible. And the thing is, I had so much fun stuff planned the first half of this year. I didn’t build those experiences up in my head and I didn’t have unrealistic standards, yet all of them kinda left a bad taste in my mouth when they happened. Travels, courses, conferences, restaurants, whatever. Everything I looked forward to had something difficult and disappointing about it, or had this Monkey’s Paw thing I mentioned in my other post. So I no longer feel like even planning nice things for myself and my wife. I’d rather save the energy, time and money. And that's sad, so I need to take some time to change that. It adds to the general burnout. I notice my impatience is worse, I get snappier, less forgiving, feeling more like someone’s fault or error is done in malice rather than accidental or born out of cluelessness/obliviousness. I no longer want to explain anything, elaborate, or help people, because I feel like I have to conserve my energy and efforts, as most interactions with others have a severe imbalance where I do most of the work. This would be the opposite if I wasn’t feeling burnt out. I react more defensively than usual if you point out small, irrelevant, inconsequential mistakes or make small requests for things I don’t care about changing. I retreat, I wanna be alone more, I wanna focus even more on personal projects that only involve me in isolation (and no other people, location, etc.) because those don’t let me down. I crave social interaction, yet listening to people or reading what they write is like nails on a chalk board. It’s a confusing time to be in, because I more or less get everything I want with some exceptions, but in a warped way where it doesn’t make me happy and is always accompanied with some annoying twist or extra price (figuratively). Nothing just flows. I have to micromanage everything and deal with ridiculous hurdles. I have stress “dreams” where I am half asleep, having hypnagogic hallucinations how it’s my turn in something (usually a board or card game happening on my bed) and I can’t figure out what people want me to do and they get impatient and urge me to finally hurry up, so I flee (sleepwalk around the apartment) before waking up and walking back to bed. In other such dreams, I am convinced I forgot to do something I promised I would do in a different reality/parallel world (?), but I can’t quite understand what I owe and how to do that thing, it’s incredibly vague and confusing, and I walk away from the bed to avoid the harassment by these dream people about it until I wake up and walk back as well. Those two repeat so often. Probably once a week. The feelings don’t leave me after I wake up, like I genuinely feel guilty and stressed even when awake and my brain still tries to decipher what I forgot to do and what I owe and that I’m running out of time? I haven’t bored myself purposefully nearly as much as I want to, need to and used to. There is always a blog post I want to write or continue; an article, book, blog post or paper to read; a video to watch; something to study; work; gym. I notice I'm desperately craving to do these things, and do them, yet also feel like I have to force myself through it. Like it takes an intense amount of energy and focus. I need a lot more time to do them, lots of micro breaks and distractions, and it all feels so difficult internally. I feel exhausted. Even when stuff is very easy and I want to do it. It’s like my brain is full, nauseous, sick. It screams at me to stop. My memory/retention is so shit, too. I have never said " I don't remember that. " ever as much in my life as I did this month. What adds to me not being able to stop is that it all feels mundane and harmless. Just one more thing. And they’re all things I do all the time, and things I am expecting myself to do, that are standard function, default. I understand when others burn out because bad timing of horrific events, like their house burned down while the pet is sick and grandma died and they just lost your job or something. Or: Insanely stressful high stakes job working 50-70 hours a week. But none of that applies to me. I just do normal things. And I don’t wanna be someone who does less. I want to do it all. My chronic illnesses play into it. You can be chronically ill, but you are supposed to work and act like everyone else and achieve things and work on yourself. You cannot be visibly ill, you cannot do markedly less, you cannot struggle with a basic task or workload. You cannot let yourself go. You cannot waste yourself. Otherwise you are giving in, you’re a lost cause, you do nothing to help yourself, you make your illness your personality, you use your illness as an excuse. You’re not an inspiration, and that’s kinda all you’re good for if you are forever sick. You are supposed to reassure everyone that chronic illness doesn’t alter life much and that life can go on unchanged and you can totally achieve everything you would have if you weren’t sick. If you cannot be used for this cause, you are discarded by society. There is a pressure to not let that happen to me, especially when my wife depends on me. Anyway, before I end up in the kind of burnout that makes you completely unable to work a job for most of your life, I have to change things. Just putting some self care things on my todo list doesn’t help, as it is just another obligation and doesn’t make me feel better. I just put it on the list because it is supposed to be good for me and a productive way to deal with stress. Like, what sounds better in our current society: That you slept all day to rest and watched some Simpsons, or that you did some yoga and then had a bath with 5 products to make you prettier and then journaled and then went on a walk? But I actually need to do the former for once. Which is what I have been doing a lot the past week. Lounging around, letting my mind wander, napping, just existing and breathing, like a cat sprawled on the sofa. I need to do things freely, and not do straining things all day, and let myself not do things that you can be measurably good or bad at. No care about consistency. I feel like I arrived at small versions of this burnout every now and then over the years, did something to help it for a while, and then experienced it again. And every time, it took a shorter while to relapse, and it felt worse, and it felt like I needed more rest and relaxation than I could realistically give. I only ever gave enough to function again, to make it work, to take the edge off, delay the worst. Like a day here and there doing little to nothing. Nothing more, no changed behavior moving forward. Something has to change permanently so I don't always run into this same issue over and over again, risking my mental health and my ability to do my hobbies and work. :) I still have to figure out where my sweet spot is between my ambition and what my body can give. I don't mind giving 200% for a time, just not forever. It seems like 1.5 years is my limit. With that said, I am gone the entirety of July. I won't blog 1 , I won't reply to emails until August, I won't read your posts. Friends can still reach me via Matrix and Signal. Reply via email Published 30 Jun, 2026 There is one announcement that I'll likely publish, that's it. ↩ There is one announcement that I'll likely publish, that's it. ↩
What made the Quick Desktop team successful is the same thing that has always produced the best work I've seen at Amazon: a small group of people who trusted each other, owned the problem end-to-end, and acted on their conviction.
I’ve never been great at dealing with stress. I have a tendency to overthink, assume the worst and constantly worry, it’s a great combination! This summer has been the most stressful of my life. My sleep has been terrible, I often feel ill and can’t get the knot out of my chest. It’s tiring to say the least. This has been compounded by a loss of time/interest for my hobbies. Cycling has mostly fell to the wayside and programming no longer captures my attention. Video games haven’t really stuck for a while now (though I’ve tried to convince myself otherwise). All to say, these are the reasons things have slowed down on here and also the driving force behind deleting most of my online presence. I’m hopeful things will calm down after August, fingers crossed!
For decades now, Raymond Chen has been posting to his blog The Old New Thing about various technical Microsoft quirks, occasionally venturing into Unsung territory. Last week, Chen shared a nice remembrance of Tony Krueger , a person responsible for implementing the red squiggly underlines in Word: Tony worked on Word 1.0, 1.1, 2.0, then on Word for OS/2 and Word for Mac, then returned to Word 6.0 and several versions beyond that. He probably holds the record for “most versions of Word shipped.” […] Tony made the spell checker much more unobtrusive so that it didn’t interfere with your foreground work. And when it found a problem, instead of waiting for you to trigger a spell check, it immediately drew red squiggles under potentially-misspelled words (and later green squiggles under potential grammatical errors). […] Today, there are red (and even green and blue) squiggles in nearly every word processor, and often outside word processors. Tony did it first. The next time a red squiggle catches one of your mistakes, say thanks to Tony. I think he’d appreciate it. Read on for some fun celebrity encounters, and even a touching comment from Krueger’s father. Another person adds that a “PM named Diana” and another Microsoft employee, Jim Walsh, might have been the people who designed the feature. Chen doesn’t name it specifically, but it’s my understanding that the red underlines were named Spell It (meh), and appeared in Office 95 in 1995. Steven Sinofsky confirms it on his blog , adding “The red squiggles were simply reflective of a proofreader’s style of mark (also one of the early uses of color in the interface).” = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/felt-a-bit-like-sorcery/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/felt-a-bit-like-sorcery/1.1600w.avif" type="image/avif"> As far as I can tell by looking at various screenshots and photos of boxes, the feature wasn’t advertised at all. It was only mentioned more explicitly a few years later in Office 97: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/felt-a-bit-like-sorcery/2.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/felt-a-bit-like-sorcery/2.1600w.avif" type="image/avif"> #history #text editing #windows
I quite enjoyed this talk from Bryan Cantrill where he discusses the difficult engineering problems they overcame while working on their company Oxide . Some of the problems they ran into were bugs. But these weren’t any ordinary bugs, they were company-destroying bugs: bugs that, if they couldn’t be fixed, would sink the entire company. And the difficulty in solving these bugs was that they had no precedent. Any documentation or knowledge they could find around the symptoms of the problem was actively incorrect. In fact, Bryan says that the team’s breakthroughs on these bugs were solutions that an artificial super intelligence would’ve never suggested because they ran against all known and available reasoning, documentation, and knowledge. His point being: intelligence isn’t everything. Human values are still incredibly important. Intelligence alone does not solve problems like [the ones we encountered]. Our ability to solve these problems had nothing to do with our collective intelligence as a team. We’ve got a terrific team, but it’s a lot more than just intelligence. And in particular for these [kinds of] problems, and many like them, we had to summon the elements of our character not our intelligence. Our resilience. Our teamwork. Our rigor. Our optimism. […] We talk about super intelligence, but is anyone talking about super collaboration or super teamwork? We absolutely needed teamwork [at Oxide]. If human values like curiosity are what led to breakthroughs — not the application of synthetic intelligence — why is there so much emphasis on intelligence these days? Bryan has a curt analysis: This infatuation with intelligence comes from people who just don’t get outside enough. He notes how intelligence isn’t everything in a job interview. Like, you don’t hire people by giving out an exam and taking whoever scores highest. You try to suss out other aptitudes. Nobody looks at applicants who lack values like teamwork or optimism and says, “Well, they can’t work with anyone and they’re incredibly unpleasant to be around, but their intelligence is great — let’s hire them!” Intelligence is great, but it’s not everything. We do a disservice to our own humanity when we pretend that [AI] can engineer autonomously. A cogent case for the values of our humanity. More like this please. Reply via: Email · Mastodon · Bluesky
If you have’t heard, Om Malik passed away . People are sharing stories of their graceful encounters with him. This one is mine. Back at the beginning of 2021, I set a goal to write 72 blog posts . I was puttering along, publishing whatever came to mind, mostly figuring that nobody was reading any of it. But that was ok. The process was therapeutic and it helped clarify my professional thinking, so I kept going. One day on Twitter I got a DM from someone with the handle . “I don’t know who this is,” I thought, “but damn that is a great handle!” Then I peaked at the follower count: over 1 million! “WTF? Who is this???” I thought. I’d never — then or since — been contacted by someone with such a high profile online. How was I even on this person’s radar? I continued on to his message: Jim I wanted to thank you for your blog. I am neither a developer or a designer but appreciate the web, the open web and in general normal, common sense writing from experts. I have quietly enjoyed your work — and hope you hit the target of 72 posts in 2021. My highly selfish ask, as I know it will feed my brain good important stuff. Have a wonderful weekend and a great writing year I was flabbergasted. Who was this person with such a high follower count saying such kind words and I’d never heard of him? I quickly went to Google. He had his own Wikipedia . “Om Malik…tech writer…founded Gigaom!” Ah-ha! I knew Gigaom the company/blog . It shaped a lot of my early exposure to the tech beat. I devoured it. I can still picture the logo in my head! Now I knew the man behind it. Knowledge unlocked! I thanked him graciously for taking the time to send a message whose importance seemed incredibly lopsided in my favor. I quote his message here because I still think about it on occasion. His words then (as well as later ones ) continue to lift me up on days when I feel like an imposter. They remind me of the power of a small act of kindness, even within such a vast world wide web. I still think about his words. I still think about him . I’m sure many will for some time. And that is a legacy. Reply via: Email · Mastodon · Bluesky
Deeper understanding of the code and software systems we work on, is not only pragmatic and practical but highly enjoyable as well ... But, if it is both joyful and powerful, why are we so often prone to skip the struggle to understand and take shortcuts, accepting copy-pasted/generated solutions and generic answers, not analyzed?
I’m getting to the age where peers have accomplished a lot. I’m not talking about people who were exceptional out of the gate and did great things in their 20s and 30s. I’m talking about people that felt like genuine peers, but now have done things like: These folks have things that I want . And I feel like I’m just as talented . I could be where they are and have what they have. In my mind I often think “why does <X> have that and I don’t”. This envy is not constructive, but that doesn’t stop it from popping up from time to time. I think I’m getting old enough that status and legacy are starting to matter in a way they didn’t a decade ago. Here are strategies I use to combat envy: I’d be surprised if I’m alone in feeling this way. Do you feel envious? If so, how do you deal with it? made a boatload of money built a business such that they have all kinds of freedom are well known in their fields Remind myself that I don’t actually know everything they have. I can see certain aspects of their life, but even for close friends I don’t know everything, just what they choose to share. The friend who is a professor who works with interesting projects and gets the summers off might have to deal with horrible politics or a low salary. I just don’t know. That means I don’t know enough to know if I’d actually want to trade places. I am idealizing what they have and not understanding the downsides. Even if I would want to trade places, I don’t know what they went through. When I see a friend with the thriving business who has flexibility and can work when he wants, I don’t see everything. I don’t see how he had to be tethered to it for years, or the risks he had to take, or the multiple years of 60+ hour workweeks and the stress that wrought on his body, family and friends. I try to imagine the late nights and the worries in the same way I imagine the benefits. Remind myself that I have agency and can work toward what they have. Even though I’m mid-career, if I wanted to adjust things to move towards what someone I see has, I can do so. As mentioned above, I need to be willing to make sacrifices, but I am lucky enough to have the space to consider it. With sufficient focus and effort, I can do most anything, I just can’t do everything. Even if I want to trade places with a friend, know what would make me happy, and would have been willing to make the sacrifices to be where they are, I am still discounting my current situation. It’s very easy to think “oh, <Y> would make me happy” but if I can’t look at where I am and be grateful, I might be kidding myself. And when I do take a hard look at where I am, I do feel more gratitude and satisfaction. One of my hacks when I’m feeling down is to just list 2-3 things that I like about my life. Related to feeling grateful for what I have, I also try to remember that just as I am looking at people and saying “why can’t I have what they have”, other folks might be looking at me and saying the same. In fact, I might have said the same 20 years ago if I was looking at someone where I am now. It’s easy to discount what you have and focus on what you don’t, but thinking about these folks makes me more grateful for what I do have.
Tech people spend all day inside logic, syntax, and expected outputs. Art does not work like that, and that is exactly why it can help. In this post, I talk about why you do not need talent or fancy tools to create something and rest your brain from code.
Career
Writing
Business
JavaScript
AI
Programming
Culture
Go
Design
Web Development
Journalism