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.

Funny that you should say that. Just met with a group of very senior engineers today and two of them said they weren't using VS Code any more. Instead they used:

1. https://www.trycursor.com/

2. https://zed.dev/

I'm still on VS Code myself. Cursor at least is just a fork of VS Code with AI features, so you can still use VS Code extensions, so it's something I might try at some point.

Zed sounds cool (it's fast; the guy who used it said it made him feel like he was programming in the 90s again, and I know exactly what he means), but I love having all the extensions (a quick search finds no Tailwind extension for Zed, for instance, and I'm really loving the Tailwind autocomplete). Might give it a try at some point, but I doubt I'll change to it.

Thing is, I was one of those people who kept jumping to new editors. Every single time it was because the current editor had a serious problem of one flavor or another--and another editor solved that problem.

VS Code is likely to be Good Enough for a long time. Zed might gain some adherents like the guy I met today, but I didn't keep trying new editors because I was "on the modern train," but because every other editor sucked in one way or another. All the vims and emacs variants suck. This shouldn't even be a debate, to be honest, but they do suck.

If VS Code keeps on its current trajectory (i.e., Microsoft doesn't abandon it), it will likely be the Good Enough editor perpetually. It's already 9 years old and it's still the "modern editor" of choice. And when I suggest people try a modern editor, I didn't even really mean VS Code but really any editor that's modern. Sublime, Atom, Visual Studio, any of the JetBrains editors...anything modern is better than vim or emacs. But some folks trained their fingers and don't want to change. Nothing you can say to them to convince them.

As another comment points out, Shakespeare is written in "modern English." It's not about chasing the "modern train" as much as not continuing to use Atom or Neovim when everyone else is using VS Code, and VS Code has become the common IDE of the work environment, is already set up to debug the app everyone is working on, and has all of the extensions everyone needs to be on the same page.

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.

Which version of node?

Latest LTS. Why wouldn't you?

Which version of npm?

The one that comes with Node? Duh. Or just `npm update -g npm` to bring it up to the latest.

...a dependency that only works on node 3.14

So I know you're making crap up now because there was no such version. Node jumped right from 0.12.x to 4.x, as a result of a fork and associated project politics. [1]

And I've been working with Node projects for nearly a decade. I don't see "only works on older-verion-of-Node x.y" almost ever. You're thinking of Python and Ruby.

`nvm` exists because, yes, sometimes you want to run an older project in its exact environment. And it's super easy to install new versions or test under different versions Just In Case there's an issue. Sometimes newer releases only work on the latest Node, so you need to upgrade Node to update to the latest-and-greatest.

But frankly it's worth using Node (and TypeScript) just to not have to ever touch PHP again. It was an is a nightmare fractal of bad design. I'm never going back.

[1] https://nodejs.org/en/about/previous-releases

Well, I think you could say I've worked in games too. [1]

In fact, it's in games that the artists, especially when working with 3d, had the hardest time getting the precise kinds of changes that I would need.

But even in 2d, if they, say, created a sprite, but then left a few pixels non-100%-transparent in the corners of the image, I could ask them to go find those pixels and erase them...or I could do it myself.

And if they don't get them completely erased, then there will still be artifacts on the screen and the texture atlas packing will be screwed up.

Yeah. I've been doing this for a long time.

And no, I don't have much hope of getting artists to migrate. I'm just tilting at windmills.

[1] https://www.mobygames.com/person/13230/tim-mensch/

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.

I don't know why you wouldn't ask the artist to make the edit.

Have you ... worked with artists? To get them to produce technically precise artwork?

The point would be that sometimes it takes 4-5 turnarounds with an artist to get something exactly right. Something that I, as a non-artist but skilled app user, can do in less time it takes to explain what I need to the artist a single time. So it's about saving my time and not having to pay for hours of artist time for something I can do in 10 minutes.

What I'd like to see is tiered licenses. They're being greedy and I refuse to patronize them. That's what it comes down to. I'm not saying they should be forced to do anything. Just that I don't like what they're doing, and therefore end up having to work around their software rather than using it.

I have a license for the last one they offered for a fixed cost; bought it for a steep discount when the new licenses were the Next Big Thing. But they won't get any more of my money until they offer the software at a reasonable price tier.

ask them for the files exported into a format you can open

They already do that. That's not the problem.

If the original Photoshop file has 200 layers, and 60 of those layers have effects that use advanced Photoshop-only features, then no other art program can open the source material. Period.

At best you can get approximations of the original Photoshop render if you open the image in another program. But generally what you get is garbage if it's not a recent version of Photoshop.

The point of getting the Photoshop original with the layers is that I might be able to make a tweak to one of the layers and have it re-render a result that is better for what I need. Something that is difficult or impossible if I just have a JPEG.

And asking the artist to do the work in a program that doesn't have all of those features is roughly equivalent to asking a software engineer to use Mac/Windows/Linux (pick one they don't know) and to write all of the code in Visual Basic/Perl/PHP/JavaScript/C/C++/COBOL (pick one they don't know). Yes, technically anything is possible in any environment, but it might take 10x as long and be 100x as painful--with a result that may not be as good due to the tools not being as good.

Artists are professionals with an acquired skill set. You can't ask them to work using unfamiliar tools and expect them to be happy or productive.

Realistically, I'm looking for artists that are good first. And 98% of them use Photoshop. Not going to restrict myself to non-Photoshop artists.

But not all of us make a living off of Photoshop.

I'm a programmer. I periodically need to make a tiny tweak in a file that's been created by a real artist, or I want to edit a photo I took, or whatever.

It's insane to spend $1500, or even $500 (the CorelDraw buy-it-outright price) for hobby and occasional-use software like that.

And yeah, I use other things like Affinity Photo, which is Good Enough for many of my purposes, but it's just annoying to not be able to use the same software as my artists--unless they flatten the image before giving it to me, it's a crap-shoot whether I can import it in anything but the exact version of PhotoShop they were using.

It feels like extortion: I have to pay the artist to make the tiniest changes because I can't edit the original file, or I have to pay Adobe an outrageous sum to do it myself. Lose-lose.

CorelDraw is great, but for years they were also subscription-only. In the last six months or so they finally started offering a single-price license again--at a prohibitive level.

I bought the previous single-price version years ago, and it's so stale that I prefer to use Inkscape, despite the more limited feature set, and I've been using the Affinity suite as a more professional replacement.

Now it looks like they let you buy it again, but at $550, I'm still giving them the finger. Their upgrade price used to be ~$200; I would pay that once ever 3-4 years or so, and consider that a reasonable expense to get a good product and have it available when I did need it. But for $550, I'd need to be planning on keeping it for something like a decade to get a similar value--and it's too much to justify buying at my limited usage level.

All of these subscription services should get over themselves and allow you to rent them for occasional usage for a reasonable amount of money. If I could give them $20 for intermittent (time-limited? operation-limited?) use, with no "auto-renewal", I might do that every time I actually needed the product.

But no, they need to be greedy and demand that you pay for a year of usage in advance (or by using deceptive practices like Adobe above).

I've used Paint Shop Pro, and I really don't like it. I can use Corel PhotoPaint and Affinity Photo, and they're fine, but PSP makes me crazy when I try to use it. I'd almost rather use Gimp.

I'm not confusing anything. I'm familiar with the Chinese Room Argument and I know how LLMs work.

What I'm saying is arguably philosophically related, in that I'm saying the LLM's model is analogous to the "response book" in the room. It doesn't matter how big the book is; if the book never changes, then no learning can happen. If no learning can happen, then understanding, a process that necessarily involves active reflection on a topic, can exist.

You simply can't say a book "understands" anything. To understand is to contemplate and mentally model a topic to the point where you can simulate it, at least at a high level. It's dynamic.

An LLM is static. It can simulate a dynamic response by having multiple stages that dig through an multiple insanely large books of instructions that cross reference each other and that involve calculations and bookmarks and such to come up with a result--but the books never change as part of the conversation.

LLMs can form new memories dynamically. Just pop some new data into the context.

No, that's an illusion.

The LLM itself is static. The recurrent connections form a soft-of temporary memory that doesn't affect the learned behavior of the network at all.

I don't get why people who don't understand what's happening keep arguing that AIs are some sci-fi interpretation of AI. They're not. At least not yet.

There's no way brains have the "right answers" fed into them as required by backpropagation.

No.

We know how current deep learning neural networks are trained.

We know definitively that this is not how brains learn.

Understanding requires learning. Dynamic learning. In order to experience something, an entity needs to be able to form new memories dynamically.

This does not happen anywhere in current tech. It's faked in some cases, but no, it doesn't really happen.

LLMs are good at tasks that don't require actual understanding of the topic.

They can come up with excellent (or excellent-looking-but-wrong) answers to any question that their training corpus covers. In a gross oversimplification, the "reasoning" they do is really just parroting a weighted average (with randomness injected) of the matching training data.

What they're doing doesn't really match any definition of "understanding." An LLM (and any current AI) doesn't "understand" anything; it's effectively no more than a really big, really complicated spreadsheet. And no matter how complicated a spreadsheet gets, it's never going to understand anything.

Not until we find the secret to actual learning. And increasingly it looks like actual learning probably relies on some of the quantum phenomena that are known to be present in the brain.

We may not even have the science yet to understand how the brain learns. But I have become convinced that we're not going to find a way for digital-logic-based computers to bridge that gap.

Your link re: Fair Dealing guidelines does NOT make it 100% legal. For one, the ENTIRE works are encoded into the model--not a part of them. For another, those are just guidelines, not explicit exceptions, just like Fair Use in the US. It's all very hand-wavy, even more so in the UK, apparently, so there's no way you can list those guidelines and say that anything is clearly allowed.

Your second link means it's legal for them to CREATE THE MODEL. This is true in the US as well: The model is a clearly transformative use of the data.

But as soon as the model produces works in the same use category as the original work (code -> model -> code, for instance, or image -> model -> image), it is no longer transformative.

If you understand the law and the technology, it's clearly generating derivative works.

If ChatGPT verbatim reproduces

Copyright covers "derivative works." Verbatim is absolutely not a requirement for infringement.

If you take a copyrighted image and modify it, even to the point where it's unrecognizable, if the image is being used in the same way (i.e., isn't a "transformative use"), then it's still a derivative work.

