SomeCallMeTim

No, and Jeffries' analogy suffers the same strawman fallacy.

The proper analogy would be if no one knew the rules of football/baseball and everyone ended up playing Calvinball instead, then you could say that football/baseball was broken. If following the rules of football produced a product of its own if the rules were followed, it shouldn't matter that other people can follow those rules better.

Or you can point at Monopoly and the fact that so many people destroy the game by playing the "Free Parking gets the kitty" rule and use that as an excuse that Monopoly is a terrible game. Well, Monopoly is a terrible game, even as designed, so that one works.

It's not about how well people follow the "rules" of agile. It's that most everyone who tries doesn't understand the intent of agile.

I would argue that most of the attempts at codifying agile, from Extreme Programming through whatever the latest fad is, are all also wrong. That if you codify agile at all, you're missing the point.

In my experience, the OP article is correct: You need good developers on the team. That's it. That's the secret to success. The methodology you use is nearly irrelevant, though some methodologies do more harm than good.

The fact that XP's flagship project (C3) was an abject failure should have been a clue that maybe it wasn't as good as people want to believe it is. Maybe Kent Beck wasn't "doing agile right" either?

Ha. Just did almost exactly that, but with a Go script--I wanted my Docker Compose to auto-update when I built on my CI server.

I found Watchtower, but polling just struck me as the Wrong Answer. Both too much overhead to keep pinging for the latest builds, and too slow to actually download the latest build. So I took some hints from Watchtower as to what I needed to do (mount the docker sock as a volume) and wrote a tiny Go server that, when pinged with a shared secret, would cause it to run `docker compose up -d --pull always`.

Probably took me an hour.

Then I added the ability to purge images before each update, because my tiny VM kept running out of disk space in the Docker partition. Oops. Scripts FTW.

I was already using the suggestion in the article about having a single reverse proxy server to redirect different paths (and different domains) to different servers hosted in the Compose file. Seemed like the obvious answer.

And I've configured k8s for my day job, so I could be using that. But I'm using Compose because I know how much of a pain k8s can be, especially around upgrades, where it has a habit of deprecating older versions of various interfaces. I'll put in the work for someone who's paying me to do it, but I'd rather work on my side project, not on configuring k8s.

In Colorado you get an email when they mail a ballot to you, another email when they receive your ballot, and a third when it's counted.

Colorado came out way against Trump, though, despite having been a swing state in recent memory.

It's easier to know where you're going when you've gone to similar places a hundred times.

I just think about a problem for two seconds and then have the entire path mapped out.

Nah, it was something unrelated to databases.

I can't even remember the details. It's like trying to remember nonsense sentences; they don't stick because they don't really make sense.

To the best I can remember, it was something like the use of an adapter pattern in a class that was never going to have more than one implementation? And it was buried a couple layers deep for no particularly good reason. Or something.

And yes, modern languages like the ones you list make many of the original GoF Design Patterns either absolutely trivial (reducing them to idioms rather than patterns) or completely obsolete.

I saw some code in a job I was just starting where they had added several abstractions that I found...confusing.

After taking an extra long time to understand what the code actually did, I realized that some junior engineer had been using some design pattern they didn't really understand, and that added zero actual value to the routine.

After deleting all of that code and refactoring it to use completely different abstractions, everything was suddenly much easier to read and to extend.

Design is a hard skill to learn, and junior developers profoundly haven't learned that skill yet. But that's what we need to teach them as senior engineers, right?

Not that I could teach the author of the code I changed, since I think it was written by an intern that no longer worked for the company. But you do what you can.

I am actually surprised that there are thousands of people working on Alexa.

WTF are they all doing?! It's pretty much unchanged from the outside in any way that's relevant to me compared to where it was in 2014. And the few changes I've noticed have been things breaking.

I used to, for instance, have a script (I forget the Alexa term) that would turn off a few lights and then play a Pandora radio station when I gave it a "bedtime" command. Worked great for about a year, and then the Pandora plugin suddenly refused to take any combination of commands that I could figure out to play a particular Pandora station in my account. This is true from outside of the automation as well, by the way. It's just completely broken.

