- I found a tiny bug in a library. A single, trivial, “the docs say this utility function does X, but it actually does Y”. I’m not even allowed to file a bug report. It took me some time to figure out how to even ask for permission, and they referred it to some committee where it’s in limbo.
- LED matrix panels are tons of fun! I strung a bunch of them together to make a marquee across my basement soffit: https://youtu.be/W0_3rzvq9Ks?si=aTT_uOZfOYh9NLUi
I have to resist the urge to tile every surface with blinky lights. I think part of the appeal goes back to why I enjoyed writing programs on my C64 to bounce my name around the screen. It’s a limited playground, and limitations inspire creativity.
- On rare occasions, I use it for the virtual display; it's actually usable to sit outside and work with a giant display on the deck, or to dial myself onto the beach. But it's not exactly comfortable for extended use, and most of the time I'd rather sit at my nice desktop with multiple monitors etc.
I also have a Quest 3 and if I could only own one device, I'd take the Q3 hands-down. The games are fun, they get you up and moving, and although I'm not going to argue that the quality of the screens is the same or anything, it's more than good enough. I'll happily give up the virtual laptop screen in exchange for the library of VR games on the Quest.
I'm not much for consuming media so that aspect is lost on me. Unfortunately, that seems to be the primary use case Apple has focused on, if you can call the anemic dribble of content they've put out focus.
- I've been using Clerk and it seems fine. I'm sure there's some drama, because everything comes with drama, but I just want to get on with building stuff.
- Sometimes I spend half an hour writing a prompt and realize that I’ve basically rubber-ducked the problem to the point where I know exactly what I want, so I just write the code myself.
I have been doing my best to give these tools a fair shake, because I want to have an informed opinion (and certainly some fear of being left behind). I find that their utility in a given area is inversely proportional to my skill level. I have rewritten or fixed most of the backend business logic that AI spits out. Even if it’s mostly ok on a first pass, I’ve been doing this gig for decades now and I am pretty good at spotting future technical debt.
On the other hand, I’m consistently impressed by its ability to save me time with UI code. Or maybe it’s not that it saves me time, but it gets me to do more ambitious things. I’d typically just throw stuff on the page with the excuse that I’m not a designer, and hope that eventually I can bring in someone else to make it look better. Now I can tell the robot I want to have drag and drop here and autocomplete there, and a share to flooberflop button, and it’ll do enough of the implementation that even if I have to fix it up, I’m not as intimidated to start.
- I don’t know if this counts as experienced, but I’ve spent about a year exploring Next.js, the last 6 months of which transitioning from exploring to building a serious project.
I understand the author’s frustrations. I have had similar ones when it comes to middleware and other parts of Next.js. I’ve also had those kinds of frustrations with every piece of software and framework I’ve ever used. A lot of times they stem from trying to shove a square peg into a round hole, and it only gets better when I finally develop the right mental model for how the thing works.
As a web developer going back to CGI scripts in the 90s, all this server and client side rendering, edge runtimes, etc., is quite foreign. But when I find myself screaming “why won’t it let me do this?”, the answer is often “because it doesn’t make sense to do that”. Auth is one of the places where that happened, and going through the process of “but why can’t I look the user up in my database from middleware” was a big part of wrapping my head around the parts of Next.js that I had been ignoring.
As far as being married to Vercel for hosting, not at all, if you don’t choose to use all their stuff. The sample Docker build they have works just fine to deploy anywhere, in my experience.
Maybe I’m speaking mostly out of ignorance of not having tried dozens of other modern TS web frameworks (I was on a big tech island for a decade and not in touch with what the cool kids were up to), but I rather like Next.js. I may feel differently when I want to start adding native mobile apps and realize I was lulled into omitting a clean API layer, but for now, adding features has been pretty smooth.
- This is literally the same mistake that has been made many times before. Of course it will be made again. “New feature is rolled out carefully with a bug that remains latent until triggered by new data” could summarize most global outages.
The thing is, nobody is perfect. Except armchair HN commenters on threads about FAANG outages, of course.
- First some feedback (I see the author is interested), and then a personal take on how I deal with this stuff.
As someone who has spent decades procrastinating, reading about systems to get things done, trying many of them, working with coaches and mentors, and teaching project management, I like to think have a cultivated interest in the topic. I’m very happy that the author found something that works for them. I’m not a gamer, so I didn’t find the comparison particularly relatable. What I did find relatable was the point about getting the dopamine hit (I know that’s debated, but let’s use it as a metaphor) off crumpling up the paper and throwing it away. That’s something I always found gratifying about a physical board full of sticky notes, and it’s just not as rewarding to mark a ticket done in Jira.
In my personal experience of ADD, novelty is a major motivator. A system like this has the appeal of all sorts of new sources of stimulation - physical objects, a new electronic toy, software to write, etc. The problem is that once that wears off, if I’m only doing it for the novelty, I won’t stick with it. I need to engage some of the other sources of motivation (interest, challenge, urgency).
Also, I would love to see someone write an article like this where they keep it entirely in the first person. In other words, focus on “my experience” and “I do this” and “this works for me”. I experience a sort of automatic pushback when I read things like “this will help you” or “you need to”. It may be linked to demand avoidance, or just my belief that there is not a single productivity system or hack that works for everyone. “You need to” try things out, reflect on your own personal struggles, and tailor the solutions to fit. Also, I’m not sure if I would ever call it a cure.
Something I’ve found very helpful is an app called Llama Life. It is not free, so stop reading if that’s a deal breaker. I think of it as kind of a pomodoro timer that someone cleverly fixed for me. I find pomodoros appealing, but they never worked for me. With Llama Life, I stack up what I plan to do for the day along with a guess at how long each task will take. The first benefit this has is that I know what I’m meant to be working on. And when the timer goes off, if I’m not done, I can snooze or extend it, or cut my losses and move on. The other thing I like is that it shows me the total amount of time I’ve allocated, and when each item ends. This helps me to avoid overcommitting: when I look at the end time and see 9:30 at night, I’m forced to reevaluate and cut some things. Anyway, I’m a happy customer.
- I jumped in to the TypeScript deep end a few months back. I build a lot of web applications back in the 2000s, then disappeared onto a big tech island where everything was a little different. After popping back out into the real world, I wanted to see how the cool kids are doing things these days, so I figured I would try full immersion by creating a bunch of Next.js sites.
For the purpose of the experiment, I turned every linter and compiler strictness to maximum, and enforced draconian code formatting requirements with pre-commit hooks. Given that my last language love was Perl, I thought I would despise TypeScript for getting in the way. To my surprise, I think I like it. It's not just complexity like I hated in C++ and tedious boilerplate like I hated in Java. The complexity is highly expressive and serves a purpose beyond trying to protect me from a class of bugs that are frankly pretty rare. When done well, TypeScript-native APIs feel a lot more intentional and thought out. When I refactored my code from slinging bags of properties around to take more advantage of TypeScript features, it shook out weaknesses in the design and interfaces.
I've definitely run into those libraries, though, where someone has constructed an elaborate and impenetrable type jungle. If that were an opaque implementation detail, it would be one thing, but I find these are often the libraries where there's little to no documentation, so you're forced to dig into the source code, desperately trying to understand what all of this indirection is trying to accomplish.
The other one that surprises me when it pops up (unfortunately more than once) is the "in your zeal to keep the implementation opaque, you didn't export something I need, so I have to do weird backflips with ReturnType<> and Parameters<>" problem.
Nevertheless, on balance, I'm pretty happy.
- Teaching myself BASIC on a Commodore 64 in elementary school made me a programmer and set the direction for the next 40 years. Different strokes I guess.
- I remember RPI had something like this in the 1990s. I can't remember what it was called though. But I do remember how impressed everyone was: if you call this phone number, they can answer ANY question!
I believe those of us who were around from then to now experienced peak information. We went from having to look things up in libraries to being able to find anything with a Google search. We're on the downward slope now. Business models have changed, spamvertisers are winning the war against search, and generative AI slop is already the dominant source of "content", ensuring the genie can never be put back. This is not an anti-AI rant, it is just an acknowledgement that like so many things, we were foolish to think that access to information was just going to keep getting better. I did not expect that in my lifetime, I would see the best it was ever going to be.
Maybe in the future, calling a trained human for help will be the only way to sort through the mountain of infogarbage to find something. Or we'll have to go back to the library.
- I think it is the permanent end of American economic/political/cultural dominance, which is a long-term gain for the world, but it's going to put the hurt on a lot of people (myself included). I am not quite altruistic enough to celebrate being sacrificed in this way, but I can see that when the future history books are written, they may look back at this as the end of a blight.
- Python is in a category of things you can't just use without being an expert in the minutiae. This is unfortunate because there are a lot of people who are not Python developers who would like to run programs which happen to be written in Python.
Python is by no means alone in this or particularly egregious. Having been a heavy Perl developer in the 2000s, I was part of the problem. I didn't understand why other people had so much trouble doing things that seemed simple to me, because I was eating, breathing, and sleeping Perl. I knew how to prolong the intervals between breaking my installation, and how to troubleshoot and repair it, but there was no reason why anyone who wanted to deploy, or even develop on, my code base should have needed that encyclopedic knowledge.
This is why, for all their faults, I count containers as the biggest revolution in the software industry, at least for us "backend" folks.
- Adding `-p 3.12` made it work. Leaving that here in case it helps someone.
- Ran it and it crapped out with a huge backtrace. I spotted `./build_bundled.sh: line 21: cmake: command not found` in it, so I guessed I needed cmake installed. `brew install cmake` and try again. Then it crapped out with `Compatibility with CMake < 3.5 has been removed from CMake.`. Then I give up.
This is typical of what happens any time I try to run something written in Python. It may be easier than setting up an NVIDIA GPU, but that's a low bar.
- Ours is a Fisher & Paykel dual dishdrawer, which does exactly that, in the space of a single unit.
- I'm surprised this Jon Richardson bit hasn't been posted already. It's an incredible piece of comedy, even moreso given that it's about loading the dishwasher.
- The C64 starts up straight into BASIC from ROM. Unlike some other contemporary computers, it doesn't attempt to boot from any external devices (except the cartridge port). There isn't really a DOS in the usual sense. Apart from simple support for loading and saving programs, and a very basic channel I/O facility, everything else is handled by the firmware in the disk drive, which has its own 6502 and operating system.
For example, there's no command for getting a directory listing. You type `LOAD "$",8` (8 being the disk drive), and the drive pretends there's a BASIC program called `$` that happens to contain a directory listing you can then look at with `LIST`. (https://en.wikipedia.org/wiki/Commodore_DOS#/media/File:Comm...)
By default, LOAD loads tokenized BASIC programs, but if you add an extra `,1` to the command, the file can contain arbitrary data starting at any location in memory. You could use this to load a machine language program and then run it with `SYS <location>`. Clever programmers figured out they could skip this step by having their file overwrite a vector that gets called after the load completes and jump right into their code, resulting in every Commodore kid having being able to type `LOAD"*",8,1` on autopilot.
I got distracted by other trivia (I grew up with this computer and it was hugely influential and I will adore it forever) from getting to the actual point: The C64 uses a variant of the 6502, the 6510. It has a special register for swapping out any combination of the three ROMs (BASIC, KERNAL (sic), and the character ROM) plus I/O registers that overlay portions of the 64 address space. If your code doesn't use those, you can access the RAM they are hiding by turning them off.
But I very much dislike when they phase it as “you need to” or “this is how it works”. Thinking everyone else’s brain operates the way yours does seems to be a frequent bias among bloggers. And managers.
I encourage those who write about their experiences to keep it in the first person.