BerislavLopac

I can't believe that this article is still alive and well on the interwebz: MacGyver vs James Bond - https://importantshock.wordpress.com/2008/08/07/git-vs-mercu...

> editor clutter has no business in any project's .gitignore, and yet there it is, in most of them

I couldn't agree more with this - except that, in practice, nobody bothers to add their own environment clutter to their own global (or even project-related) gitignore. So invariably we end up with PRs (and even main :scream:) peppered with various .vscode and similar lost souls.

In my experience, pair programming is amazing as a teaching tool. Pairing a (very) experienced dev with a much more junior one will do wonders in upscaling the technical skills of the latter and - more often than not - interpersonal skills and even humility of the former.

Technology like digital media and AI certainly have an impact, which will only increase - but things are not that black and white. All we need is to look at the history of similar technological advances we have seen in the past.

We have cars; but people still walk, ride bicycles and even horses. We have rhythm machines and synthesisers, and people still play drums and other instruments.

So we will keep writing and reading. A lot of specific details about how we are doing either will change, but the activities will still be there.

> Which means that instead of millions forced to learn and get good as part of their job, it would be a much smaller percentage of "hobbyists who love to tinker" doing it.

Plus a growing number of completely new jobs dedicated to research and exploring new directions in software. Just think about another technology that was revolutionary when it appeared: automobiles. At first, you (or your driver) pretty much had to be a mechanic, a metalworker and a "tinkerer" to maintain the car; but the majority of people just need a car to take them from one place to another. But research and development of new automotive technologies didn't stop, on the contrary.

I still can't get over the demise of Memphis [0]. :'(

[0] https://github.com/superstreamlabs/memphis

Python has Hypothesis: https://hypothesis.readthedocs.io

And this is also the reason why Mac is doing it this way. One of the big goals in development of MacOS X was to keep the experience consistent with the old Macintosh OS 9.x, even though it was based on a completely different paradigm (Unix). And the UX of Macintosh basically developed along with its paradigms, because in many ways it was the first popular OS that widely accepted the things, like windows, menus, trash and the like.

AI is going to replace artists in exact the same way rhythm machines replaced drummers.

> but no, they don't trust the LLM that much

Yet...

> I think software "engineering" is far more susceptible to fads

No - it's just revolving so much faster, in every single sense. And it's only accelerating.

"Applied poet" is my new official title.

Singapore is a special case, since it doesn't really have any rural areas.

Deleted code is debugged code.

It's interesting how most of the comments here seem to miss the most important part of the article, which is this:

> What happened in 2025 was this: the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight.

A little but further reinforced by this:

> I am just barely old enough that my first job title was “System Administrator”. [...] I lived through the shift from handcrafted server pets to immutable infrastructure cattle.

What is happening now is nothing new, we have seen it many times before: a shift in technology which is bringing changes in the ecosystem, required skills and so on. This happened with stocking frames, steam engines [1], automobiles, servers, and now the code. Just like before, many will be - and already are - harmed by this, but ultimately the world will adapt and accept the new paradigm.

[1] There's an infamous screenshot of a tweet being shared around, where someone suggests various names for writing code without AI, and someone else responds with "software engineering". Allow me to add my on contribution to this debate: codejamming.

I've been using it about 8 hours a day. That's because for every two minutes of working with it I need to wait about a minute for it to give something back.

"No longer"? When was it exactly?

The truth is that software engineering, as a profession, is not even a full hundred years old. Even if someone spent their all career with it, it has probably changed so much over time that it became a completely different job.

So far, we have barely scratched the surface.

Anyone who has ever used Mercurial knows very well what a good versioning tool UX looks like...

That's temporary. They will adapt and find ways to use it to its full potential - just like it happened with every new technological shift in history.

Python, Linux and most other great open source projects we all use today started as personal projects.

> A Python4 that actually used typing in the interpreter, had value types, had a comptime phase to allow most metaprogramming to work (like monkey patching for tests) would be great! It would be faster, cleaner, easier to reason about, and still retain the great syntax and flexibility of the language.

And what prevents someone from designing such a language?

Any program written in Python of any significant size is literally a soup of multiple languages.

> python code could be so much faster if it didn't have to assume everything could change at any time

Definitely, but then it wouldn't be Python. One of the core principles of Python's design is to be extremely dynamic, and that anything can change at any time.

There are many other, pretty good, strictly dynamically typed languages which work just as well if not better than Python, for many purposes.

> only the plot is copyrightable

But the plot can't be copyrightable, as the copyright applies only to a tangible representation of an idea (e.g. written text), and not to an idea itself.

Code is one thing, but what about writing? There is no 100% foolproof way to identify content written by LLMs, and human writing routinely gets incorrectly flagged as such. If I write a book, and a checker says that it's written by LLM, is it automatically in the public domain?

Yeah, I've been using "shit umbrella" for a long time. But the "transparent shit umbrella" is an even more powerful, albeit more disturbing, metaphor.

> What's the source of truth? Nobody knows.

Except everyone who ever used standards like OpenAPI and JSON Schema.

> it seems particularly the German-speaking countries are borderline obsessed with a) titles

There is nothing borderline about that - the German cultural space (including very much the countries of former Habsburg Empire) is still completely obsessed with titles and formal positions despite many of them losing any practical importance in modern times.

> As the article outlines: you need to acquire that knowledge. And they’re many ways to do that.

Domain-driven design is all about this.