Sean Goedecke 3 days ago

How to keep thinking

Imagine you’re the guest on some kind of frenetic, software-engineering-themed game show. The host is constantly flipping over new cards with questions that you have to answer as fast as possible: Working in 2026 feels a bit like this. When frontier AI models can do most of the tasks in your queue, the most efficient way to work is often spinning off tasks for an AI agent and continually context-switching between the results 1 . This isn’t quite mindless — in fact, it requires quite a lot of skill to skim the AI response and rapidly decide what to do with it — but it certainly involves less time for slow, careful reflection. Why does it have to be frenetic? Why not just slow down? I suppose you could , but I don’t recommend it. It’s just such a miserable experience to spend your day close-reading LLM output : carefully chewing and savoring each morsel of slop. It’s far less unpleasant to skim through quickly and pick out the useful nuggets of content. Couldn’t you simply do more of the work by hand? It’s unfortunately true that tech is high-pressure these days . If you’ve got the time and space to work more slowly, that’s great! But when your company gives you a “solve this task ten times more quickly” button, you are heavily incentivized to use it as much as possible, or risk being outcompeted by your peers. I sometimes worry that working with LLMs is making me dumber. Not in the “literally melting your brain” sense that some papers imply , but in the sense that it’s biasing me towards the quick “skimming and judging” parts of my mental toolkit and away from the slow “hammock time” needed for deep thought and real creativity. I don’t want to attribute this shift entirely to LLMs, since the post-2010s tech industry has become more frenetic for broader economic reasons . But either way, it’s got me wondering how I can keep thinking slowly . The main thing that’s worked for me is to write more. Specifically, I mean writing in my own words . Writing with an LLM does not work for this at all, even if you’re going to some effort to iterate on the content and outline the things you want to say. Why? Having to put the words together yourself forces you to articulate your thoughts. In a very real sense, it forces you to think . When you have an idea in your head for something to write, you don’t really have an idea. What you have is a kind of directional sense of where an idea might be, or a fragment of the kind of thing that might eventually become an idea. You construct the idea itself while writing. Incidentally, this is why I don’t really agree with “ideas are easy, execution is everything” 2 : most “ideas” are not really even ideas. The other thing I recommend is to read actual books . Books — particularly dense non-fiction books — are the antithesis of AI slop. The slower you can read them, the better. I’ve been reading more and more non-fiction in the last few years, and I don’t think it’s a coincidence. I think my brain is naturally craving information-dense content, in the same way that sodium-deficient people start to crave salt . In fact, I’ve been combining the two approaches: reading a book and then writing about it . This process is exactly what I’ve been craving since I started programming with LLMs. I get to carefully read a book, think hard about it, often go and read another book or two on the same topic, then sit and try to articulate what I’ve learned. It’s great! I can feel parts of my brain stretching again. It was pretty nice when I got paid to use those parts of my brain all day. Unfortunately, I think those times are coming to an end . There will always be room for some amount of careful, slow reflection in software engineering, but (for at least a little while) we’ll be expected to be rapidly switching between LLM outputs. We may have to find ways outside of work to continue the habit of thinking slowly. Even just in terms of work, I think losing that habit entirely would be a big mistake. There are still plenty of ordinary problems that are too hard for current LLMs to solve on their own. The most common example I run into is “large refactor on a complicated codebase”. Current-generation LLMs can do this without (many) errors, but they can’t yet do it tastefully . Sometimes you need to be able to think a problem through entirely with your own brain. This doesn’t mean switching between tasks . I routinely use six or seven different agent sessions on the same task: one for exploration, two or three for trying out different implementations, two or three for review, one for manual testing, and so on. Many of these can proceed in parallel. I remember reading a story 3 about a well-known author. Someone wanted to tell him their book idea, but they were so protective of it that they forced him to first sign a NDA before they retrieved the idea from their office safe. It was a single word “bioweapons” written on a slip of paper. Ironically, when I tried to google the source, Gemini kept trying to write me a story about bioweapons. Is this adjustment to the database schema right? Do these bits of data look plausible? Do these five paragraphs of text describe an actual series of manual tests that took place? Does this suggested architecture pass the smell test? Is this implementation better than the current code? Or this one? Or this one? This doesn’t mean switching between tasks . I routinely use six or seven different agent sessions on the same task: one for exploration, two or three for trying out different implementations, two or three for review, one for manual testing, and so on. Many of these can proceed in parallel. ↩ I remember reading a story 3 about a well-known author. Someone wanted to tell him their book idea, but they were so protective of it that they forced him to first sign a NDA before they retrieved the idea from their office safe. It was a single word “bioweapons” written on a slip of paper. ↩ Ironically, when I tried to google the source, Gemini kept trying to write me a story about bioweapons. ↩

AI Career Writing

▲ 0

0 views

Herman's blog 4 days ago

Committing to creativity

There's a quote from the book City of Thieves by David Benioff where a character laments the fickleness of talent: Talent must be a fanatical mistress. She's beautiful; when you're with her, people watch you, they notice. But she bangs on your door at odd hours, and she disappears for long stretches, and she has no patience for the rest of your existence; your wife, your children, your friends. She is the most thrilling evening of your week, but some day she will leave you for good. One night, after she's been gone for years, you will see her on the arm of a younger man, and she will pretend not to recognize you. While I love this quote, as well as the book (you should definitely read it), I can't help but disagree with the premise that talent and creativity are divinely bestowed and out of your control. I've read a few autobiographies of prolific authors, and they all state the same thing: the words don't come easily and sometimes need to be dragged, kicking and screaming, into the light. The book Creativity by the winner of the most-difficult-to-pronounce-name-award, Mihaly Csikszentmihalyi, shares this conclusion and suggests that creativity is a creature to be nurtured, given space to grow, and needs commitment and a lack of distractions to thrive. The thesis is clear: relying on motivation is a losing game. Motivation is a feeling, while commitment is a decision that outlives the feeling. I've found this to be true in my own life, both in creative pursuits, and in things like relationships and exercise. It is a rare person who is amped to exercise all the time, and so it requires commitment to stick with it. Similarly, showing up well in your relationships can't depend on fleeting passions, because life is bumpy. The nice thing is that commitments become easier with time. I have near zero resistance to exercising and journalling, and have been doing both almost every day for close to a decade. The first year or two were difficult, but once they were a part of my day, they became absurdly easy to continue doing. Relatedly, when I'm in a good writing routine it is effortless to write. However, if I go a month without writing on my blog (as is currently the case), each word is a struggle. Action begets motivation, not the other way around. Creativity is like a muscle. It requires constant use to grow, and atrophies when neglected. But creativity is transferable, and so, engaging creatively has positive effects in other creative domains. This post was inspired by a comic jam I attended this past weekend. The comics were great, genuinely funny, and everyone had a wholesome time. It also made me realise how long it had been since I'd sketched. Conversely, I speculate that forgoing creative thought will lead to it "leaving you for a younger man". She doesn't leave on a whim, she leaves when you stop showing up. It hurts when I see people "brainstorming with AI". This is essentially offloading creative thought to a machine, forgoing the most human of processes. It honestly makes me sad, and I can't help but feel that collectively we’re losing something beautiful. The machines are coming for so much, but we can’t let them have this. So go do something creative. Anything. Make a zine, paint with some watercolours, come up with a song. And keep doing that, forever.

Career

▲ 0

0 views

Ankur Sethi 1 weeks ago

