Also, EVs have been around for quite a few years now so it is no longer necessary to buy them new.
https://www.acea.auto/publication/report-vehicles-on-europea...
662 karma · joined March 11, 2010
I've created a Ruby and a C++11 video course for pluralsight.com.
I'm also a founder at Aotea Studios (http://aoteastudios.com). We make training products for business analysts with a focus on visual communication.
I'm an experienced C++, Ruby and CoffeeScript developer.
email: alex at cpprocks dot com
Also, EVs have been around for quite a few years now so it is no longer necessary to buy them new.
https://www.acea.auto/publication/report-vehicles-on-europea...
"Those rethinks are load-bearing parts of your voice. Readers won’t put their fingers on what’s wrong, but they’ll sense that you’ve become artificially-flavored."
The metaphor at the start is AI-like weirdness too: "without pasteurizing and jacking it with corn syrup." Pasteurising is good, corn syrup is bad - what the heck am I supposed to make of it? It's nonsense.
It may even have been handwritten by the author, but it's slop nonetheless.
You may be telling yourself that you're disciplined and you're just using the LLMs for review. But while you're reading their output, the slop makes its way directly into your brain anyway - and then it drips out into your writing.
Other commenters have pointed out that his isochrone map contains a lot of nonsense as well.
So the most charitable interpretation here is that this is a case of Gell-Mann amnesia.
There are still social activities connecting people of different age groups although I agree with the above comment that structurally the society we have has been eroding non-labour market interactions.
I dislike going back to the ICE setup.
It was also important to me to provide a non-hyped, balanced view (hence the name), including pointing people to realistic assessments of the effectiveness of these tools and highlighting the risks and concerns.
What you get when it becomes easier to generate code/applications is a whole lot more code and a whole lot more noise to deal with. Sure, some of it is going to be well crafted – but a lot of it will not be.
It’s like the mobile app stores. Once these new platforms became available, everyone had a go at building an app. A small portion of them are great examples of craftsmanship – but there is an ocean of badly designed, badly implemented, trivial, and copycat apps out there as well. And once you have this type of abundance, it creates a whole new class of problems for the users but potentially also developers.
The other thing is, it really doesn’t align with the priorities of most companies. I’m extremely skeptical that any of them will suddenly go: “Right, enough of cutting corners and tech debt, we can really sort that out with AI.”
No, instead they will simply direct extra capacity towards new features, new products, and trying to get more market share. Complexity will spiral, all the cut corners and tech debt will still be there, and the end result will be that things will be even further down the hole.
That is, there is nothing inherent about it beyond the inevitable inefficiency of all large organisations, the government was shaped to be like that by external pressures.
Viewed in that light, your favourable assessment of mafia rule is even more obviously a false alternative.
Seems like a great way to help out budding monopolies.
The problem with indiscriminate application of "code has to be easy to understand" is that it can be used to make pretty much anything, including most features of your language, off limits. After all, a junior developer may not be familiar with any given feature. Thus, we can establish no reasonable lower bound on allowed complexity using such a guideline.
Conversely, what’s too simple or too difficult is very specific to the person. Somebody who’s coming to a junior developer role from a data science background might have no problem reading 200 lines of SQL. Somebody with FP background might find data transformation pipelines simple to understand but class hierarchies difficult, and so on. So the "easy to understand for anyone" guideline proves less than useful for establishing an upper bound on allowed complexity as well.
Therefore, I find that it’s more useful to talk about a lower and upper bound of what’s required and acceptable. There are things we should reasonably expect a person working on the project to know or learn (such as most language features, basic framework features, how to manipulate data, how to debug etc.) regardless of seniority. On the other hand, we don’t want to have code that’s only understood by one or two people on the team, so perhaps we say that advanced metaprogramming or category theory concepts should be applied very sparingly.
Once that competency band is established, we can work to bring everyone into the band (by providing training and support) rather than trying to stretch the band downwards to suit everyone regardless of experience.