Yes, you are likely to get away with it if you're not caught. But that doesn't mean what you're doing is considered fair use, just that you won't get sued.

Thing is, every piece of text generated by ChatGPT is incrementally using every character of training data. So legally speaking, everything it produces is arguably a derivative work of ALL of the training data.

Generative AI isn't even a legal gray area; under current law, there's no blanket exception for "how much" of a copyrighted work is used. At best there's a fair use _guideline_ that lists, as one of four criteria, the amount and nature of the copyrighted work used. But really it's the entirety of millions of copyrighted works being used to generate the models, and those works _can_ be reproduced verbatim in many cases, proving that the works are encoded into the model.

Generative AI is only permitted because there's big money behind it along with associated lobbyists. And there are many in-flight lawsuits trying to shut down both GPT and various art-generating AIs.

Maybe they'll change the law. Maybe courts will side with the AI companies. But until then, it seems obvious to me that anyone arguing that generative AI based on models built with copyrighted works is completely legal is using motivated reasoning.

How could they prevent the framework become over bloated with semi baked plug-in?

...not sure how they plan to, but how they COULD do it is by making it easy enough to directly access native resources directly from the script language (like NativeScript) or by making it so easy to write native code (Kotlin/Swift are listed as first-class options) that you just write any specific API access code in the appropriate native language.

It doesn't give you the Electron "write once run everywhere" experience, since you need to write some of the code per-platform, but many apps are 95% UI and only 5% platform-specific functionality. So by abstracting the UI by having it be HTML/CSS/JavaScript, you're getting a "write once run everywhere UI" and the minority of the code that needs to differ is all you have to maintain per-platform.

If writing a plug-in is a high bar, then you get tons of semi-baked plug-ins as the (seemingly) only way to access native features. If instead you can drop in native code easily and quickly, then you can focus on app development and cut out the middleware. ;)

Very few people both have a ton of exposure to a language and actually study the grammar and stuff as adults.

Very few people actually learn to speak a language as a native speaker by "studying the grammar."

I remember people trying to learn what was and what wasn't a run-on sentence in junior high school, and being shocked that they had a hard time telling the difference.

And studying language explicitly doesn't change the brain regions used to the same that are used by a native speaker.

And that's my point. I didn't really "study" programming explicitly as much as understanding it intuitively. When exposed to a new concept, I just immediately internalize it; I don't need to use it a bunch of times and intentionally practice it. I just need to see it and it's obvious and becomes part of my tool-set.

People are also prone to love doing things that they're good at, so it's hard to know which came first. :)