iDiallo Yesterday

Software Engineers are Obsolete

In my first interview for a developer position, I shared a link to my personal project with the interviewer. It was a website for learning how to program. I created it from the ground up. I built the PHP app, designed the database schema, made a nice design to tie it all together. I wrote down my process, and it became the first tutorial on the site. Then I collected tutorials from all over the web and displayed them on my website, which acted as a portal. There was a section for PHP tutorials, for Ruby on Rails, for .NET, etc. Each one individually curated by me. My interviewer was so impressed. I got the job. Later, I added a section where anyone could submit their own tutorials. It was fascinating how quickly people found my website and started submitting links. The tutorials were coming in so fast that I removed the verification system and let people upload links directly. But then my mind wandered. What if I start a blog? Yes, I had another blog before this one. I built an entire blog engine from scratch. A colleague found my blog. He was so excited that he shared his own with me. At lunch, we would discuss ideas, and that same evening after work, we would buy a domain name and start a new project. We shared tips and tricks on how to rank on Google. We had a skill, being web developers, and we took full advantage. When we had an idea, we would fire up our computers that same night and build it. Friends and family would come to us for validation. We were the ultimate deciders of what was a good idea and what was a bad one. We were the gatekeepers. We knew how to program, and nobody outside our circle could say otherwise. Now, friends and family don't come to us anymore. They go straight to ChatGPT, and it tells them their idea is brilliant . They launch their favorite AI agent, which builds their entire product from a single prompt. Some of them even manage to host it on the web, accessible to the world, and they are seeing their first customers. People who used to confuse Java with JavaScript now tell me they have a platform. People who don't even know what programming is are standing at the forefront of software innovation, advocating, evangelizing, and making money. This skill I spent years honing has been made obsolete by everyday people. We, the developers, are no longer the gatekeepers. In fact, now we need to keep up or risk being left behind. Some commenters online tell me I'm just jealous, that I need to embrace progress. I don't want to be obsolete. I'm on openclaw, moltenclaw. I have accounts on all the video generation websites. I have accounts on ChatGPT, Claude, Gemini, and Mistral. Just as I'm getting a hang of one tool, my friend who works in a warehouse tells me, "just use Perplexity for that." But Perplexity isn't enough, because another friend says GenSpark is better. For some reason I can't sign into my Manus account anymore. And apparently, to get the most out of it, I need to get Meta Ray-Bans. Everyone is empowered, no one needs me, and that's that. The developer is now obsolete. But then, I opened LinkedIn. My peers, fellow developers who for some reason all have the word "AI" in their job title, are saying the opposite. "Developers are not losing their jobs to AI," they say. "Developers are losing their jobs to other developers who use AI." They are vibe-coping to the max. The history of technology has always been a story of nearly missing out. I remember another job I applied for and totally didn't get. The company had moved all their client-facing apps to Silverlight. If you're wondering what Silverlight is, you might understand why I chuckled when the interviewer described their plight: they were struggling to find developers to help them migrate to HTML and JavaScript. I'm fairly sure that chuckle is why they never called me back. It's one thing to embrace new technology. It's another thing entirely to put all your eggs in one basket. Companies are betting everything on Silverlight. Sorry, I mean AI. Without thinking through what happens if things don't pan out. AI has lowered the barrier to entry. That's a good thing. More people can now bring a fresh pair of eyes to the software engineering field. But there's a problem. Those new entrants won't become better engineers over time. Why? Because they are not writing code, not reading code, not debugging code. Their growth path, with time and experience, is to become better prompters. What this means is that, amid all the noise, my role as a software engineer may seem obsolete. But in the long run, we will be back to square one, where engineers writing code with their own meatware will hold all the cards. These are the people who learned the hard way: by reading documentation, by debugging broken apps, by having their seemingly perfect Stack Overflow question closed as a duplicate. These are the engineers who will hold the keys to software. Not because they're guarding secrets, there are no secrets. It's simply that the new developer is not, and will never be, interested in learning. While we pride ourselves on producing more software than ever, it doesn't take long to realize that software is never truly finished at delivery. It has to be maintained. It's strange, computers whose entire purpose is to repeat the same process over and over, perfectly, somehow manage to degrade over time. My tutorial website, seemingly working fine, returned an error when I visited it after months of neglect. I restarted all the services and brought it back up. It was now full of spam and NSFW URLs. An application that worked perfectly yesterday is broken today. It could be a memory leak, unexpected input, or just users with fat fingers. Your completed application is suddenly incomplete, and you have to fix it. In an ideal world, we wouldn't keep producing more software. We would have working software, and less of it to maintain. AI thrives on quantity. If you need me, I'll be in the back, patiently waiting for you to realize you can't prompt your way out of a Silverlight migration. My rates just doubled.

HTML Career AI Web Development Java

ava's blog Yesterday

new challenges at work

In the past, I have complained about some aspects of my work here and there. As I continue to grow, get more qualifications, visit conferences, and apply to interesting positions, I've put more effort into transforming the place where I'm at, to the best of my abilities. I've repeatedly asked for more work, I've asked for different tasks, and I helped create a new role. Not replacing my current role and work, but something on top/on the side next to my core tasks. I needed change and something worth logging in or coming into the office for, and of course I wanted to pivot more into my desired field. That brings some new challenges, which are desired, but can be uncomfortable at first. Years of doing the same tasks with comparatively little cooperation and following repetitive processes never forced me to put a lot of thought into what I put out, so to say. That can be very nice, and in the beginning, it was hard enough learning everything and doing everything correctly. With my core work, no one asks me to create anything from scratch, make any decisions, or organize anything independently; it's all set in stone. If I wanted to, I could just spend years doing the work-equivalent of "minding my own business" and keeping my head down, in which I work off what came in that day based on our rigid standards and use fixed email templates (not even having to formulate my own sentences), nothing more, nothing less, unbothered. That's what I did for years as I got used to everything, and as I was very sick. But now, when I want to do more challenging work, I notice that years of working like this have made me very comfortable. Not lazy, but it feels unusual and slightly scary to suddenly have a more "active" part of work where I actually have to plan meetings, host and lead them, prepare slides, and even approach people first about needing to find time to discuss something together. Completely normal office tasks for others, of course, and it's what I wanted to not stagnate further in something that bores me, but my brain still perceives it as a threat. Due to internal restructuring and moving of employees, we lost our sub-department's IT coordinator 1 (each sub-department has to assign someone). I asked my boss if I could be the new one, and she agreed. Unfortunately, at least in our department, this title is more decorative than anything else, as the IT coordinators don't even have any meetings to discuss anything at all. This has generally worked fine enough, as in " we are surviving ", but now with different AI model rollouts and other software changes, I notice employees becoming more and more confused and helpless, and a more proactive approach would be nicer. When I asked my boss for permission to be one, I said I would like to organize a meeting of all coordinators to discuss some challenges and more, and both her and the department head thought this was a good idea and asked me to schedule one soon. I didn't expect how much this task would make me freeze up; I didn't wanna be the newcomer in a group who piles more work and yet another meeting onto the other people as a first move. So I obsessed over a good way to introduce this, and how to make the first meeting worth it. I didn't want everyone to show up, discover we have nothing to discuss, and leave after 5 minutes. The invitation mail should stress that this is just a first, casual meeting in which we will talk about x, y and z topic, and then determine whether this should happen again and in what frequency. I also kept pondering whether I should also already prepare a topic/mini-presentation to not come with empty hands myself as an organizer, and what that could be, putting a lot of pressure on finding something good enough. The final hurdle was that no one in my department apparently even had a full list of who the other coordinators are; had to research that myself somehow and ask around. All that made me put off scheduling anything for a good 3 weeks. Yesterday, I finally dealt with this mess, as the task became more and more pressing and uncomfortable to think about, threatening to become this huge anxiety beast strangling me. Detangled my feelings, set realistic expectations, and scheduled it to mid June to have a bit of time. At the same time, I am finally officially the data protection coordinator of my department. My work never had any before, no other department has one either. This is just my department wanting to lead by example, and admittedly, also accommodating me and my ambitions, as I have asked for this for months. Leadership up top has repeatedly thwarted my attempts to move into the data protection team, or officially implement coordinators house-wide, and refused to even discuss it or process it in the idea management system, so this is my little rebellion, you could say. Doing things from the bottom up. I have already prepared the slides they will use to announce it in the next department meeting and the meeting of all department heads. I will also have to prepare a short presentation about data protection challenges in our department, scheduled around Q3 or Q4 of 2026 as I need time to get an overview of everything. I'll have to meet up and interview a lot of people about their team's data workflows to see what needs to be adjusted, write some analyses, write deletion concepts, create awareness, ensure compliance, and more. I'll also be the person to go to before the data protection officer is getting involved. It's what I wanted, but internally it also makes me very nervous. I finally get to create things and success will be about the quality, not just that something was done; but it opens the door for thoughts about whether I am good enough or not. Merely following process steps as described makes it easy to just be a bot that gets things done; creating things yourself, sharing your own ideas and opinions exposes you as a person, makes you vulnerable. There are people working there that will finally see that there is a person with a brain underneath the years of automatically generated emails they received in my name. There is no one else to watch and learn from, as I am the only one, and I get to make things up as I go for this new role. I will be the blueprint, for now. There are horror scenarios in my head of not knowing something in a meeting and everyone thinking I am an impostor who doesn't really know anything. That's not how real life goes, of course, and everyone is usually understanding when you say " Sorry, I will have to look that up and get back to you about that. ", but you know how brains are. I'll have to learn from every meeting. I am scared of not doing a good job and doing it all a disservice. The culture is an aspect of it too, because unfortunately, my place has a reputation of not being kind to ambitious people, and many people being rather hostile if anything is asked of them - time, expertise, feedback, a change in routine, a little bit of grace; anything. There are also a few coworkers that have proven again and again that they are unable to view younger people or people lacking this or that university degree as worth taking seriously. That's what I will be up against, and my own harsh standards I have for myself. I'm trying to reassure myself that I have time to figure things out and that I need to make mistakes to improve. Reply via email Published 13 May, 2026 The IT coordinators' role at my workplace is to share IT knowledge around in all kinds of teams so it isn't just concentrated in specific areas, and to ensure everyone is up-to-date on internal policies, new software options and more. They're also a sort of first responder to task-specific tech problems in that specific team before annoying our general helpdesk. The communication of our IT department can be lacking, and not everyone has the time to keep on top of new things (like the sudden rollout of Copilot recently, new options available in Teams, etc.), so having these people "posted" in each sub-department to share news and developments was supposed to help that. ↩ The IT coordinators' role at my workplace is to share IT knowledge around in all kinds of teams so it isn't just concentrated in specific areas, and to ensure everyone is up-to-date on internal policies, new software options and more. They're also a sort of first responder to task-specific tech problems in that specific team before annoying our general helpdesk. The communication of our IT department can be lacking, and not everyone has the time to keep on top of new things (like the sudden rollout of Copilot recently, new options available in Teams, etc.), so having these people "posted" in each sub-department to share news and developments was supposed to help that. ↩

Career

DYNOMIGHT Yesterday

What’s with all the slide decks?

