Is anyone else concerned that they might making the same decision they did with Discovery and making the series into “Star Trek: Caleb Mir”? At this point, everyone else already feel like background singers to me.

I’ll have a look once I’ve had a little sleep! I generally like GIS projects and am pretty solid on the Python front so maybe I can be useful.

That’s both rude and inaccurate:

“Only release every two weeks.”

No. Nowhere did I say that. In fact, the team I wrote this about worked on a 1 week sprint. And as I said, I generally prefer kanban these days, but note the date on the post: this was essentially before continuous deployment was in common use, so sprints were very common and deploys were often a manual process that had to be greenlit by management. Many companies still do something similar. It is far from “insane”.

“This includes bugfixes”

This is true. It’s is primarily because deviating from the commitment you made with the company to have x jobs done by the end of the sprint necessarily means being unable to meet that commitment. If the bug is catastrophic, you obviously have to fix it right away (this isn’t religion, use your brain), but doing so busts the sprint and that has a real cost so yes, bug fixes should be delayed when possible. What I said was to show discipline in keeping “can you just fix this?” out of the sprint because it can introduce unexpected behaviour (new bugs!) and undermine your relationship with the client and sow frustration and discontent with the team as they’re driven to context switch.

It’s much easier to say:

“We found this bug on Thursday, and a fix in the works to have it patched for the next sprint due out next week”

…than it is to say:

“We failed to have bugfix/feature/whatever done by the end of the sprint as promised because our developers were taken off-task, catering to the latest freak out session by the COO”.

“Emergencies can be dealt with immediately, but any root cause analysis or deeper work on underlying issues must wait for the next sprint.”

Absolutely. Are we here to get work done, or throw everything out the window to sit around and talk through a 6-person meeting whenever something goes wrong? You can, for example schedule a post-mortem for the next sprint when something breaks, but (a) more often than not, this can be handled in retro, and (b) if you need something bigger, then there’s no way you know everything right away anyway.

“If it can’t be done in 4 hours, it can’t be done at all.”

That’s a gross misrepresentation. What I said was that a job must be limited to roughly 4 hours of work. If that job is going to be more, then you should break it up to allow the work to be spread around.

“Don’t document things.”

I didn’t say that. What I said was that much of the time, people waste time/energy on writing documentation that is shortly out of date. What I didn’t say however is that I meant “commenting your code” here rather than “documentation”. I will die on the hill that most code comments are a waste at best, and a dangerous lie at worst, while obviously user documentation is very different and obviously important. It should however be listed as a ticketed job and therefore added to the sprint.

“Don’t write bad code. (Also: You must use classes and methods, and variable names must be words.)”

Yeah I stand by this.

“Rigid adherence to the “agile process” is required”

Yes. That’s the whole point. You be as rigid as possible (within reason, again, use your brain). Rigidity provides structure and manages expectations on both sides. Being flexible leads to a mess. I know this because I’ve been doing this for 27 years and it has been my experience everywhere.

“The job of a software developer is to crank out code and nothing else, especially not design, testing, or documentation”

It should not be a surprise that one would expect software developers to develop software. If you want design, you hire a designer. Testing is part of the process though, and I never said otherwise. Don’t be shitty. I’ve noted documentation above.

“Don’t even think about ethics.”

FUCK THIS. Don’t you dare suggest to me that I wouldn’t demand ethics of everyone I work with. You know nothing about me, or my career, or what I’ve sacrificed to stay on the right side of the moral line. Engineers have a responsibility to do right by the world they live in, and nothing I’ve mentioned in that post would suggest otherwise. This was a post about building an efficient team capable of building great things quickly and well, while keeping the client happy with the progress. Of course you should refuse to do evil on the job. That should go without saying. Your decision to pretend that I care nothing about ethics says more about you than it does me.

Very cool. It’s a pity there’s no option to highlight transit over roads or something though.

As someone who worked in an actually agile team years before the project managers co-opted the idea and contorted it into “Scrum” I feel this comic in my bones.

It is absolutely maddening how these people have perverted a system that worked so beautifully into the concentration-breaking wasteland we have now just to make themselves feel relevant.

While I’m presently a fan of Kanban, my happy agile experience was under sprints. If anyone is curious what that looked like, I’ve written about it here.

That can come with its own problem that’s worth looking into. I’ve got 2 USB3 SSDs attached to mine, and the minute I add another one, I get complaints in the logs about insufficient voltage… even with a powered USB hub.

It seems that there’s a limitation in there somewhere, though I’m not clear on what it is. To be safe, I’d make sure that each drive is independently powered rather than relying on getting enough juice from the device or hub.

The Pi should be able to handle torrenting no problem, but, note that you’ll want to use a separate hard drive as the Pi uses an SD card as its primary disk and those things aren’t known for dependability under the load of constant IO from the torrents.