Prevent cognitive debt by manually retyping LLM-generated code

Despite what I said in April , I'm still using coding assistants on my personal projects. Using them to one-shot entire features leaves me unsatisfied and disoriented, but I do enjoy using them to fast-forward through the boring parts of my projects. However, allowing my coding assistant to roam free in my projects leaves me with a colossal amount of cognitive debt. I might hate the idea of poring over the Django documentation to figure out how to add tagging to my website, but I still fundamentally want to understand how it works. Just because a problem is boring doesn't mean I want to fully offload my understanding of the solution to a machine. Of course, I could review every single line of code the LLM produces. That's what most developers are expected to do in this cursed year of 2026. Robots raise PRs, humans review them. It's a brave new world. But I don't enjoy reviewing AI-generated PRs. Poring over hundreds of lines of overly-defensive, badly-commented, subtly incorrect code is not fun. I might grudgingly do it for an employer—while making sure said employer becomes an ex-employer as soon as possible—but I'm sure as hell not doing it for my personal projects. Personal projects must be fun above all else. The joy of working on personal projects comes from the process, not from the outcome . So what's a boy to do? How do I offload the boring work to LLMs without ceding control of my own work and cognition to the slop machine? I've come up with a solution that's grossly inefficient and perhaps slightly comical: I ask my coding assistant to generate code in the chat, then manually make all the edits myself. I have these instructions in all the agents files in my personal projects: I want to understand every line of code that goes into this project. Never create, edit, move, rename, or delete project files unless I explicitly ask you to do so. Instead, show me every proposed edit in the chat so I can type it in manually. Do not run commands that modify project files, install dependencies, or change repository state unless I explicitly request that action. Instead, show me those commands in the chat so I can run them manually. I'm an experienced developer. Do not explain syntax, APIs, programming concepts, or implementation details unless explicitly asked. Using LLMs this way allows me to work faster than not using LLMs at all, but I'm still slower than those who are willing to allow the machine to think for them. Instead of being 10x faster, I'm probably only 2x faster. But what I lose out on in terms of speed, I gain in terms of a deeper understanding of my code. As I manually type every single line of LLM generated code into my editor, I build up a mental model of how it works and fits into my existing codebase. If I don't understand an API or algorithm, I can stop to look it up, or just ask the LLM to explain it. Typing the code myself forces me to slow down, which means I'm more likely to detect hallucinations or bad design choices the LLM might have made. I can clean up the code as I go, reorganizing it, refactoring it, adding comments, and generally adapting it to my own taste. Most importantly, this workflow allows me to build a spatial map of my codebase. I know where every bit of functionality lives in the codebase. When I need to make a change, I know exactly where I need to make it. It not only helps me work faster within my projects, it also makes it easier for me to better prompt and instruct the LLM in the future. When I was learning to code as a teenager, experienced programmers would often tell me to never copy and paste code into my projects. If I was learning from a book, I was advised to copy all the examples into my computer and make sure I could run them. If I was learning from a blog post or forum answer, I was advised to type it out and adapt it to my codebase so I understood it completely. Manually typing LLM-generated into my codebase feels like the exact same learning process. It might not be the most efficient way to work with an LLM, but I value comprehension over productivity. I've been doing this for a few months now, and it's been working well for me. I plan to continue using this workflow for as long as I can. I fear the software industry is taking on a large amount of cognitive debt that we'll have to pay back very soon. There will come a time when we no longer understand how large parts of our digital infrastructure are put together. I might not personally be able to change the course of the entire industry, but I can at least make sure I completely understand the software I put out into the world. Anything else would be professional malpractice.

Career Python AI

▲ 0

0 views

Sean Goedecke 1 weeks ago

Giving and taking credit in big tech companies

Engineers often complain that visibility should be their manager’s job. In other words, they think engineers should be able to focus on the code, while their manager figures out who’s doing well and rewards them. This attitude is an extension of the “school fantasy”: the idea that your workplace should operate by the same rules as your school or university. After all, you didn’t have to worry about “visibility” during your education. You simply did the assignments and tests you were given, and if you did well you were rewarded with a good grade. Many big tech companies encourage this attitude, because it helps them recruit smart graduates. They fashion their workplaces to look and feel like a university, even calling the physical space “campuses”. But it’s still work, not school. If you treat it like school, you are going to have a bad time. The first lesson many new engineers learn is that you have to take credit for your work . If you silently jump in to help a struggling project and get it back on track, there’s no guarantee of reward. Credit will naturally flow to the project lead, not you. In fact, if this project is outside of your direct team, it’s likely you will be punished for it: to your manager, it will look like you’re simply doing nothing at all. Even when your manager is watching your work, credit is largely uncorrelated with how well you did. That’s because, unlike at school, you are the subject-matter expert on your own work . Software systems are so complicated that only the people who work on them can hope to understand them, and even that understanding is always imperfect . If even experts can’t reliably estimate the difficulty of changes, how is your manager supposed to assess your technical performance? The answer is they aren’t. They’re simply not qualified to assess it. Instead, smart managers will find engineers on your team they trust and ask them how you’re doing. On small teams that have worked on a single codebase for a long time, this works okay, because everyone’s familiar enough to judge everyone else’s work. On large teams with a high rate of codebase churn, it goes badly, since they’re just guessing. On teams with a nasty, cutthroat culture, it sometimes goes very badly, since this is a good opportunity to actively sabotage the engineers who might threaten you. Experienced engineers know how to take the credit themselves . When they do something good, they tell their manager about it. They write internal posts explaining why it was technically difficult and how they solved it (the audience for these is partially those trusted engineers, and partially the managers who will see a long technical post and think “wow!” without reading it). They actively build trust with their management chain. Worrying about this stuff is the beginning of playing politics . There’s a kind of engineer who’s learned how to take credit but hasn’t learned any other lessons yet. They’re proactive about telling people what they’ve done, and they always maintain a “brag doc” . In particular, they love to talk about the parts they did by themselves , since those are least vulnerable to other people coming in to claim credit. You can tell they’re jealously guarding whatever credit they’ve managed to accumulate. The lesson this kind of engineer hasn’t learned is that you can often accumulate credit best by giving it away . To see why, consider how credit flows up inside a tech company. I wrote above that your manager can’t assess the quality of your technical work on their own, but instead has to rely on other engineers they trust. They’ll quietly ask those engineers “hey, was this project really that impressive?“. In fact, often there are multiple layers of this at play 1 . In big companies, line managers usually don’t decide who gets promoted or who gets a raise: they make recommendations to their manager, who has their own network of trusted engineers (confusingly, sometimes these networks overlap). The point is that there is a large group of people behind the scenes who will quietly and informally judge the value of your work . Succeeding at a tech company is largely about finding ways to get these people on your side. The easiest way is to share your credit with them — and since you don’t know who exactly is in this group, you should be sharing your credit freely. When you get feedback from other engineers, publicly thank them and mention them in your internal posts about the project. Find opportunities to ask for small favors, so you have an excuse to give other people credit. As best you can, make your individual projects at least partially group projects. Sharing credit with others gives them a reason to support you. A shared project you’ve worked on reflects well on everybody: on you, for working well with others, on the people you’ve worked with, for the same reason, and for your manager, for fostering such a great environment of cooperation. Lots of people have good reason to talk that project up, because it’s partly their project too. On the other hand, a project you’ve jealously kept to yourself reflects well on nobody: you come across as antisocial and your peers come across as unhelpful. Blame operates by the same rules as credit. When something goes badly wrong, managers will ask their networks “hey, who screwed up here?” The answer to this question is never simple. Even on a purely technical level, failures always involve an interaction between multiple complex systems, any one of which could conceivably have been built so as to avoid the failure. In other words, competent engineers can assign blame pretty much wherever they want . Because of this, it’s risky to have a project for which you’re clearly the only one getting credit. When something goes wrong, the network of people who will assign blame will likely be implicated in every part of the system but yours. They will be incentivized to attribute fault to the brand-new thing that they don’t understand and are not responsible for. If instead that network had been involved in your project — if they’d been in a position to share the credit — they’d be less incentivized to blame it. Of course, engineers are (mostly) not scheming viziers who make purely self-interested decisions. When asked who to blame, they usually make a good-faith effort to answer honestly. But in an area where there’s no single clear right answer, it’s human nature to be at least a little bit guided by your incentives. Nobody likes to think they’re responsible for a group failure. Credit and blame are the currencies of tech companies (and often directly translate to the actual amount of currency you get to take home). For technical roles, managers assign credit and blame based on lots of quiet conversations with their trusted engineers. This can be a rude awakening for very junior engineers who are used to having their work assessed by an expert grader (or less junior engineers who haven’t yet shaken that mindset completely). Don’t expect to get credit simply by putting your head down and doing good work. You have to find some way to tell people what you’re doing and why it’s important: internal blog posts, mentioning it in 1:1s with your manager, or anything else you can think of. But don’t take self-promotion too far. It’s a bad idea to try and hoard all the credit for your projects, for two reasons. First, sharing credit with other people gives them a reason to talk positively about your project. Credit is not a zero-sum game: if you do it right, you can get other people to build up your credit for you. Second, hoarding credit sets yourself up as a lightning rod for blame. Projects where the credit is concentrated in one or two people are automatically 2 blamed for complex problems, because nobody is incentivized to defend them. This is a classic example of an illegible-but-essential part of a software company. I wrote about this general phenomenon in Seeing like a software company . Of course, if you do really screw up, you’ll be blamed no matter what. I’m talking here about complex failures where it’s non-trivial to attribute blame to a single source. This is a classic example of an illegible-but-essential part of a software company. I wrote about this general phenomenon in Seeing like a software company . ↩ Of course, if you do really screw up, you’ll be blamed no matter what. I’m talking here about complex failures where it’s non-trivial to attribute blame to a single source. ↩

