Posts in Career (20 found)

Front page

I have not had a huge success with my writing in this blog so far. I don’t collect any analytics 1 , so I am not sure exactly how each post fares, but based on the amount of comments I have received in the various platforms I have shared my posts, the traffic must not be very high. This has not discouraged me from writing. My goal is to share projects that I am developing and to express some of my thoughts when I feel like it. I am glad if someone finds the content interesting and I am even happier to engage anyone who sends a comment my way. In any case, I think that the mere act of sitting down and writing your thoughts is beneficial by itself and it is worth doing, even if the audience is not there. It is true, though, that it feels nice when people accept what you are offering. And two days ago, I finally got my first breakthrough. I shared my last post on Hacker News and it reached the front page . I admit it was satisfying to see that a lot of people approved of the message and wanted to share their own opinions. I spent the next day or so participating in the discussion and digesting all the new information that was available. One of the main themes of the discussion was user interface accessibility. It is a part of software development that is of great interest and importance and I hope to more systematically approach it in my programming and my writing in the near future. The whole experience was positive. I do not claim to be a great writer, nor that my post proclaimed some profound truth, but it was gratifying to see that an extended discussion was started because of something I wrote. As a result, I now am a little braver to share my thoughts with the world. I think they can create bad incentives for content creation.  ↩ I think they can create bad incentives for content creation.  ↩

0 views
Sean Goedecke Yesterday

You have to beat the models at something

In 2025, I wrote that software engineers ought to be assessed by “value over replacement” : not how much money they made for their company, but how much they would have made compared to the average engineer in their position. I’ve always found it vaguely silly when engineers put “built a product that made $X” on their resumes, when they just did the JIRA tickets that came across their desk. Today, value over replacement is even more important. A replacement-level engineer in the 2010s was fine : maybe not worth promoting, but still worth paying , because writing code had a high fixed cost. Now writing code costs a hundred bucks a month . What are you doing that GPT-5.6-Sol or Claude Opus 5 wouldn’t do in your position? Why is it worth paying an extra two or three orders of magnitude for? This is a scary thought. But you’re not doing yourself any favors by pretending that LLMs can’t actually write code and it’s all just a scam, or that LLM-written code is inherently so bad as to cause companies using it to collapse next year. We are not going to wake up in 2027 to find that the AI craze is over and everyone is writing code by hand again. You ought to put some serious thought into what you can do better than the models in the medium and long term. Staying ahead of the models is a moving target. At the start of 2026, “make working changes to large codebases” was in this category , but now it’s not. For this reason, I doubt that you can retreat to some “hard engineering” area that requires deeper expertise. That might work in the short term, but not forever. If LLMs can find a better lower bound on the Riemann hypothesis, they will soon 1 be able to write solid high-performance kernel drivers or GPU shaders or whatever. I think it’s more useful to look at the tasks models haven’t gotten better at over time, and the tasks that are hard for them get better at in principle. The two best examples of these are: What do frontier LLMs get wrong? What kind of coding mistakes do they make? It’s been a long time since I’ve seen a straight-up hallucination from a coding agent, or a simple logic error like an off-by-one. The mistakes they make tend to be errors of ignorance : Other times they’re errors of paranoia : What do these errors have in common? They’re the kind of errors a smart engineer might make if they had no context on the system: they’re competent enough to be able to solve the problem, but they haven’t been around long enough to confidently say “yes, we can take this risk to avoid an extra three thousand lines of code”. Until someone cracks continuous learning or truly massive context windows, this is just an inherent feature of how AI agents operate. If you can catch these errors, you’ll be providing real value. The only way to catch these errors is to be familiar with the codebase and familiar with the system in general. For much more on this, see my post You can’t design software you don’t work on . But there’s also a psychological component to it. You have to be willing to confidently disagree with the agent. AI agents can be very convincing. Often they can get “stuck” on some error above where they’re not willing to take a particular risk, so they keep going back and sneaking in code to cover that case (or writing persuasive arguments about why that case is important). To add value, you need to be willing to say “this sucks, I don’t think we need X and Y at all, why can’t we do Z in a much simpler way?” It takes courage . You can’t rely on other AI agents to review each other’s work. If you use the same model, it’ll reliably make the exact same assumptions and mistakes. But even if you use different models, they’ll also tend towards the same kinds of mistakes — ignorance and paranoia — for the same structural reasons. AI-driven review loops are in fact more likely to get these things wrong, because modern AIs have been RL-ed to try to find a few nitpicks no matter what. Having a critic AI and a worker AI bounce off each other is a really good way to end up with ten thousand lines of paranoid slop. Another area where you can add value on top of AI is communication . Newer models are better at coding, but are paradoxically getting worse at writing. GPT-3.5 and GPT-4 had a human-like writing style at times. GPT-4o introduced the modern slop idiolect, and the newer Anthropic models speak “Claudish” : a bizarre semi-baroque semi-truncated way of communicating that nobody enjoys. There have been a few bright spots — GPT-4.5 was okay, and I quite liked o3 2 — but in general LLMs are not good at this. Here’s two reasons why. First, good writing is not a verifiable domain . If you want a model to get good at mathematics or coding, you can generate problems for it and automatically grade them. You can’t grade good writing. If you try to get humans to grade it — for instance, via the early OpenAI RLHF attempts — you get the kind of writing that sounds impressive to the average person when consumed in single-paragraph form. This is the origin of the “stick three hundred writing devices into every sentence” style. I think it’d be possible in principle to hand-pick some people with good taste and have them do it, but there are some obvious problems 3 that prevent this from happening. Second, the labs have been monomaniacally focused on capability instead of communication . When you’re trying to train a model that can break new scientific ground or replace a software engineer, you might trade off some communication ability. In fact, I think we can identify exactly how this has been happening. If you look at internal model reasoning tokens , they tend to have strange word choices and oddly truncated grammar: RESOLUTION: charge the current-leg’s OWN saved-prefix occupancy EAGERLY: when leg i saves e 1..e t: ALSO commit their occupancy AT LEG i If you were to translate this into proper English, you would probably end up with something that reads like Claudish: Charge the current-leg’s saved-prefix occupancy on a clean, eager path: when leg i saves e 1..e t, commit the occupancy at leg i. I suspect that the weirdly alien writing style of some LLMs is because you’re reading a semi-literal translation of that model’s internal chain-of-thought, which has become nearly incomprehensible in pursuit of better problem-solving abilities. It is surprisingly hard to translate Claudish to good English: not only do you need to follow the convoluted, compressed language of the original, but you need the technical ability to understand the problem the model is solving. Because of all this, technical communication may be a surprisingly durable skill. In Peter Watts’ novel Blindsight , the world is full of cognitively augmented humans. The main character is a “synthesist”: someone whose job is to be a translation layer between these geniuses (who speak in abbreviations and gestures) and everyone else. Watts’ idea is that communication ability may be largely independent from — or even negatively correlated with — intelligence. A “country of geniuses” may still need a bunch of ordinary smart people to translate their insights for everyone else. If you’re trying to communicate to humans, there are also huge advantages to having a human write the content. Many of us are becoming AI-blind : developing an instinctive reflex that stops us reading when we encounter AI-generated content. It’s like the reflex that allows people to ignore flashing billboards or sidebar advertisements on websites. If you circulate some planned technical strategy as an AI-written document, most of your colleagues will have to physically force themselves to read it word-by-word. Whatever you do, don’t be a meat proxy : someone who simply copies requests into an AI agent and submits their output as your own work product. Doing that is just begging to be fired, since you’re definitionally not adding any value yourself. Even if you have a cunning system of multiple agents — the so-called “software factory” — you’re still on dangerous ground. When the features of your system work their way into enterprise AI tooling (and they will), you’ll be disposable. You need to find some way to leverage your expertise to do what the models can’t. Simply not using AI at all is better than being a meat proxy, since you’ll probably do some things better than the model would have, but it’s far better to figure out what AI can do and position yourself to fill those gaps. Right now, there are two main gaps: familiarity with the technical details of the system, and the ability to clearly and persuasively write about those details. If you’re thinking “but LLMs can do these things now!”, substitute your preferred example of high-difficulty software engineering. Although this was probably a “thank God it doesn’t speak like 4o” reaction. Defining good taste is hard, there’s no guarantee that AI lab researchers have good taste to start with, nobody will agree on examples, the bulk of users might not even like it, you won’t be able to get enough people to produce the volume of data you need, and so on. Deep familiarity with the codebase Technical communication Not knowing that there’s a module in the codebase they could use instead of reimplementing some logic Making the change in the wrong system because they didn’t know System X was the standard place for this functionality Adopting a coding style that’s inconsistent with the company’s standard practice Implementing triply-redundant checks for a value that technically could be wrong but practically is set once from config and never updated Assuming that ten milliseconds of stale data is unacceptable and designing a complex, unnecessary system to keep it always up to date Building in fallbacks and “graceful” degradation into some code that ought to simply crash on error (e.g. a CLI tool, or a restartable k8s service) If you’re thinking “but LLMs can do these things now!”, substitute your preferred example of high-difficulty software engineering. ↩ Although this was probably a “thank God it doesn’t speak like 4o” reaction. ↩ Defining good taste is hard, there’s no guarantee that AI lab researchers have good taste to start with, nobody will agree on examples, the bulk of users might not even like it, you won’t be able to get enough people to produce the volume of data you need, and so on. ↩