You can also do this with New Pipe.

Multiple disks with many moving parts, containing 80TB of data on magnetic platters flying at high altitude where they’ll be subjected to far more physical impacts, radiation, and cosmic rays than at sea level.

Yeah, it’s a risk.

Here’s a really amazing Radiolab episode about bit flips!

They’re all on the high seas and they’re all excellent.

“Oh hi! Here’s some code. I didn’t write it and don’t understand it, but you should totally run it on your machine.”

Does this mean we can finally ditch all those memory-hungry Electron apps?

I love it, and have some feedback of you’re interested:

• As your puzzle grows, the area onto which you drag your shapes shrinks. This means that there’s comes a point where your finger is obstructing the shape and target completely. There were many frustrating moments where I got the placement wrong because I couldn’t see what I was doing.
  • Suggestion: an zoom feature when placing a tile when things are at a given scale, or maybe allowing the puzzle to expand off screen and slide around?
• When the above happened, I was surprised that there’s wasn’t an undo button.
• Some music and sound effects would be nice. Something chill, like this would be nice.
• A confirmation when hitting the “back” button would be good when doing so would exit the game as well. I lost a rather impressive build out 'cause my finger slipped and it exited the game, wiping everything.

Am I the only one who thinks this might be a Caretaker reference?

The bit of information you’re missing is that du aggregates the size of all subfolders, so when you say du /, you’re saying: “how much stuff is in / and everything under it?”

If you’re sticking with du, then you’ll need to traverse your folders, working downward until you find the culprit folder:

$ du /*
(Note which folder looks the biggest)
$ du /home/*
(If /home looks the biggest)

… and so on.

The trouble with this method however is that * won’t include folders with a . in front, which is often the culprit: .cache, .local/share, etc. For that, you can do:

$ du /home/.*

Which should do the job I think.

If you’ve got a GUI though, things get a lot easier 'cause you have access to GNOME Disk Usage Analyzer which will draw you a fancy tree graph of your filesystem state all the way down to the smallest folder. It’s pretty handy.

Plus the FF extension is really full-featured. I can clip in different formats or even take a screenshot if the webpage makes clipping hard.

I didn’t even know there was a Firefox extension! I might give it a look.

I’m afraid I have no idea what an RCS is, but maybe that’s a network/region specific thing? I’m in the UK using GiffGaff (O₂) and the phone, SMS, and data works exactly as well as everyone else’s… which is to say perfectly in most places and sporadically on the train due to the dead zones on the route.

I’m using a Fairphone 4, which is 4 years old at this point (October 2021) and I’m still quite happy with it, but I owned the Fairphone 1 and 2 as well.

In terms of software atrophy, they do offer support for your device for 5 years, which is better than most, and because of its open nature, it’s generally well supported by alternatives like Lineage or Calyx, but yeah, I’m still on Android 13. While I still get regular security patches and haven’t really had a need for an upgrade, there’s no denying that the FP4 is behind.

Of course, it’s also easily repairable, supports an SD card and replaceable battery, so that’s a tradeoff I’m happy with.

I’d rather see a stable OS and ecosystem for good, Free apps that we can flash onto existing devices. I’m quite happy with my Fairphone (repairable! modular! ethical!) and we know that building and marketing a device is painfully expensive.

Let’s make Debian or Arch just work on most phones instead of trying to compete in a saturated market.

I was a Windows user as a kid in the 80s & 90s doing pirate installs of 3.11 and later 95 for friends and family. I got into “computers” early and was pretty dedicated to the “Windows is the best!” camp from a young age. I had a friend who was a dedicated Mac user though, and she was bringing me around. The idea of a more-stable, virus-free desktop experience was pretty compelling.

That all changed when I went to school and had access to a proper “Mac lab” though. Those motherfuckers crashed multiple times an hour, and took the whole OS with them when they did it. What really got to me though was the little “DAAAAAAAAAAA!” noise it would make when you had to hard reboot it. It was as if it was celebrating its inadequacy and expected you to participate… every time it fucked you over and erased your work.

So yeah, Macs were out.

I hadn’t even heard of Linux in 2000 when I first discovered the GPL, which (for some reason) I conflated with GNOME. I guess I thought that GNOME was a new OS based on what I could only describe as communist licensing. I loved the idea, but was intimidated by the “ix” in the name. “Ix” meant “Unix” to me, and Unix was using Pine to check email, so not a real computer as far as I was concerned.

It wasn’t until 2000 that I joined a video game company called “Moshpit Entertainment” that I tried it. You see, the CEO, CTO, and majority of tech people at Moshpit were huge Linux nerds and they indoctrinated me into their cult. I started with SuSe (their favourite), then RedHat, then used Gentoo for 10 years before switching to Arch for another 10+.

TL;DR: Anticapitalism and FOSS cultists lead me into the light.