Career

▲ 0

0 views

Allen Pike 1 weeks ago

Weighing the Business Case for Quality

Most of us want to do great work. Building things of exceptional quality – work that’s beautiful, lovable, fast – is one of life’s great joys. However, the story goes, capitalism doesn’t value quality. Businesses don’t fund software that is lovable. Thus, you need to make a career choice: do you want to be a craftsperson, or do you want to make money? This dichotomy is nonsense. I mean, yes, these two things are in some tension. You can easily make money maintaining EOL plumbing if you can motivate yourself to do it well, and you can easily make beautiful products if you can afford to give them away for peanuts. But there absolutely exist businesses that are very large and successful in part because they invest in quality. Beauty, speed, and user experience can drive profits. Patrick Collison spoke about this back in 2023: My intuition is that more of Stripe’s success than one would think is downstream of the fact that people like beautiful things, and for rational reasons. Because what does a beautiful thing tell you? Well, it tells you the person who made it really cared. And you can observe some superficial details, but probably they didn’t only care about those and did everything else in a very slapdash way. … If someone really convinced me that the financial returns to craftsmanship and beauty – which I believe are greater – are not greater, I’d still do it. Life’s too short. So you could try working at Stripe. Even within Stripe, however, there are products and areas that don’t justify the level of care Patrick describes here. To get a real mandate for quality – to do great work, and earn a good income doing it – you need to ask yourself a question: is there a business case for quality here ? If you want the resources necessary to build something well, then choose to work on things worth doing well. There are a lot of reasons a product could be worth doing exceptionally well. Here are some: There are many others, but even just the above attributes describe some of the most craft-centric companies out there: Linear, Figma, Stripe, Wealthsimple, Apple, and so on. The economic details vary, but if a large company is spending the surprisingly large amount of resources it takes to build exceptional products, there’s a business reason to do so. Meanwhile, many of the most slapdash products out there are the inverse of this dynamic: imagine an internal control panel that an enterprise contract obliges you to deliver. A project like that shouldn’t be laboured over – it should be built to a minimum reasonable standard, then shipped. Its primary success factor is to exist. So if your goal is to work on things that are worth doing well, how do you figure that out a priori ? You need to get a sense of the business. Who are the customers, what makes them buy, and what makes them stick around? If you want to build a company that can justify making great stuff, ensure that you’re in a market where quality can confer an advantage. The analysis is a bit easier if you’re being recruited, since you can simply ask. Back when I ran Steamclock , occasionally I’d be approached by a prospective client that wanted to make a delightful app (excellent, that’s what Steamclock is all about) but for a use case that seemed… peripheral. Maybe it was an occasional-use product, or perhaps it was an internal tool. Sometimes it was plainly obvious that hiring an A-Team for the project was overkill, but other times, I’d explicitly ask: Thinking about what success looks like, how much do UX and quality for this product contribute to the success of the business overall? Sometimes they’d quickly realize it was a bad fit. But other times, they’d make a compelling economic case for craft and UX – starting us off on the right foot to execute on that vision. At the end of the day, there are countless ways to make a career building great software. The important thing to remember is that it’s not enough to care deeply about craft. It’s a great start, but if your customers won’t actually reward quality, you’ll be running uphill. Instead, work on products that have a business case for craft. You’ll have a durable mandate to do great work – and make money doing it. The product is used often – by many people, many times a week The motion is product-led – people self-serve, and refer by word of mouth The focus is retention – customers will vote with their feet The customers have high LTV – each buyer could grow into a huge account The buyers are users – quality impacts the decision-makers themselves The users are demanding – developers, designers, and other prosumers

Business Career

▲ 0

0 views

Unsung 1 weeks ago

“Insights and ideas emerge from that interface.”

From Robin Sloan : Yet we should never forget that the product of work isn’t only the work — it’s also the worker. Doing the work changes you; the up-close expe­ri­ence trans­forms your capa­bil­i­ties and even your desires. Insights and ideas emerge from that interface, and I believe the agent mae­stros lose a lot — too much — when they take their big step back. But I suppose this is just my temperament, which I’ve written about before . I don’t merely want things done; I want to do them. #ai #craft

Career AI

▲ 0

0 views

Ratfactor 1 weeks ago

How I got through my inbox in only two months

Concluding the thing I started three entries ago, I've replied to the pile of email I'd let accumulate. And I'm really pleased with my new hand-rolled personal contact database...

Productivity Programming Career

▲ 0

0 views

iDiallo 1 weeks ago

BI Slop