0 views
Sean Goedecke 3 days ago

Selling out

In 1973, Tom Lehrer famously sang that “selling out is easy to do”. That may have been true in the seventies, but it’s not true today: selling out requires both technical skill and a careful sense of how large organizations work in practice . One of the goals of this blog is to teach people how to do it. If you want to live with uncompromised integrity, you don’t need anyone to tell you how: simply always do exactly and only what you want to do. You will be repeatedly punished for it — your managers will dislike you, you will lose jobs and lose out on the chance of getting hired, your financial situation will be less stable, and so on — but that’s just part of the deal. Like deadlifting four plates, it’s not easy, but it is straightforward. It’s more complicated to sell out a little bit. Sellouts like me walk a fine psychological line: figuring out how to work a large organization on one hand, and maintaining some kind of independent inner life on the other. But is this safe? Does role-playing as a professional inflict some kind of psychic damage? People often tell me that acting professional is dangerous because it’s “Marxist alienation”. I suspect many people have a vague sense that “alienation about your job” is in some sense necessarily Marxist, but the actual concept is more specific. In Marx’s First Manuscript he describes it like this: The worker becomes poorer the more wealth he produces, the more his production increases in power and extent. … This fact simply means that the object that labor produces, its product, stands opposed to it as something alien, as a power independent of the producer. Marx’s theory here goes something like this 1 : when you work for a capitalist boss, they make ten dollars for every dollar you make 2 . The more you work, the more powerful you make your boss with respect to you 3 . Your work is thus producing a force that is your enemy: a literally “alien” power. For Marx, alienation is proportional to the amount you’re working: the more the worker produces, the less he has to consume; the more value he creates, the more worthless he becomes; the more his product is shaped, the more misshapen the worker; the more civilized his object, the more barbarous the worker; the more powerful the work, the more powerless the worker; the more intelligent the work, the duller the worker and the more he becomes a slave of nature. So far Marx is just talking about the worker’s alienation from his work. But he does touch on the internal psychological effects as well. Since work is such a big part of life, to be estranged from your work is to be in some sense estranged from your self: [labor] does not belong to [the worker’s] essential being; that he, therefore, does not confirm himself in his work, but denies himself, feels miserable and not happy, does not develop free mental and physical energy, but mortifies his flesh and ruins his mind. Hence, the worker feels himself only when he is not working; when he is working, he does not feel himself. Overall, I can make out four distinct senses 4 of Marxist alienation: I don’t think the first one is relevant to big tech software engineers. The idea here is that the harder you work, the more you (relatively) disempower yourself, so you’d be better off coasting and putting your company in a worse financial position. But this just seems straightforwardly wrong: as a software engineer, you want your company to be doing as well as possible! The more powerful and rich your company is, the better your position will be 5 . A company that is struggling is more likely to treat you badly, lay you off, cut your benefits, and so on. The second one is more relevant (particularly in large companies), but there’s a missing story here about why that separation is bad. I also don’t think the third sense of alienation applies to me: Marx is talking about the physical toll of factory work or other hard physical labor, which doesn’t apply to software engineering 6 . The fourth sense of alienation — that your effort is being directed at other people’s goals — is the most straightforwardly relevant to my own experience. But I don’t think Marx has a great psychological account of why that happens or what it feels like. To go deeper into this psychological aspect of alienation, we need to look at some later Marxists. In 1967, Guy Debord and Raoul Vaneigem both published their masterworks. They were members of the “Situationist International”: an influential group of Marxist artists and political theorists 7 . Both of them have a lot to say about alienation. Debord writes : The worker does not produce himself; he produces an independent power. The success of this production, its abundance, returns to the producer as an abundance of dispossession. All the time and space of his world become foreign to him with the accumulation of his alienated products. This idea — of the worker’s efforts not going to his own ends, but to some alien power — is straight out of Marx’s First Manuscript . But note how Debord is already talking in terms of “representation”. Elsewhere he writes: the more he contemplates the less he lives; the more he accepts recognizing himself in the dominant images of need, the less he understands his own existence and his own desires. The Situationists are all about representation. It wouldn’t be too far wrong to think of them as a bunch of Marxists who saw the rise of advertising in the 1950s and 1960s and lost their minds. TV advertising is Capital itself made real, dressed in multicolored lights, projected into everyone’s homes. So when they talk about alienation, they talk about it in terms of representation . Vaneigem explicitly calls it roleplaying: The roles we play in everyday life, on the other hand, soak into the individual, preventing him from being what he really is and what he really wants to be. They are nuclei of alienation embedded in the flesh of direct experience. Alienation means giving up your real, authentic self in order to play some “role” (for instance, the role of “effective staff engineer”). It’s a vicious cycle, because the more you lean into the role, the more your authentic life becomes trivial, which in turn makes the role more appealing: Life is sacrificed, and the loss compensated by means of accomplished prestidigitation in the realm of appearances. The more daily life is thus impoverished, the greater the attraction of inauthenticity, and vice versa. Dislodged from its essential place by the bombardment of prohibitions, limitations and lies, lived reality comes to seem so trivial that appearances become the centre of our attention, until roles completely obscure the importance of our own lives. Ultimately, Vaneigem describes alienation as an addiction: This ambiguity accounts to my mind for people’s addiction to roles. It explains why roles stick to our skin, why we give up our lives for them. They impoverish real experience but they also protect this experience from becoming conscious of its impoverishment. Indeed, so brutal a revelation would probably be too much for an isolated individual to take. This is almost a straightforward preview of the 90s idea of “selling out”: people are born wild and free, but when they watch too much TV they give up on their dreams for a paycheck and become big fat phonies. According to this view, it’s always better to not sell out. It may leave you poor and without prospects, but at least you won’t be unoriginal 8 . What shall it profit a man, if he gains the whole world but loses his soul ? I’m sure this is an accurate description of some people’s hangups about work. But I don’t think even the Situationists would agree that any advice on how to play a role well — i.e. the advice I give throughout my blog — is inherently harmful. The problem with role-playing is that you risk losing your authentic inner life, but that’s a risk , not an inevitable consequence. Vaneigem has a wonderful quote on this: Nobody is ever completely swallowed up by a role. Even turned on its head, the will to live retains a potential for violence always capable of carrying the individual away from the path laid down for him. One fine morning, the faithful lackey, who has hitherto identified completely with his master, leaps on his oppressor and slits his throat. This is a little overdramatic, but it seems straightforwardly true. It sounds very impressive to talk about alienation (or like Marx, to derive alienation from the basic economic conditions of work), but, you know, you can just not do it , right? Healthy people can present different selves for different situations: you can be loose at a party, respectable at church, solemn at a funeral, professional at work, and so on. I’m not convinced this is alienating or impoverishing. In fact, it’s not just humans: my dogs act differently around different people too, and I don’t think that makes them inauthentic. If maintaining a professional identity is harmful, it has to be because of something fundamental about work that makes it different from regular role-playing. Could it just be that acting professional at work is too inauthentic? Some amount of role-playing might be okay, but if the role you’re playing is completely alien, does it become lying to yourself? Another common term for alienation is “bad faith”. The original version of this comes from Jean-Paul Sartre’s famous book Being and Nothingness 9 , where he describes bad faith as telling yourself lies. Lying to yourself is weird because you’re both deceiver and deceived: Bad faith then has in appearance the structure of falsehood. Only what changes everything is the fact that in bad faith it is from myself that I am hiding the truth. Here’s another quote from Sartre’s partner Simone de Beauvoir, who writes more explicitly about professional bad faith (what she calls the “serious man”): The serious man’s dishonesty issues from his being obliged ceaselessly to renew the denial of this freedom. He chooses to live in an infantile world, but to the child the values are really given. The serious man must mask the movement by which he gives them to himself, like the mythomaniac who while reading a love-letter pretends to forget that she has sent it to herself. The key idea here is that professional bad faith — alienation — comes from losing yourself in the role. Instead of just playing at being a professional, you decide that you’re going to take it fully “seriously”, and treat professional values as if they’re absolute. But of course that’s not coherent: you can’t decide to treat a value as absolute, it either is or isn’t. So this requires a kind of continual self-deception where you pretend there’s no decision to be made at all. I have the same attitude to this as I do to Debord and Vaneigem: sure, some people might make this mistake, but you don’t have to. I can see why it might be tempting to treat work as the ultimate source of value: it gives you food and shelter, it (for Marxist reasons) can feel like a powerful alien force, companies constantly propagandize their employees , and so on. But work is just a collection of people following incentives until they reach some kind of stable equilibrium. From the inside, this equilibrium can look like the structure of the universe. However, if you treat it like that, you’re going to be bitterly disappointed when it turns out to be as arbitrary and pointless as other stable equilibria. I’ve considered a bunch of theories on which work — even well-paid knowledge work — might be inherently alienating: I don’t buy any of these (or at least, I don’t buy that they show that acting professional is inherently bad). But there are lots of types of jobs in the world, and some of them definitely seem more alienating than others. The best books I’ve read on these are C. Wright Mills’ White Collar or Erving Goffman’s The Presentation of the Self in Everyday Life 10 . The American sociologists are in the same conversation as Marx, the Situationists, Sartre and de Beauvoir 11 . Mills writes about the median “salaried employee”: In the case of the white-collar man, the alienation of the wage-worker from the products of his work is carried one step nearer to its Kafka-like completion. The salaried employee does not make anything, although he may handle much that he greatly desires but cannot have. No product of craftsmanship can be his to contemplate with pleasure as it is being created and after it is made. Being alienated from any product of his labor, and going year after year through the same paper routine, he turns his leisure all the more frenziedly to the ersatz diversion that is sold him, and partakes of the synthetic excitement that neither eases nor releases. He is bored at work and restless at play, and this terrible alternation wears him out. In this, we see both Marxist alienation, where the employee is physically separated from his craft, and Situationist alienation, where the employee is absorbed into the world of the “spectacle”. For Mills, this was television, but today it’d probably be scrolling short-form video on your phone. Mills goes on to describe how white-collar work can be humiliating and dehumanizing: In his work he often clashes with customer and superior, and must almost always be the standardized loser: he must smile and be personable, standing behind the counter, or waiting in the outer office… self-alienation is thus an accompaniment of his alienated labor. Here are the new little Machiavellians, practicing their personable crafts for hire and for the profit of others, according to rules laid down by those above them. This is a great articulation of something I write about a lot : that your primary job is to make your bosses happy, and that you ought to shape both your emotions and values towards this goal. When necessary, you must be the “standardized loser”, happy to have your professional plans disrupted. You must be a “little Machiavellian”, quietly laying the groundwork for your personal goals. I think here we come to the strongest version of “alienation”. Playing the professional is bad because “professional software engineer” is an inherently subservient role . Why can’t you just maintain a healthy mental distance (as the Situationists suggest)? Because humiliation takes its toll , whether you’re role-playing it or not. As an analogy, suppose you’re an actor in a film where you get slapped in the face. There’s a sense in which you’re not really getting slapped — everyone’s just acting — but you’re still being physically hit with each take, which will leave bruises over time. There’s a tradeoff here that everyone has to make in their own way. At the one end is becoming fully alienated, like de Beauvoir’s “serious man”, and at the other end is leaping up to slit your master’s throat, as Vaneigem describes. Here’s some examples of points on that spectrum: I am making the world a better place by achieving my OKRs. My yearly review cycle tells me how good of a person I am. I must work hard to ensure my company succeeds. I have my own goals and values, but while I’m at work it’s in my best interests to be as professional as possible. My yearly review cycle tells me how effective I’ve been at pulling the strings in the organization. I must work hard to make money. I have my own goals and values, which I try to accomplish as best I can in the context of work. I often argue with my managers about their priorities. It’s my responsibility to push my company towards my set of values, which is hard work and often unrewarded. My workplace is an enemy I fight every day in order to get what I want done. I routinely ignore my manager’s priorities and do the things I think are important. My yearly review cycle tells me how much of a sellout I am: I wear bad reviews as a badge of honor. I agree with my sources above that the first point is a big mistake, if for no other reason than that companies don’t follow their own stated values . If you prefer the fourth — the path of pure integrity — fair enough. You get to decide what tradeoffs to make with your own life. I land on the second point here (occasionally the third). I suspect it’s also a mistake to purely occupy the second point. Having some values that you occasionally trade off against your company’s values prevents you from slipping into the first point. I don’t bring my whole self to work. My coworkers and bosses see the most professional version of me: friendly, cooperative, largely apolitical, patient, and so on. I try and save the edgier, more opinionated version of myself for my friends and family in real life. Readers of this blog get something in the middle. When I write about being a software engineer, I give a lot of advice about mindset. I don’t just say what you should do, but what you should think and feel. In effect, I’m advising my readers to adjust their personalities into a more professional mold. This definitely works . If you turn yourself into the kind of person who’s successful in big tech companies, you will probably be more successful in big tech companies. Is this safe? I think so, as long as you’re adjusting your work personality, not your authentic internal self. The well-known accounts of why it’s dangerous either assume that your work takes a physical toll (like Marx’s factory workers), or that you’re unable to maintain any mental distance between your personal and professional selves (like de Beauvoir’s “serious man”). Debord and Vaneigem say that role-playing can be dangerous, but if you’re able to avoid treating it like an addiction you’ll be okay. Another danger is that being a professional is often humiliating, and humiliation does mental damage over time. Still, there are jobs that are way worse in this respect than “software engineer”. If you approach the job right — and you’re good at it — technical ability gives you quite a lot of power . Power is an antidote to humiliation. Everyone gets to make their own deal with Mammon . You can decide exactly how much you want to compromise in exchange for wealth and career success. I don’t know if this is the best way to organize the world, but it’s the way the world is organized right now. Given that, I’m comfortable with my blog serving as a guide for how to get the most bang for your buck. If trading your integrity for wealth and power is sad, it’s even more of a tragedy to throw it away for nothing. It’s always terrifying discussing Marx: like Hegel or Kant, he’s one of the most studied philosophers in the world, so there’s no way to reference him without getting a bunch of things wrong. Sorry in advance to any Marxist scholars! Because they own the machines, or the factory, or the datacenter, or whatever gives your work high leverage. Marx also writes a lot about work making the worker sick, deformed and misshapen: I think here he’s talking about the physical toll of factory work or other hard physical labor, which doesn’t really apply to software engineering, so I’m going to focus on the relative-empowerment stuff. Marx’s own taxonomy has four different senses: he collapses 2 and 3 into a single sense, then adds a third mysterious sense in which workers are estranged from their “species-being” and thus from each other. Plausibly Marx is talking about labor and capital in general : if every worker decided to start half-assing it, maybe companies would be less capable in general, and the balance of power would tilt more towards labor. That may change! If it turns out that LLMs really do have negative cognitive effects, we could be in the same boat as factory workers. I wrote about this in Software engineering may not be a lifetime career . Vaneigem resigned from the group in 1971, was fiercely denounced by Debord, and the whole group disbanded in 1972. True or not, my sense is that Millennials and later generations think that worrying about “selling out” is a sign that you had it too good. Consider the endless anecdotes of Boomers and GenX-ers living in a van surfing until their mid-thirties and then walking into a good office job because they had a firm handshake: they could afford to be authentic because they didn’t have to hustle. I only read the Marx, Debord, and Vaneigem texts while researching this blog post, but I did in fact read Sartre and de Beauvoir for my philosophy degree, so hopefully I do a better job. And Robert Jackall’s Moral Mazes , which informs much of my writing, and about which I owe a long-form blog post one of these days. There’s a good Goffman quote: “A status, a position, a social place is not a material thing, to be possessed and then displayed; it is a pattern of appropriate conduct, coherent, embellished, and well articulated.” Goffman goes on to explicitly link Sartrean “bad faith” to this kind of professional role-playing. (For Goffman, it’s roles all the way down.) Alienation is when your work empowers your employer more than you, thus making you more disposable over time Alienation is when your work separates you from the physical act of craftsmanship (and thus of the product you’re creating) Alienation is when your work physically and mentally harms you: making you injured, deformed, and so on Alienation is when you do not psychologically “confirm yourself” in your work, because you’re working on other people’s goals instead of your own Capital is intrinsically an alien force Workers can become addicted to role-playing Treating work as an ultimate source of value is self-deception It’s always terrifying discussing Marx: like Hegel or Kant, he’s one of the most studied philosophers in the world, so there’s no way to reference him without getting a bunch of things wrong. Sorry in advance to any Marxist scholars! ↩ Because they own the machines, or the factory, or the datacenter, or whatever gives your work high leverage. ↩ Marx also writes a lot about work making the worker sick, deformed and misshapen: I think here he’s talking about the physical toll of factory work or other hard physical labor, which doesn’t really apply to software engineering, so I’m going to focus on the relative-empowerment stuff. ↩ Marx’s own taxonomy has four different senses: he collapses 2 and 3 into a single sense, then adds a third mysterious sense in which workers are estranged from their “species-being” and thus from each other. ↩ Plausibly Marx is talking about labor and capital in general : if every worker decided to start half-assing it, maybe companies would be less capable in general, and the balance of power would tilt more towards labor. ↩ That may change! If it turns out that LLMs really do have negative cognitive effects, we could be in the same boat as factory workers. I wrote about this in Software engineering may not be a lifetime career . ↩ Vaneigem resigned from the group in 1971, was fiercely denounced by Debord, and the whole group disbanded in 1972. ↩ True or not, my sense is that Millennials and later generations think that worrying about “selling out” is a sign that you had it too good. Consider the endless anecdotes of Boomers and GenX-ers living in a van surfing until their mid-thirties and then walking into a good office job because they had a firm handshake: they could afford to be authentic because they didn’t have to hustle. ↩ I only read the Marx, Debord, and Vaneigem texts while researching this blog post, but I did in fact read Sartre and de Beauvoir for my philosophy degree, so hopefully I do a better job. ↩ And Robert Jackall’s Moral Mazes , which informs much of my writing, and about which I owe a long-form blog post one of these days. ↩ There’s a good Goffman quote: “A status, a position, a social place is not a material thing, to be possessed and then displayed; it is a pattern of appropriate conduct, coherent, embellished, and well articulated.” Goffman goes on to explicitly link Sartrean “bad faith” to this kind of professional role-playing. (For Goffman, it’s roles all the way down.) ↩

