Thanks for writing this. There’s a severe shortage of this kind of concrete, detailed example in discussions about how people are using these tools.
One thing that strikes me about the examples in the article is that they’re all small, self-contained, greenfield projects with no existing coding conventions or architecture. I’m far from the first to observe this, but my hunch is that one of the reasons I haven’t had as much success with these tools is that very little of my work fits that description. The vast majority of my day-to-day coding involves modifying an existing code base with a lot of moving parts whose behaviors are mostly governed by a messy pile of domain-specific business rules that have accumulated for years.
My experience with various tools (disclaimer: I have only this week started to try out Claude Code, so maybe it’ll be better) is that they can be okay at following low-level technical requirements, but they struggle with higher-level concepts and make lots of fundamental mistakes based on not having a big-picture understanding of how all the pieces fit together.
They’ll know that the data model has entity types A, B, and C, but won’t know that an instance of C can only exist if there’s a corresponding B. So they’ll write code that creates a new C in isolation. The agentic tools will then spin their wheels trying over and over again to fix the fact that the “create C” function is bombing out, but they’ll never notice the problem is actually the lack of a B. I then have to spend time iteratively nudging them in the right direction and it quickly gets into “would have been faster to just write the code myself” territory.
On some level, I suspect that this is a documentation failure. It takes a new engineer on my team a bit of time to come up to speed, and they spend much of that time pairing with or picking the brains of the existing team members to learn things they couldn’t find in our internal docs. Some of the things that take new team members the most time to learn are the same ones LLMs struggle with. Maybe if our docs were better and talked in depth about those things and were kept up to date, both LLMs and new engineers would struggle less.
However, to the tools’ credit, I’ll say my team has seen much more impressive results in UI code. Our web app is fairly standard React/Redux code and LLM tools seem to cope with it a lot better. I don’t work on UI code too much, but I know our frontend engineers have been saving time asking tools to write new components for them and such. Even for them, it’s not a “3x more productive” level of gain, but it seems significant.
A big issue with these tools is that they are supposedly “intelligent” and therefore should be capable of doing everything. Products like Claude Code, Cursor, etc. reinforce that impression. But it is the wrong way to go about it. They are not intelligent, and the task quickly becomes too big for them.
An LLM is a tool, like a drill or a screwdriver. But what they try to sell you is a machine that can hang a painting on your wall. That machine will inevitably make a mess in any situation that is not ideal, but drills and screwdrivers are quite useful.
My number one use of LLMs with coding is this: write a // TODO comment, pipe the function (or the file) to a local, not brilliant LLM, and replace it with the response. That’s it.
As @xigoi mentioned here, in languages with grammatical cases, the form of {location} may vary.
It’s not very straightforward. Best-case scenario is actually that a noun that indicates a location is always the same case (e.g. accusative), and you just have some declension rules + a series of exceptions to remember because there’s always a few of those.
But some languages retain a locative case – i.e. they indicate a location by a specific form of the noun, rather than with a preposition like “in”. To make matters worse, the locative form may be gendered. E.g. in Polish it’s w domu, but w Austrii. Hopefully. Polish is special in every way there is :-).
To make matters worse, some languages retain the locative, or variants of a locative, but it’s no longer productive. I think the only European language here is Hungarian, which no longer uses the locative, but retains a locative form for some places.
And to make them even worse, some languages actually have different cases for relative locations. Some Baltic languages are like that. E.g. the “house” in “out of the house” and “inside of the house” would be in different cases (illative vs. ellative) and thus different forms (Finnish, which hopefully someone can correct me about if I got it wrong, would be talosta in illative but taloon in ellative.
I know that there are many other constructions in some African and Asian languages, but I don’t know enough about those. I know, for example, that there are languages where:
Locatives agree with verbs and other predicates, so the form depends on what’s between {user} and {location}.
The form of the verb depends on word order/agreement (I think some Bantu languages are like that: “to be” would have different forms when saying “the birds are in the tree” vs. “in the tree are the birds”).
Some locative forms can drop certain verbs (so the “is in’ is implicit if {location} is in a locative form).
It’s not so easy in English either. For example, “Please select an {object}”. If object is “pen”, then you get a grammatically incorrect English sentence. The use of “a” vs. “an” depends on the initial syllable of the following word.
And then you have an issue with “items”, because there are languages which don’t have an equally generic word that you can use. It would be either a different one depending on what you’re selecting, or would sound really clumsy.
That would encode English grammar into program logic, though. Pragmatic me wants to avoid it because it adds guilt from this list of falsehoods.
If that “s” string can be tied to this context (because gender affects pluralization) before given to translators, it can work beautifully for many other languages, but I heard at least slavic follows a different pattern.
Even in English it’s not complete: plural for potato is potatoes, not potatos.
I heard at least slavic follows a different pattern.
Yeah, slavic numerals are hard. In Polish: ziemniak - potato
1 ziemniak
2|3|4 ziemniaki
5-21 ziemniaków
22|23|24 ziemniaki
25-31 ziemniaków …
Sometimes the case is genitive, sometimes nominative 🤷.
As a native I can become puzzled given awkward and unnatural enough sentence. I was once shown an example from a C1 language exam: I danced with 21 girls. All variants of a numeral sound a little awkward in my head.
The big problem, if you care about translating your app down the road, isn’t even the “s” suffix. It’s the assumption that you use a particular word if there is exactly 1 of something, and a different word if there is any quantity other than 1 of the thing. That’s true in some languages, but it’s not universal.
In some languages, there are different forms of nouns based on quantity, but they don’t follow the “if 1, then X, else Y” pattern. In Russian, for example, it’s based on the last digit of the quantity. Mostly. If the quantity ends in 2, 3, or 4, you use one word form, but not if the quantity is 12, 13, or 14. If the quantity ends in 5, 6, 7, 8, 9, or 0, or it’s 11 through 14, you use a different form. And if the quantity ends in 1, but isn’t 11, the form varies depending on the grammatical context. (Disclaimer: I don’t speak Russian, but I remember Russian being a fun stress test of some pluralization code I worked on when I was doing i18n stuff.)
And it’s not always more complicated than English. In some languages (Chinese, for example) there isn’t a plural form at all. The concept of pluralization just flat-out doesn’t exist, aside from a small handful of plural pronouns like the words for “them” and “us.”
Rankings being like, 1st 2nd 3rd 4th … 11th … 21st … 111th, is an example of how much of a pain at least one language can be, let alone every other language’s approach. (I think some actually use completely different words between counting and ranking too, fun!)
Aside: There was a table I found one day that listed “all” the languages and their handling of counting, ranking, etc, and how to program around it. Forgot to bookmark it however.
I’ve been learning some Korean lately and picked up that what we’d say as “outside of the apartment” in English is more like “apartment outside” in Korean.
And the idioms are different. One interesting example from Dutch: “Hij lijkt op zijn vader” is “he looks like his father” in English but it’s ~literally “He looks on (top of) his father” which of course doesn’t make much sense in English.
LOL, despite what you say the verb means, that looks so much like Norwegian: “Han likner på sin far”, where “likne” is the verb for to “look like”. But yes, “på” means “on (top of)” here as well.
I was the tech lead of the internationalization effort for a popular website a number of years back. This was in the US. The site was English-only and we wanted to make it available in a wide variety of languages. We wanted to make it feel as native to each language as we could, rather than feeling like a translation of a foreign site.
My team and I came up with a bunch of internal tools and a flexible library we could use to make our code work in multiple languages. When I say “flexible” I mean it went way beyond simple token replacement; it could do things like look up different variants of sentences depending on whether a caller-supplied place name referred to a city or a country and whether that distinction mattered in the target language, could use different pluralization rules for different languages, took gender into account if a sentence mentioned a person whose gender was known, and so on. We had people with linguistics backgrounds making sure we didn’t fall into any obvious traps.
The code base was far too big for my little team to update on our own, so an early goal was to give the rest of the engineering team all the resources they needed to do a really good job of updating their own corners of the code. In addition to thoroughly documenting our tools and libraries, we wrote up a set of annotated examples of how to change existing English-only code to be translation-friendly, and we made sure it covered all the common patterns in the code base (including visual design things like assuming a button only needed to be exactly big enough to hold an English label) and included examples of what could go wrong in different languages if people decided to just do string concatenation instead.
Then we started rolling it out. My expectation going into it was like yours: that the monoglot American devs would struggle to embrace all the techniques because English-specific assumptions would be too deeply ingrained.
But once I started doing code reviews of people’s changes, the reality was different. It turned out there was no measurable relationship between how good someone was at making their part of the site translatable into a wide variety of languages and which language(s) they spoke. Americans who’d never spoken anything but English were just as good at it, on average, as trilingual Europeans or people whose native languages were very different from English.
The thing that floored me was seeing people from other countries repeatedly make mistakes that would have made it impossible to correctly translate part of the site into their own native languages. This happened a lot, and it happened across multiple native languages. It seemed to me like some people were able to put their brains in “human language is highly variable and the code needs to act accordingly” mode, and some people were stuck in “I am working in English right now, so everything is English” mode, and it barely mattered if they happened to speak some other language or not.
Maybe the situation would have been different if the site had been in more than one language from the get-go; I don’t know. But that experience really shattered some of my preconceptions about the advantages of speaking multiple languages. (For the record: I still think it’s worthwhile to be multilingual!)
The first job I had in Germany, having moved here as a fresh-faced monolingual foreigner, was kind of like this. We were building an internal tool that was used by warehouse workers in various European countries. We knew we had a lot of fairly monolingual users in a variety of different languages, so when we decided to redesign the tool, I pushed really hard for making sure that every part of the UI was fully translated into all the relevant languages. I was amazed by how much my German colleagues pushed back against this, saying it would be a lot of effort, and people could just learn what the different English-language messages meant over time.
There were things a decade ago that my non-American English native speaker coworkers (Romanian, Croatian, Indian [Hindi & Marathi]) learned alongside me who’d been doing localization for a while — back then, I spoke natively American English but had six school years of Latin, 10+ years of self-driven Esperanto, and smattering of (Mexican) Spanish and (Canadian) French — when we did a big project targeting 10 languages on release days and 22 within four weeks in a patch release. I’ve picked up Dutch and some Korean since then and I’m constantly learning new things about language having gotten into linguist sector of Instagram, Threads, Bluesky, and the fediverse.
Unless you’re a linguist, you’re always learning surprising new things about language, discovering new tools in the toolbox, per se. If you’re a linguist, you’re learning which has/does what because you’re more familiar with what’s in the toolbox.
Cool you’ve learned so many languages. I’m currently trying to learn a new language and struggling a bit so maybe you can help. What are your preferred ways to learn a new language and make it stick?
Consistent practice. Try to experience all modes - reading, writing, listening, speaking, and conversing.
Find media you like. You don’t have to be even at 50% comprehension to listen to some audio, but obviously you’re only going to get little bits.
Adverts are much simpler than anything except children’s media.
Experiencing the language is generally the best way to internalize the rules, but reading up on complex rules to help you practice them is also important.
Regular practice. Duolingo is fine if all you can put into it is 10-15 minutes per day. That’s better than 0 and 5 minutes isn’t doing much. Most of my focus is on reading and writing until I started learning Dutch in 2023. You have to read a ton and listen a lot. I don’t listen as much as I should, but there are plenty of Dutch teachers and comedians on social media that I’ve come to enjoy.
I think it’s important to remember your purpose. I like learning languages because I like linguistics and language, not because I have an acute need to interact in another language. Honestly, some trips to Belgium and The Netherlands in the last few years have been the most immersive foreign language environment I’ve been in… and any Belgian or Dutch can tell you that you can get along just fine in most both of those countries speaking just English. I was able to use nothing but Dutch to get lunch in my great grandmother’s small hometown, though!
Absolutely not, I’ve seen a couple of these with German software, with English/French just an afterthought. And that’s already two languages where half of the stuff doesn’t even apply because they are both LTR languages in latin script. I will admit that it’s of course more likely to be a US/UK dev team.
From discussions about this elsewhere, I learned that the meaning of “bit” in this paper, and in the cognitive-science world in general, is different than the usual meaning in the context of computers. The meaning here is more like, “the outcome of a process with two possible results where the probability of each result is around 50%,” rather than, “a single digit in a base-2 number.”
Replace the word “bit” with the word “decision” and you might end up with a clearer intuition of what they’re saying. Or maybe think of it like, the brain takes in a lot of information and can resolve roughly 10 questions per second about the ambiguities in that information stream.
I got the impression that for the authors of this paper, these two things are exactly the same. They use the word “bit” mostly in the information theoretical way, using the classic base-2-number definition and applying the base-2-logarithm, e.g.
Because the number of possible permutations of the cube is 4.3 × 1016 ≈ 2^65, the information rate during the perception phase was ∼ 65 bits / 5.5s ≈ 11.8 bits/s.
They make no distinction between the “decision” bit and a bit as used in computer science:
A much more demanding cognitive task is image recognition. A neural network model called AlexNet was trained to
classify about 1 million photographs into 1000 object categories. That means extracting 10 bits from an image
with 1.2 million bits.
Both cogsci and CS get the concept “bit” from information theory. The paper is talking about what in CS we usually qualify as “bits of entropy”, when talking about data compression or passwords.
Dang, the voice-preview device looks very impressive. I’m more stoked about this than I was when the pinebook was announced.
Imho, voice control to the computer may be the next big evolution in human->computer interactions.
I’ll be hacking a way to achieve full terminal control via voice, but would hate to be reinventing the wheel. If anyone knows a solid implementation of voice control to linux CLI input, please share that with me.
I live in a house with many other people. When I’m not around them I’m in an office with many other people. There are certain lifestyles for which voice control is going to be the way, I’m not sure I’ll be among them.
I wouldn’t want to replace my keyboard with voice control either, but even in a shared environment I think it has its uses. Controlling things like Home Assistant seems like one of them: it doesn’t matter which member of the household says, “Turn on the kitchen lights,” and it’s arguably a desirable feature that anyone can say it.
To try to generalize that a bit, maybe it’ll end up being the case that voice control in a shared space is suitable for performing actions that affect everyone in the space.
It doesn’t matter which member of the household says it, until one of your descendants/dependents (or one of your friend’s descendants/dependents) that feels the urge to tell the lights to do this multiple times a day, every day, says it. Or uses that innate sense of curiosity to see what else can be messed with just using their voice.
But - meh, bigger things to worry about I guess. Maybe it’s just karma for my compulsion to flip all the switches when I was that age.
It’s a surprise for no one that a certain technology isn’t a solution for everyone, so I’m not sure what value your comment adds tbh. For others, it’ll be useful 🤷♂️
My circumstance is not uncommon. I describe a not uncommon circumstance in which this technology is not useful.I do so in response to somebody saying that this is the next big thing. When the next big thing excludes a very common reality, then it is unlikely to be the next big thing.
Your response to my comment makes it sound like I get violently ill at the sight of the color purple and therefore the purple box will not be useful for me. My concerns are not nearly so individual as technology choices sometimes can be.
Does that better explain the context in which my comment is a useful addition to the conversation?
The number of places where voice interaction is useful is quite limited. The most detailed experiments that I’m aware of were done in the ‘90s but you can repeat them yourself. Stand behind someone and interact with a computer by telling them what to do. Use someone who is an experienced computer toucher, so that you can use higher-level abstractions talking to them. See how long you last before you push them out of the way and start using the computer yourself.
Controlling a terminal with voice is easy. There are a load of text-to-voice things that produce text streams that you can send to the shell. The only people who ever use them are people who have lost the use of their hands, because for everyone else they’re much worse than typing.
I also think that using voice control for a PC/laptop is not likely to give many benefits (well maybe for dictating texts – I guess most people cannot touch-type, so typing a long text would be cumbersome for many). For controlling a computer, mouse/keyboard/touchscreen etc. are probably better than voice.
But I see quite the big advantage of voice input for a) home automation (basically what Amazon Echo and this Home Assistant device are targeting) and more importantly b) mobile use. Controlling a smartphone via a 7” touchscreen still feels painful and IMO this is a thing that Apple etc. will try to improve. Voice input might be one avenue.
For home automation, the ‘lost the use of their hands’ part can apply. My hands may be full, or on the other side of a room from the thing I’m trying to operate.
A thing about a field thats as profitable as this one and also has zero credentialism is that it’s increasingly full of people who aren’t here for the love of the game.
Someone wise once said “you have the right to a purpose, if you do not choose one, one will be provided for you.” Not digging into how stuff like history works is what happens when “programming” is increasingly a purpose that is provided to people who didn’t bring their own, or brought ones that don’t pay the bills.
(I can’t find the quote right now, would love to know where it’s from)
It’s hard to overstate how much this change in the industry has been draining my enthusiasm over the years, even outside the context of my day job.
If you’d asked me 20 years ago, I would have predicted that some day I’d probably retire from paid work, but would still participate in the software development community for the enjoyment of interacting with other people who share my love of the craft. Now I find myself quitting communities that are focused on programming topics I find interesting, simply because the quality discussions are so often drowned out by low-effort beginner content and self-promotion by people discovering the same things over and over again.
I can tell you with a high degree of certainty that when I started with FOSS, people who sent junk PRs to game Hacktoberfest for free shirts and people sending dubious (and, in the last years, LLM-generated) vulnerability reports didn’t exist. Not saying we aren’t getting older, but there are objective changes in the field, too.
Still the original claim of “people discovering the same things over and over” is part of today’s lucky 10000. I can’t tell you though how you stop yourself from feeling the déjà-vu all the time. In the same way you can be annoyed by reposts - but realistically a lot of people will see it the first time.
There’s a difference between people who are excited to have learned a new thing and people who are posting explanations of things that they don’t really understand to try to farm attention. I try to avoid LinkedIn, but if I accidentally read things there, a lot of posts are from people trying to show that they’re experts by posting ‘explanations’ of things that are at least two-thirds wrong, with little networks of their friends posting ‘amazing’ or ‘great insight’ in the comments.
Back in the ‘good old days’, there was a lot of gatekeeping. We almost certainly lost good people as a result, but a side effect was that this kind of relentless self promotion would have been killed. I don’t want to go back that world, but it would be nice to find somewhere between the two extremes.
Wouldn’t have thought that LinkedIn would make for a good example, but I think you’re right. The main reason to be annoyed by repetitive posts is when it’s clearly dangerous half-knowledge with the whole incentive of farming attention.
On another note: People that aren’t breathing Recruiter are actually reading those LinkedIn posts ?
LinkedIn seems to be a better community environment than Twitter/X nowadays. I would have never expected this five years ago.
YMMV. I can only speak from personal experience. But I have a few friends (solo founders) who have been tracking metrics across various platforms for, well, business reasons—their feedback has been consistent: post-Musk Twitter/X has degraded a lot, and they see more and qualitatively better engagement on LinkedIn. Pre-Musk it was the opposite.
Probably cause and effect: those that wanted to leave Twitter post-Musk (or simply wanted to interact with others in a more pleasant environment) had to go somewhere, and LinkedIn was one of the options (plus Bluesky, Mastodon, etc.).
I have been noticing this for a long time. It seems like there are a lot of people who can’t fathom that software development isn’t just websites/web services and that the internet isn’t just the web.
The IT of half the companies I’ve worked for seem to disagree. For some reason the only way to talk to the outside world is TCP on ports 80 and 443…
Seriously, before I left a couple weeks ago I couldn’t even push my Git commits because they blocked the SSH port. I had to go through my phone connection and pay the bandwidth of my own pocket (okay, let’s be honest I was nowhere near my data limit, but just on principle).
Likely Microsoft infrastructure with most software purchased from vendors. They’ve been conditioned that exposing anything including RDP is dangerous, so they wholesale block everything. SSH and GIT are completely off their radar.
Likely Microsoft infrastructure with most software purchased from vendors.
Spot on: Windows computers even for Linux devs (I miraculously fell through the cracks, but most of us had to use a VM), Outlook/Teams for all communications.
Windows computers without local administrator rights, of course. Usually issued and managed by people with half the pay and tenth of the knowledge of the system in question.
I have fond memories of leaving a company that blocked random websites using mandatory proxy. Always fun to find out the random tech forum discussion your exact problem was blocked.
Whole departments just brought in their own routers and set up alternative WiFi to be able to work.
Somehow “software development consists entirely of writing code to display things in a web browser” makes sense to some people despite the fact that it requires “a web browser” which, by definition, can’t itself be a web app.
Perhaps to them it’s just a part of the operating system (a given substrate upon which everything else is built)? Even among most “regular” developers, the idea that you can actually work on an operating system is somewhat foreign. To be fair, such jobs are far and few in between, and with the job market being the way it is, the web jobs outnumber the “native” developing jobs by at least an order of magnitude.
Despite working for an LLM company, I did not use AI much in my work. However, the Zed integration actually changed this completely. I am using this on a day to day basis and it made me probably 2x more productive. It’s not magic, but a tool that when learned can be quite helpful. I found the Zed integration particularly good, because it doesn’t try to be smart or hide prompts, but just gives you a raw experience with a very tight loop.
Over time I learned the patterns where the model is good and where it makes mistakes. I tuned my prompts and now get a very high success rate of gettign what I want. Does it one-shot everything? No, but a repeated prompts with the right detail gets me much quicker to the result than if i would write it myself.
Are you able to share any specific examples? I see “it has made me 2x more productive” kinds of statements and I keep wondering what I’m doing differently because while I do use LLM tools in my work, I’d say they make me more like 5% more productive at the “writing code” part of my job: enough to be noticeably beneficial, but not enough to fundamentally alter how I work.
The win for me is mostly in simple situations: single-line autocomplete or tiny code blocks that can be described very tersely. Every time I’ve tried to do something more complex, I have ended up spending 3-5x longer wrestling with prompts and fixing up the generated code than it would have taken me to write the code myself.
I have not, however, tried Zed. So I’m curious to hear concrete examples of how much better it is.
The way I work with LLMs is Zed + Claude Sonnet 3.5 (I assume GPT 4o will do fine as well).
What I generally found useful is the following approach: I write a function definition in a class, then select the whole class. I add context to the assistant panel in Zed, usually the most recent tabs I opened, that provide additional context for the implementation. Then I use inline assist to prompt for implementing the given function and give it some basic requirements. Usually this works very well. Similarly, i make changes to the whole class by selecting the whole class, adding context to the assistant panel and then inline prompt (CTRL + Enter).
What I’ve found is that trying to one-shot large files doesn’t work well. What works well if targeted changes, implementations with the right context in the assistant panel. There are clear limitations in waht models can do and most importantly how good retrieval methods are. In general i found any sort of magic retrieval, “Ask the codebase”, etc not very good.
One example very recently: I regenerate some pydantic types from a json schema. I now add all the new types into the context window and select a whole file at a time and prompt the model with : I’ve have changed the files in types.py, but have yet to change the usage of said types. Please go ahead and change the usages for me appropriately.
In these examples the initial pass gets about 90% right, the last 10% I either fix or select and make specific prompts.
So that’s all to say, waht I feel peoeple try is big one-shot examples, or relying on fancy retrieval methods which rarely work. What does work well is targeted prompting with the human selecting the right context. So effectively I use the model as superhuman writer, not a as superhuman understanding.
I eagerly await the next container breakout vulnerability! I’m sure it already exists, but is being used in secretive operations that have more value than whatever garbage flows through ChatGPT
Plenty of parties would like to establish a foothold in the OpenAI network with the ultimate goal of exfiltrating the GPT 5, or later, weights. Depending on what you believe, and how things turn out, that could be the most valuable thing humanity ever develops.
That sounds a bit dramatic. Can chatgpt fix climate change? Cure cancer? Make the trains run on time? Do the dishes? If not, then it is not very high on the “important things” list.
I agree it sounds a bit dramatic, but you could also ask those questions about, say “art” or “music” or “the Internet” and conclude that none of those things are important either.
This sounds like discovery of essential vs accidental complexity in the program requirements.
If you keep removing things from the requirements that aren’t necessary to solve the root problem, you’ll be left with the essential complexity of the problem.
So in other words, this article’s 4-way definition of complexity can be simplified to the usual 2-way definition of complexity for the spec and implementation separately.
And reducing complexity of the spec doesn’t need to be solely the responsibility of software engineers, though they can participate in it. Whittling requirements down to the bare essentials is one of the key skills of a good product manager and often requires little or no technical background.
Kudos to the author for explaining what Melange is in the first sentence of the post. Too many release announcements that get posted to social media assume that readers recognize the name of whatever the thing is.
They mean the program that makes Dylan language C-FFI declarations from C headers, right?
Well, that’s what it means to me anyway. Or the spice of course.
Virtual libraries correspond to Dune’s ability to compile parameterised libraries and delay the selection of concrete implementations until linking an executable.
The feature introduces two kinds of libraries: virtual and implementations. A virtual library corresponds to an interface (although it may contain partial implementation). An implementation of a virtual library fills in all unimplemented modules in the virtual library.
The benefit of this partition is that other libraries may depend on and compile against the virtual library, and they might only select concrete implementations for these virtual libraries when linking executables. An example where this might be useful would be a virtual, cross-platform, clock library. This library would have clock.unix and clock.win implementations. Executable using clock or libraries that use clock would conditionally select one of the implementations, depending on the target platform.
This goes hand in hand with the data suggesting that smaller changes lead to better review quality.
I’ve definitely caught myself becoming less and less attentive as I make my way one alphabetically-ordered file at a time through a medium-sized code review. When I catch my attention waning, I stop and take a break and come back to it fresh. But of course there are no doubt plenty of times I fail to catch myself and produce reviews like the study describes.
Oddly, if I’m presented with a large enough change to review (and there’s no immediately obvious clean way I can ask the author to split it up) I think I tend to have the problem less often because my reviewing method changes: rather than reading the whole thing from top to bottom, I jump around a lot more. With a large change, I’m much more likely to start by reviewing the tests before I even look at the implementation.
“Types should generate code” implies that the type system needs to be expressive enough that the intent and the implementation details can be fully specified by types alone. Okay, that’s interesting! But it’s not meaningful for existing languages with existing type systems.
Telling, say, a TypeScript coder that they should be generating code from their types instead of using const x = someFunction(); and relying on the compiler to figure it out isn’t an actionable suggestion.
In my day-to-day work, even when I’m reading other people’s code in a web browser, I very rarely find type inference a barrier to understanding. I’m mostly working in Kotlin nowadays, where the convention is to declare types explicitly only in cases where inference can’t figure them out or in cases where a reader would likely be confused without an explicit type. That last part, on paper, sounds like the makings of an inconsistent mess of clashing opinions. But in practice, people seem to pretty quickly converge on agreement on where explicit types are helpful, even if (as has been the case for nearly everyone else on teams where I’ve worked on Kotlin code) they have zero prior experience with the language.
To use a concrete example:
val numActiveUsers: Int = users.count { it.isActive }
val numActiveUsers = users.count { it.isActive }
The first one isn’t, to my eye, any clearer than the second one, it’s just longer.
I’ve been using SchemaSpy to generate these kinds of diagrams. It supports a bunch of different database engines, though it’s nowhere near as lightweight as this tool.
Dating myself: my mom was a community college teacher and in the late 1970s, Apple gave the school a batch of Apple II computers. The school decided to let teachers take them home for the summer to experiment with, and my mom ended up with one of them.
She barely touched the thing because 7-year-old me was completely fascinated by it and spent the whole summer glued to it. It came with documentation that included a beginner’s guide to BASIC as well as a book with a printed copy of the operating system source code in 6502 assembly, and by the end of the summer I was writing my own simple games in BASIC and starting to get curious about what the big book of gibberish actually meant. My parents got me a computer of my own when my mom had to give the school’s one back (happily, Apple offered her a big discount, so it wasn’t budget-breaking) and I’ve been coding ever since.
There was never a question in my mind about what I wanted to major in at college or do for a living afterwards. That was back in the days when computer programming wasn’t a particularly highly-paid job, just kind of a run-of-the-mill white-collar one, but the fact that at the time I could have made more money doing something else never tempted me. Happily, it ended up being a very lucrative line of work a decade or two later.
A framing I’ve found useful as an addition to the usual framings is, “What would it have taken for this to have not been able to happen?” It’s similar to, “What didn’t we do that we should have,” but the focus is a bit broader and I think it nudges you toward thinking critically about costs and tradeoffs rather than just trying to come up with technical solutions.
Obviously you usually want solutions too, but in the heat of the moment I think it can get hard to step back and realize, “We could have prevented this but it wouldn’t have been worth the cost,” which is sometimes the case. That realization makes it much easier to have a truly blameless postmortem. The linked post kind of gets at this point as well.
Inside companies following the agile development process, team members meet daily to discuss progress, synchronize tasks that are underway, and identify blockers.
Daily standups are not part of agile and they’re not even part of all Agile methodologies; they’re largely a Scrum thing.
Productive agile teams work in “sprints” over a short period of time (often two weeks)
Sprints are not part of agile or all of Agile either. They’re Scrum. Kanban shops are still doing Agile but there’s no concept of a “sprint” in Kanban.
Stopped reading at this point because an article that repeatedly fails to distinguish between “agile” and “Scrum” is unlikely to have keen insights into the pros and cons of agile methodologies.
Adopting agile wont fix a broken culture. Fixing a broken culture probably means you will become more agile.
In neither case is a consultant or process adoption required. What is required is recognizing that culture is broken and getting buy in from all the stakeholders that fixing the culture is something that needs doing. If adopting an Agile methodology gets the right people to agree to fixing the culture then great. But in practice adopting a methodology often means those people will ignore that the culture is broken and pretend that the process is enough.
In my experience a process (in general, not just agile) only helps fix a broken culture if it acts as a constraint on all the parties who interact badly in whatever context the process applies to.
Too often, organizations introduce processes that only constrain one of the parties, whether by design or because the rules are inconsistently enforced or because there’s a power imbalance that supersedes the process, and the other parties continue or double down on their existing bad behavior. The culture ends up more broken afterwards.
Can Agile even be done right? I’d say it’s irrelevant, because it is too dangerous. It broke me down professionally and gave me PTSD. It must not be attempted. Bury it already.
When done wrong, “agile” becomes synonymous for baseless deadlines and short-sighted goals. That over time makes everything into a war. Scrum is when a wheel falls off your car, and you continue driving.
In particular, you need to be allowed to think for yourself and spend some percentage of your time on what really needs fixing, and maybe not succeeding every day, inbetween delivering features without having to defend it daily.
If your colleagues appreciate it, it was probably worth doing.
Scrum is a big red flag in a potential job for me at this point. Maybe it can be done well but it goes off the rails so easily that it’s not worth the risk.
But I’ve found Kanban pretty agreeable.
It lacks the things I find most annoying or stressful about Scrum (sprints, daily standups, scrum masters) but still acts as a forcing function to get stakeholders to decide what they want (backlog replenishment) and to rate-limit the team’s incoming workload (work-in-progress limit).
Kanban is also more agile than Scrum, in the original sense of that word: in Scrum if there’s a priority change mid-sprint, it’s treated as a process-breaking special case and teams will often push back hard against it because it screws up their plans for that sprint. But in Kanban, it just means the top item in the backlog might be different the next time someone goes to get their next task.
I say this a lot, but: “Agile” was a buzzword-y way for a bunch of consultants to tell their clients “the project is late and over budget in large part due to you”.
If you have a workplace where the people with the authority to demand changes to a software project also accept *responsibility for the impact of demanding those changes, then you’re “Agile” and it doesn’t matter what methodology you use. If you have a workplace where that doesn’t happen, then you’re not “Agile” and no methodology can help you.
I guess it depends on if you mean Agile or agile. There’s nothing in agile methodologies that would prevent one from spending time cleaning up and improving; in fact, a properly autonomous agile team will naturally spend a good chunk of their time doing just that. To clarify, the important concepts I’m referring to here are: complete ownership of their own processes, iterative improvement of the ways in which they work, breaking work into iterations to separate redwork from bluework, and retrospecting on each iteration to learn how to improve, and perhaps most importantly a focus on their users, outcomes, and impacts.
I’ve worked with many teams who weren’t doing these things to help them to improve, and the results have been universally good (both from the perspective of the team itself and their executive leaders). Notice that I didn’t use the words Scrum, stand-up, story point, or anything else - those are not the important part (though each individually can be useful tools for individual teams, depending on their make-up and what the team needs at the time).
So, I’m basically just paraphrasing the article. What were your specific concerns with it? It sounds to me like you’ve been burned by Agile. But I wouldn’t throw the baby out with the bathwater. There is a lot of potential positive change from applying these ideas correctly.
At this point “Agile” feels like communism. If the revolution fails, the system is never at fault, it’s because of sabotage by the petit bourgeoisie, or the lack of revolutionary zeal among the working classes.
Anyone else find the “Market Forces” section really unsatisfying? They seem to be saying “if we could somehow invent some way to measure the security of software, then ‘the market’ could deal with it” but it feels like a cop-out, or maybe just a defense of free-market ideology. Like “hey, the free market is great actually, as long as you have informed buyers, which we don’t have, but if we DID have them, boy the free market would be great, you just wait and see”.
Potentially effective ways to address the problems with market forces without just relying on magic handwavium could include greater degrees of liability for peddlers of insecure software, or federal funding for critical widely-adopted open-source projects. But they don’t mention any of that.
My interpretation was a bit more charitable: having a good way to measure software security will make it much more feasible for markets to put a monetary value on security.
Even with a good objective measure, there’s no guarantee that markets will value security. Your criticism is totally valid and worth voicing, IMO: markets may not be enough. I think the message the report was trying to convey was more that the absence of a good way to quantify security pretty much guarantees that markets won’t value it.
If there isn’t a way for the market to determine what software is good and what is terrible until after it fails, what magic handwavium will allow the government to do so before they dictate it to the rest of us?
Market and government priorities are by design different from each other. Markets prioritize profits, while governments can focus on other aspects first such as engineering. That doesn’t mean governments can solve this, but the market failing does not directly imply the government will be unable to succeed.
Thanks for writing this. There’s a severe shortage of this kind of concrete, detailed example in discussions about how people are using these tools.
One thing that strikes me about the examples in the article is that they’re all small, self-contained, greenfield projects with no existing coding conventions or architecture. I’m far from the first to observe this, but my hunch is that one of the reasons I haven’t had as much success with these tools is that very little of my work fits that description. The vast majority of my day-to-day coding involves modifying an existing code base with a lot of moving parts whose behaviors are mostly governed by a messy pile of domain-specific business rules that have accumulated for years.
My experience with various tools (disclaimer: I have only this week started to try out Claude Code, so maybe it’ll be better) is that they can be okay at following low-level technical requirements, but they struggle with higher-level concepts and make lots of fundamental mistakes based on not having a big-picture understanding of how all the pieces fit together.
They’ll know that the data model has entity types A, B, and C, but won’t know that an instance of C can only exist if there’s a corresponding B. So they’ll write code that creates a new C in isolation. The agentic tools will then spin their wheels trying over and over again to fix the fact that the “create C” function is bombing out, but they’ll never notice the problem is actually the lack of a B. I then have to spend time iteratively nudging them in the right direction and it quickly gets into “would have been faster to just write the code myself” territory.
On some level, I suspect that this is a documentation failure. It takes a new engineer on my team a bit of time to come up to speed, and they spend much of that time pairing with or picking the brains of the existing team members to learn things they couldn’t find in our internal docs. Some of the things that take new team members the most time to learn are the same ones LLMs struggle with. Maybe if our docs were better and talked in depth about those things and were kept up to date, both LLMs and new engineers would struggle less.
However, to the tools’ credit, I’ll say my team has seen much more impressive results in UI code. Our web app is fairly standard React/Redux code and LLM tools seem to cope with it a lot better. I don’t work on UI code too much, but I know our frontend engineers have been saving time asking tools to write new components for them and such. Even for them, it’s not a “3x more productive” level of gain, but it seems significant.
A big issue with these tools is that they are supposedly “intelligent” and therefore should be capable of doing everything. Products like Claude Code, Cursor, etc. reinforce that impression. But it is the wrong way to go about it. They are not intelligent, and the task quickly becomes too big for them.
An LLM is a tool, like a drill or a screwdriver. But what they try to sell you is a machine that can hang a painting on your wall. That machine will inevitably make a mess in any situation that is not ideal, but drills and screwdrivers are quite useful.
My number one use of LLMs with coding is this: write a
// TODOcomment, pipe the function (or the file) to a local, not brilliant LLM, and replace it with the response. That’s it.I don’t doubt the, uh, falsehood of this one, but it surprised me a bit. I don’t know any other language well enough to think of a counterexample.
It’s, uh, it sucks.
As @xigoi mentioned here, in languages with grammatical cases, the form of {location} may vary.
It’s not very straightforward. Best-case scenario is actually that a noun that indicates a location is always the same case (e.g. accusative), and you just have some declension rules + a series of exceptions to remember because there’s always a few of those.
But some languages retain a locative case – i.e. they indicate a location by a specific form of the noun, rather than with a preposition like “in”. To make matters worse, the locative form may be gendered. E.g. in Polish it’s w domu, but w Austrii. Hopefully. Polish is special in every way there is :-).
To make matters worse, some languages retain the locative, or variants of a locative, but it’s no longer productive. I think the only European language here is Hungarian, which no longer uses the locative, but retains a locative form for some places.
And to make them even worse, some languages actually have different cases for relative locations. Some Baltic languages are like that. E.g. the “house” in “out of the house” and “inside of the house” would be in different cases (illative vs. ellative) and thus different forms (Finnish, which hopefully someone can correct me about if I got it wrong, would be talosta in illative but taloon in ellative.
I know that there are many other constructions in some African and Asian languages, but I don’t know enough about those. I know, for example, that there are languages where:
It’s not so easy in English either. For example, “Please select an {object}”. If object is “pen”, then you get a grammatically incorrect English sentence. The use of “a” vs. “an” depends on the initial syllable of the following word.
Or, notably, “You selected {number} items”.
item(s);)Not to take away the point, but this one is at least so commonly “fixed” that most people stopped caring.
And then you have an issue with “items”, because there are languages which don’t have an equally generic word that you can use. It would be either a different one depending on what you’re selecting, or would sound really clumsy.
Some developers really are lazy… Like, how difficult is it to write
"{number} item{number == 1 ? "" : "s"}"?From my experience at least 50% of the time that is becoming a lot uglier depending on template language. Yes, if it works like this, fine.
That would encode English grammar into program logic, though. Pragmatic me wants to avoid it because it adds guilt from this list of falsehoods.
If that “s” string can be tied to this context (because gender affects pluralization) before given to translators, it can work beautifully for many other languages, but I heard at least slavic follows a different pattern.
Even in English it’s not complete: plural for potato is potatoes, not potatos.
Yeah, slavic numerals are hard. In Polish: ziemniak - potato
Sometimes the case is genitive, sometimes nominative 🤷. As a native I can become puzzled given awkward and unnatural enough sentence. I was once shown an example from a C1 language exam: I danced with 21 girls. All variants of a numeral sound a little awkward in my head.
This broke my brain a bit. There’s no way to phrase it well. At that point your only good way out is to dance with one more.
The big problem, if you care about translating your app down the road, isn’t even the “s” suffix. It’s the assumption that you use a particular word if there is exactly 1 of something, and a different word if there is any quantity other than 1 of the thing. That’s true in some languages, but it’s not universal.
In some languages, there are different forms of nouns based on quantity, but they don’t follow the “if 1, then X, else Y” pattern. In Russian, for example, it’s based on the last digit of the quantity. Mostly. If the quantity ends in 2, 3, or 4, you use one word form, but not if the quantity is 12, 13, or 14. If the quantity ends in 5, 6, 7, 8, 9, or 0, or it’s 11 through 14, you use a different form. And if the quantity ends in 1, but isn’t 11, the form varies depending on the grammatical context. (Disclaimer: I don’t speak Russian, but I remember Russian being a fun stress test of some pluralization code I worked on when I was doing i18n stuff.)
And it’s not always more complicated than English. In some languages (Chinese, for example) there isn’t a plural form at all. The concept of pluralization just flat-out doesn’t exist, aside from a small handful of plural pronouns like the words for “them” and “us.”
You need to do that anyway, because some languages do not have a straightforward equivalent of “item(s)”.
Good point!
Rankings being like, 1st 2nd 3rd 4th … 11th … 21st … 111th, is an example of how much of a pain at least one language can be, let alone every other language’s approach. (I think some actually use completely different words between counting and ranking too, fun!)
Aside: There was a table I found one day that listed “all” the languages and their handling of counting, ranking, etc, and how to program around it. Forgot to bookmark it however.
the canonical data source for things like that is the unicode common locale data repository (cldr), specifically the ‘ordinal numbers’ in the language plural rules charts. this data is used, for example, by web browsers to power
Intl.PluralRulesand otherIntlapis.Foe example, in any language that has grammatical cases, you would need to know the proper declension of {location}.
In French:
Similarly in Polish
A lot of those issues seem to be due to English speakers not knowing any other languages.
I’ve been learning some Korean lately and picked up that what we’d say as “outside of the apartment” in English is more like “apartment outside” in Korean.
Prepositions are untranslatable because they don’t map one-to-one: I am in the toilet.
And the idioms are different. One interesting example from Dutch: “Hij lijkt op zijn vader” is “he looks like his father” in English but it’s ~literally “He looks on (top of) his father” which of course doesn’t make much sense in English.
LOL, despite what you say the verb means, that looks so much like Norwegian: “Han likner på sin far”, where “likne” is the verb for to “look like”. But yes, “på” means “on (top of)” here as well.
More like American programmers
You’d think so! I did too.
I was the tech lead of the internationalization effort for a popular website a number of years back. This was in the US. The site was English-only and we wanted to make it available in a wide variety of languages. We wanted to make it feel as native to each language as we could, rather than feeling like a translation of a foreign site.
My team and I came up with a bunch of internal tools and a flexible library we could use to make our code work in multiple languages. When I say “flexible” I mean it went way beyond simple token replacement; it could do things like look up different variants of sentences depending on whether a caller-supplied place name referred to a city or a country and whether that distinction mattered in the target language, could use different pluralization rules for different languages, took gender into account if a sentence mentioned a person whose gender was known, and so on. We had people with linguistics backgrounds making sure we didn’t fall into any obvious traps.
The code base was far too big for my little team to update on our own, so an early goal was to give the rest of the engineering team all the resources they needed to do a really good job of updating their own corners of the code. In addition to thoroughly documenting our tools and libraries, we wrote up a set of annotated examples of how to change existing English-only code to be translation-friendly, and we made sure it covered all the common patterns in the code base (including visual design things like assuming a button only needed to be exactly big enough to hold an English label) and included examples of what could go wrong in different languages if people decided to just do string concatenation instead.
Then we started rolling it out. My expectation going into it was like yours: that the monoglot American devs would struggle to embrace all the techniques because English-specific assumptions would be too deeply ingrained.
But once I started doing code reviews of people’s changes, the reality was different. It turned out there was no measurable relationship between how good someone was at making their part of the site translatable into a wide variety of languages and which language(s) they spoke. Americans who’d never spoken anything but English were just as good at it, on average, as trilingual Europeans or people whose native languages were very different from English.
The thing that floored me was seeing people from other countries repeatedly make mistakes that would have made it impossible to correctly translate part of the site into their own native languages. This happened a lot, and it happened across multiple native languages. It seemed to me like some people were able to put their brains in “human language is highly variable and the code needs to act accordingly” mode, and some people were stuck in “I am working in English right now, so everything is English” mode, and it barely mattered if they happened to speak some other language or not.
Maybe the situation would have been different if the site had been in more than one language from the get-go; I don’t know. But that experience really shattered some of my preconceptions about the advantages of speaking multiple languages. (For the record: I still think it’s worthwhile to be multilingual!)
The first job I had in Germany, having moved here as a fresh-faced monolingual foreigner, was kind of like this. We were building an internal tool that was used by warehouse workers in various European countries. We knew we had a lot of fairly monolingual users in a variety of different languages, so when we decided to redesign the tool, I pushed really hard for making sure that every part of the UI was fully translated into all the relevant languages. I was amazed by how much my German colleagues pushed back against this, saying it would be a lot of effort, and people could just learn what the different English-language messages meant over time.
There were things a decade ago that my non-American English native speaker coworkers (Romanian, Croatian, Indian [Hindi & Marathi]) learned alongside me who’d been doing localization for a while — back then, I spoke natively American English but had six school years of Latin, 10+ years of self-driven Esperanto, and smattering of (Mexican) Spanish and (Canadian) French — when we did a big project targeting 10 languages on release days and 22 within four weeks in a patch release. I’ve picked up Dutch and some Korean since then and I’m constantly learning new things about language having gotten into linguist sector of Instagram, Threads, Bluesky, and the fediverse.
Unless you’re a linguist, you’re always learning surprising new things about language, discovering new tools in the toolbox, per se. If you’re a linguist, you’re learning which has/does what because you’re more familiar with what’s in the toolbox.
Cool you’ve learned so many languages. I’m currently trying to learn a new language and struggling a bit so maybe you can help. What are your preferred ways to learn a new language and make it stick?
Consistent practice. Try to experience all modes - reading, writing, listening, speaking, and conversing.
Find media you like. You don’t have to be even at 50% comprehension to listen to some audio, but obviously you’re only going to get little bits.
Adverts are much simpler than anything except children’s media.
Experiencing the language is generally the best way to internalize the rules, but reading up on complex rules to help you practice them is also important.
Regular practice. Duolingo is fine if all you can put into it is 10-15 minutes per day. That’s better than 0 and 5 minutes isn’t doing much. Most of my focus is on reading and writing until I started learning Dutch in 2023. You have to read a ton and listen a lot. I don’t listen as much as I should, but there are plenty of Dutch teachers and comedians on social media that I’ve come to enjoy.
I think it’s important to remember your purpose. I like learning languages because I like linguistics and language, not because I have an acute need to interact in another language. Honestly, some trips to Belgium and The Netherlands in the last few years have been the most immersive foreign language environment I’ve been in… and any Belgian or Dutch can tell you that you can get along just fine in most both of those countries speaking just English. I was able to use nothing but Dutch to get lunch in my great grandmother’s small hometown, though!
Thanks, I’ll keep practicing! :)
Absolutely not, I’ve seen a couple of these with German software, with English/French just an afterthought. And that’s already two languages where half of the stuff doesn’t even apply because they are both LTR languages in latin script. I will admit that it’s of course more likely to be a US/UK dev team.
From discussions about this elsewhere, I learned that the meaning of “bit” in this paper, and in the cognitive-science world in general, is different than the usual meaning in the context of computers. The meaning here is more like, “the outcome of a process with two possible results where the probability of each result is around 50%,” rather than, “a single digit in a base-2 number.”
Replace the word “bit” with the word “decision” and you might end up with a clearer intuition of what they’re saying. Or maybe think of it like, the brain takes in a lot of information and can resolve roughly 10 questions per second about the ambiguities in that information stream.
I got the impression that for the authors of this paper, these two things are exactly the same. They use the word “bit” mostly in the information theoretical way, using the classic base-2-number definition and applying the base-2-logarithm, e.g.
They make no distinction between the “decision” bit and a bit as used in computer science:
Both cogsci and CS get the concept “bit” from information theory. The paper is talking about what in CS we usually qualify as “bits of entropy”, when talking about data compression or passwords.
Dang, the voice-preview device looks very impressive. I’m more stoked about this than I was when the pinebook was announced.
Imho, voice control to the computer may be the next big evolution in human->computer interactions.
I’ll be hacking a way to achieve full terminal control via voice, but would hate to be reinventing the wheel. If anyone knows a solid implementation of voice control to linux CLI input, please share that with me.
I live in a house with many other people. When I’m not around them I’m in an office with many other people. There are certain lifestyles for which voice control is going to be the way, I’m not sure I’ll be among them.
I wouldn’t want to replace my keyboard with voice control either, but even in a shared environment I think it has its uses. Controlling things like Home Assistant seems like one of them: it doesn’t matter which member of the household says, “Turn on the kitchen lights,” and it’s arguably a desirable feature that anyone can say it.
To try to generalize that a bit, maybe it’ll end up being the case that voice control in a shared space is suitable for performing actions that affect everyone in the space.
It doesn’t matter which member of the household says it, until one of your descendants/dependents (or one of your friend’s descendants/dependents) that feels the urge to tell the lights to do this multiple times a day, every day, says it. Or uses that innate sense of curiosity to see what else can be messed with just using their voice.
But - meh, bigger things to worry about I guess. Maybe it’s just karma for my compulsion to flip all the switches when I was that age.
It’s a surprise for no one that a certain technology isn’t a solution for everyone, so I’m not sure what value your comment adds tbh. For others, it’ll be useful 🤷♂️
My circumstance is not uncommon. I describe a not uncommon circumstance in which this technology is not useful.I do so in response to somebody saying that this is the next big thing. When the next big thing excludes a very common reality, then it is unlikely to be the next big thing.
Your response to my comment makes it sound like I get violently ill at the sight of the color purple and therefore the purple box will not be useful for me. My concerns are not nearly so individual as technology choices sometimes can be.
Does that better explain the context in which my comment is a useful addition to the conversation?
The number of places where voice interaction is useful is quite limited. The most detailed experiments that I’m aware of were done in the ‘90s but you can repeat them yourself. Stand behind someone and interact with a computer by telling them what to do. Use someone who is an experienced computer toucher, so that you can use higher-level abstractions talking to them. See how long you last before you push them out of the way and start using the computer yourself.
Controlling a terminal with voice is easy. There are a load of text-to-voice things that produce text streams that you can send to the shell. The only people who ever use them are people who have lost the use of their hands, because for everyone else they’re much worse than typing.
I also think that using voice control for a PC/laptop is not likely to give many benefits (well maybe for dictating texts – I guess most people cannot touch-type, so typing a long text would be cumbersome for many). For controlling a computer, mouse/keyboard/touchscreen etc. are probably better than voice.
But I see quite the big advantage of voice input for a) home automation (basically what Amazon Echo and this Home Assistant device are targeting) and more importantly b) mobile use. Controlling a smartphone via a 7” touchscreen still feels painful and IMO this is a thing that Apple etc. will try to improve. Voice input might be one avenue.
For home automation, the ‘lost the use of their hands’ part can apply. My hands may be full, or on the other side of a room from the thing I’m trying to operate.
A thing about a field thats as profitable as this one and also has zero credentialism is that it’s increasingly full of people who aren’t here for the love of the game.
Someone wise once said “you have the right to a purpose, if you do not choose one, one will be provided for you.” Not digging into how stuff like history works is what happens when “programming” is increasingly a purpose that is provided to people who didn’t bring their own, or brought ones that don’t pay the bills.
(I can’t find the quote right now, would love to know where it’s from)
It’s hard to overstate how much this change in the industry has been draining my enthusiasm over the years, even outside the context of my day job.
If you’d asked me 20 years ago, I would have predicted that some day I’d probably retire from paid work, but would still participate in the software development community for the enjoyment of interacting with other people who share my love of the craft. Now I find myself quitting communities that are focused on programming topics I find interesting, simply because the quality discussions are so often drowned out by low-effort beginner content and self-promotion by people discovering the same things over and over again.
How much of that is the world changing, and how much is that you just getting older?
I can tell you with a high degree of certainty that when I started with FOSS, people who sent junk PRs to game Hacktoberfest for free shirts and people sending dubious (and, in the last years, LLM-generated) vulnerability reports didn’t exist. Not saying we aren’t getting older, but there are objective changes in the field, too.
Still the original claim of “people discovering the same things over and over” is part of today’s lucky 10000. I can’t tell you though how you stop yourself from feeling the déjà-vu all the time. In the same way you can be annoyed by reposts - but realistically a lot of people will see it the first time.
There’s a difference between people who are excited to have learned a new thing and people who are posting explanations of things that they don’t really understand to try to farm attention. I try to avoid LinkedIn, but if I accidentally read things there, a lot of posts are from people trying to show that they’re experts by posting ‘explanations’ of things that are at least two-thirds wrong, with little networks of their friends posting ‘amazing’ or ‘great insight’ in the comments.
Back in the ‘good old days’, there was a lot of gatekeeping. We almost certainly lost good people as a result, but a side effect was that this kind of relentless self promotion would have been killed. I don’t want to go back that world, but it would be nice to find somewhere between the two extremes.
Wouldn’t have thought that LinkedIn would make for a good example, but I think you’re right. The main reason to be annoyed by repetitive posts is when it’s clearly dangerous half-knowledge with the whole incentive of farming attention.
On another note: People that aren’t breathing Recruiter are actually reading those LinkedIn posts ?
LinkedIn seems to be a better community environment than Twitter/X nowadays. I would have never expected this five years ago.
YMMV. I can only speak from personal experience. But I have a few friends (solo founders) who have been tracking metrics across various platforms for, well, business reasons—their feedback has been consistent: post-Musk Twitter/X has degraded a lot, and they see more and qualitatively better engagement on LinkedIn. Pre-Musk it was the opposite.
Probably cause and effect: those that wanted to leave Twitter post-Musk (or simply wanted to interact with others in a more pleasant environment) had to go somewhere, and LinkedIn was one of the options (plus Bluesky, Mastodon, etc.).
So it goes
I have been noticing this for a long time. It seems like there are a lot of people who can’t fathom that software development isn’t just websites/web services and that the internet isn’t just the web.
The IT of half the companies I’ve worked for seem to disagree. For some reason the only way to talk to the outside world is TCP on ports 80 and 443…
Seriously, before I left a couple weeks ago I couldn’t even push my Git commits because they blocked the SSH port. I had to go through my phone connection and pay the bandwidth of my own pocket (okay, let’s be honest I was nowhere near my data limit, but just on principle).
Likely Microsoft infrastructure with most software purchased from vendors. They’ve been conditioned that exposing anything including RDP is dangerous, so they wholesale block everything. SSH and GIT are completely off their radar.
Spot on: Windows computers even for Linux devs (I miraculously fell through the cracks, but most of us had to use a VM), Outlook/Teams for all communications.
Windows computers without local administrator rights, of course. Usually issued and managed by people with half the pay and tenth of the knowledge of the system in question.
I have fond memories of leaving a company that blocked random websites using mandatory proxy. Always fun to find out the random tech forum discussion your exact problem was blocked.
Whole departments just brought in their own routers and set up alternative WiFi to be able to work.
Somehow “software development consists entirely of writing code to display things in a web browser” makes sense to some people despite the fact that it requires “a web browser” which, by definition, can’t itself be a web app.
Perhaps to them it’s just a part of the operating system (a given substrate upon which everything else is built)? Even among most “regular” developers, the idea that you can actually work on an operating system is somewhat foreign. To be fair, such jobs are far and few in between, and with the job market being the way it is, the web jobs outnumber the “native” developing jobs by at least an order of magnitude.
Despite working for an LLM company, I did not use AI much in my work. However, the Zed integration actually changed this completely. I am using this on a day to day basis and it made me probably 2x more productive. It’s not magic, but a tool that when learned can be quite helpful. I found the Zed integration particularly good, because it doesn’t try to be smart or hide prompts, but just gives you a raw experience with a very tight loop.
Over time I learned the patterns where the model is good and where it makes mistakes. I tuned my prompts and now get a very high success rate of gettign what I want. Does it one-shot everything? No, but a repeated prompts with the right detail gets me much quicker to the result than if i would write it myself.
Are you able to share any specific examples? I see “it has made me 2x more productive” kinds of statements and I keep wondering what I’m doing differently because while I do use LLM tools in my work, I’d say they make me more like 5% more productive at the “writing code” part of my job: enough to be noticeably beneficial, but not enough to fundamentally alter how I work.
The win for me is mostly in simple situations: single-line autocomplete or tiny code blocks that can be described very tersely. Every time I’ve tried to do something more complex, I have ended up spending 3-5x longer wrestling with prompts and fixing up the generated code than it would have taken me to write the code myself.
I have not, however, tried Zed. So I’m curious to hear concrete examples of how much better it is.
The way I work with LLMs is Zed + Claude Sonnet 3.5 (I assume GPT 4o will do fine as well).
What I generally found useful is the following approach: I write a function definition in a class, then select the whole class. I add context to the assistant panel in Zed, usually the most recent tabs I opened, that provide additional context for the implementation. Then I use inline assist to prompt for implementing the given function and give it some basic requirements. Usually this works very well. Similarly, i make changes to the whole class by selecting the whole class, adding context to the assistant panel and then inline prompt (CTRL + Enter).
What I’ve found is that trying to one-shot large files doesn’t work well. What works well if targeted changes, implementations with the right context in the assistant panel. There are clear limitations in waht models can do and most importantly how good retrieval methods are. In general i found any sort of magic retrieval, “Ask the codebase”, etc not very good.
One example very recently: I regenerate some pydantic types from a json schema. I now add all the new types into the context window and select a whole file at a time and prompt the model with : I’ve have changed the files in types.py, but have yet to change the usage of said types. Please go ahead and change the usages for me appropriately.
In these examples the initial pass gets about 90% right, the last 10% I either fix or select and make specific prompts.
So that’s all to say, waht I feel peoeple try is big one-shot examples, or relying on fancy retrieval methods which rarely work. What does work well is targeted prompting with the human selecting the right context. So effectively I use the model as superhuman writer, not a as superhuman understanding.
I should probably make a video about this.
I hope that helps.
I eagerly await the next container breakout vulnerability! I’m sure it already exists, but is being used in secretive operations that have more value than whatever garbage flows through ChatGPT
Plenty of parties would like to establish a foothold in the OpenAI network with the ultimate goal of exfiltrating the GPT 5, or later, weights. Depending on what you believe, and how things turn out, that could be the most valuable thing humanity ever develops.
That sounds a bit dramatic. Can chatgpt fix climate change? Cure cancer? Make the trains run on time? Do the dishes? If not, then it is not very high on the “important things” list.
I agree it sounds a bit dramatic, but you could also ask those questions about, say “art” or “music” or “the Internet” and conclude that none of those things are important either.
None of those things will ever happen. Especially the dishes.
Not yet.
This sounds like discovery of essential vs accidental complexity in the program requirements. If you keep removing things from the requirements that aren’t necessary to solve the root problem, you’ll be left with the essential complexity of the problem.
So in other words, this article’s 4-way definition of complexity can be simplified to the usual 2-way definition of complexity for the spec and implementation separately.
And reducing complexity of the spec doesn’t need to be solely the responsibility of software engineers, though they can participate in it. Whittling requirements down to the bare essentials is one of the key skills of a good product manager and often requires little or no technical background.
Kudos to the author for explaining what Melange is in the first sentence of the post. Too many release announcements that get posted to social media assume that readers recognize the name of whatever the thing is.
They mean the program that makes Dylan language C-FFI declarations from C headers, right? Well, that’s what it means to me anyway. Or the spice of course.
/me goes to read the post…
I don’t know what Dune virtual libraries are, but I guess that’s the naming connection?
Having now read the link, seems so, yup. And I don’t know either.
Source: https://dune.readthedocs.io/en/stable/variants.html
This goes hand in hand with the data suggesting that smaller changes lead to better review quality.
I’ve definitely caught myself becoming less and less attentive as I make my way one alphabetically-ordered file at a time through a medium-sized code review. When I catch my attention waning, I stop and take a break and come back to it fresh. But of course there are no doubt plenty of times I fail to catch myself and produce reviews like the study describes.
Oddly, if I’m presented with a large enough change to review (and there’s no immediately obvious clean way I can ask the author to split it up) I think I tend to have the problem less often because my reviewing method changes: rather than reading the whole thing from top to bottom, I jump around a lot more. With a large change, I’m much more likely to start by reviewing the tests before I even look at the implementation.
“Types should generate code” implies that the type system needs to be expressive enough that the intent and the implementation details can be fully specified by types alone. Okay, that’s interesting! But it’s not meaningful for existing languages with existing type systems.
Telling, say, a TypeScript coder that they should be generating code from their types instead of using
const x = someFunction();and relying on the compiler to figure it out isn’t an actionable suggestion.In my day-to-day work, even when I’m reading other people’s code in a web browser, I very rarely find type inference a barrier to understanding. I’m mostly working in Kotlin nowadays, where the convention is to declare types explicitly only in cases where inference can’t figure them out or in cases where a reader would likely be confused without an explicit type. That last part, on paper, sounds like the makings of an inconsistent mess of clashing opinions. But in practice, people seem to pretty quickly converge on agreement on where explicit types are helpful, even if (as has been the case for nearly everyone else on teams where I’ve worked on Kotlin code) they have zero prior experience with the language.
To use a concrete example:
The first one isn’t, to my eye, any clearer than the second one, it’s just longer.
I’ve been using SchemaSpy to generate these kinds of diagrams. It supports a bunch of different database engines, though it’s nowhere near as lightweight as this tool.
Dating myself: my mom was a community college teacher and in the late 1970s, Apple gave the school a batch of Apple II computers. The school decided to let teachers take them home for the summer to experiment with, and my mom ended up with one of them.
She barely touched the thing because 7-year-old me was completely fascinated by it and spent the whole summer glued to it. It came with documentation that included a beginner’s guide to BASIC as well as a book with a printed copy of the operating system source code in 6502 assembly, and by the end of the summer I was writing my own simple games in BASIC and starting to get curious about what the big book of gibberish actually meant. My parents got me a computer of my own when my mom had to give the school’s one back (happily, Apple offered her a big discount, so it wasn’t budget-breaking) and I’ve been coding ever since.
There was never a question in my mind about what I wanted to major in at college or do for a living afterwards. That was back in the days when computer programming wasn’t a particularly highly-paid job, just kind of a run-of-the-mill white-collar one, but the fact that at the time I could have made more money doing something else never tempted me. Happily, it ended up being a very lucrative line of work a decade or two later.
A framing I’ve found useful as an addition to the usual framings is, “What would it have taken for this to have not been able to happen?” It’s similar to, “What didn’t we do that we should have,” but the focus is a bit broader and I think it nudges you toward thinking critically about costs and tradeoffs rather than just trying to come up with technical solutions.
Obviously you usually want solutions too, but in the heat of the moment I think it can get hard to step back and realize, “We could have prevented this but it wouldn’t have been worth the cost,” which is sometimes the case. That realization makes it much easier to have a truly blameless postmortem. The linked post kind of gets at this point as well.
Daily standups are not part of agile and they’re not even part of all Agile methodologies; they’re largely a Scrum thing.
Sprints are not part of agile or all of Agile either. They’re Scrum. Kanban shops are still doing Agile but there’s no concept of a “sprint” in Kanban.
Stopped reading at this point because an article that repeatedly fails to distinguish between “agile” and “Scrum” is unlikely to have keen insights into the pros and cons of agile methodologies.
Adopting agile wont fix a broken culture. Fixing a broken culture probably means you will become more agile.
In neither case is a consultant or process adoption required. What is required is recognizing that culture is broken and getting buy in from all the stakeholders that fixing the culture is something that needs doing. If adopting an Agile methodology gets the right people to agree to fixing the culture then great. But in practice adopting a methodology often means those people will ignore that the culture is broken and pretend that the process is enough.
In my experience a process (in general, not just agile) only helps fix a broken culture if it acts as a constraint on all the parties who interact badly in whatever context the process applies to.
Too often, organizations introduce processes that only constrain one of the parties, whether by design or because the rules are inconsistently enforced or because there’s a power imbalance that supersedes the process, and the other parties continue or double down on their existing bad behavior. The culture ends up more broken afterwards.
Can Agile even be done right? I’d say it’s irrelevant, because it is too dangerous. It broke me down professionally and gave me PTSD. It must not be attempted. Bury it already.
When done wrong, “agile” becomes synonymous for baseless deadlines and short-sighted goals. That over time makes everything into a war. Scrum is when a wheel falls off your car, and you continue driving.
Alternative: Grow professionalism
In particular, you need to be allowed to think for yourself and spend some percentage of your time on what really needs fixing, and maybe not succeeding every day, inbetween delivering features without having to defend it daily. If your colleagues appreciate it, it was probably worth doing.
Scrum is a big red flag in a potential job for me at this point. Maybe it can be done well but it goes off the rails so easily that it’s not worth the risk.
But I’ve found Kanban pretty agreeable.
It lacks the things I find most annoying or stressful about Scrum (sprints, daily standups, scrum masters) but still acts as a forcing function to get stakeholders to decide what they want (backlog replenishment) and to rate-limit the team’s incoming workload (work-in-progress limit).
Kanban is also more agile than Scrum, in the original sense of that word: in Scrum if there’s a priority change mid-sprint, it’s treated as a process-breaking special case and teams will often push back hard against it because it screws up their plans for that sprint. But in Kanban, it just means the top item in the backlog might be different the next time someone goes to get their next task.
I say this a lot, but: “Agile” was a buzzword-y way for a bunch of consultants to tell their clients “the project is late and over budget in large part due to you”.
If you have a workplace where the people with the authority to demand changes to a software project also accept *responsibility for the impact of demanding those changes, then you’re “Agile” and it doesn’t matter what methodology you use. If you have a workplace where that doesn’t happen, then you’re not “Agile” and no methodology can help you.
I guess it depends on if you mean Agile or agile. There’s nothing in agile methodologies that would prevent one from spending time cleaning up and improving; in fact, a properly autonomous agile team will naturally spend a good chunk of their time doing just that. To clarify, the important concepts I’m referring to here are: complete ownership of their own processes, iterative improvement of the ways in which they work, breaking work into iterations to separate redwork from bluework, and retrospecting on each iteration to learn how to improve, and perhaps most importantly a focus on their users, outcomes, and impacts.
I’ve worked with many teams who weren’t doing these things to help them to improve, and the results have been universally good (both from the perspective of the team itself and their executive leaders). Notice that I didn’t use the words Scrum, stand-up, story point, or anything else - those are not the important part (though each individually can be useful tools for individual teams, depending on their make-up and what the team needs at the time).
So, I’m basically just paraphrasing the article. What were your specific concerns with it? It sounds to me like you’ve been burned by Agile. But I wouldn’t throw the baby out with the bathwater. There is a lot of potential positive change from applying these ideas correctly.
At this point “Agile” feels like communism. If the revolution fails, the system is never at fault, it’s because of sabotage by the petit bourgeoisie, or the lack of revolutionary zeal among the working classes.
Anyone else find the “Market Forces” section really unsatisfying? They seem to be saying “if we could somehow invent some way to measure the security of software, then ‘the market’ could deal with it” but it feels like a cop-out, or maybe just a defense of free-market ideology. Like “hey, the free market is great actually, as long as you have informed buyers, which we don’t have, but if we DID have them, boy the free market would be great, you just wait and see”.
Potentially effective ways to address the problems with market forces without just relying on magic handwavium could include greater degrees of liability for peddlers of insecure software, or federal funding for critical widely-adopted open-source projects. But they don’t mention any of that.
My interpretation was a bit more charitable: having a good way to measure software security will make it much more feasible for markets to put a monetary value on security.
Even with a good objective measure, there’s no guarantee that markets will value security. Your criticism is totally valid and worth voicing, IMO: markets may not be enough. I think the message the report was trying to convey was more that the absence of a good way to quantify security pretty much guarantees that markets won’t value it.
If there isn’t a way for the market to determine what software is good and what is terrible until after it fails, what magic handwavium will allow the government to do so before they dictate it to the rest of us?
Market and government priorities are by design different from each other. Markets prioritize profits, while governments can focus on other aspects first such as engineering. That doesn’t mean governments can solve this, but the market failing does not directly imply the government will be unable to succeed.