News from the world of real jobs: Apparently, sometime between 10 and 20 years ago, it became standard for people to communicate by sending slide decks around. These slides are never presented. They aren’t intended to be presented. They’re born, they’re sent around, and they die. What? I stress, the question is not why (or if) people give bad presentations . The mystery is why everyone is using presentation software for communication that is not a presentation. Is it because we’re all dummies? I’m putting this theory first because I suspect that you, beloved readers, will favor it. True, if you ask people why they make slides instead of writing, they’ll usually say, “because nobody wants to read”. So there’s that. But I don’t consider this much of an explanation. Dummies though we may be, we’ve been like that a long time. If we entered the Slideocene 15 years ago, why then? Why not before? Did we get worse at reading? The Discourse seems to have decided this is true, but is it true, or just moral panic? Since 1971, the US has tested 13-year-olds to measure long-term trends in reading ability. This shows a slow improvement until 2012, then a slow decline, and finally a post-COVID drop. The declines seem too small and too late to explain our mystery. Since 2000, PISA has tested reading performance in 15-year-olds around the world. This shows a decline on average, but it’s smaller in rich countries and nonexistent in the United States. (It’s the same story for science and a bit more negative for math .) Among adults, data is scarce. Basic literacy is generally improving , and American time use data shows a decline in reading for pleasure from around 23 minutes per day in 2003 to around 16 minutes per day in 2023. But this seems to miss time people spend reading on their phones. So it’s unclear if people got worse at reading. It feels plausible that people now spend less of their adulthood grappling with complex written arguments, and so got worse at that. But there’s little firm evidence. Another obvious theory is that we now have computers and software and the internet. Without these things, it would be impossible to email slides to each other. This seems relevant! Yes, but we had those things for a while before slide culture really took hold. And think about the situation before computers. Photocopiers were ubiquitous in corporate offices by the mid-1980s, and mimeographs were around decades before that. If slides were really that great, people could have made them by hand. But no one did. Of course, making slides by hand is inferior. But it’s not that inferior. So slides can’t be that big of a win. And… that’s pretty much the end of the obvious theories. None of them are very satisfying. So let’s take a step back. Historically, how did the slide-as-document displace the memo? As best I can tell, this was driven by management consultancies. If you go back to 1960, they delivered detailed written memos. The memo was the product. They’d likely give a presentation as well, but that was a separate ancillary thing, likely done using flipcharts or chalkboards. In the 1970s, the memo was still the product, but consultancies started to enforce a top-down logical structure (the Pyramid principle ). Presentations shifted to acetate transparencies. Both memos and presentations often included hand-drawn graphics like the nine-box or growth-share matrices. In the 1980s, the memo was still the product, but presentations became increasingly lengthy and polished. Expensive computers like the Genigraphics started to be used to generate charts. The 1990s were when things started to shift. By then, PowerPoint was everywhere, and junior analysts were expected to create presentations themselves. Consultancies gradually started to notice that (1) clients didn’t always read the memos; (2) clients loved slides and passed them around long after the presentation was over; and (3) creating a memo and a polished presentation was a lot of work. They put more and more effort into the slides. McKinsey especially evolved towards treating slides as the primary product, and mostly stopped writing long memos. Other consultancies followed. During the 2000s, slides became even more ornate. Consultancies evolved their formatting rules, and created fancy data-dense charts. They learned that a 200 slide deck made clients feel like they got a lot for their money. Gradually, they oriented their entire business around slides. Projects would start with managers creating a template presentation with “ghost slides” and assigning different parts to junior analysts. Soon, this spread outwards, both from people who interacted with consultants and from the ex-consultant diaspora. People everywhere started thinking and communicating in slides, and now everything is slides, yay! That story makes slides-as-documents sound inevitable: People liked them, so they became popular. But there’s an alternative timeline in which we resisted the slide into slide maximalism. That timeline is Amazon.com, Inc. In 2004, Jeff Bezos famously instituted a no-presentations policy at Amazon. His logic was that slides hide poor reasoning and are a tool to persuade rather than inform. Instead, everyone involved with strategic decisions at Amazon needs to learn to write a six-page memo. Meetings begin with everyone sitting and silently reading one of these memos. Presentation software is not banned at Amazon. The ban is only for using it for internal meetings and decision-making. They use slides for external communication. There is no policy that prohibits someone from making slides and emailing them around. And yet, people don’t make slides and email them around, because it’s not part of Amazon’s culture. In effect, Amazon is a counter-movement. Most of the world decided that slides are good, because slides are easy. Bezos decided that writing is good because writing is hard. There are millions of articles explaining why Bezos’ policy is pure genius. They claim that constructing a narrative requires deeper analytical thinking and exposes flaws in logic. I want to believe those theories. I now realize they’re very similar to some of my arguments for why writing with too much formatting is bad. I’m not sure if writing is the secret to Amazon’s success. But Amazon is successful. This demonstrates that slide life is a choice, not technological destiny—institutions can choose writing over slides and flourish anyway. Warning: If you like your theories simple and mono-causal, you aren’t going to like this. Slides are a win, but a small one. The shift to slides wasn’t a “mistake”, it happened because people like it. But if sharing slides outside of presentations became illegal, this wouldn’t cause per-capita GDP to crash. That’s why people didn’t scratch slides into mimeograph stencils back in the 1950s. It wasn’t worth the modest effort. When computers and software showed up, it became easier to share slides. But people didn’t immediately shift to slides-as-documents because the win isn’t that big, because culture changes slowly, and because everyone had pre-existing skills for reading and writing documents. Consultancies happened to be in the economic niche with the strongest selection pressure to evolve towards slides-as-documents. So when making slides became cheaper, they shifted. Slowly, that norm spread outwards, people got used to communicating in slides, and here we are. Institutions can resist that norm and still be successful. If you take modern people and force them to read and write, they do just fine. Humans evolved to learn and communicate in a fragmented, interactive, and visual style. It’s hard to argue that any shift in that direction is a catastrophe. Except blogs. The decline of the blog must be arrested.

Career Writing

Jim Nielsen 2 days ago

Building Software Requires Digestion

Here’s Scott Jenson in his insightful piece “The Ma of a New Machine” : the chatbot interface [makes us] feel like deep cognitive work is happening. But the interface is fundamentally reactive. It spits complex text at you, you skim it quickly, and you immediately type a reaction to keep the momentum going. My hypothesis is that the very structure of the chatbot interface (type, read, type again) actively discourages reflection. When you are moving too fast, you get stuck in a groove. You literally need to take a break, step back, and basically step out of this groove so you can view the problem from a new angle. We’ve all walked away from a tough problem only to have the solution arrive unbidden into our thoughts later in the day. In my decades+ experience designing and developing software, I can’t count the number of times I’ve stepped away from a problem at the computer only to return and find the problem magically resolved in my brain. But the human-computer interaction of prompting doesn’t encourage the use of that skill in our subconscious. In fact, I think it actively discourages it (our tools shape us). Scott talks about this Japanese concept called “Ma” which is about deliberately creating pauses between things. He quotes Studio Ghibli director Hayao Miyazaki who says “if you just have non-stop action with no breathing space at all, it’s just busyness.” Here’s Scott (emphasis mine): Ma provides a framework for understanding that a pause is not a lack of work As humans we need pauses. We need space to breathe. We need time to digest. Pausing, breathing, synthesizing, digesting — these are all necessary work . “Digestion” is an interesting word here. Putting food in your body is merely the beginning of feeding yourself. Our bodies must digest that food, break it down, absorb it, and get rid of the waste. But that’s all happening mostly without our attentive oversight, so I guess it’s not “real” work — right? Building good, healthy software requires digestion. Reply via: Email · Mastodon · Bluesky

Career Programming Design

matklad 2 days ago

Learning Software Architecture

In reply to an email asking about learning software design skills as a researcher physicist: I was attached to a bioinformatics lab early in my career, so I think I understand what you are talking about, the phenomenon of “scientific code”! My thoughts: First meta observation is that “software design” is something best learned by doing. While I had some formal “design” courses at the University, and I was even “an architect” for our course project, that stuff was mostly make-believe, kindergarteners playing fire-fighters. What really taught me how to do stuff was an accident of my career, where my second real project ( IntelliJ Rust ) propelled me to a position of software leadership, and made design my problem. I did make a few mistakes in IJ Rust, but nothing too horrible, and I learned a lot. So that’s good news — software engineering is simple enough that an inquisitive mind can figure it out from first principles (and reading random blog posts). Second meta observation, the bad news: Conway’s law is important. Softwaregenesis repeats the social architecture of the organization producing software. Or, as put eloquently by neugierig , If I were to summarize what I learned in a single sentence, it would be this: we talk about programming like it is about writing code, but the code ends up being less important than the architecture, and the architecture ends up being less important than social issues. I suspect that the difference you perceive between industrial and scientific software is not so much about software-building knowledge, but rather about the field of incentives that compels people to produce the software. Something like “my PhD needs to publish a paper in three months” is perhaps a significant explainer? Two things you can do here. One , at times you get a chance to design or nudge an incentive structure for a project. This happens once in a blue moon, but is very impactful. This is the secret sauce behind TIGER_STYLE , not the set of rules per se, but the social context that makes this set of rules a good idea. Two , you can speedrun the four stages of grief to acceptance. Incentive structure is almost never what you want it to be, but, if you can’t change it, you can adapt to it. This is also true about most industrial software projects — there’s never a time to do a thing properly, you must do the best you can, given constraints. Let me use rust-analyzer as an example. The physical reality of the project is that it’s simultaneously very deep (it’s a compiler! Yay!) and very wide (opposite to an LLM, a classical IDE is a lot of purpose-built special features). The social reality is that “deep compiler” can attract a few brilliant dedicated contributors, and that the “breadth features” can be a good fit for an army of weekend warriors, people who learn Rust, who don’t have sustained capacity to participate in the project, but who can sink an hour or two to scratch their own itch. My insistence that doesn’t require building , that it builds on stable, that it doesn’t have any C dependencies, and that the entire test suite takes seconds, was in the service of the goal of attracting high-impact contributors. I was wrangling the build system to make sure people can work on the borrow checker without thinking about anything else. To attract weekend warriors, the internals of rust-analyzer are split into multiple independent features, where each feature is guarded by at runtime. The thinking was that I explicitly don’t want to care too much about quality there, that the bar for getting a feature PR in is “happy path works & tested”. It’s fine if the code crashes, it will only attract further contributors, provided that: In contrast, when working on the core spine which provided support for features, I was very relatively more pedantic about quality. A word of caution about adapting to, rather than fixing incentive structure — the future is uncertain, and tends to happen in the least convenient manner. The original motivation behind rust-analyzer experiment was to avoid the need to write a parallel compiler (the one in IntelliJ Rust), and to prototype a better architecture for LSP, so that the learnings could be backported to . So, even in core (especially in core), the code was very experimental. Oh well. Stuck with one more compiler now, I guess? I might hazard a guess that something similar happened to uutils project, which started as the primary destination for people learning Rust, and ended up as Ubuntu coreutils implementation. Third , now to some concrete recommendations. Sadly, I don’t know of a single book I can recommend which contains the truths. I suspect one can only find such a book in an apocryphal short story by Borges: practice seems to be an essential element here. But here are some things worth paying attention to: Boundaries talk by Gary Bernhardt is all-time favorite. It contains solid object-level advice, and, for me, it triggered the meta inquiry. How to Test is something I wish I had. I immediately understood the importance of testing, but it took me a long time to grow arrogant enough to admit that most widely-cited testing advice is shamanistic snake-oil, and to conceptualize what actually works. ∅MQ guide and, more generally, writings by Pieter Hintjens introduced me to Conway’s Law thinking. That “feature development” architecture of rust-analyzer? – optimistic merging , applied. Reflections on a decade of coding by Jamii is excellent, goes very meta. It is intentionally the first of my links . Ted Kaminski blog is the closest there is to a coherent theory of software development, appropriately framed as a set of notes to a non-existing book! As for the actual books, Software Engineering at Google and Ousterhout’s The Philosophy of Software Design are often recommended. They are good. SWE, in particular, helped me with a couple of important names . But they weren’t ground breaking for me. the quality is isolated to a feature, and doesn’t spill over, at runtime, the crash is invisible to the user (it’s crucial that rust-analyzer features work with an immutable snapshot, and can’t poison the data).

Programming Rust Career

ava's blog 3 days ago

a little note on the choices we make