0 views
neilzone 3 days ago

On lawyers, ethics, and integrity

I have been reading some of Richard Moorhead’s new book, arising mainly from the UK’s Post Office scandal, “Frail Professionalism? Lawyers’ Ethics after the Post Office and Other Cases” . It is open access, and available as a PDF (linked above), with html available too; I have not found, nor made, an ePub. I focussed on chapter 8, “Routes Back to Proper Professionalism” , to see the author’s recommendations. Mainly, I was reading this through the lens of “what can I, personally, do better”. For anyone reading this who does not know me, it might be worth noting here that my work is predominantly Internet and telecoms law (with a side helping of data protection). My work is fundamentally commercial in nature, whether it is advisory (as a lot of it is) or transactional. Day to day, a lot of it is simply “solving problems”. I don’t litigate or go to court. I don’t prosecute people. I do not get involved in employment disputes. For me, a key part of my toolkit for solving problems entails building enduring, trusted relationships, through being honest, reasonable, practical, and diligent, to be able to collaborate in an open, genuine manner. As a consequence, I place considerable stock in my personal integrity. These things are important to me. So, of course , I like to think that I already act with integrity and with ethics - these traits are important to me - but I would be foolish to think that there nothing I could do to improve, or that I could not reflect usefully and meaningfully on my own approach. This is not a review, far less a critique, of the book and more me just noting parts which I found particularly resonant, and reflecting on my own working life. What we see in the PO scandal is information being processed based on what is arguable or helpful rather than what is true, fair, and balanced. A culture of ‘can we get away with it?’ is driven by wishful thinking and legitimised by lawyerly zeal. I think that this is particularly true when someone has determined the conclusion that they wish to reach, and is asking for legal advice to support that pre-determined outcome, irrespective of what a neutral, independent appraisal of the situation might conclude. Conversely, if someone has a goal in mind, but is genuinely open to hearing “there is no appropriate (that’s a tricky word; that needs unpacking) way of doing it, but here are some alternatives”, then that is rather different. [Lawyers] compete on being commercial, and more business partnerish. Yes, absolutely. For me, “being commercial” means giving my clients practical, sensible advice, consistent with the broader context of whatever the issue might be. It does not mean - to me - being willing to bend rules, or look away, or act unethically because that will maximise revenue, or increase shareholder value, or make a problem go away, and so on. For what it is worth, I think that “being commercial”, in the sense of my definition above, is a desirable trait in a solicitor. People want, and deserve, pragmatic problem solving, at a reasonable price. If “being commercially aware” is being used as a shield for impropriety, then that is indeed problematic. If a lawyer is asked for an opinion that will foreseeably assist illegality or mislead others they should decline or take reasonable steps to prevent or limit that risk. Yes. I am struggling to see how preparing advice with the intention of misleading someone could be consistent with a professional duty to act with integrity. Harm to a client’s opponents, for instance, cannot always be avoided, but being required to consider and, if proportionate, mitigate or alleviate harm might reduce some of the unnecessary excess that lawyers engage in. I am not entirely sure what the author is angling at here. It is a short section, almost standing on its own. Could it, for example, condemn the common and (to my mind) unsavoury practice of timing letters, and ensuring deadlines, over holiday periods, to cause maximum inconvenience and stress? Quite possibly, where that is a tactic in itself. Writing friendlier, or at least more neutral, less aggressive letters? Some lawyers trade on aggression. I don’t; that’s just not me. In terms of mitigating harm, if I act for Client A, negotiating a contract with Client B (who is also represented), how far would a duty to “alleviate harm” extend? Would my duty extend to helping Client B achieve the best deal for them, for instance (rather than focussing on my own client’s objectives)? How far would it go into trying to solve someone else’s problems? (Reaching a deal which is in the interests of both parties may well be desirable for all number of reasons, but that is separate to a professional duty.) It is curious that this is formulated adversarially, in terms of a “client’s opponents”. It presupposes litigation or conflict. I wonder to what extent it might apply to, say, advice in developing a computer system, where the system could adversely impact the rights and freedoms of third parties who are not “opponents”. Would it stretch to a professional duty to only advise in the context of designing the least harmful online services, for example. Perhaps not a bad thing, although placing that on the doorstep of solicitors, rather than on the companies developing those services, seems backwards. Ethical knowledge and practice should of course be a routine and proactive part of competence review for all lawyers I would be all for the regulator producing an annual ethics refresher course - perhaps an hour or so’s reading. That would seem very helpful. We need to more clearly challenge the claim that lawyers do law but not morality I agree that “this is arguably legal” is a very low standard. Similarly, that what is legal is not the same as what is right . I wonder how morality would be judged. Does it depend on a solicitor’s own sense of what is moral, or on some subjective notion of morality? What of the situation in which there are two, perhaps polarised, stances, with groups behind each stance claiming that morality is on their side? I don’t think that I object to the notion of solicitors needing to consider morality, but in terms of how that professional duty should be constructed, that seems to need quite careful thinking. Perhaps it has already been tackled in other jurisdictions.