The weather app integration is annoying too. I wanted weather to use a different weather source, and instead of just giving me results from that weather source, it would always preface it with "Weather from BlueSky" or whatever. Maybe it's their fault and they wanted the ad blurb? But as a consumer, it sucked. I just wanted more localized weather, not an ad every time I asked for the weather.

And the "AI" behavior of the app...it was just awful. I could get better answers from Google Home devices across the board. The best Alexa would do if I asked it a question is to read the first paragraph of a Wikipedia entry, and it was about a 1 in 4 chance it would actually choose the correct Wikipedia entry.

OH, and don't get me started on the Android Alexa app (!!!). Again, the most major change was a UI update where the most important feature I ever use was hidden behind another layer of menus for no particularly good reason. And the "Kindle Accessibility" feature of reading Kindle books is so flaky I doubt anyone on the team ever uses it, from random pauses to sudden jumps back to read from the beginning of the section of the book you started on 10 minutes ago, looping forever on those same 10 minutes.

Sorry. I know it wasn't your fault. But I finally gave up on using Echo devices, and the only reason I still even have the Alexa app on my phone any more is so I can have it read a Kindle book while I'm driving, and it's so amazingly frustrating to use that it would likely be better if it didn't even exist. It's more "customer frustration" than useful.

It's not a TypeScript mistake.

You could argue that it was a C++ mistake. It makes parsing harder, but otherwise seems to work as expected, so I don't consider it a mistake, but you could at least argue that way.

But regardless if it was a mistake in C++, it's now a complete standard, used in C++, Java, C#, and other languages to denote type parameters.

I would argue that it would have been a mistake to break that standard. What would you have used, and in what way would that have been enough better to compensate for the increased difficulty in understanding TypeScript generics for users of almost every other popular language?

As long as Node understands to use the project-specific version of TypeScript (i.e., the one in node_modules or the PNP equivalent), that should be fine.

But it would be a step backward to need to globally upgrade TypeScript (as you do with npm), since some older projects will not be compatible with newer versions of TypeScript.

Ask me how I know. ;)

Agreed with pretty much everything.

I couldn't agree with the article on almost any point.

One additional point: You can get "mildly dynamic" websites by using services. I have a completely static web site that's 100% on a CDN and that I've written zero lines of code for...but it has a full dynamic comment section due to Disqus integration. My "how many people have visited my page" is handled by Google Analytics. Other similar embedded services can provide many of the most common "mildly dynamic features".

I'm using Astro on a newer project, which allows you to static-generate pages however you like, but also allow you to run just one component as JavaScript, you can, without the inherent danger of running code on a server every time someone hits your web site. For full heavy-dynamic pages, you can render on the server as well. It's a nice compromise IMO.

That and I never want to use PHP again. Especially Drupal. I liked Drupal at first, but I never want to see it again.

No company I've worked for in the past decade has told me what kind of computer I should work on. Even the W2 gigs have allowed me my choice of Mac/Linux/Windows. I work for tech-savvy companies, though. I'm sure there are tech-naive companies that force everyone to work on Mac or whatever.

And companies that want programmers who write, say, Delphi or Visual Basic, are going to be getting crap developers, and would be better off porting their software to something more modern. I did some work on a Delphi project to help out a friend, and no, I wouldn't go to work for a company to work on Delphi full-time. They couldn't possibly pay me enough.

But that's my point: Just like they would get crap developers, I would get crap artists. Or extremely expensive artists. Not interested. It would literally be cheaper to pay Adobe the extortion they ask than to try to work with non-Adobe artists.

I'm stuck with CorelDraw X8 which dates to 2016. If they were selling a buy-it-once license in 2020, I wasn't aware of it. I swear they had switched to subscription-only by then? But maybe it happened that year and I missed the last opportunity to buy a permanent license.

Last time I looked at Essentials, it looked to me like they had hamstrung it too much. I don't remember the specific restrictions they put on it, but I didn't want what they were selling. Might be worth another look with the Humble Bundle though.