When I think something is bad, immoral, unethical, harmful, evil - or whatever may apply - I neither do it in private or in public. I don’t just adhere to this rule of not doing it when I’m by myself, I also don’t do it when I’m with others, regardless of whether they might do that thing and would think it’s more comfortable for them when I partake as well. That’s what’s at the core of living within my own moral boundaries and values. Yes, it might be difficult at times or offend people, but at least I neither feel like a hypocrite nor a coward. I stay true to myself and my behavior aligns with what I expect from myself and how I wish others lived. I cannot force anything they don’t want on them, but I can lead by example and enforce my own boundaries. Do what you want, but I will not do it. You compromising on your understanding of what’s right and wrong simply to appease others and not stand out is sad. You are betraying yourself and what you stand for for very little, temporary gain, and you rob others of being challenged and inspired. It also makes me wonder if you really stand behind what you preach; if you truly think something is cruel and unacceptable, you would not try to find loopholes to still keep doing that thing, and then pointing fingers as to who made you do it or what exception counts. No more excuses pointing at what others are doing, how your behavior has no impact and how hopeless or hard it is. Hard things are worth doing. It’s time that you show some respect to yourself and stop putting off making some decisions and sticking to them. Your trust in yourself erodes when you keep making promises to yourself you don’t keep. Aren’t you fucking sick of seeing other people live the way you want to? You don’t have to feel inadequate, guilty, jealous or like a hypocrite in their presence. You can avoid feeling like you have to justify yourself if you commit even for just a month and go from there. Take inspiration from the people you admire and ask them for help. Find your own path that’s similar to theirs if that’s what works. You made yourself do that. Take someone accountability for your actions. You have a choice every time. Reply via email Published 11 May, 2026

Career Writing

Ludicity 4 days ago

The Worlds Left To Conquer

It has been a year and a half since I quit my job to start a consultancy. It took me years to build up to quitting, and I had not only a chip on my shoulder, but to quote Seth Sentry, “the guac and the dip and the salsa.” The people that read this blog probably understand what I’m talking about. I looked around at how organizations are run, at the people that told me what to do, and thought “Surely I could do a better job than this.” This feels like a dangerous train of thought. On one hand, that arrogance is precisely one of the mechanisms that makes someone incompetent. If you’ve learned everything, there’s no real reason to open up another book, and even that is rather generously assuming that the person providing a service to you has bothered to crack the spine on even one . On the other hand, how else are we to make sense of the world? If you walk out the door, you will be immediately clotheslined by institutions failing to achieve the most basic of tasks with any reliability. Almost every office I’ve walked into as an employee has been a decrepit nest populated by the beaten-down working class, a sickly ooze of self-important managers amongst whom a Gladwell reader ranks as a towering intellect, and executives that are feverishly muttering the word “AI” to credulous journalists as they blindly cut headcount. So many of these institutions seem to be held together by either regulatory capture or writhing clients bound by enterprise contracts like so much barbed wire. I’ve lost track of the number of times that someone has looked at work from a company like KPMG and gone “Ha ha ha, maybe we should all be consulting – then we can do terrible work and bill at two thousand dollars a day.” This joke is so overused that you can see the person saying it is reluctantly dispensing the cliché. So when I kicked off the company, some traitorous part of me was hoping that it would be difficult, as horrible as that would be for me personally. If it was hard, yes, perhaps I’d have to go back to some miserable office and be beset on all sides by smiling imbeciles talking about innovation, but it would make sense . It simply can’t be that easy to be free of those structures. Surely there’s a reason for it that isn’t simply “Wow, we’re systematically producing people that are terrible at their jobs and they can’t even see it.” Unfortunately, that really is most of the explanation. In late 2025, I said I’d write more after admitting how awkward it is to say the business is going well. I haven’t written anything for five months, and there’s no delicate way to put this, I drastically understated how well we’re doing. I'm ripping off the bandaid: in February 2026, I realised that we had already generated enough revenue to last us until 2027. On some engagements, I split my income several ways with teammates that weren’t on the job and still exceeded my corporate salary. For forty hours in 2025, I broke a thousand dollars an hour on tasks with measurable success metrics, an amount of money that would have seemed like some sort of sick joke two years ago, and both customers asked for a repeat engagement because the service quality was higher than what specialised firms were doing – I had spent about ten hours thinking about the engagement model. And we still have seven months left in the year. All of this is to say two things. The first, I’m not going to pretend that everyone would find it as easy as I do 1 , but it’s easy enough that basically anyone that can read both a book in software and the humanities will be fine. 2 The other is that this was all so easy that I’m going mad with boredom. Crept to their door, opened it slowly and tip-toed but, shit Somebody set the bar too low and I tripped over it Whoops, jumped up, tried to throw in a quick ultimate Just hopin' to scare 'em but, oh, it just killed both of 'em Bodies with slit throats on the linoleum I just throw 'em in dumpsters, the shit's appropriate Blue Shell , Seth Sentry I wish that I could say it was difficult to make things work. It would make sense of the world. I could have fun talking about going extremely overboard with machinations . The reality is that all of it, from service delivery to sales, has been more-or-less trivial. Closing and delivering a deal for twenty thousand dollars takes less time and energy than one sprint in a regular office. Nothing even feels high stakes – the global economy is so large that, for an efficient team, you can roll the sales conversation dice over and over until it turns up a 20. I personally blundered hundreds of thousands of dollars in sales over our first six months, and we’re fine . As a company, there are many things that I'd like to improve – it might sound silly given that we’re doing well and all our customers are happy (or lying to me), but the places where we're falling short of my expectations are extremely visible to me. By virtue of having a sizable following on this blog, I have extensive exposure to programmers that are better than me and people that are smarter than me. Every Thursday, I have a call with Efron Licht , and frankly I can scarcely grasp why someone that competent spends time talking to me 3 . The problem is that I’m not competing with Efron. If I was, I'd either have to study for five hours every day for the rest of my life, or shut the company down tomorrow. I’m competing with people that don’t have functional literacy. And it’s not just incompetence at programming, it’s everything. The world has phoned it in, leaving us with no pressure to push for excellence. Last year, I was unable to put clients on both Evidence and Prefect because the former failed to attend a sales meeting booked through their website and the latter failed to book a meeting after the ex-real estate agent they hired failed to actually schedule a meeting following outreach also through their website . Our (excellent) accounting team is Hales Redden , who managed my co-founder Jordan Andersen’s old physiotherapy business… because the people I tried in Melbourne don’t check their sales inbox. Our lawyer is reader Iain McLaren 4 because the firms I initially tried also don’t respond to their sales inbox . I cannot state this clearly enough – the bar is so low that it is hard to give people money . There are competent actors on the market, but at least in software, there are simply so few of them that you’re more likely to be allies than enemies. This was infuriating at first, comical later, and has now lapsed into depressing. As an employee, these people were an unending source of frustration, the same six-figure delinquents that would forget to renew my contracts when I was on a temporary visa. As an independent operator, they’re babies that have yet to develop executive function and I’m taking their candy. I’ll do it – candy is delicious and babies are weak – but it's hard to feel good about it after the thrill of being right wore off. Some days, I get to 5PM after pitching to fix a competitor's work, put my head in my hands, and go “There is no way you dumb motherfuckers can’t stand up a database. We’ve been on the moon. We’ve been on the fucking moon . There’s no way you dipshits cannot operate Google.” Nonetheless, there is money in my bank account and I’m in a house with three bedrooms, and we must all reckon with this dreadful portent. Is this it? I’m just going to stand up data platforms for the next forty years, a task so easy for us that we could do it drunk out of our minds, then die? As much as I enjoy having free time, the whole affair has been oddly unsatisfying. Every day, I wake up and feel like I’ve opted out of society. I don’t have the same problems as my peers anymore. Daily stand-up is a hazy memory that I remember with faint queasiness. And the very nature of consulting, even though we make the majority of our money on technical delivery rather than pure advice, is that we’re simply adding efficiency to clients. We’ve had the luxury of firing a few for bad vibes 5 , leaving us only with clients that we’re very happy to work with – but at the end of the day, they‘re doing the thing worth being proud of, and we’re simply an instrument. They do the admirable thing, and we make them better at it. It’s better than continuing to be an ultra-coward and getting paid to let people Do Scrum at me, but I dunno. Part of the reason that we’ve done so well to begin with is that we haven’t worried about scaling at all. I still think that is the obviously correct decision when you’re starting off and don’t want to take on debt. But at the same time, when a reader asks me if I’m hiring, my answer is essentially, “The whole business is designed for the team to be comfortable, and we didn’t build in the leeway to take care of other people.” My largest expenses outside of housing over the past year have been donations to a local writer’s group, Meridian Australis , and various bits to other causes, but this amounts to a few thousand dollars per year. I’m probably supposed to be content with that, but I’ve already quit my job, so what’s a bit more risk? Why am I always reading about unreflective narcissists and tedious bootlickers funding things? Why can’t the causes I care about have resources thrown at them without them having to contort their value systems for the money? At any rate, the passage is crystal clear in both cases: Alexander is not weeping in sorrow that there are no more throats to cut. This is not a picture of a man at the end of a career of world conquest; he’s at the beginning. “Look at all these throats—and I haven’t even cut one!” And Alexander Wept , Anthony Madrid We still run into problems all the time that aren’t solvable by simple efficiency – perverse incentives from sloppy legislation, places where buyers can’t understand enough to avoid exploitation, gambling companies run by vile degenerates, things that make me want to throw up. I am fully engaged with capitalism every day, and despite the fact that I’m winning for some definition of winning, much of it is grotesque. Sometimes I wonder whether I should have gone into medicine, like most of my family, but at the same time someone has to keep the databases running. So here’s what’s going to happen for now. We have seven months left in the year. Around the start of June, we’ll be done with our most complex work, and ready to try something new, where by “something new” I mean we’re going to pick some nerds (pejorative) and cut their throats. The area that we’ve picked out specifically is technical recruiting, if only because it is the most accessible area that is most densely populated with easy prey. It should take us a little bit to knock out a small platform 6 , then I’ll broadcast that here for readers to sign up. We’ve done some work in the space, and all I can say is that software recruiters are defenseless money piñatas incapable of serving the competent sectors of the market, and I am going to beat them with a large stick and then loot the wallets from their corpses. Is this it? I’m just going to stand up data platforms for the next forty years, a task so easy for us that we could do it smashed out of our fucking minds, then die? At a rough estimate, every time we place someone that would otherwise have had to go through the hellish experience of conventional recruiting, we could plausibly knock one individual recruiter out of the market because of their slim margins (due to all the incompetence), which will temporarily satisfy my never-ending lust for blood. Then we’re going to take that money and use it to knife someone else that's causing negligent misery, and funnel some of the excess into things we care about. If we do a really good job, I really believe we can meaningfully distort some section of the market, even if that’s just “Ugh, everyone knows you can't recruit software engineers in the A$180K band in Melbourne. Those Hermit Tech folks have destroyed all the margin and established themselves as supreme dictators, and also their CEO will bully you online if you do a bad job.” I’m going to commit economic violence for the next forty years, and get so good at it that we can do that smashed out of our minds, teach other people how to do it, then die, and some of you will pick up the work where we left off. I’ve had a sale for $100,000 fall through, and twenty minutes later said “Easy come, easy go” and moved on with my life. I’m sure this is trainable, but I can’t take credit for this because I think I’m just a weirdo.  ↩ It is unbelievable how much of a competitive advantage “Responds to emails from paying clients within 24 hours” is. The bar is subterranean.  ↩ Incidentally, the two largest influences on my company’s culture are Jesse Alford and Efron Licht, on team culture and programming fundamentals respectively. I don’t think Jesse has written anything particularly friendly for mass-consumption, but Efron has an amazing series called Starting Systems Programming that has been transformative for my practice. It might seem obvious to some of the most talented programmers in the audience, but I cannot recommend it highly enough for everyone else. If you enjoy it, I’m sure he’d get a huge kick out of an email, as I don’t think he has analytics. I’ll do a writeup on all my influences at some point, as the list is long and they all write quite a bit.  ↩ Certified Cool Dude, by the way.  ↩ To no one’s surprise, they’re mostly startups.  ↩ Think “limited window for candidate signups and extreme pickiness about employers, no CVs, and a hard limit on interview stages, and so on”, not Seek. I don’t think Seek has done anything wrong , they’re just the inevitable result of the state of letting the entire market use their service.  ↩ I’ve had a sale for $100,000 fall through, and twenty minutes later said “Easy come, easy go” and moved on with my life. I’m sure this is trainable, but I can’t take credit for this because I think I’m just a weirdo.  ↩ It is unbelievable how much of a competitive advantage “Responds to emails from paying clients within 24 hours” is. The bar is subterranean.  ↩ Incidentally, the two largest influences on my company’s culture are Jesse Alford and Efron Licht, on team culture and programming fundamentals respectively. I don’t think Jesse has written anything particularly friendly for mass-consumption, but Efron has an amazing series called Starting Systems Programming that has been transformative for my practice. It might seem obvious to some of the most talented programmers in the audience, but I cannot recommend it highly enough for everyone else. If you enjoy it, I’m sure he’d get a huge kick out of an email, as I don’t think he has analytics. I’ll do a writeup on all my influences at some point, as the list is long and they all write quite a bit.  ↩ Certified Cool Dude, by the way.  ↩ To no one’s surprise, they’re mostly startups.  ↩ Think “limited window for candidate signups and extreme pickiness about employers, no CVs, and a hard limit on interview stages, and so on”, not Seek. I don’t think Seek has done anything wrong , they’re just the inevitable result of the state of letting the entire market use their service.  ↩

