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.