> I don’t want to sound elitist, but if you don’t want to learn to go beyond vibe coding, maybe coding isn’t for you. It’s not elitist, it’s just a fact. Being a viber for life will keep you at the bottom of the greasy pole earning bottom-pole salaries. We are out of the era of $160,000/year SV entry-level job handouts - programming is now real work for realistic pay. If you don’t enjoy it or at least tolerate it more than the next thing, why are you here? This life is brief and you should become an ophthalmologist or struggling artist instead.

LLM-based tools cultivate dependence on rent-seekers, and meanwhile the spam they generate is destroying search engines and polluting all sorts of other educational resources. Take heart: as many of the *loudest* developers (but far from all developers) choose to let their programming skills atrophy and submerge in mediocrity by using LLMs to automatically generate an endless stream of technical debt, knowing what the hell you’re actually doing is more valuable than ever.

RSS has always been a dumpster fire of incompatible versions, misleading version numbers, and amateurish vague “specs”. Atom was a valiant attempt to fix that, but we ended up with the xkcd “now you have 14 standards” punchline. I was involved in that stuff at the time, but tried to stay out of all the mud-slinging (for which Dave Winer, one of my least favorite people in tech, bears much of the blame.)

One of my personal signals of a high quality codebase is the ability to make simple changes by touching as few files as possible. If it takes edits to eight files to add a checkbox that’s an architectural design smell for me. I know there are plenty of systems out there that work like that but I’ve never found myself regretting working on systems that manage to avoid that level of multi-file complexity. These days I much prefer a project with a few large files than a project with hundreds of tiny ones. My ideal change involves editing code in two files: an implementation file and an accompanying test file.

Building for Windows is easy. Running tests on windows is hard, because it’s a counter example for “everything is POSIX”. CI system should support POSIX and non-POSIX, and that level of heterogeneity is one of the hard problems.

Helix reminds me of a saying I once heard: “the first examples of a superior principle are worse than the last examples of an inferior principle.” I’ve tried to use it a few times and I can tell that noun-verb with multiselection is just *so much better* than verb-noun! But it’s also missing critical things I need like a scripting system (which is different from a plugin system!) and autocommands. I’m hopeful that eventually it’ll be something that can replace Neovim for me! Or that someone will make a complete noun-verb system for neovim that’s close enough.

My question is: why is that good? “Magical” is one of those words in programming that usually means something has gone horribly wrong. Don’t get me wrong: I want my tool to make it easy to make mechanical changes that touch a bunch of code. I just don’t want the process to do it to be a magical heuristic.

> Reliable software is extensively tested software, and extensively tested software is running software This has been proven false countless of times. In non-trivial programs the state space can be too large to test exhaustively. The states that lead to vulnerabilities are not the states used during normal program execution. For example, if you’re parsing a file, your code will be battle-tested on correct and slightly broken files. It may be further tested on random fuzzed files, but there may still be a very specific combination of inputs that never happens in real files, and that’s too rare to be discovered by random chance, but which can be deduced by an attacker. e.g. NSS – millions of users, decades of real-world testing, fuzzed, and yet missed a basic safety issue: [1]: https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html?m=1

At Oxide, we reach for building our own tools very often. And while it does have some disadvantages, it also has tremendous utility. As an example, when we first started writing web servers, it was decided that types are good, and we should use OpenAPI as a means of defining our APIs, and work from there. When we looked around at the existing ecosystem, what we wanted didn’t exist, so we built Dropshot as a server side framework, and wrote our own code generator to generate TypeScript clients from the OpenAPI definitions Dropshot can produce. This has led to a really nice workflow, and we can tell at compile time if the two sides disagree! Another example being Hubris, our totally-not-a-RTOS, and Humility, our debugger. It’s really important to be able to properly debug embedded systems, and by having a debugger that is aware of the shape of the system being debugged, it feels like the example with the editor from the article. You can get custom workflows that really save you a ton of time in the end. Anyway I mention my job specifically because a hard part about building your own custom tools in a work context is being able to get buy in on spending time building the tool. That’s the tough part of doing something like this; you’re paying an up-front cost (building the tool) to amortize over a lifetime of lower costs (using the tool). So there’s some risk there. Additionally, you have to be willing to spend time getting new employees up to speed with your tooling, because it’s unlikely they’re already familiar with what you’re doing. But we’ve found it’s worth it quite often.