Career Shell Business

Sean Goedecke 5 days ago

AI makes weak engineers less harmful

Like other kinds of puzzle-solving, software engineering ability is strongly heavy-tailed. The strongest engineers produce way more useful output than the average, and the weakest engineers often are actively net-negative: instead of moving projects along, they create problems that their colleagues have to spend time solving. That’s why many tech companies try to build a small, ludicrously well-paid team instead of a large team of more average engineers, and why so far this seems to be a winning strategy. Being effective in a large tech company is often about managing this phenomenon: trying to arrange things so that the most competent people land on projects you want to succeed, and the least competent are shunted out of the way 1 . For instance, if you’re technical lead on a project, you more or less have to ensure 2 that the most critical pieces are in the hands of people who won’t screw them up (whether by directly assigning the work, or by making sure someone can “sit on the shoulder” of the engineer who you’re worried about). Claude Code changed this. Frontier LLMs don’t have the taste or the system familiarity of a strong engineer, but they have absolutely raised the floor for weak engineers. Instead of getting a pull request that could never possibly work or would cause immediate problems, the worst you’ll now see is a standard LLM pull request: wrong in some ways, baffling in others, but at least functional on the line-by-line level and not so obviously incorrect that someone with no knowledge of the codebase could point it out. That is a huge improvement! You can try this out yourself. If you attempt to deliberately make mistakes while working with a coding agent, you’ll find that the agent pushes back hard against many obvious errors (i.e. caching user data with a non-user-specific key, writing an infinite loop that might never terminate, or leaking open files). Of course, the agent will still miss subtle errors, particularly ones that require understanding other parts of the codebase. Working with the least effective engineers is now sometimes like working with a Claude Opus or Codex instance that you communicate with over Slack. Occasionally it’s literally that: your colleague is simply pasting your messages into Claude Code and pasting you the response. This is annoying, but it’s a much better experience than working with this kind of engineer directly. After all, you probably already work with a bunch of LLM instances. The Slack interface is not ideal - unlike using Claude Code directly, you sometimes wait hours or days for a response, and you don’t get visibility into the agent’s thought processes - but it’s still helpful on the margin. More compute being thrown at your problem is better than less. Of course, this isn’t a great state of affairs for the engineer in question, who is almost certainly learning less than if they were making their own (bad) decisions. It’s also a bad state of affairs for the company, who is paying a human salary and getting a Copilot subscription (which they’re likely also paying for) 3 . After the current push to figure out what value AI is adding to engineers, I suspect there will be a push to figure out what value engineers are adding to AI , and the engineers who aren’t adding much may find themselves out of a job. You can’t talk to Claude-over-Slack like you’d talk to normal Claude. If you tend to handle LLMs roughly (insulting them, or just being very curt), you’ll have to change your communication style. A human is going to read your messages, after all, even if you’re really interacting with a LLM. There’s no point being rude. But if, like me, you say please-and-thank-you to the models 4 , you can treat your LLM-using coworker as just another Copilot window or Codex tab. It’s far better than having to treat them as an unwitting saboteur. Not all net-negative engineers use AI tools like this. Many are strongly convinced in their own wrong opinions about how to build good software, or mistrust AI in general, or believe that relying heavily on LLMs is not a good way to improve 5 . But no strong engineers use AI tools like this. Even when they’re being lazy or sloppy, a capable engineer will have enough baseline taste to catch obvious AI-generated errors. So the phenomenon of engineers 6 becoming thin wrappers around Claude Code is limited to the kind of engineers for whom this is an improvement in their work product. More charitably: many “least competent” engineers are just out of their comfort zone, and can be fine or even excel under the right circumstances (though in my view the best engineers are able to do good work in a wide variety of environments). Also, I don’t currently work with a lot of incompetent people. Much of this is based on past experience or talking to other engineers in the industry. Since your managers are doing the same thing, this can sometimes feel like Moneyball: you’re trying to identify underappreciated talent who are strong enough to help you win without being so high-profile that your boss poaches them to lead something else. I suppose it’s better to pay for nothing than to pay for net-negative output, but it still doesn’t seem good . I think this is actually the right way to hold Claude Opus 4.7. Is this true? I think relying on LLMs is not a great way for most engineers to improve, but if LLM output is consistently better than your own, it might be different. So long as you’re paying attention to where the LLM does better, it could actually be a good way to learn. I don’t have as much experience (or anecdotes) about non-engineers falling into this trap, but this post has convinced me that it might be worse. More charitably: many “least competent” engineers are just out of their comfort zone, and can be fine or even excel under the right circumstances (though in my view the best engineers are able to do good work in a wide variety of environments). Also, I don’t currently work with a lot of incompetent people. Much of this is based on past experience or talking to other engineers in the industry. ↩ Since your managers are doing the same thing, this can sometimes feel like Moneyball: you’re trying to identify underappreciated talent who are strong enough to help you win without being so high-profile that your boss poaches them to lead something else. ↩ I suppose it’s better to pay for nothing than to pay for net-negative output, but it still doesn’t seem good . ↩ I think this is actually the right way to hold Claude Opus 4.7. ↩ Is this true? I think relying on LLMs is not a great way for most engineers to improve, but if LLM output is consistently better than your own, it might be different. So long as you’re paying attention to where the LLM does better, it could actually be a good way to learn. ↩ I don’t have as much experience (or anecdotes) about non-engineers falling into this trap, but this post has convinced me that it might be worse. ↩

Programming AI Career

Simon Willison 1 weeks ago

Vibe coding and agentic engineering are getting closer than I'd like

I recently talked with Joseph Ruscio about AI coding tools for Heavybit's High Leverage podcast: Ep. #9, The AI Coding Paradigm Shift with Simon Willison . Here are some of my highlights, including my disturbing realization that vibe coding and agentic engineering have started to converge in my own work. One thing I really enjoy about podcasts is that they sometimes push me to think out loud in a way that exposes an idea I've not previously been able to put into words. A few weeks after vibe coding was first coined I published Not all AI-assisted programming is vibe coding (but vibe coding rocks) , where I firmly staked out my belief that "vibe coding" is a very different beast from responsible use of AI to write code, which I've since started to call agentic engineering . When Joseph brought up the distinction between the two I had a sudden realization that they're not nearly as distinct for me as they used to be: Weirdly though, those things have started to blur for me already, which is quite upsetting. I thought we had a very clear delineation where vibe coding is the thing where you're not looking at the code at all. You might not even know how to program. You might be a non-programmer who asks for a thing, and gets a thing, and if the thing works, then great! And if it doesn't, you tell it that it doesn't work and cross your fingers. But at no point are you really caring about the code quality or any of those additional constraints. And my take on vibe coding was that it's fantastic, provided you understand when it can be used and when it can't. A personal tool for you, where if there's a bug it hurts only you, go ahead! If you're building software for other people, vibe coding is grossly irresponsible because it's other people's information. Other people get hurt by your stupid bugs. You need to have a higher level than that. This contrasts with agentic engineering where you are a professional software engineer. You understand security and maintainability and operations and performance and so forth. You're using these tools to the highest of your own ability. I'm finding the scope of challenges I can take on has gone up by a significant amount because I've got the support of these tools. But I'm still leaning on my 25 years of experience as a software engineer. The goal is to build high quality production systems: if you're building lower quality stuff faster, I think that's bad. I want to build higher quality stuff faster. I want everything I'm building to be better in every way than it was before. The problem is that as the coding agents get more reliable, I'm not reviewing every line of code that they write anymore, even for my production level stuff. I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it's just going to do it right. It's not going to mess that up. You have it add automated tests, you have it add documentation, you know it's going to be good. But I'm not reviewing that code. And now I've got that feeling of guilt: if I haven't reviewed the code, is it really responsible for me to use this in production? The thing that really helps me is thinking back to when I've worked at larger organizations where I've been an engineering manager. Other teams are building software that my team depends on. If another team hands over something and says, "hey, this is the image resize service, here's how to use it to resize your images"... I'm not going to go and read every line of code that they wrote. I'm going to look at their documentation and I'm going to use it to resize some images. And then I'm going to start shipping my own features. And if I start running into problems where the image resizer thing appears to have bugs or the performance isn't good, that's when I might dig into their Git repositories and see what's going on. But for the most part I treat that as a semi-black box that I don't look at until I need to. I'm starting to treat the agents in the same way. And it still feels uncomfortable, because human beings are accountable for what they do. A team can build a reputation. I can say "I trust that team over there. They built good software in the past. They're not going to build something rubbish because that affects their professional reputations." Claude Code does not have a professional reputation! It can't take accountability for what it's done. But it's been proving itself anyway - time and time again it's churning out straightforward things and doing them right in the style that I like. There's an element of the normalization of deviance here - every time a model turns out to have written the right code without me monitoring it closely there's a risk that I'll trust it at the wrong moment in the future and get burned. It used to be if you found a GitHub repository with a hundred commits and a good readme and automated tests and stuff, you could be pretty sure that the person writing that had put a lot of care and attention into that project. And now I can knock out a git repository with a hundred commits and a beautiful readme and comprehensive tests of every line of code in half an hour! It looks identical to those projects that have had a great deal of care and attention. Maybe it is as good as them. I don't know. I can't tell from looking at it. Even for my own projects, I can't tell. So I realized what I value more than the quality of the tests and documentation is that I want somebody to have used the thing. If you've got a vibe coded thing which you have used every day for the past two weeks, that's much more valuable to me than something that you've just spat out and hardly even exercised. If you can go from producing 200 lines of code a day to 2,000 lines of code a day, what else breaks? The entire software development lifecycle was, it turns out, designed around the idea that it takes a day to produce a few hundred lines of code. And now it doesn't. It's not just the downstream stuff, it's the upstream stuff as well. I saw a great talk by Jenny Wen , who's the design leader at Anthropic, where she said we have all of these design processes that are based around the idea that you need to get the design right - because if you hand it off to the engineers and they spend three months building the wrong thing, that's catastrophic. There's this whole very extensive design process that you put in place because that design results in expensive work. But if it doesn't take three months to build, maybe the design process can be a whole lot riskier because cost, if you get something wrong, has been reduced so much. When I look at my conversations with the agents, it's very clear to me that this is moon language for the vast majority of human beings. There are a whole bunch of reasons I'm not scared that my career as a software engineer is over now that computers can write their own code, partly because these things are amplifiers of existing experience. If you know what you're doing, you can run so much faster with them. [...] I'm constantly reminded as I work with these tools how hard the thing that we do is. Producing software is a ferociously difficult thing to do. And you could give me all of the AI tools in the world and what we're trying to achieve here is still really difficult. [...] Matthew Yglesias, who's a political commentator, yesterday tweeted , "Five months in, I think I've decided that I don't want to vibecode — I want professionally managed software companies to use AI coding assistance to make more/better/cheaper software products that they sell to me for money." And that feels about right to me. I can plumb my house if I watch enough YouTube videos on plumbing. I would rather hire a plumber. On the threat to SaaS providers of companies rolling their own solutions instead: I just realized it's the thing I said earlier about how I only want to use your side project if you've used it for a few weeks. The enterprise version of that is I don't want a CRM unless at least two other giant enterprises have successfully used that CRM for six months. [...] You want solutions that are proven to work before you take a risk on them. You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options .