You must use the tool. We must justify it. These aren't the words companies use, but that's what it comes down to. When you buy an expensive solution before you've clearly identified the problem, you have to use the tool to justify its line item in the spreadsheet. At most companies I've worked in, there's always some application I've used once or twice. The third time I want to use it, it's gone. If a tool isn't popular, the finance team has no trouble dropping it. But for some reason, it's different with AI. If nobody's using it, the assumption is that employees aren't being productive enough. So we got signed up for mandatory training. There was limited space, but I moved fast and got a spot. I'd been using ChatGPT since it came out, so I was hoping the training would turn me from a casual user into a pro. Instead, we were shown how to copy and paste data from Excel and other sources into the chat interface. We worked with sample data, and there was always someone in class who'd say "mine didn't work." The developers in the room asked about Codex. The OpenAI-certified instructor replied that she wasn't a developer. There was an awkward moment when someone asked if we could just use Copilot, since it's already integrated into Excel. I got my certificate. But I don't think I learned anything I couldn't have picked up with a free account on my own time. What comes with a certificate, though, is the obligation to use the tool. I had a hammer, and everything looked like a nail. Whenever I ran into dense information, I'd copy, paste, extract insight. The great thing is that the result always looks neatly presented. I didn't have time to read the dense information in the first place, so of course I wasn't going to verify whether it was accurately referencing the source material. Besides, everyone was doing the same thing. I hate it when people use AI to write a Slack message, but at this point it's inevitable. One time, after a meeting, I pulled the transcript and asked ChatGPT to organize it into action items and generate a Q&A based on the content. It gave me something very elaborate. Or at least it looked elaborate. I skimmed it and passed it along to the next person, who actually had to use it to research a project. What I failed to notice was that a large part of the document was hallucinated. Some of the action items sounded technical enough to fool me. But to someone who actually had to work on them, they made no sense at all. I'm guilty of this, and it's become the norm. The same way we use large language models to write code as software engineers, the planning and architecting behind that code is increasingly written by LLMs too. In my household, AI slop videos are strictly banned, to the point that my kids police their friends who watch that stuff. So when my son saw ChatGPT open on my computer, he asked if I was making BI Slop. "BI Slop? What's that?" "It's Business Intelligence Slop!" I was so proud of him for recognizing exactly what I was doing. And I was so disappointed in myself, because that's exactly what I was doing. The same way we scrutinize code and refuse to merge PRs that are entirely AI-generated, we need to pay attention to the other ways we use these tools. Business decisions and plans produced by LLMs need to pass the smell test before they're accepted. The issue is the same one. We merge large PRs because we don't have time to read them, then suffer the consequences later in unexpected ways. With business intelligence, we don't read the output because of its sheer volume, and we approve it because it looks good on the surface. Then, again, we suffer the consequences later in unexpected ways. This is a problem created only because we were handed a mandatory solution: use AI to justify the line item in the spreadsheet. It only saves you time in the sense that you skip reading the output, and you do that because it looks good on the surface.

Career AI

▲ 0

0 views

Kev Quirk 1 weeks ago

Toot.community is shutting down

by Jorijn Schrijvershof Sadly, toot.community is shutting down in October. This post talks about why Jorijn has made that decision. Read post ➡ So much of this post resonated with me and aligned closely with my reasons to step away from Fosstodon . Being a fediverse server admin is a thankless job and as Jorijn says: I find myself feeling more angry or discouraged after spending time as an admin, and that’s not what I want from social media or a volunteer project. Over a year on since I stepped away from the Fosstodon team, I'm much happier now, but the experience has tainted my experience of social media. These days I probably visit Fosstodon maybe once per week. Every post I write is written here, on my site, and syndicated over there. I feel this is much better for me personally, as it keeps me away from the latest drama. When I do go visit the timeline, it's usually fun because it's fleeting. I don't have time to get involved in the latest drama. I go, check notifications, quickly peruse the timeline, and leave. It's a much healthier way of engaging, I think. More broadly, I think the issue with admin and mod burnout on the fediverse is what will limit it in the long run. It's almost entirely propped up by volunteers, who don't want to be involved with the drama, or be attacked for making a decision you don't agree with. And as a result, servers like toot.community fall by the wayside. I don't know what the solution is here - I actually don't think there is one. It's a fundamental limitation of the way in which the fediverse is architected and as a result, another great server is gone. 😔 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 .

Programming Career Open Source

▲ 0

0 views

Sean Goedecke 1 weeks ago

You don't have to be smart if you can think clearly

When you’re on fire, problems are transparent: they’re solved simply by the act of looking at them. Even complicated layers of multiple problems can simply be glanced through like stacked panes of glass. But nobody can work that way all the time. This is a common pitfall for smart engineers. Accustomed to being able to immediately intuit the solution, the first time they run into a problem they can’t do this to is a disaster. It doesn’t even have to be a hard problem, just a problem where for whatever reason they don’t see the trick right away. The difference between a “smart” engineer and a “strong” engineer is how they react to problems that aren’t solved instantly. A smart engineer might flail and struggle, hoping to find that flash of insight that eluded them; a strong engineer will have some process for methodically plodding away. There’s nothing worse than working with a smart engineer on their first really hard problem. When you don’t have the muscle to grind, it’s too tempting to just take any possible solution as the right one. Smart engineers can get into an increasingly-flustered loop of pointing to a series of bad solutions. They’re liable to panic: after all, much of their professional identity is bound up in their ability to solve problems easily. What skill do these smart engineers lack? I think it’s the ability to think slowly and clearly . Smart engineers can think clearly, but they can only think clearly at high speed. Strong engineers can think clearly all the time , even if their highest speed isn’t quite as fast. It’s like the difference between a Formula 1 car and a regular car: Formula 1 cars have a high top speed, but you couldn’t drive them in traffic, because the tyres and brakes don’t work at normal driving speeds. When I wrote about this before in Thinking clearly about software , I said that the key is to focus on the invariants : beliefs about the system that you know are true. When you’re stuck in a puzzling situation, it’s usually because some assumption you’ve made is false. If you’re able to identify the assumptions that can’t be false (for instance, if you’re getting an error message from the service, the service must be handling the request), that gives you solid ground that you can stand on to evaluate the assumptions that are less reliable. Thinking fast is about packing as much data in your brain as possible and letting your intuition leap to the right conclusion (or at worst, to a series of wrong conclusions that you can immediately dismiss before you come across the right one). It can feel deeply satisfying to make leaps like this; conversely, sitting with the raw data and not making mental leaps feels unsatisfying. People hate doing that. If you can force yourself to do something people hate, there’s typically a lot of value waiting to be extracted. This is no different. Engineers who can think clearly in a state of uncertainty tend to be extremely effective, whether they’re capable of great intuitive leaps or not.

Programming Career

▲ 0

0 views

Martin Fowler 1 weeks ago

Why I’m Writing Rachel’s Ramblings

