don-code

Much like the author, I consider myself to not use my phone too much. That said, it's probably just as far from the truth for me as it is for him.

Microsoft Authenticator is the biggest offender that comes to mind - without it, I cannot work. My company requires that we share our location to access systems (it's to enforce compliance controls that data stays in the country), so I can no longer use an offline MFA strategy like a U2F token or a TOTP key - I _have_ to use Microsoft Authenticator.

This seems to be how a lot of modern history is found.

I recently got to talk to a big-ish name in the Boston music scene, who republished one of his band's original 1985 demos after cleaning the signal up with AI. He told me that he found that tape in a bedroom drawer.

There's a certain meaningfulness ascribed to deliberately taking time for something.

I actively listen to a vinyl record when I cue it up. I let the radio sputter in the background while I work.

I actively read a book when I have a night or weekend to myself. I let Hacker News articles tend to go in one ear and out the other, even if I tell myself I spent some time reading before bed.

I actively figure out what's going on in the world when "what's going on in the world" becomes too dire for me to ignore. I fall asleep to the 10:00 news.

It surprises me _not in the least_ that I'd spend time with something that I want to make time for, and not just something I've allowed to become part of my routine.

I wrote a web application in an internship, circa 2011. I had no existing platform/framework to work with, no mentorship (the team wasn't really prepared to support an intern), and most importantly, an Apache web server running in Cygwin, with no PHP runtime installed. No one as much as told me what language I'd be writing at this job.

The Web development I'd done up to that point consisted of raw HTML/CSS, with some ASP.NET or PHP running on the backend. I'd never written a line of JavaScript in my life.

It was at this point that I "discovered" a winning combination: HTML, CSS, and JavaScript running in the user's browser. The backend was a set of C# applications which wrote to standard out, which could be invoked directly by Apache's mod_cgi, since C# compiles down to Windows executables. There were countless better other solutions at this point - ASP.NET/PHP (as I'd already used). FastCGI, WSGI, and others were all a thing at this point, but I'd never heard of them.

I outputted a JavaScript object (I had no idea what JSON was at the time, or that I was effectively outputting it) and read it back into the browser using a thin wrapper around XMLHttpRequest. I then iterated over the outputm and transformed the data into tables. JQuery was a thing at that point, but likewise, I'd never heard of it.

Say what you will about the job, the team, the mentorship (or lack theorof) - it took them three months before they realized I'd written C# at a Java shop, and at that point the thing was already being used widely across engineering.

The important takeaway here was, that "winning combination" of some minimal JavaScript and CGI was the perfect ratio of simple, approachable, and powerful, to enable me to finish the task at hand, and in a way that (at least until anybody saw the architecture) everybody was thrilled with. It didn't require a deeper understanding of a framework to bootstrap it from nothing. Write an HTTP response to standard out, formatted as an object, and you were on your way.

I don't think such usage is malicious, so much as ignorant - it's sometimes hard to know that a behavior _isn't_ part of the API, especially if the API is poorly documented to begin with.

I maintain a number of such poorly-documented systems (you could, loosely, call them "APIs") for internal customers. We've had a number of scenarios where we've found a bug, flagged it as a breaking change (which it is), said "there's _no way_ anybody's depending on that behavior", only to have one or two teams reach out and say yes, they are in fact depending on that behavior.

For that reason, we end up shipping many of those types of changes ship with a "bug flag". The default is to use the correct behavior; the flag changes the behavior to remain buggy, to keep the internal teams happy. It's then up to us to drive the users to change their ways, which.. doesn't always happen efficiently, let's say.

This strategy was actually used during World War II, to ensure pilots could come home safely. Weather forecasting not being what it is today, meteorologists determined what conditions would result in the _most_ lives being lost, then together with mission commanders "designed" missions to simply not meet those conditions.

Source: https://medium.com/butwhatfor/suppose-i-wanted-to-kill-a-lot...

I also "boycott" many such systems, and I completely empathize with the author on not really being sure why I'm doing it. It's, sadly, more for myself than it is in belief that anything will change, because many of these systems are ingrained, and it's not reasonable to expect that the others around me are also going to give them up.

Some examples:

I haven't ordered anything on Amazon since 2014. I hope the rationale is pretty obvious. I lean heavily into brick-and-mortar and especially local stores, where possible (I'm blessed with many local book and music stores). I do use eBay, and occasionally (maybe 1 in 10 purchases) I find out that the seller is actually just doing arbitrage from Amazon - they buy a $10 item on Amazon for $5, and have Amazon ship it to me using the "gift" feature. $5 profit for them; lots of bad feels for me.

I don't subscribe to any of the streaming platforms. I believe that I should have a tangible video that can't be clawed back, so that means buying a lot of DVDs and Blu-rays. Blu-rays, I know, are a tower of cards, since my ability to play them back indefinitely relies on leaked keys. If I want to watch a "Netflix exclusive", like Stranger Things, it means I'm organizing a watch party with friends who have subscriptions, where I'll provide food and beverages to at least attempt to offset that I'm benefiting from a streaming platform.

I listen to a local college radio station, instead of Spotify. I love that there are human DJs curating the playlists. They're creating community (the station actively engages the community), and since they're mostly college students, they're learning a valuable skill for their futures as well. Since laws around public radio prevent them from selling advertisements, I donate to the station in excess of what I'd pay for Spotify, since I value it. For buying music, my preference order is Bandcamp (DRM-free FLAC; the artists actually get a decent cut on the sale), followed by physical CDs (see the tangibility comment, above).

I run my own e-mail - both inbound and outbound. This is because I am stubborn, and have done it for twenty years now. I know Gmail and Outlook are on the receiving end of 90% of the e-mails I send, so they have a copy of most every message. The maintenance makes it a Pyrrhic victory.

I abstain from social media entirely. Hacker News comments are about as "social" as I get in the public sphere these days, as they capture the spirit of what I loved about the Usenet/forum days. I do participate in some professional Slack networks. Much as all of those networks would prefer _not_ to be on Slack, it'd be too hard to up and move the communities.

I could go on, but the gist is that I know these decisions are helping me, more or less exclusively - they don't even register in the overall trend.

My "stack" for watching TV consists of:

* A Hauppage WinTV HVR-950 tuner, connected to a Kubernetes cluster in the basement.

* NextPVR, scheduled on the appropriate node in the cluster (yes, it's non-redundant, even though I have three nodes). This handles DVR scheduling, and transcoding should I want to watch TV off-network.

* Kodi Media Center, running on a PC in the living room, and a Raspberry Pi 3A in the kitchen. Both pass through the full MPEG-2 stream. I additionally have an XSPF playlist link on my laptop and phone that open VLC to the transcoding-capable playback URLs for NextPVR.

* FreeNAS with a _significant_ amount of buffer available (at least for my one-hour-daily recording schedule), backing the DVR capability over NFS.

I'd argue this setup is actually _better_ than what I'd be able to do with a simple VCR/DVR. It's like having a robotic tape library, but without the physical space required.

I love the first issue and went to follow the site's RSS feed, but the four posts on the feed seem like spam? They each start with "Leverage agile frameworks to provide a robust synopsis..."

By 2040, I suspect not much will have changed. In the US, most engines that required leaded gasoline rolled off the assembly lines in the 1960s, with the legal phase-out beginning in the 1970s, and finally ending in the 1990s.

As I have a classic car that I intend to keep running, I suspect eventually (e.g. not by 2040), buying fuel for it will be similar to buying pre-mixed fuel for small two-stroke engines, like leafblowers and chainsaws: go to Auto Zone and buy a few gallons of fuel. Auto Zone and friends won't be going anywhere - EVs still need wiper blades, brake pads, and other incidentals.

I was literally just there an hour ago, buying $800 worth of gear for a Wi-Fi mesh buildout.

Could I have gotten it cheaper online? Probably. But when you have 36 hours notice that you need to build out Wi-Fi, you can't beat Micro Center.

There were several years (late 2015 to mid 2017) where I did a much less extreme version of this. I stopped because, as many commenters have noted, I was (to quote this one: https://news.ycombinator.com/item?id=44077097) "living off the economic surplus of [others]", and perhaps even taking opportunities away from those who needed them much more than I did.

Some anecdotes from that time:

I had a $30/mo phone plan that got me 100 minutes, and 5GB of data at HSPA+ speeds. I basically never worked from home, even if that had been an option, because one too many `npm install`s or video conferences would've set me over the edge. I brought my personal laptop to the office to install OS updates, and took downloads back home on a flash drive. And if I had an unexpected call to a 1-800 support hotline - one that I knew would take an hour - I'd literally go find a payphone, where you could call it for free (although it's a much higher charge to the recipient).

I developed a strong love of free-to-me media and entertainment. I was a voracious reader of library books, got my news off broadcast TV, listened to FM radio for music (to be fair, I'd always - and still - done that), and so on. I was attending one or two tech meetups a week.

I didn't have a car. Being a 15-minute walk from a train station helped drastically, but I wasn't as close to the city as most of my colleagues were (maybe 20min over others' average). Visiting my parents took 115 minutes (30 minutes by car) and I did it every other week. Twice a week, I'd take a commuter rail train south of the city, then walk 20 minutes to get where I was going. Most of the time I'd bum a ride back to the station with someone else there. All said, it was probably two extra hours of commuting whenever I did this. There were even times where I'd carry odd things home from Home Depot on the train.

And then, as we got older, many of my friends started to move far out of the city, to places unserved by our transit system. I was totally dependent on my friends still in the city to carpool, even though I was almost certainly making more than they were. I wish - truly I wish - that I could say that this was the straw that broke the camel's back, what made me snap out of it.

Sadly, that honor went mostly to both my work changing (much more teleconferencing / Zoom), and my family situation changing (needing to commute out to the burbs regularly, sometimes with little notice).

I still remember some of the jibes I'd get while doing this - "why do you make life so hard on yourself?" and "you don't know how to have money".

I look back on that time and do think it was an interesting experiment, and to an extent, I'm glad I did it for the perspective. But really, I was naive. I wasn't doing something that somehow made me more independent, or less wasteful. I was dependent on much of other's output, and really only wasting my own ability to be productive.

A few years ago, I had a three-day power outage. Unfortunately, at the time I worked for an e-commerce company, and Black Friday was in two weeks - not the time for me to be off work. (Mind you, this was 2021, and temporarily returning to the office was questionable at best at that time).

Most of my neighbors seemed to have up and left. The immediate neighborhood was quiet. I ventured out and saw what had happened: a large tree had come down, taking the power lines and the road with it. So I assumed the recovery process would be something like:

1. Remove the tree - one company on one schedule

2. Re-pave the road - another company on another schedule

3. Put the telephone pole back up - the phone company (the poles are owned by Verizon in my area)

4. Restore electrical cables - the power company

And I realized that this would not be a quick process.

I threw a 100-foot extension cord out my second floor window, and hooked it up to the 400-watt inverter in my car. (Yes, I know this is terrible for my engine. The silver lining was that somehow the folks at BMW made an engine that got up to operating temperature while idling.) The other end got plugged into the three monitors and laptop on my desk. I hotspotted my phone, and... just kept going at Black Friday readiness.

At one point, I got an interesting sideways glance from the CEO on a Zoom call, as if to say - "Why are you wearing a jacket and fingerless gloves indoors? Do we pay you enough?" I'm just glad the smell of not showering wasn't transmissible through Zoom.

Although I lost most of the contents of my fridge, and I ended up eating a lot of peanut-butter-and-jelly and protein bars, I did find some ways to keep it interesting during the day. I put my moka pot on the charcoal grill for coffee in the morning, and at one point I made a grilled-ish cheese on top of the engine block.

I used a handheld flashlight and an LED lantern for light after the sun went down. And I did treat myself to dinner with friends all three nights, charging up two UPSes at their homes while we went out, so that I could in turn run some other appliances without running the car. I seem to recall at one point watching the 10:00 news on TV thanks to those UPSes.

I would not have wanted this experience with a family like this person did, for sure, but I actually found it somewhat fun and interesting.

I challenge anyone to find another place on the Internet where one person's joke is another person's kernel module.

I can't be sure about the latest models, but my two iRobot products - a Roomba 650 and a Braava 380t - don't have Wi-Fi connectivity to begin with.

The Roomba has physical buttons on it, which allow you to set a cleaning schedule if you so choose. There's also a small LED display, and a speaker that "says" what's wrong.

The Braava, by contrast, is a dumb-as-bricks device with two buttons - "mop" (which uses mop-like motions) and "sweep" (which uses broom-like motions).

Do they bump into stuff? Yep. Do I call them "dumbass" as I watch them clean? Sure do. But they're otherwise perfectly capable little single-function devices that don't try to do anything more than they really need to do.

Chef did not make a clean transition into the immutable world. Chef Client was great for persistent infrastructure, but the options got dicier once we started talking about pre-provisioned infrastructure like image building:

1. Chef Solo (how I last used it when attempting this), which felt intentionally hobbled. All you needed was one poorly-behaved cookbook that called `search` and the bets were off.

2. Chef Zero, which was unnecessarily complicated for being Chef Solo that wasn't intentionally hobbled, so much so that I kept using Solo for awhile after its deprecation.

3. Chef Client, against a Chef Server that was run either for your other persistent infrastructure, or just to have a place to put the cookbooks. Heaven forbid you weren't cleaning up all of those dynamically-created nodes, though...

I still think Chef's Ruby DSL is much more natural than the YAML manifests used by Ansible, and the ability to integrate at the source level with custom Ruby code is a killer feature as soon as any complexity enters the mix. But I almost certainly would not be using Chef in a greenfield deployment these days.

This is, in some way, endemic to all branches of software. Every group of practitioners has a shared vocabulary - as the article says, it's exploiting an efficiency. If we all have a common language, we can speak more efficiently about what we're doing, and what needs to be done.

That said, how approachable that vocabulary is reflects how approachable the community around it is.

For instance, I've found the DevOps community to be very open and accessible to newcomers. There is shared language - orchestration, config management, even some acronyms like CI/CD - but they generally seem to use approachable language. I've also found the Python and Ruby communities to be very welcoming and willing to teach newcomers, and while I'm not involved in it, I've heard the Rust community really shines here.

On the other hand, one of the reasons I've stayed away from the security community is its propensity for acronyms. SIEMs, CSPMs, ASPMs, SASTs, DASTs, EDR tools, and maybe you've even got a CISSP cert.. It's not approachable, and I've found that many security practitioners wear knowledge of these acronyms as a badge of honor. I've found the networking community even more toxic: there are some pieces of software I've used for over 20 years, with forums I avoid like the plague, because many questions are answered with some variety of "Read the docs!" or "You don't KNOW?!?!"

If I were a benevolent-dictator-for-life and had to bootstrap a community, I'd be aiming to foster the former, not the latter.

Yes! This is actually where I learned about the patched "_0024" images for IDE drives.

Unfortunately, at boot, the drive is recognized but can't be mounted. I suspect it has something to do with the LBA card (Promise EIDEMax) I have in the machine I was trying to install it in, since the machine only supports C/H/S drives out of the box.

I can point to my phone as being one of those devices that's _lost_ functionality over the past ten years.

Losing functionality is not bad in and of itself, if I stand to gain something in excess of what I lost, but that hasn't happened. Consider when I made the switch from a Treo 650 to an HTC Sensation (yes, I had that Treo a _long_ time): I sacrificed the hard keyboard and exceptionally easy-to-use operating system for Wi-Fi, a decent quality camera, fast-at-the-time 3.5G network connectivity, and the entire Android ecosystem.

Then I broke the screen, and got an HTC M9. I gained a bigger screen that I didn't want, an IR blaster that I never used, faster CPU, more memory, more flash... for a device that I didn't do much with. Worse, I lost the replaceable battery - I actually had multiple batteries before that.

Then I broke the screen on _that_, and got an HTC 10. I again gained a bigger screen that I didn't want, I lost the IR blaster that I never used, and again got a faster CPU, more memory, and more flash for a device that I didn't do much with.

Then the battery went flat, and I got an Asus Zenfone 8, which gained me basically nothing over the HTC 10 except 128GB of storage that I don't use. In this trade, I lost having a good camera in my pocket - the Zenfone 8's camera is atrocious, and even my HTC Sensation took better photos than it does. It has a headphone jack, but it's died and I haven't fixed it... which is a shame, because I have an 80s car with the cassette deck adapter, so effectively that feature's as good as gone as well.

My next phone will probably be a headphone jack-less, swappable battery-less, SD-card-less, possibly even SIM-card-less monster of a 6-inch-plus phone. At least I'll hopefully end up with a better camera in that trade.

I'm thankful for folks who write articles like this. Even if the goal wasn't reached (getting the AlphaStation to boot), having something to show for a negative result still helps if someone else needs to go down a similar road - or, for that matter, needs to know not to go down a particular road.

I likewise wrote a COVID-boredom-induced blog post about my many missteps, and eventual failure, getting AIX to run on an old PC. My "learnings" there were that the installation media (floppies) are _written to_ by the installer, making a reset to a known state rather difficult, and also that support for IDE disks was only made available in a patch.

I have a coworker who _excels_ at writing code - one of those engineers who can metabolize caffeine directly into code.

They write code to implement the all-important features. They write code to work around lack of process. They write code to work around problem people not doing their jobs well. They write code to work around buggy code by other developers. They write code to work around their own code, written weeks or months earlier.

I've been encouraging them to _reduce_ the amount of code they write, and instead consider the context around why they're writing the code. Code is just one way - and not always a particularly good way - that we can solve people and process problems.

We had a similar setup at my university - printing to a lab printer was disallowed from a machine that wasn't physically in the lab. The printers had routeable IPs, so I'm guessing they did some kind of whitelisting at the printer itself.

The problem was, we were a Sun campus, and my tablet PC ran Linux. So I could SSH in, open up StarOffice, and hit Print on a document - all from the tablet PC in the crook of my elbow - then walk into the lab and pick the documents up out of the tray.

I never got in "trouble" for this, per se, but I did have a lab technician once look at me as if to say, "that's not allowed..."

I agree this seems overly principled to me.

I recall a DSP class where there was an exam with a question like (not exactly this):

> What does the following code print?

> `printf("Hello, world!");`

If you responded with:

> Hello, world!

...which - of course - the whole class did, you got the question wrong.

If you responded with:

> "Hello, world!"

...which is actually not what that would print, you got the question right.

A small band of us went to the professor and noted that, in fact, `printf("Hello, world!")` does not print the quotes. But he wanted us to show that it printed a string, and we denote strings by quotes.

This was something that we learned to do just for him - all strings had to be enclosed by quotes, to denote that they were strings. As far as I'm concerned, it served no practical purpose; we never had to differentiate strings like "Hello" from ['H', 'e', 'l', 'l', 'o', 0] or other representations.

A better example of how this could go - and not one that had anywhere near the same stakes - was a question on the entrance exam for my college radio station:

> What is the airspeed velocity of an unladen swallow?

I got this question right by answering, "Ni!"

(edit: formatting)

If after eight weeks a junior engineer is still toiling on their story, I'd ask why someone more senior didn't get involved.

There are lots of reasons - maybe the senior engineers are overburdened with other work (or don't care), maybe the project manager or team lead wasn't asking if the junior needed help, or maybe the junior was lying about their progress.

Either way, a story that goes for eight weeks feels excessive. Much, to your point, taking eight weeks to figure out that there was a bad part feels excessive. My counterpoint is that teams don't typically operate like labs. In a college lab, the objective is for you, specifically, to succeed. In an engineering team, the objective is for the entire team to succeed. That means the more senior engineers are expected to help the more junior engineers. They might directly coach, or they might write better documentation. I don't believe that dynamic is present in a lab setting.

Just out of curiosity, were you up-front after the fact that this was part of the exercise?

We had a first-semester freshman year course that all incoming students were required to take. The first assignment in that class was an essay, pretty typical stuff, I don't even remember what about.

A day after handing it in, roughly half of the class would be given a formal academic citation for plagiarism. That half of the class hadn't cited their sources. "This one time only", the citation could be removed if the students re-submitted an essay with a bibliography.

While it was obvious, in hindsight, that the point of the exercise was to get you to understand that the university took plagiarism seriously, especially with the "this one time only" string attached, it felt dishonest in that nobody ever came out and said so. I luckily wasn't on the receiving end of one of those citations, but I can only imagine the panic of a typical first-semester freshman being formally accused of plagiarism.

Sometimes it's not even rare that documentation is wrong. The documentation for a vendor who I won't name - but might be at Series J and worth north or $50 billion - seems to be wrong more often than it's right.

We frequently say, don't blame the tools, it's you. That pushes "blame the tools" outside of the Overton window, and when we need to blame a tool, we're looked at like we have five heads.

Ten years ago, I was dealing with a bizarre problem in RHEL where we'd stand up an EC2 instance with 4GB of memory, have 4.4GB of memory reported to the system, and be able to use 3.6GB of it. I spent _a long_ time trying to figure out what was going on. (This was around the time we started using Node.js at that company, and needed 4GB of RAM just for Jenkins to run Webpack, and we couldn't justify the expensive of 8GB nodes.)

I did a deep dive into how the BIOS advertises memory to the system, how Linux maps it, and so forth, before finally filing a bug with Red Hat. 36 hours later, they identified a commit in the upstream kernel, which they forgot to cherry-pick into the RHEL kernel.

That's a very human mistake, and not one I dreamed the humans at Red Hat - the ones far smarter than me, making far more money than me - could ever make! Yet here we were, and I'd wasted a bunch of time convinced that a support ticket was not the right way to go.

Indeed it could have. I was on a fairly prestigious scholarship; luckily, my marks were good enough that this was a low-risk decision.

That said...

I graduated with a 3.2 GPA, after being the stereotypical "gifted" student up through high school. A 3.2 is, apparently, still decent. However, I did feel a bit of a twinge seeing my peers walk at graduation with with cords, bents, and other regalia, where I just had my standard-issue black robe.

It had less to do with my grade in this particular class, and more to do with the fact that I had a part-time engineering job - 10-20 hours a week - and was making money. When you've spent a couple of years being broke, having an extra few hundred dollars per month was a big deal. Enough so that I didn't really care about putting the extra effort in for A's - that extra time was time better spent working. B's were fine if I could afford to take my girlfriend out to dinner every month.

In the years since then, it seems like this was a good decision. That job became full-time after college, and I stayed there six years. At the end of six years, nobody really cared about my college GPA. At the end of nine years (when I next looked for a job), I didn't even bother listing it on my resume.

It's a good question! I didn't think to check the markings on the chip. The lab tech was convinced I was doing something wrong with my setup, and likewise he had me convinced it must be something wrong with my setup.

Coincidentally, I've been knee-deep in some problems that I've applied the Cynefin framework to. I'd call this problem "chaotic", where throwing things at the wall might be _more_ effective than working down a suggested or tried-and-true path from an expert. I was pleasantly surprised just a few weeks ago where one of the more junior engineers on my team suggested updating a library - something I hadn't considered at all - to fix an issue we were having. (That library has no changelog; it's proprietary / closed source with no public bug tracker.) Surely enough, they were right, and the problem went away immediately - but I was convinced this was a problem with the data (it was a sporadic type error), not a library problem.

This is, more or less, exactly what happened when I took Electronics I in college.

The course was structured in such a way that you could not move on to the next lab assignment until you completed the one before it. You could complete the lab assignments at your own pace. If you failed the lab, you failed the class, regardless of your grade.

The second or third lab had us characterize the response of a transistor in a DIP-8 package, which was provided to us. If you blew it up, you got a slap on the wrist. That DIP-8 was otherwise yours for the class.

I could _never_ get anything resembling linear output out of my transistor. The lab tech was unhelpful, insisting that it must be something with how I had it wired, encouraging me to re-draw my schematic, check my wires, and so on. It could _never_ be the equipment's fault.

Eight (!) weeks into that ten week class, I found the problem: the DIP was not, in fact, just a transistor. It was a 555 timer that had somehow been mixed in with the transistors.

I went and showed the lab technician. He gave me another one. At this point, I had two weeks to complete eight weeks of lab work, which was borderline impossible. So I made an appointment to see the professor, and his suggestion to me was to drop the class and take it again. Which, of course, would've affected my graduation date.

I chose to take a horrible but passing grade in the lab, finished the class with a C- (which was unusual for me), and went on to pretend that the whole thing never happened.

While I doubt they'd find it - the SOP for issues with these modems must just be to replace them with a new one - something tells me Comcast wouldn't look kindly on physically modifying rental equipment.