AI Programming Career JSON Sql

Martin Fowler 1 weeks ago

Bliki: Mythical Man Month

In the early 1960s, Fred Brooks managed the development of IBM's System/360 computer systems. After it was done he penned his thoughts in the book The Mythical Man-Month which became one of the most influential books on software development after its publication in 1975. Reading it in 2026, we'll find some of it outdated, but it also retains many lessons that are still relevant today. The book contains Brooks's law: “Adding manpower to a late software project makes it later.” The issue here is communication, as the number of people grows, the number of communication paths between those people grows exponentially. Unless these paths are skillfully designed, then work quickly falls apart. Perhaps my most enduring lesson from this book is the importance of conceptual integrity I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. He argues that conceptual integrity comes from both simplicity and straightforwardness - the latter being how easily we can compose elements. This point of view has been a strong influence upon my career, the pursuit of conceptual integrity underpins much of my work. The anniversary edition of this book is the one to get, because it also includes his even-more influential 1986 essay “No Silver Bullet”.

Programming Career Books

Sean Goedecke 1 weeks ago

Why I don't like the "staff engineer archetypes"

The most influential piece of writing about staff engineers in the last decade has to be Will Larson’s Staff engineer archetypes . He argues that the “staff engineer” title covers at least four very different roles: the team lead, the architect, the solver, and the right hand. This taxonomy gets cited a lot as advice for people who are trying to become effective staff engineers. For both of my promotions to staff engineer, my manager at the time linked me to the “staff engineer archetypes” and asked me to consider which of these archetypes I was aiming towards. These archetypes definitely exist 1 . However, I think it’s bad practical advice to tell engineers to try and target them. To see why, let’s take the “team lead” archetype. Larson describes this as an informal technical leadership role: not necessarily an explicit authority figure, but someone who’s good at scoping work, planning projects, and maintaining the kind of relationships (e.g. with other teams) needed to successfully ship . If you want to fill this role, shouldn’t you start trying to do these things? No! You don’t become a technical leader by trying really hard to be a technical leader, much like you don’t become a writer by trying really hard “to be a writer”. You become a technical leader by doing good technical work until your skills and relationships emerge organically. I wrote about this process in Ratchet effects determine engineer reputation at large companies . To get good at shipping large complex projects, you must start by shipping tiny pieces of work, until you’re familiar enough with the system and you’ve built enough trust to take on slightly larger pieces. At each stage, if you do good work - “good work” here means “deliver shareholder value ” - you will very naturally be given opportunities to work on more complex and important things. If you try to jump ahead, you’re going to run into all kinds of problems: The other archetypes are like this as well. If you want to become a successful architect, you do not get there by studying software architecture in the abstract, because you can’t design software you don’t work on . The “solver” and “right hand” archetypes both rely on having an enormous amount of trust and influence. You can’t aim for those archetypes directly, because trust and influence accumulate over time. In fact, the idea of “aiming for” a particular staff engineer archetype reflects a misunderstanding of what the staff engineer role is. What is the defining attribute of the staff engineering role, then? A staff engineer has to be useful to the company. Of course, a senior or mid-level software engineer ought to be useful too, but all they have to do is execute on the job in front of them. If they end up not providing value (maybe their project turns out to be unimportant, or they don’t get the support needed to succeed) that’s their manager’s problem, not theirs 3 . In contrast, staff engineers are expected to deliver value regardless: to make the project work, or to find something else useful to do if the project truly can’t be salvaged. This is an unfair expectation. Often projects really do fail through no fault of your own, and sometimes it just isn’t possible to conjure useful work from thin air. That’s actually by design: the staff engineer role is supposed to be unfair . Something many engineers don’t realize is that all senior management and executive leadership roles are unfair too, in the same way. That’s just part of the deal: executives are given power and great compensation, and in return they get thrown off the boat in bad weather 4 . “Staff engineer” is the first engineering role where you are held largely responsible for outcomes you don’t control. Developing a “staff engineer mindset” thus has very little to do with the archetypes. Instead, you should: At the beginning, you won’t look much like any of the staff engineer archetypes. You will look like being a level-headed engineer who can be trusted to move projects forward with a minimum of fuss, and who can be re-tasked to different work without complaining. You’ll also look like someone who’s paying a lot of attention to what their manager’s actual priorities are, and who is thinking hard about how to fulfil those priorities (instead of their own goals). If you do this for long enough, you’ll eventually find yourself in one of the staff engineer archetypes. However, it probably won’t be the one you’re “aiming for”. The whole point of being a staff engineer is that you’re willing to fill whatever archetype the company needs at the time. In his original staff engineer post, Larson is pretty clear that these archetypes are more of an anthropological description of some of the varied niches staff engineers fill, not a how-to guide for succeeding in the role 5 . At the time, the “staff engineer” role was fairly new and people were still trying to figure out what it even meant. Pointing out that there were a few very different ways to succeed in the role was a genuinely novel observation. The staff engineer archetypes are a good list of ways an engineer can be very useful to their organization - but only once they’ve built a deep relationship of trust with their organization’s leadership. Advice on how to succeed as a staff engineer should be about how to build that trust , not about what to do once you have it. One caveat that is too pedantic for the body of the post: each tech company has a different structure of roles. Some don’t have the formal “staff” title at all, while others have “staff” as a fairly early rung on the ladder and a panoply of “senior staff”, “senior principal staff”, and so on roles above it. Like all “staff engineer” discourse, this post is not about the word itself but about the point in the engineering job ladder where progression becomes significantly more difficult. Impressing your VP’s trusted lieutenants can actually be a good way to build trust in the medium-term, but you’d better hope you’ve built enough understanding of the system to do it right. If this process goes badly, your reputation in the org might be torched for years. In theory, at least. In practice it’s always better to be useful (again, in the sense of “delivering shareholder value”). This is why very senior leadership sometimes seem so unempathetic towards engineering complaints: their work environment operates by very different rules and norms to that of most engineers. I keep meaning to try and write about this and never succeeding. This draft is the closest thing I have to a deeper exploration of the point. For the record, my how-to guides are here and here . Important projects are usually assigned top-down, not bottom-up, so you’ll either be trying to muscle out the planned engineering lead for a project or to pitch your own (complex, important) engineering task to senior management. Either way, good luck with that! You likely won’t have a good enough relationship with senior management to know what their real priorities are. If you’re not yet trusted to execute, you may get assigned “minders” (often current staff engineers) who will ghost-lead the project through you 2 . You’ll likely make poor technical decisions . Develop the habit of constantly asking yourself “is this useful to the company” (and answering correctly). Lose the habit of worrying about if you’re being treated “fairly”. Instead, try to think about your role in terms of incentives and consequences. One caveat that is too pedantic for the body of the post: each tech company has a different structure of roles. Some don’t have the formal “staff” title at all, while others have “staff” as a fairly early rung on the ladder and a panoply of “senior staff”, “senior principal staff”, and so on roles above it. Like all “staff engineer” discourse, this post is not about the word itself but about the point in the engineering job ladder where progression becomes significantly more difficult. ↩ Impressing your VP’s trusted lieutenants can actually be a good way to build trust in the medium-term, but you’d better hope you’ve built enough understanding of the system to do it right. If this process goes badly, your reputation in the org might be torched for years. ↩ In theory, at least. In practice it’s always better to be useful (again, in the sense of “delivering shareholder value”). ↩ This is why very senior leadership sometimes seem so unempathetic towards engineering complaints: their work environment operates by very different rules and norms to that of most engineers. I keep meaning to try and write about this and never succeeding. This draft is the closest thing I have to a deeper exploration of the point. ↩ For the record, my how-to guides are here and here . ↩

Career

Thomasorus 1 weeks ago

AIDHD - AI coding workflow as an exclusion machine

I was recently diagnosed with an attention disorder with sustained attention issues, combined with planning and initiation difficulties. I favour quality over speed, which means it takes longer to do certain tasks, and the longer time spent on them increases fatigue exponentially. For a while I thought my inability to stay interested and accomplish tasks others could do in minutes was a lack of determination or character, a personality flaw. Learning that my brain is objectively bad at them was a huge relief. Unfortunately, reviewing code is among those difficult tasks, it demands a huge mental effort from me. I can write code for hours because I am the one doing it , and doing it delivers dopamine shots every few minutes, when I compile/refresh my page to see my changes. It keeps me focused and interested. But code reviewing? It's such a drag to me. It's long, non-interactive, boring, and worst of all it requires sustained attention due to the multiple parameters you have to take into account. That's not something you can botch, and so it fries my brain. Any distraction is an opportunity to stop, which drags it even longer. It's a vicious cycle. AI driven development, where the code is generated by the machine and reviewed by a human, will therefore never be compatible with my brain. If it becomes mandatory to work this way (as it is increasingly seems it will be), it will exclude not just me, but all other people with a similar neurodiversity. For a technology which is all about empowering people , I find this perspective ironic, even if unsurprising.

AI Career

iDiallo 1 weeks ago

Editing my LLM assisted Articles