TL;DR I have ideas. I haven’t been writing them. That’s about to change. I promise… myself. I’ve been thinking a lot about talent. Actually, I’ve been thinking a lot about thinking. And writing. Or more specifically, not writing. This really hit me earlier this year at the Future of Software conference. I was surrounded by people sharing their latest ideas and I had a slightly uncomfortable realization: I have my own. Not just opinions. Actual patterns. Hypotheses. Things I’m seeing across clients, across teams, across the industry that feel new or at least not well articulated yet in a way that a leader can think about and act upon in some way that can influence how they strategise and plan for the future. Because helping clients and other leaders internal and external to thoughtworks do this is actually a big part of what I do and without letting my northern humbleness get in my own way, I’m actually pretty good at it. If I wasn’t I wouldn’t be the global CTO of a future thinking tech org, you know the kind that has Martin Fowler as its Chief Scientist. A title I know he loves… Martin, by the way, is one of the people pushing me to do this, which is weird because on paper I’m his boss but I don’t believe in the traditional idea of a boss anyway. I’m a strong believer in the servant leadership type but I’ll save that for when I write about that. Anyway the point is for all the ideas I have and discussion I have I don’t do a good job of writing it down. At best I’ll stick it in a presentation deck when I’m forced to communicate with them in some forum or another. I hate decks and love writing so I’m obviously doing something wrong. So why haven’t I been writing? It’s easy to say I’ve been too busy. I don’t have an easy job. It’s a fun one but not easy. I also have two small children, 5 and 8. In case you are interested, I attempt to give as much time as possible to this busy job. And then I try to have a life. I’m also writing an epic world building sci-fi fantasy book which is a huge passion project I may also share more about so I am definitely busy. But that’s not actually the real reason I haven’t been writing this down and pushing it out publicly. The real reasons… So this is an experiment. Rachel’s Ramblings is exactly what it sounds like. Fast, imperfect, thinking out loud. Naming ideas early rather than waiting until they’re fully formed. Because the reality is, most of what I do day to day isn’t answering known questions. It’s spotting patterns and asking questions we haven’t quite figured out yet. My brain works a bit like a knowledge graph. Constant associations, constant pattern matching. That’s useful in conversations, in client work, in strategy. It’s less useful if it never gets written down. So this is me fixing that. I’ll write about: Some of it will be wrong. Some of it will evolve. That’s the point. If nothing else, this is a forcing function to turn thinking into something that exists outside my head. Let’s see where it goes. I overthink it. I move too fast to the next idea. I’ve convinced myself it needs to be more polished than it does. what is the future of software how software development is changing in the age of AI and what that means for engineers, leaders, and organizations how platforms, agents, and people actually work together and occasionally, how I manage the reality of doing this job with all the other things I have going on

Writing Career

▲ 0

0 views

Lalit Maganti 2 weeks ago

How I Find Problems to Solve as a Staff Engineer

Note: this post was revised after publishing for increased clarity, based on reader feedback . “How do you find problems worth working on?” a senior engineer I mentor asked me recently. He’s trying to make the jump to staff engineer and realized that the role isn’t just about doing the work he’s assigned. He also needs to get involved in figuring out what his team and org should be building. Someone else had suggested blocking out time in his calendar to think about the bigger picture. He’d tried that, but hadn’t found it productive, so he asked if I had any alternatives. I told him I rarely find good problems by staring at a blank page and trying to “think strategically.” Instead, I act like a sponge. I listen to the stream of day-to-day noise, absorb the problems people are having and let them sit in the back of my mind. Over time, some fade away while connections begin to appear between others that initially seemed unrelated. Eventually, I start to see what’s really slowing people down and what my team or I can do about it. I’ve worked with many engineers who’ve never really tried this. They wait for managers or leads to identify opportunities, then demonstrate their value by solving the hardest assigned problems. That can absolutely lead to promotion. But the projects that have made the biggest impression in my career were the ones where I found and solved an important problem my leaders did not yet realize existed. One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. People love talking about the problems they are facing: in meetings, chat threads, presentations and email. They explain why their work is hard, complain about what slows them down and describe what they wish they could do. When something overlaps with my area, I start pulling on the thread. I might ask, “If X existed, would it solve your problem?” or point them at an existing feature in a product I own and ask how much of their use case it covers. Users often ask for a particular solution instead of explaining their root issue. Rather than taking the request at face value, I keep digging until I understand what they are trying to accomplish and why existing products do not work for them. As a natural introvert, this sort of ambient listening works particularly well for me. I don’t need to fill my calendar with speculative meetings just to find ideas; there is already an enormous amount of useful information flowing around me during a normal week. When a problem seems worth exploring, though, I become more active; I need to see how it affects the team’s day-to-day work. I’ll sit with them as they walk me through their workflows and the bugs they’re investigating. When I can, I’ll try working through some of those bugs myself. Seeing the problem firsthand makes it easier to separate what the team actually needs from the solution they asked for. I also seek out people who see more of the organization than I do: those who own critical systems, work across several teams or have particularly deep insight into the work downstream of my team. I’ll arrange a 1:1 or coffee chat and ask about interesting problems they’ve come across. They may have already seen the same issue in several places and started connecting the dots, giving me a head start on patterns I might otherwise have taken much longer to notice. Several times, I’ve been burned by moving too fast. I became excited by a request from a vocal team, built the feature and watched them barely use it. Their priorities had changed, or the request had come from a one-off investigation that no longer mattered. How eager a team was in that moment wasn’t the same as how important the feature was relative to everything else my product needed to support. By hyperfocusing on their request, I lost sight of the bigger picture. That taught me to let potential problems pile up. Listening the way I do leaves me with far more of them than I could possibly solve, and not all deserve action. Most don’t need to turn into projects the first time I hear about them; waiting can be a superpower. Waiting means the same problem might pop up independently in different teams, making it a higher priority to solve. Or problems that look different on the surface might turn out to have the same shape, so I can address several use cases in one shot. Or, as I’ve learned painfully, the requesting team didn’t even care that much in the first place. Instead, I make a mental note and revisit the problem if it comes up again. Other engineers I know write this sort of thing down more systematically. The mechanism is a personal choice: everyone has to figure out what works for them. What matters is keeping unresolved problems around long enough for more evidence to accumulate. Waiting helps me collect evidence, but that alone doesn’t tell me what to build. I still need to work out whether the problems I’ve retained are genuinely related and what, if anything, could address them together. Perfetto, the performance debugging tool I work on, is a good example. It displays recordings of system activity on a timeline made up of rows called “tracks.” Over a couple of years, teams kept asking for small, specific additions to the UI. One wanted a command to keep their preferred tracks pinned to the top of the screen; the next team wanted the same, but for a completely different set of tracks. Others wanted Perfetto to open already zoomed in on a particular part of a recording, or to show a custom aggregation tuned to what they cared about. A few had stopped waiting for us and built elaborate workarounds with bookmarklets. 1 By the time enough of these had piled up, my head was the usual tangle: the requests themselves, the constraints on each and a handful of half-formed solutions. I’ve learned not to force a solution by just sitting at a desk and thinking. Instead, my best untangling happens on long, aimless walks around London, where connections come more easily when I’m not trying to force them. What I eventually realized was that none of these teams really wanted the specific feature they’d asked for. Each wanted to personalize Perfetto for their own workflow without imposing their choices on everyone else. The underlying need wasn’t any one feature but rather the ability to extend the UI. When a connection like that finally clicks, it’s one of the best feelings in the job: several awkward requests collapse into a single idea, and possibilities open up that none of them hinted at on their own. That feeling, though, is exactly when I have to be careful, because a common shape is only a hypothesis and elegance is not evidence. When it happened with extending the UI it turned out to be real, but I’ve been fooled before. In another recent case I was convinced that building a transparent caching system for querying Perfetto traces would solve issues with sharing large traces and repeated queries. It was only as I wrote the RFC and built a prototype that I realized the elegance was a lie: the two problems wanted genuinely different solutions. I reluctantly split the design in two, both halves of which have since shipped. 2 You’d think this would be the moment I start building, but it usually isn’t. How far I go depends on how sure I am that the idea works and that people actually want it. If something is useful and low-risk enough, I act straight away: I send the change and let my manager know. When I’m unsure whether an idea will work or how much effort it will take, I build a throwaway prototype instead; it exposes the failure points and gives me something concrete for others to react to. And when an idea is big but I’m convinced by it, I commit to the full effort: weeks or months of work and the hard yards of building support across other engineers and teams. Through all of it, I’m not only trying to convince other people; I’m also trying to convince myself. Sometimes the honest answer is to stop: if people don’t see the value I do, or we hit a major technical wall, I’d rather drop the idea now than build something no one uses or that becomes a maintenance nightmare. And sometimes it holds up but the timing is wrong, so I park it, ready to spring into action the day it becomes an org priority. When an idea does hold up, I don’t necessarily need to be the person who builds it. I might implement it, someone else on my team might, or it might change what the org focuses on. Finding and shaping the right problem can have an impact even when I don’t own the implementation. The Perfetto extensions idea was worth that full effort. We were already building plugins to modularize the UI, but they weren’t enough: teams had to open source all their plugin code, which wasn’t an option for many internal use cases. So before building anything new, I took the problem and my proposal to my manager, teammates and the client teams. I ended up writing two RFCs, having several 1:1s and giving a couple of talks, refining it as the feedback came in. In the end, I designed and implemented macros as “lightweight extensions”: a way to automate actions in the UI without writing a plugin. Extension servers took the idea further by letting teams share their macros. Instead of implementing every requested feature ourselves, we gave teams ways to adapt Perfetto to their own needs. Dozens of teams inside Google now use macros and extension servers, and several other companies use extension servers internally too. The more often I go through this process, the easier it becomes. When I show genuine interest in someone’s problem, ask useful questions or help solve it, they remember. They start coming to me earlier and bring me into conversations with other people facing related issues. That gives me a wider view of what is happening across the organization, making it easier to spot patterns and build things people actually need. Solving one of those problems brings me into more conversations, and the loop continues. Those successes build the kind of trust that comes from long-term stewardship . Early on, I had to turn many of these ideas into something real myself to prove that my judgment was sound. Over time, my manager and org gave more weight to my assessment of what mattered. That allowed me to influence the roadmap without needing to own every project. This differs from the idea that becoming a staff engineer means replacing technical work with meetings and coordination. For me, conversations are inputs into what I build, not the end result. That is what I wanted my mentee to understand: finding problems worth solving isn’t separate from the rest of the job. It comes from staying engaged with people’s work long enough to see what no single request can show you. These workarounds used bookmarklets to run JavaScript against Perfetto’s internal UI APIs.  ↩︎ The original proposal was to use a transparent cache for repeated queries and faster reopening of large traces. As I worked through it, I realized repeated queries were better served by keeping sessions warm in memory, whereas reopening was better served by explicitly exporting a trace into a format designed to load quickly. A transparent disk cache could also retain multi-gigabyte files without the user realizing and would need a new system to manage their lifetime. The proposal was ultimately replaced by warm sessions and streaming table export .  ↩︎ These workarounds used bookmarklets to run JavaScript against Perfetto’s internal UI APIs.  ↩︎ The original proposal was to use a transparent cache for repeated queries and faster reopening of large traces. As I worked through it, I realized repeated queries were better served by keeping sessions warm in memory, whereas reopening was better served by explicitly exporting a trace into a format designed to load quickly. A transparent disk cache could also retain multi-gigabyte files without the user realizing and would need a new system to manage their lifetime. The proposal was ultimately replaced by warm sessions and streaming table export .  ↩︎