0 views

A curmudgeon tries a language server

I write code roughly the same way I did ten years ago: I make edits in my text editor, I switch over to a terminal window and I run a command to compile and execute the code. I look at the result, then switch back to my editor. If I am unsure of what happens, I either add tracer prints to the code and restart the program, or I restart the program in a debugger. If I hit an exception that crashes my program, I fix the problem and then restart it. I’m envious of what Lisp programmers do. Lisp development typically happens by typing code directly into the REPL to add, remove, and replace parts of the live, running system. (Continue reading the full article on the web.) A Lisp programmer does not need to “switch over” to something else because they are already inside their program process. They never “compile and execute” the code because the code is already running and they edit it by hot-swapping code. They never restart in a debugger because they are already inside their program process and can inspect anything they want. They don’t have to restart the program on exceptions, because the condition system allows resuming the crashing code from anywhere in the stack after the system has been patched with a fix.

0 views
Sean Goedecke 1 weeks ago

You should never be angry at work

I try not to give a lot of prescriptive advice about working in tech companies 1 . There are many ways to be successful, and every company works differently. If you’re shipping projects and your management chain is happy, it doesn’t really matter how you’ve accomplished it. However, there’s one thing that I do think is solid advice: you should never be angry at work . Anger in the workplace is toxic. An angry colleague immediately becomes a new problem to be managed, not a professional helping you manage problems. When someone is visibly angry in a meeting or in Slack, it kills the entire atmosphere: other engineers will often go quiet entirely, not wanting to make the situation worse. If you routinely “get heated” at work, the best-case scenario is that you’re part of a tight-knit team of confident people who aren’t put off by it 2 . No harm, no foul. But the second someone comes onto your team who’s not so confident, or you have to communicate outside of your team, it becomes a big problem. Healthy workplaces route around anger in the same way that networks route around damage. Emotionally unreliable engineers will get left out of conversations that might cause them to blow up. Decision-making will get done around them in backchannels. I’ve seen this become a self-reinforcing cycle: angry engineers aren’t consulted on key decisions, which makes them angrier, which pushes them even further away from the spaces where decisions get made, and so on. You can often find these engineers bitterly complaining that they keep the company together, but nobody ever listens to them. In my experience 3 , this is almost never true. Engineers who are highly effective tend to get listened to — at minimum by their colleagues, and eventually by managers and product managers who want to extract as much value as possible from them. (One reason this is true is that all successful projects involve working with other people, and if nobody listens to you, you can’t do that.) Why do angry engineers believe they’re important? Paradoxically, anger can be really useful to a software engineer . Angry engineers are rarely the ones holding the company together, but they’re also rarely useless . One surprising thing about working for big tech companies is that some engineers are not just unproductive, but actively net-negative : either because they’re incapable of doing useful work on their own, or because they’re sloppy enough that they create more work than they do, or because they’re so checked out that they literally do nothing. Angry engineers might be net-negative in a cultural sense, but in terms of literally solving tickets and shipping features, they’re usually well above average. Why is this? Anger often comes from caring about your work, and caring a lot is sufficient to make you a competent engineer . I’ve never worked with someone who genuinely cared about their work who wasn’t (or didn’t eventually become) competent. I actually think it’s healthy for an early-career engineer to sometimes get angry about their work, because it means they care a lot: it’s still a mistake in the moment, but it’s a “good mistake” . I certainly used to get angry — in fact, I wrote about the angriest I’ve ever been at work here 4 . But you have to move past it . Think of “caring about your work” as a vertical tube, unsealed at either end. You fill the tube by pumping in emotional investment from the bottom 5 . If you have too little, it drains away and you end up as a useless coaster. But if you have too much, it overflows and you end up as an angry engineer that people have to work around. One solution is to try and care the exact right amount: be invested in work a bit, but also have hobbies and a family and whatever else gives you perspective about your work problems. If you have a rich and healthy personal life, it’s hard to find yourself yelling at somebody about React state management. However, this is a tricky balance to maintain over time. Another solution is to care about different things. The reason too much caring overflows into anger is because what you care about is misaligned with what the organization cares about . If your interests are perfectly aligned with your company’s (for instance, if you primarily care about delivering shareholder value ), you can fit way more emotional investment into the tube before it overflows. Here’s some dangerous advice : showing a little bit of anger at work can sometimes be useful. It can be a good way to signal that you care, or to build rapport with certain people, or to draw attention to something you think is important. However, it’s still always a mistake to be angry. You need to be able to drop back to a friendly mode at will, which is very difficult when you’re genuinely angry. Being able to show a full range of emotion at work is good. It makes you more persuasive and more human. Being a fully professional robot is fine — you can have a successful career this way — but there’s always going to be some kind of uncanny-valley HR-ness to your work persona that will make it hard to connect with your colleagues. If in doubt, don’t show anger. It’s never wrong to be professional. However, if you can signal that you’ve got enough distance to separate your professional feelings from your real feelings, and enough perspective to realize that the stakes of a technical decision are fundamentally not that high in the grand scheme of things, it can sometimes be okay to show visible frustration so that people know you’re still human. Well-known software engineering personalities are often angry. It feels unfair to give too many negative examples, but obviously Linus Torvalds’ rants about Linux are a great example. Some of my favourite engineering talks are from Bryan Cantrill, who is sometimes visibly furious at his subject matter. There are too many well-known angry blog posts to list, but I’ll cite one I genuinely like: my Australian blogging colleague Nikhil’s post titled I Will Fucking Piledrive You If You Mention AI Again . Anger is a part of the general image of a competent software engineer. Many junior engineers learn from this that it’s okay to be angry. However, taking your emotional cues from engineering celebrities is a big mistake, for a few reasons. First, you are not Linus Torvalds or Bryan Cantrill . Torvalds is the BDFL of the most important software system in the world. Cantrill is the cofounder and CTO of his company. When these people are angry at work, people will not work around them, because they are the ones deciding what gets worked on . Once you’re the one in charge, you can get away with being emotional in the workplace 6 . Second, you don’t know what it’s like to work with these engineers . People give talks and write blog posts because they’re emotionally worked up about something. If your only exposure to a celebrity is via their conference talks and blog posts, you’re seeing them at something like their maximum emotional intensity. If you then take that level of emotion into your normal everyday work, you’re almost certainly overshooting. I’ve been reorged into dysfunctional teams, have had projects I enjoyed cancelled, and have worked on systems that were extremely chaotic. I can’t remember the last time I was actually angry at work. To be clear, I’m not successfully hiding my anger (unless it’s so repressed it’s invisible to me as well) 7 . Nor am I naturally a chill person. I’ve just reached a point in my career where I genuinely don’t get upset about work stuff. A cynical person might say here that I’ve stopped caring about my work, so of course I don’t get angry anymore. I’ve left the side of the “real engineers” — the Linus Torvalds and Bryan Cantrills of the world — and sold out for that sweet, sweet big tech money. I mean, maybe! It’s true that I’m less invested in specific technical decisions than I used to be. But I still care a lot about doing a good job, I still spend a lot of time tweaking and reading code, and I certainly get more done than I did when I was more emotionally volatile. Being angry at work feels good. It feels like proof that you’re working on something that matters, and that you’re personally having an impact. If you’re angry, nobody can call you a coaster. But anger is only a local maximum. If you can find your way to a different style of working, you’ll not only be more effective, but you’ll be in a far better place to have impact on problems that actually matter. Mostly, I fail . As I understand it, this is the work environment that most famously angry engineers came up in. My experience is certainly limited (a handful of companies, and maybe ten different teams or organizations). I can certainly believe it happens! About halfway down, in the section titled “it’s not your manager’s fault”. Emotional investment is a liquid with the viscosity of water. To a point. Even Torvalds famously said he’d gone too far with the anger and decided to turn it down a bit. I suppose I’m not the best person to judge whether this is true. If you work with me and I do come across as an angry guy, please do tell me. Mostly, I fail . ↩ As I understand it, this is the work environment that most famously angry engineers came up in. ↩ My experience is certainly limited (a handful of companies, and maybe ten different teams or organizations). I can certainly believe it happens! ↩ About halfway down, in the section titled “it’s not your manager’s fault”. ↩ Emotional investment is a liquid with the viscosity of water. ↩ To a point. Even Torvalds famously said he’d gone too far with the anger and decided to turn it down a bit. ↩ I suppose I’m not the best person to judge whether this is true. If you work with me and I do come across as an angry guy, please do tell me. ↩