Last year, I used AI to help me write articles. As I've mentioned before , it's convenient when you are doing so because it saves you time. But the problem comes up when you try to quote those articles back. Whatever you think you wrote is not what's in there. I always cringe when I read them back. As I've said before, I'm rewriting those articles so that they capture my voice, and so that I can actually quote the real thoughts I had in mind at the time of writing. I will show you exactly what the article looked like before and after. From prompt, to the final post, and the new edit. Prompt: Feb 4th, 2025 on DeepSeek I am writing a blog post, help me refine it . It should be a fun read that helps convince readers that building useless tools is part of the journey and career growth. Programmers don't use calculators, they build them and abandon them 3 quarters completed. The start of a project is always exciting. You have an brilliant idea, you have the skills to build it, and you have a blind spot. This blind spot propels you into a journey of excitement, setting up the project, deciding on frameworks, paying for AWS servers. You even get to test some of your ideas in a prototype version of your project. As you keep building the project, and resolving the low hanging fruits, you realize that it takes more than the CRUD part to bring your project to life. This is where we start making excuses. The clearer the blind spot gets, the more we lose interest. Resistance is the secret to creating a collection of abandoned projects. Early in my career, i found myself with a brand new life altering idea several times a week. My weekends were spent in front of a laptop, typing away on my IDE and testing an idea. I have to admit I often get distracted by creating meta code, like a ORM that should be ultra efficient, or a html parser that will allow me to use custom html tags that automatically render into components in real time. At the end, I have a robust framework with 3 quarters of an application that is getting less and less exciting. But this is not a warning call to tell you your idea sucks and shouldn't work on it. It's a confession to tell you that those useless projects are exactly how developers hone their skills. We are tricked into wanting to change the world by our own mind. But the result is that we end up learning new marketable skills. I wrote about the importance of kids playing before, it helps them hone physical skills that you can't learn from a book. You have to climb the monkey bar at the park to develop the strength of your arms. In that same way, we need to build 3 quarters of a calculator to learn how to properly compartmentalize your util functions DeepSeek "thought" for 38 seconds, and gave me a draft titled: "Why Building Useless Tools is the Secret Sauce of Developer Growth" . First Draft: Title: Why Building Useless Tools is the Secret Sauce of Developer Growth Hook: Programmers don’t use calculators—they build them, abandon them three-quarters finished, and then accidentally invent the next big thing while trying to fix a typo in the README. Every developer knows the rush: you’re struck by a “life-altering” idea (your 14th this week), and suddenly, you’re setting up repositories, debating frameworks, and buying AWS servers at 2 AM. The blind spot? You’re convinced this time, you’ll finish. Spoiler: You won’t. But that’s okay. “The first 90% of the project takes 10% of the time. The remaining 10% takes another lifetime.” —Ancient Developer Proverb (probably). That initial blind spot isn’t a flaw—it’s rocket fuel. It lets you ignore the boring bits (user auth, error handling, documentation ) and dive headfirst into the fun: prototyping wild features, inventing a “revolutionary” ORM named LazyLlama , or crafting custom HTML tags that’ll “change frontend development forever.” Sure, your enthusiasm fades faster than a free-tier server under load, but along the way, you’ve accidentally learned: - How to optimize database queries (to make LazyLlama slightly less slow). - Why shadow DOM exists (after your custom tag broke 14 legacy sites). As the blind spot clears, reality hits: your app needs more than CRUD and caffeine to survive. Suddenly, you’re procrastinating by rewriting config files or alphabetizing your npm dependencies. This resistance isn’t failure—it’s a teacher . Every abandoned project is a masterclass in: - Scope creep : “Wait, should the calculator also solve quantum physics?” - Tooling : “I spent 3 days building a CI/CD pipeline… for a todo app.” - Prioritization : “The login page can wait—let’s add animated emojis first.” Kids don’t climb monkey bars to “build upper body strength”—they do it because it’s fun. Likewise, developers don’t build half-finished tools to pad their résumés. We do it because playing with code is joyful . And just like kids, we walk away stronger: - That abandoned Twitter-for-Cats app taught you websockets. - The “ultra-efficient” ORM? Now you understand query optimization. - The calculator left at 75%? You’ve mastered state management… and humility. Your GitHub is a museum of “almosts,” and that’s beautiful . Every skeleton in your code closet taught you something. Remember: - Instagram started as a check-in app. - Slack was a gaming company’s side hustle. - Your Blockchain-Based Pet Rock project? It taught you smart contracts—and that not every idea needs to see daylight. The next time guilt whispers, “You never finish anything,” laugh in its face. You’re not failing—you’re iterating . The world needs developers who’ve climbed the mountain of “useless” projects, survived the valleys of tech debt, and lived to code another day. So go ahead: build that calculator. Abandon it at 75%. Then use what you learned to accidentally create something actually world-changing. Final Thought: The only thing better than a finished project? A dozen unfinished ones that turned you into a coding wizard. Call to Action: What’s your favorite abandoned project? Tag it #UselessButBrilliant and confess your coding sins. We’ve all got a LazyLlama in our closets. I've made some edits, asked to remove the headings, and this is what I got: Title: Why Building Useless Tools is the Secret Sauce of Developer Growth Programmers don’t use calculators—they build them, abandon them three-quarters finished, and then accidentally invent the next big thing while trying to fix a typo in the README. Every developer knows the rush: you’re struck by a “life-altering” idea (your 14th this week), and suddenly, you’re setting up repositories, debating frameworks, and buying AWS servers at 2 AM. The blind spot? You’re convinced this time, you’ll finish. Spoiler: You won’t. But that’s okay. That initial blind spot isn’t a flaw—it’s rocket fuel. It lets you ignore the boring bits (user auth, error handling, documentation ) and dive headfirst into the fun: prototyping wild features, inventing a “revolutionary” ORM named LazyLlama , or crafting custom HTML tags that’ll “change frontend development forever.” Sure, your enthusiasm fades faster than a free-tier server under load, but along the way, you’ve accidentally learned how to optimize database queries (to make LazyLlama slightly less slow) or why shadow DOM exists (after your custom tag broke 14 legacy sites). As the blind spot clears, reality hits: your app needs more than CRUD and caffeine to survive. Suddenly, you’re procrastinating by rewriting config files or alphabetizing your npm dependencies. This resistance isn’t failure—it’s a teacher . Every abandoned project is a masterclass in scope creep (“Wait, should the calculator also solve quantum physics?”), tooling (“I spent 3 days building a CI/CD pipeline… for a todo app”), and prioritization (“The login page can wait—let’s add animated emojis first”). Kids don’t climb monkey bars to “build upper body strength”—they do it because it’s fun. Likewise, developers don’t build half-finished tools to pad their résumés. We do it because playing with code is joyful . And just like kids, we walk away stronger. That abandoned Twitter-for-Cats app taught you websockets. The “ultra-efficient” ORM? Now you understand query optimization. The calculator left at 75%? You’ve mastered state management… and humility. Your GitHub is a museum of “almosts,” and that’s beautiful . Every skeleton in your code closet taught you something. Instagram started as a check-in app. Slack was a gaming company’s side hustle. Your Blockchain-Based Pet Rock project? It taught you smart contracts—and that not every idea needs to see daylight. The next time guilt whispers, “You never finish anything,” laugh in its face. You’re not failing—you’re iterating . The world needs developers who’ve climbed the mountain of “useless” projects, survived the valleys of tech debt, and lived to code another day. So go ahead: build that calculator. Abandon it at 75%. Then use what you learned to accidentally create something actually world-changing. The only thing better than a finished project? A dozen unfinished ones that turned you into a coding wizard. I've retitled it, removed the headings from the draft, edited it down, and published this version: Article Published on March 6th, 2025: Every developer knows the rush. You are driving and suddenly you’re struck by a “life-altering” idea (your 14th this week). At the next red light, you record an audio while driving, avoiding eye contact with what clearly looks like a cop’s car. At 2 AM, you wake abruptly remembering the recording. Now you’re setting up repositories, debating frameworks, and buying AWS servers in the middle of the night. The blind spot? You’re convinced this time, you’ll finish. Spoiler: You won’t. But that’s okay. Programmers don’t use calculators. They build them, abandon them three-quarters finished, and then accidentally invent the next big thing while trying to fix a typo in the README. That initial blind spot isn’t a flaw. It’s rocket fuel. It lets you ignore the boring bits (user auth, error handling, documentation) and dive headfirst into the fun: prototyping wild features, inventing a “revolutionary” ORM named LazyLlama, or crafting custom HTML tags that’ll “change frontend development forever.” Sure, your enthusiasm fades faster than a free-tier server under load, but along the way, you’ve accidentally learned how to optimize database queries (to make LazyLlama slightly less slow) or why shadow DOM exists (after your custom tag broke the browser's rendering engine). As the blind spot clears, reality hits: your app needs more than CRUD and caffeine to survive. Suddenly, you’re procrastinating by rewriting config files or alphabetizing your npm dependencies. This resistance isn’t failure. It’s a teacher. Every abandoned project is a masterclass in scope creep (“Wait, should the calculator also solve quantum physics?”), tooling (“I spent 3 days building a CI/CD pipeline… for a todo app”), and prioritization (“The login page can wait—let’s add animated emojis first”). Kids don’t climb monkey bars to “build upper body strength.” They do it because it’s fun. Likewise, developers don’t build half-finished tools to pad their résumés. We do it because playing with code is joyful. And just like kids, we walk away stronger. That abandoned Twitter-for-Cats app taught you websockets. The “ultra-efficient” ORM? Now you understand query optimization. The calculator left at 75%? You’ve mastered state management… and humility. Your GitHub is a museum of “almosts,” and that’s beautiful. Every skeleton in your code closet taught you something. Instagram started as a check-in app. Slack was a gaming company’s side hustle. Your Blockchain-Based Pet Rock project? It taught you smart contracts and that not every idea needs to see daylight. The next time guilt whispers, “You never finish anything,” laugh in its face. “You’ve got the wrong fellow,” you answer. You’re not failing, you’re iterating. The world needs developers who’ve climbed the mountain of “useless” projects, survived the valleys of tech debt, and lived to code another day. So go ahead: build that calculator. Abandon it at 75%. Then use what you learned to accidentally create something actually world-changing. The only thing better than a finished project? A dozen unfinished ones that turned you into a coding wizard. It sounds very much like any LLM, and I couldn't stand reading it. At the time, I was trying to save time with my heavy schedule of writing every other day for a whole year. But I ended with this. If you read it, it captures the idea I was trying to share. As far as being functional, it did exactly what it was supposed to do. But it wasn't my human experience with the subject. In my new edit, I've removed things that do not sound like me. Phrasings that are awkward to me. I'm happy with the result. It's not a banger, but it captures my sentiment on why developers build calculators. Read edited article here (May 1st 2026) It's the only way to learn

AI Writing Career HTML

Kev Quirk 1 weeks ago

Thoughts on Leaving GitHub

I've read a few posts about people leaving GitHub recently, and following my short note to the Fediverse a number of people have piped up saying they're not fans of GitHub, either. From the reading I've done, these frustrations are usually threefold: In all honesty, none of the factors above really bother me that much. I think that's because I don't rely on GitHub for anything significant. I'm not a professional software developer, so my livelihood doesn't depend on it. As for Copilot being trained on open source software, and them repeatedly ignoring the GPL to do so, it does irk me, but I kind of expect shit like this from Microsoft at this point. I went into using GitHub assuming that any code I upload there can (and probably will) be used for shitty stuff. But even that isn't enough in isolation to put me off GitHub. The way I see it is that public code is for the public, and if Microsoft want to use my code in that way, while not ideal, doesn't piss me off that much. So why think about moving at all? Well, for me it's about reliance on big tech. I'm trying to reduce it where possible, but the social and "centre of mass" aspects of GitHub are giving me pause. For example, the Simple.css repo has a whopping 5,000 stars! Do I really want to lose that visibility? Buuuuuuuuuut, I can always redirect any popular repos to another platform, just like I did with 512KB Club when I handed that to Brad . Plus, let's be honest, it's all just popularity bullshit. It doesn't really mean anything. What's important is that the code is readily available for people to use. It's like leaving Facebook - when I was thinking about it, I was worried if I'd miss my friends or be out the loop. It's been over a decade at this point and I don't miss it one bit - no regrets whatsoever. I think moving off of GitHub would be the same. I plan to slowly start migrating public repositories over to Codeberg so that all my projects are hosted there. I'll also use it as an opportunity to archive off any old repos that I no longer need. Codeberg also supports logging in with GitHub and Gitea, so anyone who contributes to my projects on GitHub, should be able to do so easily in Codeberg too. Then, for my private repos (of which there are many that host personal projects) I've installed Synology's Git server on my Synology, and have been playing with that for a few days. It works extremely well, so all my private repos will live there, safe and sound, away from Microsoft's greasy mitts. Ultimately it's personal choice. For me it's about reducing my reliance on big tech, but also making my private repos more private. I won't be deleting my GitHub account though, as I think it will be important to use as a marker for anyone who wants to find my source code when it moves. Have you thought about leaving GitHub? 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 . Microsoft ownership Microsoft training Copilot on open source software Large amounts of downtime

Open Source Career Business CSS

ava's blog 1 weeks ago

message to a friend / self-reflection