Career Java JavaScript

▲ 0

0 views

Jim Nielsen 2 weeks ago

Podcast Notes: Ed Catmull on David Senra

Ed Catmull, co-founder of Pixar and former president of Disney Animation, was on the David Senra podcast and I quite enjoyed the interview. (If you like the interview, you should read his book .) Ed talks about what he considered his job to be: get the dynamics right for groups of people working together. To do this, he would pull people out of meetings, make groups smaller, make them bigger, just constantly work on fine-tuning getting the right people together at the right time with the right feedback (without ego). Granted he didn’t always do it, but that was his goal. He says: This is so important to get [these group dynamics right] because this is what our product is based on: getting this group of people to work well together. So paying attention to the dynamics of the room is the job. They’re the ones making the movies. I’m not making the movie. I’m just trying to get them to work well together. When Steve Jobs came to Ed and essentially said, “We’re gonna bet everything at Pixar on Toy Story , and the same week that Toy Story is released in theaters we’re gonna IPO.” What did Ed think? I thought it was crazy [laugh] I’ve learned a lot in this process. He was right. I love this frank exchange and Ed’s ability to go from “I thought he was crazy” to “I learned”. In a creative endeavor, where so many earlier iterations suck, how do you gauge whether you should keep going? Because to keep going can make you seem a tad crazy, e.g. “This sucks — let’s keep going!” So how do you know whether you should keep investing in it? Ed’s answer: What’s your basis for proceeding? For me, the basis was: what’s the spirit of the team? Because we all know it [sucks] but if they’re all working together — they’re laughing, and [doing things] together — then you say, “Let’s keep going. Let’s keep trying to solve it.” I love this. He didn’t say, “You open a spreadsheet and do a cost analysis.” He said he looks at the spirit of the people working on it. It really backs up what he said his job is: find and help groups of people work together. His attitude seems to be: a group of people with the right dynamics can solve anything. Ed talks about Pixar’s willingness to take on hard problems because they believed a hard problem led to better outcomes (because few others were willing to do the hard work): A hard problem is more likely to lead to an interesting film. If it’s easy, then it’s more derivative. You know how to write a script, you know what the three-act structure is, you know all these elements of storytelling, and you put together all the pieces and you got a story. Is it a great story? Is it emotional? Sometimes yes, sometimes no […] It’s fairly easy to come up with something that is mediocre — and it’s cheaper too. If you take on hard things then you need to spend more time trying to figure out how to be different in what you’re doing. So if you take on a hard problem and you just keep pushing at it, then the fact that it was hard is what is going to make it different. Stated again for emphasis: “ the fact that it was hard is what is going to make it different ”. And it’s the execution that’s hard, not having the idea: If you’re going to make a movie about a rat that likes to cook, that is not a slam dunk. A lot of people want to keep their projects secret, but this is one where you could tell everybody: “We’re going to make a movie about a rat that cooks!” His point being: nobody can steal that idea and make it good. Execution is everything there. And if you look at it and say, “Well that’s too hard. How could you make a film about a rat that likes to cook?” You’re skirting the hard work, which is exactly what is going to make you different. Don’t skirt the hard thing. If you do something that’s hard, that’s the differentiation. Lastly: I love Ed’s perspective on mission statements: The reason [we never had a mission statement] is because a mission statement is an answer, when typically we should always be asking questions, like “What are we doing?” His point being: if somebody asks “What are we doing?” and you immediately go back to the mission statement and say, “Oh, well we’re doing this” that’s not good. It’s better to always be questioning. “Are we doing the right thing? Are we going in the right direction?” You should always be wrestling with those questions. Reply via: Email · Mastodon · Bluesky

Movies Career Business

▲ 0

0 views

David Bushell 2 weeks ago

Businessing 101