in these threads, there are always several archetypes: **the big tech employee** buys only perfectly considered, pristine gear. no dust or mess. macbook, standing desk, expensive chair, standalone mic, monitor-on-an-arm, face tracking webcam, and a very expensive set of wireless headphones. pictures of this setup typically look very aesthetic. **the hardware hacker** typically two arbitrary same-height desks wedged together to form an L, with a monitor inexplicably placed in the corner. small circuits and soldering irons coat every square centimeter of surface area. gigantic magnifying glass machines with tons of strange limbs are crimped to the desk. a single ancient oscilloscope sits on a stack of reference manuals. **the gnu enthusiast** an ancient librebooted thinkpad (coated in FSF and EFF stickers) is docked on the only proprietary dock that the libre version of the linux kernel supports. a single 20-inch monitor from 2004 sits on the desk, along with several penguin plushies. the laptop does not produce audio. the desk itself was purchased for $80 from the local amish resale market. their chair is a big recliner. **music maker** 2 LS-50 speakers, a schitt amplifier, and a mixer dominate most of the desk. the monitor is inevitably mounted a little-too-high. despite taking up 90% of the workspace, the music equipment is used somewhat sparingly, while the music maker is left craning their neck upwards towards their monitor to watch youtube videos until 3am. **the person who writes software that 90% of the world uses** an arbitrary laptop running ubuntu + a couch. **me personally** i’m a hybrid - somewhere between big tech employee and gnu enthusiast. my ancient monitor sits on a big green milk crate: [https://imgur.com/a/6Oo2Cos][1] [1]: https://imgur.com/a/6Oo2Cos

> **So was this a violation of the chip ban?** > > Nope. H100s were prohibited by the chip ban, but not H800s. Everyone assumed that training leading edge models required more interchip memory bandwidth, but that is exactly what DeepSeek optimized both their model structure and infrastructure around. > > Again, just to emphasize this point, all of the decisions DeepSeek made in the design of this model only make sense if you are constrained to the H800; if DeepSeek had access to H100s, they probably would have used a larger training cluster with much fewer optimizations specifically focused on overcoming the lack of bandwidth. This was amusing to read and feels almost like the premise for a novel. Country bans export of important resource. Opposition discovers a way to use a cheaper resource to reach parity.

i like antirez’s take on licensing here. reminder that the OSI was started by libertarians, and has always held business interests first & software freedom second. the OSI definition of open source is basically “as long as companies can sell your software labor for free & not contribute back in any meaningful way, it’s open source.” it’s time to explore alternatives. anyone holding the “open code = good” opinion should re-evaluate in the face of companies viciously exploiting open projects for money — it’s a digital land grab.

It’s very easy to explain the problem with Wayland in non-technical terms. [Thing] worked before, and now it doesn’t anymore. Times thousand. As long as technical purity is prioritized higher than the user’s needs, this won’t change. You can’t just rewrite everything, drop and break half the functionality and pretend that it’s a drop-in replacement. This will be more painful than the Python 2 to Python 3 version jump. But I guess things need to get worse before they can get better if you are in a local optimum.

I can tell our industry is fucked because I can’t imagine convincing a product manager or manager to prioritize a ticket called “making the product usable from slow satellite uplinks”. “What’s the expected ROI on that?” “I already promised features X, Y, and Z to customers for this quarter.” The only times I’ve been able to convince leadership to work on stuff that didn’t directly affect our bottom line were when external regulations demanded it.

I feel really similarly about Python (for web backends, specifically, but probably also any large project). I can’t wrap my head around how anyone can try to write and maintain a large, long-lived, project with Python. And if you do somehow get a bunch of people to agree on conventions and style, and write reasonably correct code, your reward is just like you described for Ruby: really bad performance (both execution speed *and* memory consumption).

Having worked with Ruby for close to two decades I’m convinced there is no point anymore for large software systems. It’s a nice language for sure but after a few ten thousand lines it becomes impossible to deal with. Add just a couple inexperienced engineers and the whole thing unravels. You’re constantly fighting an uphill battle for good code and the language does not help you: it has no package-level segregation, no type system, no way to enforce interfaces, implicit method definitions all over…you have workarounds for all of these but they’re all non-idiomatic and no one uses them. It’s just as easy to write “beautiful” code as it is bad code, you gotta keep yourself to an opinionated subset of the language and be vigilant about it. And what you get in the end is not encouraging—if you manage to keep good separation of concerns and extensible code you get the big prize: one of the worst performance profiles in major languages. Over the years I’ve seen speed of development fall off a cliff while systems get bigger, taking away one of Ruby’s main advantages. This is also an overrated aspect of software systems and languages: you’re in a “I want this to be stable and efficient” state for much more time than you’re in “I need to prototype this fast” state, so it doesn’t make sense to optimize for the later. If you take an extra week to get to market in a “slow to write, statically typed” language nothing bad will happen to your company and you won’t need to worry about any of the above.

> I wish it were possible to look up any medical issue without being exposed to the most graphic photographs ever taken by man or beast. I couldn’t agree more with this. I wish browsers had a global “disable all images” toggle somewhere for exactly this use-case.

The “What’s missing” section is on point. There are a lot of tutorials for helping someone learn the basics of Nix and build Baby’s First Package. There are not many tutorials about how to package real software you are actually developing. I think this is because it is (relatively) easy to explain what attrsets are or how to type `nix run some-flake` and press enter, and it is hard to explain what `LD_LIBRARY_PATH` is, or how Python environments are built, or why you should have known to apply this `.patch` file at that step, etc. It is, in the words of the authors of Zero to Nix, “fun and exciting to make a splash” by writing a completely new Nix 101 tutorial. That’s why we have half a dozen Nix 101s, very little Nix 201, and Nix 301 is searching GitHub for code snippets that solve a problem adjacent to yours.

We use nix very conservatively. We only use it for managing local developer environments, ie. build toolchain and other cli tools (ansible, terraform, etc). That has worked out amazingly for us. I’m in general a lot more skeptical about nix for production. You don’t clearly get the kind of support like you would from, for example, Ubuntu’s packages. There’s no “LTS” as far as I know for nix, merely the stable NixOS release. Though, that being said, nixpkgs tends to be way ahead of other package managers’ versions of software. We’ve started messing around with using nixpkg’s docker tools for some web projects. That would be the first time that we’d be using nix in our production environment. In general, it’s really easy to go overboard with nix and start using it really inappropriately. But if you use some discipline, it can be an *amazing* tool. It’s completely solved our python problems related to installing ansible. That’s invaluable.

I still struggle to understand the appeal of wireless earbuds, Airpods or otherwise. Under my value system, the costs are significant while the benefit is small: * you have yet another battery to keep charge * you have another object to lose * you have yet another flaky wireless connection to contend with * you must pay a good fraction of $1000 for the mediocre audio quality supported by said wireless connection * you have to live with the knowledge that after two years you will have introduced yet another sliver of unrecoverable minerals to a landfill somewhere While the last consideration alone is, for me, enough to summarily rule out wireless earbuds from my purchasing options, apparently there is no shortage of people who feel that the benefit had in being rid of a cable outweighs all of these costs. Given that any decent set of wired earbuds will have a relatively tangle-free cable and carrying case, I can’t help but wonder whether I am failing to see some key benefit beyond not having to occasionally manage a cable.

I’m no longer able to live like this for the usual reasons (family, kids) but agree with everything here. I’m more likely to burn out from other responsibilities than I ever could from coding. Coding *is* my main relaxing activity, my main hobby, the thing I spend most unallocated time doing. Coding for “work” did break this in me for awhile. Just like reading for school can kill a love of books for awhile. But with some space from toxic environments like school and soul-sucking jobs they have both come back and now I read books and write code for myself again.

I have never been called a massive wanker, but I do often get confused stares when I try to explain this. For me both literature, or creative writing, to be less presumptuous, and programming are ways of expressing the ideas, stories and models that float around in my mind when I am thinking about the world. Some stories are better told with fiction, others by software. Many can be told by both, in the same way that a painter can paint the same picture with different techniques and get results that highlight different aspects of the picture. As with all forms of expression, it is never possible to completely transfer the inner world of my brain to that of someone else. So we use approximations. Programming and creative writing are different techniques for making those approximations and both use text as a storage format. And thus they are naturally closely related to each other.

I tell anyone asking me for career advice the same two things. The first: the deeper in the world’s dependency tree you are, the less frequently things will churn, and the longer your skills will last. TCP doesn’t change very often. [Theoretical skills][1] may be applicable for your entire career. Human skills are more durable than any technical skill. Kernels don’t change very often (but more than TCP). Databases don’t change very often (but more than kernels). There is a spectrum of skill durability, and you will burn out faster if you find that all of your skills become worthless after a very short time. Dependency forces things not to change their interface, which causes the work to shift toward performance and reliability among other things that some people find far more rewarding over time. The second: the more people who do what you do, the worse you will be treated, the more BS you will have to put up with, the worse your pay will be, the faster you will be fired, the harder it will be to find a job that values you, etc… etc… Supply and demand applies to our labor market, and if you want to be happier, you should exploit this dynamic as heavily as possible. Avoid competition like the plague. But don’t avoid funding. How do you avoid competition without going off into the wilderness where there is no money to be made? Hype drives funding, but it also drives a lot of competition. However, using rule #1 above, the hyped things depend on other things. Many of these dependencies are viewed as “too hard” for one reason or another. That’s the best place to be. Go where other people are afraid, but nevertheless have a lot of money depending on. All hyped things rely on things that for one reason or another are not commonly understood, and tend not to change quickly. That’s a good place to find work involving durable skills that tend to have lower competition. Go where the dependency is high but the competition is low, and you have a better chance of being happy than people who go where the competition is high or the dependency is low. Bonus points if it’s actually “hard” because then you won’t get bored as quickly. There are areas of front-end that are high-dependency, durable, slow-changing, and low-competition. That’s where engineers are likely to be happiest. But these two principles apply to every field or zooming out to any business generally. I’m pretty happy working on new distributed systems and database storage engines for the time being. But I’m always looking for the things that are viewed as hard while also receiving significant investment, as these are the things that will ultimately give me more opportunities to live life on my own terms. [1] https://sled.rs/perf

The principle is the same with electronic voting machines. When software becomes law, proprietary code is like having secret laws.

This article really gets to a fundamental misunderstanding I feel our whole industry has: Programming is not construction, it is design. Yeah, houses rarely collapse, but structural engineers don’t expect that their second draft will be taken out of their hands and built. Or that the fundamental requirements of their structure will be modified. I don’t mean to suggest that programming should behave more like construction. The value of programming is the design. Programming is the act of really thinking through how a process will work. And until those processes are really done and won’t change (which never happens) that design never stops.

The only way to protest these harmful developments is to quit these websites altogether and use alternatives. If the information on reddit is so important, just read passively using teddit, but stop feeding your valuable data into a system you don’t support. Rather, help expand communities that actually respect their users with your knowledge. Someone has to start it.

Software engineering is a creative, not a manufacturing discipline. Every one of these attempts to measure or gauge developer productivity seems to miss that point.

It’s OK for most of our contributions to go away some day. We’re not as special as we were told growing up, and we’ll be a lot happier if we learn to accept transience.

This seems like a good compromise to me. The tools that provide safety eventually fail, but you need social pressure to avoid devs saying ‘f*** it. We’ll do it live.’ every day.

Just like with any tool, it’s usually great when it feels like it’s an extension of yourself. If you struggle to achieve, create, check or understand something, you’ll always be fighting. But that doesn’t mean there’s a ready-made solution, your knowledge and experience is also important. I’m not sure if it holds for teams as well though…

One of the project ideas in my backlog is an aggregator like lobste.rs where the front page only updates daily. People can submit and vote however they like using Slashdot like categories (insightful, funny, etc). Once a day, a new front page is generated from the top submission per category. Discussion is only enabled on frontpage submissions. By design, you cannot comment on current stuff due the delay. So people who desire that should scratch that itch elsewhere. The goal of the site is not to collect hot new links but to discuss interesting things. There are clear “topics of the day”.

There’s a huge funnel problem for computer science at the moment. Go and Rust have some pretty serious evangelical marketing teams, but they are a drop in the ocean compared to the emergent ultramarketing behemoth that feeds JavaScript to the new developer. Part of this is that JS is constantly “new and modern” – with the implication that it’s a bandwagon that you’ll be safe on, unlike some of the old cobwebbed bandwagons. Constant change and “improvement” is itself a safety generator. Another part is that it’s so easy to get to hello, webpage. The sweet spot on the racket is enormous. Every computer including your phone comes with at least 1 and usually several JS interpreters. Frictionlessness drives adoption. The problem is that JS is, violently, garbage for most purposes. It’s a local maxima that has essentially everyone trapped, including the next generation. It’s not clear how we escape from this one.

I would say that this is a kind of premature optimization in 99.9% cases. Where are we going as software developers if we have to spawn a thread to just release memory? Maybe I’m just old fashioned or maybe I’m just shocked.

I can appreciate the sentiment of this article, but it does border on encouraging incompetence. I know people who really treasure that they’ve always been “nerds” and “into computers and programming”, but were actually very ineffective. But, I’ve seen the other way too, where people clearly are just interested in trying to skate by with an easy gig, minimal effort, no extra effort at learning new things or gaining useful skills unless required. I feel like hard work, competence, and initiative is all that is expected. These are hard to define in practical steps, but easy to spot when you see it.

Breadth-first, not depth. Defer relentlessly. Check with your primary goal regularly. Time-boxing. The trick with making meaningful progress and not spinning out on these tangents is *pausing to recognize them as tangents*. Only execute on a sub-task if it is *necessary* to complete your immediate goal. If a sub-tasks can be deferred, do that; You can evaluate if they are still useful later. Capturing them to get it out of your head should alleviate some of the pull that they have on you – they won’t be forgotten, but don’t need to be done now. And always be asking the question “Is this helping me solve my immediate problem?”. Why did you want the interactive debugger? Probably for more context. For debugging specifically, always be asking is there a dumber/simpler way to find concrete information? Just sitting and thinking through the specific context that you think you need may have allowed you to continue with print debugging might have short-circuited the tangent. The other tactic that can help is, when you start a sub-goal, estimate how much time it is worth to you, and set a timer. Had you valued the interactive debugger at 20m, and then the timer went off and you realized that you were about to re-install your interpreter. That is a good moment to re-evaluate. And having the concrete time box prevents you from losing an entire afternoon to a chain of those. As a reminder, maybe put a sticky note in front of you with your current goal. And keep checking in that you are still really working towards it. As for tooling, omnifocus and dynalist.io both have quick capture features for things you can defer until later. And dynalist.io and workflowy literally let you nest these tangents, which can be a visual signal when you’ve gone too far. But I think the crux of your question is more about focus and process and less about the tools.

Time. Take the time to take a step back, think about what you’re doing, and why. Don’t assign the PR you finished right away, but give it some time, let it linger, and see if later you can make it simpler. Don’t pick the first solution you came up with, but take some time to think about other options. In my experience, any other optimizations you make dwarf in comparison.