0 views
Martin Fowler 1 weeks ago

Fragments: August 18

Part of the reason why I’m at Thoughtworks is because I’d like to see a software development organization founded on technical excellence as an example for the rest of the industry. The trouble is that I have little aptitude or inclination for the hard work of building such an organization. So I rely on working with people who are prepared to actually put the effort in. A key partner in all of this is Rachel Laycock , who is the global CTO of Thoughtworks. Not just is she far better than me at running a technology organization, she’s also a keen observer and connector of ideas. I’ve been urging her to write these down, even if her busy schedule makes it difficult for her to compose them into something substantial. Happily she’s starting writing “Rachel’s Ramblings” Fast, imperfect, thinking out loud. Naming ideas early rather than waiting until they’re fully formed. Because the reality is, most of what I do day to day isn’t answering known questions. It’s spotting patterns and asking questions we haven’t quite figured out yet. ❄                ❄                ❄                ❄                ❄ My colleagues in Europe are organizing XConf Europe in London on September 11th . The sessions examine what happens when agentic systems meet compliance, how to run sovereign models, performance patterns in data migrations and how to safely navigate legacy codebases. Lu Wilson will give a keynote on ‘Jam-oriented programming’. ❄                ❄                ❄                ❄                ❄ Noah Smith recognizes the high usage of AI, and its impressive feats - but also that there aren’t signs of massive productivity growth or job losses . This may be the calm before the storm, but Smith thinks there may something else in play. He quotes a metaphor from François Chollet One of the biggest misconceptions people have about intelligence is seeing it as some kind of unbounded scalar stat, like height. “Future AI will have 10,000 IQ”, that sort of thing. Intelligence is a conversion ratio, with an optimality bound. Increasing intelligence is not so much like “making the tower taller”, it’s more like “making the ball rounder”. At some point it’s already pretty damn spherical and any improvement is marginal. The thought here is that intelligence in the sense that we know it, isn’t something where there’s a lot of room for massive improvement. That doesn’t mean AI won’t be “smarter” than us in other respects, after all even without AI my computer is better at me than remembering what I’ve agreed to do over the next six months. But even if AI doesn’t get smarter than humans, it can gain by being more replicable. Not just does this make it cheaper to use, perhaps more importantly it makes it more responsive. While I might harrumph at how slowly The Genie responds to my queries, it’s still far faster than contacting a human. Smith continues by surmising that AI may be able to make sense of phenomena that can’t be reduced to simple laws, but can only be understood by something able to comprehend a multitude of details: there may be laws of the universe that humans can’t understand but AI can. I call these “cloud laws” — causal regularities that can be exploited by technology, but which are too diffuse and complex for an individual human being to either intuit or communicate. His thought is that even if there isn’t any space for AI to get more intelligent than humans along the lines we are used to, that they can open up new directions. As well as these cloud laws he also thinks that AI can understand human systems that rely on the kind of tacit, distributed knowledge that human organizations build up over time. My take-away here is that AI won’t seem more intelligent in the way that we typically frame intelligent, but more intelligent in different ways. The converse of which is that the human value comes in artfully combining our human nature with these new spells that The Genie can cast. ❄                ❄                ❄                ❄                ❄ Especially in our profession, we’ve seen increasing emphasis on the importance of data. However I’ve observed that most people still struggle to understand the message data is telling us. One of the reasons I’m interested in election forecasting is in how they communicate their insights, especially since so many people have difficulty with probabilistic forecasts. (I often wonder how much being a board-gamer has helped me be comfortable with this, all that time interacting with Combat Results Tables in my youth must have benefited me somehow.) 50+1 (one of the successors of 538) have published a little explainer on how they designed their 2026 election forecast page . There’s a good discussion of the logic behind their simulation histogram, I like how they use a text annotation to explain one point, giving the reader enough guidance to understand the rest of the graphic. They also tackle the knotty problem of visualizing geographical data on the house races. There’s a common visualization error in the U.S. using choropleth maps that leads to large areas of the landmass shown red, implying dirt votes rather than humans. Their approach to this, using dots on the map, helps visualize both the politics and the population density. They also explain how to deal with this kind of data on small screens. Lastly they describe their approach to tabular data, and how this is the right place for lots of details, together with affordances to help both casual and power-users navigate those tables. ❄                ❄                ❄                ❄                ❄ I’ve kept an eye on Alex Stamos for a while now, as he’s a sensible voice on security and safety. He’s posted a newsletter on substack that casts an intelligent eye over recent safety issues with AI . He makes a clear critique of recent US government actions around LLM models On a Friday afternoon at around 5pm PT, Anthropic was forced to shut down a system that had been plumbed into coding agents, SOCs, customer service bots, and countless products. […] This had the immediate effect of injecting political risk into the US AI ecosystem for both American and non-American customers. It signaled that you cannot depend on American AI infrastructure because, at any moment, an unwritten, capricious, and legally dubious justification could be used to yank that infrastructure from underneath your feet. When Fable was turned back on, it was much dumber and less useful to cyber defenders While Fable was down, Z.ai was taking advantage of the free market and permissionless innovation culture provided by the (checks notes) General Secretary, Politburo, and Communist Party of the People’s Republic of China, and released GLM 5.2. With 753B parameters, it falls a bit short of Opus 4.8 in most tasks but is extremely efficient and is small enough to be trained and hosted in many enterprise contexts. With an MIT license it can be fine-tuned with a wide range of techniques and used by any customer in any context. Since then, Kimi K3 has rocked the industry by providing Fable-like performance As he highlights, one of the biggest dangers with the danger of shutting down a frontier model is that it can cripple an organization’s defenses: Hugging Face tried to use an Anthropic model to defend itself during an active incident, got blocked by the classifier, and moved to GLM 5.2 on an emergency basis. Their advice to everyone else was to keep an open-weight model on the shelf for defensive cyber. On the whole, he sees it as a Good Thing that these model escapes have happened: The OpenAI attack against Hugging Face, and Hugging Face’s excellent write-up has given us a preview of what a standard AI-enabled attack might look like in a matter of months. It’s good that we got this warning shot. Nobody got hurt, the target was a sophisticated actor with the ability to defend themselves and the ability to give us a detailed write-up, and OpenAI turned the model off. He follows up by saying that all of this is signal that we should “stop talking about AI finding bugs, focus on fixing them”. These modern LLMs can do much to fix bugs and improve security, and people need to work on that rapidly to fix holes before less reputable folks than OpenAI find them. Then figure out how to harness LLMs to introduce this kind of checking into the everyday build process, so that this kind of analysis just a step in the continuous delivery build pipeline. I agree with him both that open-weight models should be legal, have their upsides, but will also be used for many bad things by bad actors. Both the industry and government agencies need put serious effort into figuring out how to mitigate these risks. Where I would go further is to say the same is true of the closed-weight models too. Although closed weight models are subject to greater controls, the same fundamental issues apply. He rightly takes the foundation model companies to task: There is an old saying I pass down to my students when I give them career advice - if you are a jerk to people on your way up, don’t expect them to catch you when you are on your way down There’s a lot of sound advice for model companies, the government, defenders, and venture capitalists. We will go through some rough changes, I just hope that we will indeed come through it with a better society. On the whole, that’s happened with previous technological changes like this, but past performance does not guarantee future results. ❄                ❄                ❄                ❄                ❄ The Economist has a good article on the impact of AI in China . China has made an all-out push in ai, under the conviction that, in its competition with America and the rest of the world, dominance of the technology is an almost existential necessity. […] But the party is increasingly concerned about how ai will displace workers. Robots and AI are appearing in an economy that’s struggling after the recent property crisis. The Chinese government is opposing firms using AI to cut jobs. China will need robots: its population will shrink by 25% by 2050. But with less working people, there’s less financial support for pensions. Many countries have to deal with shrinking population, but China’s challenge is particularly acute. ❄                ❄                ❄                ❄                ❄ Rob Bowley: I go on holiday for a few weeks and we’ve already moved on from Loop Engineering to Graph Engineering The half-life of a paradigm is getting shorter than my annual leave My prediction: neuro-symbolic engineering by the end of August, at which point we’ll have gone full circle and reinvented Prolog