Back when I began freelancing I figured I’d set up a limited company eventually. I guess thirteen years later is eventually. I’ve finally got a local accountant working on company registration. Exciting times! The final push was this Making Tax Digital thing from GOV.UK. It’s probably not complicated if I cared to look but I’m crawling back to FreeAgent anyway. My home-cooked accounting app served one whole tax year! I will have an accountant do everything now. Another big reason to become Ltd is to face challenge and opportunity head on. A loud contingent of the web industry are giving themselves up to the borg. Mandated token servitude and knee-bending to grifters like Google is sending web dev back to the stone age. I still care about making meaningful websites for real people. I have no desire to dump dead websites on the dead internet . I want to champion and preserve the knowledge and expertise being discarded at astonishing rates. This is not an “anti-AI” movement per se; I simply don’t compete with chat-box-driven development. Trading under a limited company allows more opportunity to collaborate with other creative professionals. As a freelancer I’m hired personally. As a company I can offer the same services and assurances whilst expanding the team if specialists are needed. Who knows, maybe one day I’ll be in a position to hire full-time. This does not mean I’m going back to LinkedIn. I deleted that account like ten years ago. Please don’t make me go back! My income is modest. My freelance years have ranged from ~£20–60,000 annually. I work a four-day week with sensible hours and avoid overlapping projects. Working hard and working long hours are not the same thing. I expect my new business will remain shy of the VAT threshold but I’ll see what my accountant advises. I’m not sure my rates have kept up with “inflation” and cost of living. According to the Bank of England inflation calculator : What cost £1.00 in 2013 would cost £1.44 in June 2026. Hmm, feels like I’m paying a lot more… probably the shrinkflation . One things for sure, the quality of my services will not shrink. I’ve got a lovely new brand and website ready. That’s been in the works all year. Once the red tape is completed I can go live. August or September, maybe? Thanks for reading! Follow me on Mastodon and Bluesky . Subscribe to my Blog and Notes or Combined feeds.

Business Career

▲ 0

0 views

Kev Quirk 2 weeks ago

📝 2026-07-24 11:20: I think if I had my time again, I would have become a software developer....

I think if I had my time again, I would have become a software developer. I just so much fun - coming up with ways to solve a problem in an elegant way is very satisfying. Then people emailing saying they enjoy the tools I'm creating. Very rewarding! Mind you, would it still be as fun if it was my job? I don't know. 🤔 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 .

Career Programming

▲ 0

0 views

ptrchm 2 weeks ago

Nothing Works and Everyone Is Euphoric

As I’m writing this, we’re in the middle of an AI-induced mass psychosis. People are literally token-maxxing themselves into hospital beds , scrambling to capture some of that market value before everything is automated away. I can’t blame them. Models keep getting better, programmers are being laid off left and right. We’ve been repeatedly told that AI will write 100% of the code by the end of the year. Whether that’s true or not, this may not be the best time to sit back.

Career AI

▲ 0

0 views

tonsky.me 3 weeks ago

Looking for work

Hey, Niki here. This is a bit unusual. My sabbatical is coming to an end, and I am looking for a new opportunity. Full-time or contract, startup or research, remote or Berlin, individual contributor, ideally—tight team, ambitious product. I am a software engineer first and foremost with 20+ years of experience. I work on technically challenging products, foundational technology, dev tools. I’ve been doing Clojure and web recently, but I'm also very excited to explore closer-to-the-metal programming. I have an eye for design, user interfaces, UX, DX. I would love to work with a team that takes interface quality seriously. Or to work with graphics! I am pretty sure I am good at explaining stuff, including what we are building, why, why this way, why is it important, etc. For example . The overarching theme is to understand computers deeply, and then use that to make better and simpler software. If you care about that too, we might be a great match! Instant DB is a US startup building a modern Firebase. I worked on the sync algorithm, performance, DX. A summary of my commit log . Roam Research is an OG personal knowledge manager. I worked on database optimization and a plugin system. At JetBrains , I developed a new Skia renderer for Fleet and Jetpack Compose Desktop. I’ve built many open-source libraries , including a database , a GUI toolkit , a Clojure dev environment , a React wrapper , a well-known font ... More recently, Clojure+ gives you a taste of my approach to DX, and Fast EDN —to performance. I maintain several active projects — AlleKinos.de , Grumpy Website , this site. If you want to dive deeper, here’s the usual stuff: Projects / Talks / LinkedIn / GitHub I also made a two-page PDF CV . It’s an attempt to reach beyond my immediate network. I’ve been doing Clojure for a long time, and now want to explore. If you are working on a compiler, a database, an IDE, a programming language or another technically ambitious product, touching graphics, typography, algorithms, low-level programming, and you think my experience can help, let’s talk: [email protected] .

Career Open Source Programming Clojure

▲ 0

0 views

Anton Sten 3 weeks ago

Working backwards

This weekend I visited a friend who studies at an art school. She showed me around the studios, walls covered in figure drawings, still lifes, and portrait studies in various stages of completion. It brought back memories from my own school years. I studied at Hyper Island 25 years ago, back when the program was called New Media Design, believe it or not. Different school, different medium, but the same feeling of a place where people are there to learn how to see. Because on paper, what she does and what I do have little in common. Design solves a problem. There's a user, a constraint, a business goal, someone waiting on the other end who needs to accomplish something. Art carries no such obligation. Donald Judd said it best in seven words: "Design has to work. Art does not." — Donald Judd That difference shapes everything. When I design something, my taste is in service of someone else's outcome. When my friend paints, the outcome is the painting. Neither is harder or nobler than the other, but they are different jobs. Still, the longer I walked around, the more I noticed how much of her training would make anyone a better designer. In one of the rooms, someone had taped up a printout titled "Good Habits." Four items: step back to look at your work from a distance, use a mirror or flip your piece upside down, squint to see the big shapes, take a break and clear your mind. That's painting advice. It's also a better summary of senior design behavior than most things I've read in design books. Understanding the big picture is often what separates senior designers from junior ones. Juniors polish the component in front of them. Seniors step back and ask whether the screen makes sense in the flow, whether the flow makes sense in the product, whether the product makes sense at all. And squinting has a direct design equivalent. In my book I write about the one-handed test, which came out of my work at Summer Health. A parent booking a doctor's appointment usually has one hand free because the other one is holding their child, and their focus is split at best. Squinting at a painting and using an app while bouncing a feverish kid do the same thing: they strip away the details and reveal whether the big shapes hold up. If the hierarchy only works for a calm person with two hands and full attention, it doesn't work. Next to the habits hung another printout: "Focus Glasses." Alignments, angles, measurements, implied lines. Ways of looking, each one training your eye on a specific relationship within the work. This is the essence of craft, and honestly, it's the skill I fear is going missing as more people design things through prompts. The tools will catch up on some of it. I already use a couple of skills in Claude Code to check that font sizes hold a sensible ratio, that spacing follows a scale. But a tool that checks ratios can't tell you what to look for when something feels off and the checklist comes back clean. That still takes a trained eye. David Hoang wrote about this recently in a piece called Training design senses . His argument is that taste and judgment don't arrive with a job title, they get built through deliberate practice, the way a musician or boxer trains. His first year of art school allowed no color: charcoal, still lifes, figure drawing, and copying the old masters. His advice for interface designers is to do the equivalent. Put a great screen on your canvas and rebuild it from scratch, noting the margins, the spacing, the type sizes, and asking why each decision works. He also passes along a line from a colleague that stuck with me: someone can have twenty years of experience at the same skill level. The thing that struck me most came at the end of the visit. My friend told me about an exercise where they take a finished painting and deconstruct it. They start with the final piece and step backwards through it, layer by layer, to understand how the result was actually achieved. The image below shows what that looks like in practice: the same composition as a sketch, as an underpainting, and as the finished piece, side by side on the wall. Samuel Hulick did something like this for products years ago. His site UserOnboard broke down onboarding flows screen by screen, annotating what worked and what didn't, and it's still online. At the time it felt like a clever content format. Walking through that studio, I realized it was the same exercise the art students do: take a finished thing and walk backwards until you understand how it was built. I wonder if we need more of this now, not less. We've reached a point where an idea becomes a prompt and a prompt becomes an app in the store in days. The finished result appears almost instantly, and nobody steps backwards through anything. Meanwhile these students spend weeks deconstructing a single painting to understand its structure. One of those groups is building the judgment to know why something works. I'm not sure it's the faster one.