A few days ago, I wrote a reply to an email by my friend Cris, keeping each other updated about our lives after a few months of not hearing from another. Writing it really helped me realize some good changes and upcoming things to look forward to. A part of it that stuck out to me and that I felt like keeping here for posterity was this: [translated from German to English for the post] "I am getting much more involved in volunteer work this year than last year, and I generally say “yes” to things more often. This is also happening because I actively want to encourage myself to be more curious and to give things more of a chance. As a result, I’ve also taken on additional roles at work, had a job interview (it wasn’t a fit, but it was still great), and I’m attending workshops and conferences. I’m sort of trying to collect more “nos” as a challenge, but because I ask about more things and get involved, I end up getting more “yeses.” That’s nice too. " It can be easy to talk yourself out of things. This is too hard, this costs money, this takes too much energy, this doesn't look productive enough to other people, this is for people smarter than me, I am not good enough for this, no one will care, everyone will think this is cringe... the list goes on. But you actually grow when you just try things and aren't afraid to feel out of place or embarrassed. I feel much more unapologetic about where I am in life right now, and that I don't know certain things yet, or haven't yet tried this or that, or am not finished with certain things I am working on (like my degree). I am allowed to make mistakes despite trying my best. You can no longer shame me about these things. I also enjoy the processes more, rather than just yearning for the reward, or the moment at which I can say " I have done that ". I'm way more open to guidance, asking for help, seeking mentors, and for the first time, feel properly connected to hear about events and workshops that interest me and can sign up for. I am letting go of the mindset that I have to do it all on my own, and hide it until I am perfect. I keep learning that being hyper-independent, perfectionistic and afraid of feedback and performing in front of people hasn't served me well anymore and that I want and need to transcend beyond that. And I'm doing a good job at that. Looking back on the last 10 years, I think I have always changed for the better, but right now, it feels like a more calm, refined way that I actually control and nurture; less about the standards of others, and more about who I wanna be. Focusing more on what is actually in my power and trying to make the most of things. The "I can just do things" era of me. It really helps with cultivating trust in myself, because I actually follow through with things and do not break my own promises or block my own blessings any longer. I have so many cool things planned the coming months; we'll see how it goes. Reply via email Published 01 May, 2026

Career Writing

Takuya Matsuyama 1 weeks ago

10 years of indie dev: How I went global from Japan (talk w/ Hiroshi) - Part 1/2

I joined Hiroshi's podcast episode a few weeks ago. We shared our experience and knowledge on indie dev. I'd like to cross-post our talk in English here. I also tried to create an English dub using AI. The voice cloning quality is quite impressive, so I hope you enjoy it. 00:00 I joined Hiroshi's podcast 01:12 Intro & welcome Takuya from Inkdrop 02:31 Takuya's background: from Walknote to Inkdrop 06:07 Going indie: cautious vs. reckless paths 08:06 How indie dev became a freelance pipeline 10:36 Timeline to making a living from Inkdrop 13:28 Why target the English market from day one 15:30 Pre-AI struggles writing English copy 17:31 Thoughts on the AI vibe-coding era 18:37 Reviewing every line: AI usage philosophy 22:19 The Shinkansen analogy for AI 27:05 Why personal taste matters more than ever 28:19 Living better in the AI era (Ichiju-Issai) 30:18 Enjoying tech change like the seasons 32:11 Avoiding the herd & staying unique 36:27 Dealing with online critics 37:46 Wrap-up Hiroshi: Hi, hello, good evening. I'm Hiroshi Creation, an indie app developer. Today we have another special guest with us: Takuya from Inkdrop. Thanks for joining us. Takuya: Thanks for having me. I heard you quit your day job, Hiroshi, so I figured I had to come show some support. Hiroshi: Thank you. Our connection goes back a while, right? I think the first time was about 5 years ago when I wrote a guest post on your blog. Takuya: Way before that, actually — we'd been following each other and watching each other's work. Back then your app was called "Family TODO," and now it's "minto." You'd been building it for a long time, and when it hit 10,000 users, that's when I invited you to write something on the blog. That's how it started — me reaching out to you. Hiroshi: Ah, that's right. Most indie devs probably already know you, but for now, Takuya, could you give a quick self-introduction? Takuya: Sure. I'm Takuya. I make a Markdown-focused note-taking app called Inkdrop — I've been working on it for about 10 years now. Originally I joined Yahoo as a new grad, quit after a year and a half. While working there I was always doing indie dev on the side, and what I built then was a music app called Walknote, for iOS — well, iPhone OS at the time. It got picked up and went viral. On that momentum I quit my job, like "I'm gonna live off my dream apps," and just jumped without thinking. In the end, monetization for Walknote totally failed, but it gathered around 130,000 users. Hiroshi: Wow. Takuya: It made it into the top rankings, things were going well, but I hadn't thought through monetization at all, so it didn't pan out. I gave up on it, then made a bunch of other things that all failed, and finally I thought "I want a better note-taking app, let me just build one." That became Inkdrop. Hiroshi: Oh, I see. Takuya: Until then I'd had tons of failures — it's not like I built Inkdrop out of nowhere and it just worked. Hiroshi: Right, that's the thing. People only see the bright side — the apps that actually succeed — but you'd built quite a lot before that, huh? Takuya: In terms of indie dev, it goes back to high school, even middle school. I've been doing personal projects basically since I started programming, so my programming history equals my indie dev history. Hiroshi: Wow, you're a real veteran. In minto-years, how old is Inkdrop now? More than 10? Takuya: Exactly 10 — this year is the anniversary. Thanks to everyone, it's still going. Hiroshi: I'd love to talk with a veteran like you about all kinds of things today. minto, by the way — in about a month it'll hit year 7, the 7th anniversary. Seven years is actually a lot, when I think about it. Takuya: Yeah, 7 years is long. Hiroshi: But in my case I went independent really late — for about 6 and a half years I was doing it as a side gig while working a day job. So my pace has been like a turtle's, honestly. Takuya: Was that about balancing monetization and being able to cover living expenses? What was the deciding factor for taking the leap? Hiroshi: Well, some people borrow money from places like the JFC and just dive in — Takuya, you might've been like that at first too. But in my case I was very cautious, like crossing a stone bridge by tapping it first. I waited until revenue was solid before going independent. Because of that, it ended up taking 6 and a half years. Takuya: I think that's totally fine. In my case, I really wasn't thinking — pure youthful recklessness. After I quit, friends literally called me asking "Are you okay?" So I really wouldn't recommend it. But the reason I survived was that Walknote had become a track record, and that mattered a lot. Back then the iPhone market was super hot, Facebook was on fire — everyone wanted to be the next Mark Zuckerberg, that was the vibe. So in that environment, word got around that "this guy can build high-quality iPhone apps." Through friends introducing me, I got work from startups I knew, and even bigger companies started giving me design work. So indie dev itself led directly to my freelance work. Even though it wasn't direct monetization, indie dev as a means of making money came through huge for me. Hiroshi: Right, back then there weren't many people who could build iPhone apps either. You probably had people asking "How do you even do this?" — that kind of thing. Takuya: Yeah, exactly. If you build something, it leads to work, so you don't have to worry about starving. You don't have to obsess over making it work financially as just an app. Hiroshi: Yeah, exactly. It's not 0 or 1 — if your indie app doesn't sell, you can take freelance contracts, or honestly just go back to being employed and work as a salaried engineer. When you think about it that way, the risk isn't really that big. You've got the skills, that's enough. minto already serves as a business card too. Even in the worst case where I can't make a living off it, everyone already knows "this guy can build stuff like this," so work would just keep coming in. Takuya: Yeah, and beyond just the technical side — having actually shipped a personal app means your marketing instincts aren't off compared to the average person. Plus, both you and I do our own design. Being a frontend engineer with some design sense — you don't need to explain it in a job interview. Just say "I made this" and they get it instantly. I've never explained it. I've never said "I have X years of PHP, X years of JS." I just say "I can build this app," show them, and the work comes in pretty easily. They go "Oh really? Actually we've been thinking about something like this," and the conversation moves forward fast. Hiroshi: When was it — you wrote about it on the blog. Takuya: For the first year after release I couldn't make a living off it at all. Around year 2, I wrote a blog post like "I can now cover half my rent, my full rent." So by year 3 I think I was fully able to support myself. Hiroshi: From there it was just Inkdrop full-time? Takuya: Pretty much. I basically don't take contracts anymore. Just one time — there was this Austrian React Native developer friend of mine, Marc Rousavy, who runs an agency. He needed designer work and asked me. I told him "Sure, as long as I can use it as content for my videos," and he said OK. So I turned it into YouTube content while doing the work — that was the last contract I took. Hiroshi: Got it. So basically just Inkdrop now. Takuya: My stance is, if something really interesting comes along I'll do it without being too rigid. That one was great because it was my first time taking work from an Austrian company — first time doing overseas contract work — and the fact I could turn it into video content was interesting too, plus it paid. All three things lined up. Hiroshi: That reminds me — about your videos. Your YouTube channel has crossed 200K subscribers now, right? That's pretty incredible. Takuya: I have two channels. DevAsLife is the main one with 210K, and the other one is talk-focused — I started it for English speaking practice — that one's at about 20K now. Hiroshi: Whoa. So you have the Silver Play Button too? Takuya: Yeah, I have it. Lately I've been posting more on the second channel (craftzdog), the talk-focused one, than on DevAsLife. Hiroshi: I think that's because you're constantly publishing in English, and Inkdrop is also primarily in English. Rather than focusing on Japan, your whole activity has gone beyond Japan and into the global market. My recent theme has been about earning foreign currency from a cheap Japan. But you've been doing this from a really early stage — about 10 years ago. Why did you choose to market to overseas audiences? Takuya: Because there was no reason to limit it to Japan, from the start. It's a note-taking app — why would I only sell it in Japan? That was the first question. Through development I'd been contributing to open source a lot, so "overseas" was already very close to my daily life. Hiroshi: I see. Takuya: I was filing issues, sending PRs, doing all that in English daily. Overseas developers were already in my circle. So when I conceived Inkdrop, since it's for developers, my target was naturally the developers around me — which means English-speaking people. If those were my target, not doing it in English wasn't an option. Of course, it's clear that Japan's economy will shrink over the next 10 to 20 years — but rather than keeping that in mind, basically when thinking about what I want to sell, I think about what kind of thing I'd buy. And then I think about who I want to sell to. That's someone close to me — someone similar to me, someone I can easily understand. That's the English-speaking developers around me. Following that line of thought, building it in English just made sense. Hiroshi: Got it, so it was natural. Rather than deliberately deciding to push hard into the English market, it was part of the open source flow — going overseas was the natural path. Takuya: Yeah. Of course my English was terrible at the time, so writing one blog post would take 2 weeks. To make a website I'd visit all kinds of sites, copy-paste phrases, mash them together. Coming up with copy in English was insanely hard. I could only do literal translation, and translation tools didn't really give good results either. So I'd visit the homepages of all the apps I was using, pick out "this phrase works, this one was useful," collect them, and stitch them together. Nostalgic. Hiroshi: Wow, that's amazing. Whereas now, if you want to make an overseas site or sell a service abroad, you just translate with AI and you're done — that's how easy it feels, putting quality aside. Hiroshi: So my impression of you, Takuya — even before AI you were heavily into indie dev, and among indie devs you have really high technical skill. You've contributed to open source from way back, you can do Electron performance tuning and app optimization. So I'd love to ask how you're feeling about this AI vibe-coding era right now. Takuya: It's super fun. I've been writing about this in recent blog posts too — AI is so pervasive that avoiding it is impossible. Honestly, in terms of skill, the AI is already beyond a new grad. But in terms of how I use it — it's polarized maybe. There's the extreme type who just lets AI do everything and doesn't even read the code AI wrote, and on the other side the type who only uses AI as chat. I feel the graph kind of looks like that, and I'm sitting in the middle. The code AI writes, I basically read line by line, review it, and only commit once I'm satisfied — that's how I use it. Because there are paying users already on the product, I can't just drop in irresponsible code. To ship something I'm ultimately responsible for, I have to review every single line. So firing up 10 or 20 agents and producing tons of stuff at insane speed — that's not how I'm using it right now. I always look at things one at a time. Hiroshi: Yeah, I get it. I've been making something new lately, and since the new thing has no users, I can make breaking changes freely. But when I'm working on minto, there's already thousands, like 10,000 lines of code that humans wrote — that I wrote — and there are existing users. So I really can't cut corners line by line. But for the new project, I'm letting AI do about 90% of it. I do review it, but it's pretty much half-self-driving — like 70% autopilot. Takuya: That feeling of "I can't fully trust AI yet" when you've already written an existing service by hand and it has users — I totally get it. When you're starting something completely from scratch with AI involved, the cost of writing is basically zero, so you can make breaking changes without hesitation. Like if you're making a new web page, a landing page — at that moment I'd definitely use AI, but in the trial-and-error process I'd be tossing out the code I just wrote. Just spinning the PDCA loop at insane speed, getting closer to the shape little by little. This is similar to image generation. When you make a website with AI, you let it build the whole thing each time, then "I don't like this part, regenerate, regenerate" — it's really similar to image generation, that mental image. Hiroshi: Before, only one-man-band CEOs with crazy clients could work that way. But now individuals can do it — that's the change. Whether it's a good way of working, nobody really knows yet. Takuya: In the end, if you actually want to pay attention to the fine details, that approach has limits. I wrote about this on the blog before — there's an analogy that AI is like the Shinkansen. Basically, you can get from Osaka to Tokyo at incredible speed, but if you specifically want to go to Asakusa, or back to Hikarigaoka Park where you used to live, you have to switch to local trains, take a taxi, take a bus — these fine-grained mode switches become necessary. So if you want to go somewhere specific, do something specific, when filling in that level of detail, leaving it to AI has limits. When you ride from Osaka to Tokyo, the scenery flies by at incredible speed, so the entire process becomes invisible. I think that's why your head feels foggy when you use it. Hiroshi: Ah. Takuya: "Actually we've arrived in Tokyo, we're at Shinagawa." From there, when you start figuring out how to get further, suddenly the scenery becomes visible — "Oh, a new building has gone up here." You can notice changes like that. The way I'm using AI in Inkdrop right now is probably more like taking a bus, taking a taxi, or noticing which buildings have been rebuilt — that kind of usage where you can see the world. Hiroshi: So basically, first you ride the Shinkansen, fly around, try lots of places, going "ah, this design style doesn't fit," like German style, Austrian style, and so on. You travel around like that, and once something clicks, from there specifically — "this specific architectural style, this window feel, reproduce this" — you start giving instructions at that level of specificity. Takuya: Yeah, exactly. That foggy-head feeling, I really get it. You can't read it anymore, the speed is too fast for humans to keep up. You lose the will to read it, it's too fast. Hiroshi: So as instructions, like "change the shape of this clock here a little, change the color" — at that unit of instruction, the way you're probably doing it, Takuya — when you instruct AI like that, you can look at each line and say "this color is bad." But broadly, if you give vague instructions before you even have an image of the world you want to realize, it's really unbearable to watch. Takuya: Recently I tried this front-end set — for website design, someone analyzed landing pages of various famous companies and turned them into Markdown. It was called design.md — or maybe Awesome DESIGN.md, that's the one. I just sent the link, you can see it in the chat. I tried it once, testing different site styles one by one on my own website, but the quality wasn't good enough to use as-is, unfortunately. The frame structure — page structure, layout, color palette — that's the only level it replicates. It doesn't blend things nicely with my app's concept. I thought "yeah, this isn't quite it." Hiroshi: That sense of "something's off," your authorial voice, the worldview that's uniquely you, Takuya — it shows in Inkdrop, in your daily blog, in your illustrations. I feel like that kind of sensibility is really important in the AI era. Otherwise you can't make the call, because without a refined sensibility, you can't judge whether a design is good, or whether it's missing something. If you just hand yourself over to whatever AI outputs, you end up with similar designs and apps. So in the process of refining that sensibility, what have you been doing lately, outside of AI — outside of the computer? Anything you've been doing? Takuya: Just yesterday I posted a Vlog and a blog post on exactly this topic — discussing how to live better in the AI era. The inspiration came from Yoshiharu Doi's Ichiju-Issai — the one-soup-one-side concept. When you're constantly online, you get steeped in algorithms. Open Twitter, X, and you're flooded with drama and gossip, your attention gets pulled in. To use a food analogy, those things are additives — you can live without them. So you keep subtracting that kind of thing, leaving only what's necessary, and maintain the rhythm of your life. That's one. The second is treasuring organic connections and ideas. Random ones — like a barista at the cafe you frequent striking up a conversation, that kind of small warm moment — or chats with the moms you see every morning, or playing a bit with kids you often see at the park. That kind of connection that wasn't designed by anyone — treasuring that. As for ideas, instead of staring down at the screen in front of your computer, set it aside, go for a walk, go camping, drive somewhere — make time to step away — and then suddenly good ideas pop up. Hiroshi: Yeah, yeah. Takuya: And then — how do I put it — enjoy technological change like the changing seasons. Hiroshi: Ooh. Takuya: Every day there's some new AI thing, this AI, that-and-that-agent — keeping up with all of it is exhausting. Instead of living each day competing, racing against someone, you know — "spring is here, the cherry blossoms are beautiful," "apples are in season, let's eat some," "I love saury, looking forward to autumn" — that kind of thing. Not chasing, but appreciating what comes — the things each season brings — appreciating, enjoying, gratefully receiving — that attitude when engaging with technology. The tension drops, and you take in only what's needed, when needed. Take it in, internalize it, let it ferment — I think that's good for keeping your own pace. Not just chasing trends, but more naturally — when the chance to engage comes through those organic connections, then it's fine to take it in. If you live at that pace, I think unique ideas emerge on their own. Hiroshi: Yeah, exactly — it's like being in the herd, no uniqueness emerges, as long as you're chasing trends. You're just imitating what others are already doing, so there's no element for uniqueness to emerge. So you have to do something different from others — otherwise you won't think of new video formats, won't write articles with unique perspectives. Publishing in English about how to live in the AI era based on Ichiju-Issai — nobody else is doing that, so at minimum that's unique, I'd say. I read your blog yesterday, and I thought there's no way miso soup or anything could connect to AI, but it really did connect. And I learned for the first time that Doi-san's book was that deep. Takuya: Yeah, exactly — it's not just recipes or that kind of suggestion, it traces all the way back to deep Japanese roots. It's a really profound book. So miso isn't an additive — it's something originally aged or fermented. Things with that kind of depth, versus additives like trends or X posts — it's better to think about them separately. You don't have to completely eliminate them — no need to forcibly remove them — but having something inside you that you don't get tired of even eating every day, like miso or rice, that becomes your axis and stabilizes you. It could be playing guitar every day, or drumming — in my case, when I drum, somehow I can return to my original self. That kind of thing seems to have no connection to indie dev at all, but I think it's actually really important. Hiroshi: Hmm, yeah. Takuya: The tech world is pretty closed, right? There are a lot of similar-type people. When that happens I can never quite fit in, can't really get into that circle. Ever since school, I've had a personality where joining a fixed group makes me anxious for some reason. Same in tech circles, same in English-speaking circles — when I hang out with the same people too long, suddenly I come back to myself, "wait, is this okay for me?" — and I can never stay rooted. It's just my nature. Hiroshi: Right. Takuya: I think that's fine. The flip side is loneliness follows me forever, but not staying with the same homogeneous group — I think that's one of the elements that makes me unique. Hiroshi: That's so important. The previous guest, Ko-san, was saying the same thing — basically, doing the same thing as everyone else doesn't get you anywhere. Sometimes intentionally going to a different community — Ko-san was talking about that too. So interesting. Love that kind of person. Hiroshi: I saw your post recently — even overseas, when you post on DevAsLife or your sub-channel, you get comments like "Why aren't you using OpenCode?" Even though using Claude Code or any AI agent at all already puts you in the top 0.something percent. And within that, people compete and try to one-up each other over 0.000-something percent — flexing on each other. I found it interesting that this kind of thing happens overseas too. Takuya: Tons of it. The people who say that are mostly anonymous accounts, people without confidence in themselves. They use VSCode and want the validation of "VSCode is fine" — so they attack non-VSCode users to convince themselves. So you can ignore them all, it's fine. Just a bit annoying. Hiroshi: I see. I thought it's like a village — being stuck in a village forever, you can't let yourself get swayed by those words. Takuya: You don't need to deny others — to validate what you're doing, the question of "what to belong to" is beside the point. Those people should first build up their own self-affirmation. Hiroshi: Thank you. So let's pause here for now, and make the second half about the topics you, Takuya, want to talk about. Takuya: Sure, thank you. Let's wrap up here for now. Thanks so much. Hiroshi: See you. X: https://x.com/hirothings Podcast: https://open.spotify.com/show/19HqgO48GOmiFXUMp6YuWv Minto: https://mintotodo.app/