0 views
Dan Moore! 2 weeks ago

What I Learned From Playing “Spelling Bee”

I’ve been playing Spelling Bee for a few weeks now, where you guess words from a selection of seven letters, one of which must be used in every word. The letters are arranged in a hexagon with that primary letter in the middle. If you want to learn more about how to play it, follow the directions here : For information on how to play, select the More in the top right corner of the game and then select How to Play . It has surprised me. I have learned that “oleo” is a word and that you can tell how hard the puzzle will be by looking at the rankings. But what I really wanted to talk about is the lessons I’ve learned from playing and how they can apply to your career. Switch Things Up There is a button that can flip around the arrangement of the letters around the hexagon. The primary letter remains in the center, but all the others are moved around randomly. When I first saw that, I thought it was silly. But I found it to be super useful over time. When I’m looking for words, I get stuck. Pressing the rotate button reveals new words because it changes my perspective. Just moving the letters around makes new words visible to me. In real life, when you feel stuck, you can sometimes make progress by flipping things around. I’ve done this in my career. I quit my first head of engineering job where I was trusted by the CEO, had loads of autonomy and worked on software that helped people find homes they loved. After, I enjoyed the freedom of lucrative contracting and learned a ton about other tech stacks. I took a quarter life sabbatical when I was around 25. After months of leisure, I learned that, yes, I really did like reading about parsing XML. I left the food-focused startup I’d co-founded (an area I’d dreamed of working in) which had just raised a seed round. Departing led me to an entirely different area of the software industry that I love and never would have explored at the startup. There are of course other ways to gain new perspective than quitting jobs: changing routines, asking friends for advice, or even taking a new route to work. Before you give up on something, flip the script and see what the results are. Just Try Something Sometimes you just have to try things. I will often put in words that I know are not valid, just mashing different combinations of vowels and consonants, like “manu”. This is not an English word, nor will it ever be. Spelling Bee also disallows proper nouns and three-letter words, but I’ve definitely put in plenty of those. Even though these are all invalid moves, they are movement. This helps me not feel like an idiot just staring at a phone screen. Even better, it can trigger other ideas. It’s a lot easier for me to visualize a full English word when I see part of it, rather than staring at those seven letters in a hexagon. After typing “manu” I found “manual”. There is value in just taking a step forward if you aren’t sure what to do. If you have some kind of goal in mind but aren’t sure how to get there, do something. Take a step towards that goal. If you are trying to get a job in the software industry, especially right now, it can feel overwhelming: so hard, so difficult. But you can take concrete steps towards that goal that are smaller. These steps, when you’re looking at them, may not make 100% sense and won’t make you money. But they are helping you on the path towards employment, and will lead to other steps to take that will get you closer to the goal. I’ve written before about how attending meetups is a fantastic career move . Doing so doesn’t have an immediate payoff, which is super frustrating when you’re trying to find a job, when your bills are piling up and your savings are draining. It’s super hard to think “I’m going to take an hour out of my day and go hang out with geeks talking about ruby “. But joining a meetup can open up other doors. Just like typing “manu” reveals “manual,” going to a meetup repeatedly can help you get a reputation in a community, offer contract opportunities, let you understand the market, and may help you get a job. This is just one example. There are a thousand different steps you can take towards your goal. It can be hard to determine which step is the right step, but the lucky thing is that there are many right steps. You just have to start. Double Down On What Works I like to double down when I have a pattern that is working. In Spelling Bee, if you see a pattern of “ull” being a portion of a word, you should double down on that while you’re thinking about it, and make all of the “ull” words you can. Same with suffixes like “ed” or “ing”. When I see that, I know that I can spell both the initial word like “mint” and get more points by adding “ing” to get “minting”. Even though I have 100% been guilty of a grass-is-greener outlook in my life, where I think, “oh, I’m frustrated with this company, or in this position, or with this situation, it’ll be better over <somewhere else>”. But after 25 years in software development, I know that every place has its issues. I was recently talking to a former colleague, and he was just hired at a super impressive top-tier company. He was talking about some of the issues they have and some of the burning fires. I would not have suspected it from the outside, because they look like they’re killing it. Sometimes, you should look for the good things in your current position and double down on them. This isn’t the same as staying stuck; it’s the opposite of that. Instead, this is about noticing when something is actually working and resisting the urge to abandon it just because it’s familiar. Switching helps when nothing is working; doubling down helps when something is. What does it look like? It might be working a bit extra, taking some free time to study for an employer-funded professional certificate, making small improvements to your team’s workflow, or just bringing your best self to work every day. All of these are taking what works and doing more of it. Double down on what is currently working for you, and it’ll make you happier and you’ll score more points. Three lessons I learned from the Spelling Bee game: switch things up, just try something, and double down on what works. Who knew that looking for words could be so educational?