Career Design

▲ 0

0 views

Dan Moore! 3 weeks ago

What It’s Like To Lead An Engineering Org: Thoughts On “CTO In The Loop”

I just read CTO In The Loop by Balki Kodarapu. It’s free on Kindle through July 20th, so if you want to give it a read, go do that now. It’s a narrative arc following a developer, “Sam”, who starts as a software engineer at a startup, and ends up a fractional CTO after a career that includes engineering manager, director of engineering and VP of engineering at a company that IPOs. The book was a fun read, and does a good job describing what it’s like to build a company and a software business from the early days to a more mature organization. The realities of Sam’s growth ring true: he starts out focused on features and clarity, and then moves up levels of abstraction. He loses touch with tasks and areas that used to matter, but gains higher level views and more ability to influence the organization. As a director, if you’re still reviewing PRs the way you used to, you’re basically breaking your organization We also see the evolution of several other characters, including Priya the project manager, Mei the UX designer and Jack the senior developer. Some of these folks stay with Sam across companies, while others pop in and out, just like real world colleagues. Some details felt a little forced; for example, locking down a GitHub repo and preventing merges to the main branch are treated as a major effort, when most software shops do that pretty early. I especially liked the portrayal of the thorny moments of management that Sam encounters: I also really enjoyed the emphasis on integrity, and how the protagonist was repeatedly challenged to hold onto it through different stages of business growth. I think integrity is an easy thing to write about and much harder to actually live. In the moment, you tell yourself that just this one tweak that you might feel uneasy about will move the business in a positive direction. But doing this repeatedly only works in the short term. The benefit is immediate and the cost is deferred, and avoiding these kinds of decisions is a constant challenge as an organization grows. The hard part is that it’s rarely obvious where the line is. Most people agree you shouldn’t commit fraud. But there are dark UX patterns that benefit the business. For example, you could make it much harder to unsubscribe from a service than it was to subscribe; every organizational incentive points that direction. Another example is the integrity in making it easy for a customer to leave: making it easy for people to export their data and take it with them. That’s a frustrating tradeoff for whoever’s job it is to sell the product, but it’s a pretty clear-cut example of integrity. You want to earn people’s business, not hold their data hostage. There are other places integrity shows up over the course of a career, but the author does a good job of showing how it is hard to maintain, especially when you are focused on the day to day of building a software business. CTO In the Loop is a fun, easy read. I read it on the Kindle app in about 2 days while on a vacation. I’d highly recommend it to people early or mid-career in software who are curious what life looks like at a different level of the org chart. When I was younger, I assumed people at higher levels had a lot more control, agency, and power. That’s true, but they are also further from the customer, removed from knowledge of how technical systems actually work, and have a lot less clarity about the day to day. To say nothing of many competing demands that folks at the director or higher level have on them. Writing code, or telling an AI how to write code, is one thing. Thinking about what the company looks like in one year or five, how to bring different teams together, how to manage investors and understand the market, and how to keep every department rowing in the same direction: that’s a tremendously difficult job. This book is an accessible narrative of those tensions, to which I don’t think new or even mid-career developers usually get exposure. So go check it out. Did I mention it’s free on Kindle through July 20th? Balki, thanks for writing this excellent, interesting fable of a software developer’s career. firing a team member multiple rounds of layoffs (and subsequent hiring) changing his understanding of the constraints and goals of the engineering org he is in

Business Career

▲ 0

0 views

Kev Quirk 3 weeks ago

I've Moved Back to GitHub

Back in May, I wrote a post about how I'd migrated all my repos away from GitHub. This ended up being a combination of my self-hosted Git server on my Synology (for my private repos) and Codeberg for my public ones. Well, since then Codeberg has just given me problem after problem. I had issues working with repos via SSH for weeks . It just kept timing out, or taking an age to actually do anything. So I switched to HTTPS instead, which seemed a little better, albeit still generally very slow. This morning I came to do a bit of work on some issues and PRs that have been logged against the Pure Comments repo and (unsurprisingly at this point), I was greeted with this: I've been trying to get to the repo for around 30 minutes now, and it just keeps failing. I can't work like this - I'm a busy guy, so when I do get time to work on these fun side projects, my shit needs to work. People give GitHub a hard time for outages, scraping, etc. but in all the years I've used it, I've never had an issue. It has always been quick, and it always worked. In my boredom while waiting for Codeberg to sort themselves out, I decided to peruse my RSS feeds and I came across this post by Sal . It seems he's been having similar problems with Gitlab. This was the final straw. I've had enough of battling with Codeberg, so I've switched back to GitHub. Some may not like this decision as Codeberg is generally considered the more community friends code hub, but I need to make a pragmatic choice here as the constant issues are sapping most the fun out of these projects. I'll continue to host my private projects on the Synology, as that works great. But as of right now, we're back on GitHub for all [my projects . I think I've caught all references to Codeberg across the various sites and docs (thanks to Gemini), but if you see a problem, please log an issue. There is 1 final update on Codeberg for both Pure Blog and Pure Comments. This points the updater back to GitHub, from then on, subsequent releases will be on GitHub. I'm bound to get some comments and suggestions about other options other than moving back to GitHub, so I'll try and hit them before you take the time to comment/email with recommendations: What about a self-hosted Forgejo instance? Absolutely not. I don't have time to maintain something like that. I'd rather spend my free time working on fun projects than managing infrastructure. But GitHub are really bad because of what about ? Nope, sorry. I don't want to use other platforms that potentially introduce the same issues I've been having with Codeberg. Look at Sal's post further up - he was on Gitlab and having similar problems to me. This is disappointing, are you sure about your decision? I'm very sure. It is disappointing, I agree. But I've given it a lot of thought over the last few weeks and I'd rather go with the tool that I know will work, than the one I have to battle with. Plus, this is all public code, so I don't think I'm giving anything away by switching back. I'll NEVER use GitHub. I'm gonna stop using now. That's a shame, but it's your call. 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 . What about a self-hosted Forgejo instance? Absolutely not. I don't have time to maintain something like that. I'd rather spend my free time working on fun projects than managing infrastructure. But GitHub are really bad because of what about ? Nope, sorry. I don't want to use other platforms that potentially introduce the same issues I've been having with Codeberg. Look at Sal's post further up - he was on Gitlab and having similar problems to me. This is disappointing, are you sure about your decision? I'm very sure. It is disappointing, I agree. But I've given it a lot of thought over the last few weeks and I'd rather go with the tool that I know will work, than the one I have to battle with. Plus, this is all public code, so I don't think I'm giving anything away by switching back. I'll NEVER use GitHub. I'm gonna stop using now. That's a shame, but it's your call.

Career Open Source Git

▲ 0

0 views