Career Business AI Java JavaScript

A Working Library 2 weeks ago

The “correct” attitude

In one layoff announcement after another, we hear that AI can now do the work of a great many people, which is why far fewer people are needed to do the work. If, for the moment, we take that assertion at face value, this still leaves an obvious alternative path: instead of reducing the number of workers, companies could reduce the amount of working time . That is, rather than laying off twenty percent of the workforce, they could have everyone work twenty percent less. In fact, I’d venture that a great number of knowledge workers would be more than happy to take a twenty percent pay cut in exchange for a four-day work week. 1 Time is very often more valuable than cash. But the steady drumbeat of layoffs suggests that no member of the C-suite has even considered this path. Why not? It could hardly be more clearly stated that the workers taken in by the big companies are a small “elite,” not because they have higher levels of skill, but because they have been chosen from a mass of equally able individuals in such a way as to perpetuate the work ethic in an economic context in which work is objectively losing its “centrality”: the economy has less and less need of it. The passion for, devotion to, and identification with work would be diminishing if everyone were able to work less and less. It is economically more advantageous to concentrate the small amount of necessary work in the hands of a few, who will be imbued with the sense of being a deservedly privileged elite by virtue of the eagerness which distinguishes them from the “losers.” Technically, there really is nothing to prevent the firm from sharing out the work between a larger number of people who would work only 20 hours a week. But then those people would not have the “correct” attitude to work which consists in regarding themselves as small entrepreneurs turning their knowledge capital to good effect. Gorz is writing more than two decades before the current crop of LLMs hit the market, but of course the seeds of our present predicament were planted long ago: in the years before the dot-com crash, we also saw a small number of privileged people earning large sums of money while working egregiously long hours in overpriced but ostensibly comfortable chairs. Perhaps if something is different now it’s the scale of the threat: in the years since that first tech bubble, the number of tech and tech-adjacent jobs have soared. Meanwhile, the leaders of tech companies today claim that AI will take all the work away, that no job is safe. It is hard to maintain the “correct” attitude to work in light of such apocalyptic claims. Which begs the question, what attitude is taking its place? What happens when we no longer see ourselves as “small entrepreneurs”? We’re on our way to finding out. Of course, from a labor perspective, the demand should be a four day workweek at full pay .  ↩ View this post on the web , subscribe to the newsletter , or reply via email . Of course, from a labor perspective, the demand should be a four day workweek at full pay .  ↩

Business Career

Alex White's Blog 2 weeks ago

re: Who knows that you blog?

David talked about their reluctance to share their blog with others in the real world. I have much the same reluctance, I definitely don't want a coworker on my blog, or even one of my IRL friends. I do occasionally share links to my articles with my wife, but that's infrequent, and I know she forgets the link between pings. For me, the reluctance is similar to David's. This blog is my space to write what's on my mind in my own little vacuum. It's disconnected from the expectations of real life, and a more real reflection of myself versus the "masks" I wear IRL. It's a playground, a place to rant and a place to nerd out. Sometimes I wish my blog was even more private, disconnected from my IRL identity. There's a lot I would like to rant about around corporate America, but I dare not publicly when it's linked to my professional identity. Gotta pay the bills after all. To forward David's ending question: "Do you tell people you blog?".

Writing Career

Shayon Mukherjee 2 weeks ago

I am not leaving GitHub any time soon

I created my GitHub account in October 2011. User 1,100,970. My first repository was a small project for an openSUSE summit, pushed in February 2012. I’ve opened GitHub almost every day since then for nearly fifteen years. It’s where most of my professional life has happened. So when Mitchell Hashimoto wrote last week that GitHub “is no longer a place for serious work” and that he’s moving Ghostty off the platform, I paid attention.

Github Open Source Career

Mitchell Hashimoto 2 weeks ago

Ghostty Is Leaving GitHub

Open Source Github Career