0 views
Kev Quirk 2 weeks ago

On Publishing Your Salary

One of my favourite things to do online is perusing the IndieWeb . It's fun, and I've been able to discover a tonne of interesting people along the way. But every now and then, I come across someone who has published their salary history on their site. At first, I thought this was a great idea. It feels transparent, and it theoretically gives people an idea of what they could or should be earning in a particular field. But as I've discovered more people doing this (for the record, I've only seen it a handful of times), a pattern seems to have emerged that makes me think it might actually have the opposite effect. Before we go any further, I want to state for the record that I have nothing against people publishing their salary. If you want to do it, that's entirely your call. Personally, I've decided not to post it here, but I am open about it - if you want to know what I earn, email me and I'll gladly tell you. Discussing pay here in the UK isn't as taboo as in other parts of the world, either. We actually have legislation in place that allows us to talk about our salaries with co-workers. So what's my concern? Of the handful of times I've seen people sharing their salary history, they are always very high. For context, a six-figure (£100,000) salary in the UK puts you in the top 4% of earners in the country . This is where my concern starts - we only ever see these high outliers, so the sample size is incredibly skewed. Nobody is rushing to publish their £25,000 salary history, which means the curmudgeon in me can't help but feel that these pages can sometimes read more like a humble brag than genuine advocacy, even if the author's intent was entirely pure. For the reader, this can be deflating, rather than empowering. A developer earning a perfectly respectable £50k (which already puts them in the top 15% of UK earners) might look at Jane Smith earning £105k and think, "Jesus, I'm doing terribly." But salary is highly subjective. It depends on where you live, the company you work for, the unique responsibilities of your role, what your peers earn, how hard you negotiate, and how supportive your manager is. When you strip all that context away and just publish a high number, what is the reader supposed to do with it? If our developer goes to their manager and asks for a 100% pay rise because they saw Jane Smith online earning £105k, they're going to be laughed out of the room. Because, without context, the raw numbers are useless. I'm all for paying people the maximum amount possible for good work, but unfortunately, we live in a world where many organisations want to pay their staff the minimum they can get away with. I don't know what the perfect answer is, but I don't think it's telling people to stop sharing. Transparency is important, and it's severely lacking in the corporate world. Perhaps the solution is context? If you feel comfortable publishing your salary, maybe add a disclaimer explaining the unique circumstances behind it, stressing that it's a record of your personal journey, not an industry target or a standard benchmark. Or, maybe just ignore everything I've said in this post, as who am I to tell you what to do with your site. 🙃 I've thought about adding a salary page to this site many times, but I've always held off. Honestly, I think I'm grossly overpaid for what I do, especially compared to roles like nurses, police officers, or members of the armed forces. I'm incredibly grateful for it, and I've worked hard to get here, but I don't want to add to the noise. If you publish your salary on your site, more power to you. But it's worth considering how that number might be perceived by the people reading it, and whether it's truly helping them or just making them feel left behind. 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 .

0 views
pSYoniK 2 weeks ago

All Your Projects Are Now Brownfield

LLMs promise that we can tackle any new project we want, greenfield is the default, but the reality is that brownfield is the new norm. You’ll always work on an ’existing’ codebase.

0 views
Sean Goedecke 3 weeks ago

How to keep thinking

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

0 views
Herman's blog 3 weeks ago

Committing to creativity

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

0 views
Ankur Sethi 4 weeks ago

Prevent cognitive debt by manually retyping LLM-generated code

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

0 views
Sean Goedecke 4 weeks ago

Giving and taking credit in big tech companies

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

0 views
Allen Pike 1 months ago

Weighing the Business Case for Quality

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

0 views
Unsung 1 months ago

“Insights and ideas emerge from that interface.”

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

0 views
Ratfactor 1 months ago

How I got through my inbox in only two months

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

0 views
iDiallo 1 months ago

BI Slop

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

0 views
Kev Quirk 1 months ago

Toot.community is shutting down

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

0 views