In this context, YAGNI is a very good principle, because incidentally, working too much ahead to avoid technical debt can actually cause technical debt.

The writer made the whole essay because saying “just ask your engineers what they need to improve” wouldn’t make him money.

I wonder if the writer ever worked as an engineer.

Tech debt is a term directed at managers to convince them to not always go for the quickest and dirtiest hack.

It’s not a term that’s ever meant to describe anything to an engineer.

Technical debt is a management term.

The reason we use it is to tell non-technical management people why implementing a simple feature might take an hour on a fresh project and a week on an old legacy project.

It’s used to tell them why we shouldn’t go with the quickest and dirtiest solution but instead should go with a more expensive proper solution.

It also tells management why we might have to spend some time imrpoving our code base without any tangible improvements to the customer.

And because it’s a term that speaks to non-technical management it uses financial language, becausee that’s what they understand. Technical debt means “I am choosing to cut corners today, but we will have to pay up in the future by fixing stuff that wouldn’t be broken if we do it right today.”

And because it’s aimed towards non-technical management and not towards developers, it’s of course not very specific. Non-technical management doesn’t need to understand about dependency hell, unclean code or bad developer documentation. That’s not their field and it doesn’t have to be.

The real problem in OOPs example wasn’t that there’s no clear metric or definition of technical debt. The problem was that non-technical managemnt thought that technical debt is an engineering concept instead of a management one, and thought that they themselves were allowed to meddle with it.

The right way to handle that is to ask the people who are actually impacted by technical debt what they want to improve. Any developer can quickly give you a good list of the most pressing tech debt issues in their code base. No need to pull in someone from outside of the project to make up some useless KPIs that will end up missing critical topics.

Btw, engineers already have engineering terms for what’s described as technical debt. E.g. “dependency hell”, “low test coverage”, “outdated dependency”, “bad code style”, “unoptimized code” and so on. And since these are engineering terms, they actually have specific meanings and most of them are testable and quantifiable in some specific way.

I guess if you want an automatic alarm, that could be useful.

That is the title from the news article. It might not be how good journalism would work, but copying the title of the source is pretty standard in most news aggregator communities.

Smartphone detection cameras are relatively recent and I pointed them out because they are the best solution that exists so far.

But laws against using your phone while driving, we had them already decades ago, and we had other solutions before the cameras. E.g. placing police next to the highway and letting them pull everyone out who uses their phone. We had that too decades ago. And that too works.

But it’s not only that. There are posts all the time about Americans being surprised that speed cameras exist, that red light cameras cameras exist, that speed limits are things that can actually be enforced and so on.

Today there was even a post about some road being restructured with sidewalks, pedestrian crossings and shrubbery, and that was seen as something revolutionary by all the americans in the thread, and not something that the rest of the world has been doing since the 50s and that’s already way outdated compared to what’s happening now.

The US is a total backwater country where everything that benefits regular people happens 50 years later.

It’s only an unsolvable problem if you haven’t ever been to any other place than the US. Like so, so many things. I don’t get why you guys keep thinking you have to reinvent the wheel, when the rest of the world has solved the same issues decades ago.

You know speed cameras? Modern ones can detect a phone in a hand. And they only store images of that when they detected law-breaking behavior, so they are fine in terms of privacy.

I mean, it’s better than nothing, but it’s not exactly a great conversion.

Both setups waste space like crazy that could be used much better.

• They are using a roundabout as a slow-down area. That’s ok, though not exactly great. The road leading up to it is still straight and uninterrupted, which means crossing pedestrians still have to deal with speeding cars.
• There is a pedestrian crossing with an island, which is an improvement.
• They added a road-center green space. These things are a total waste of space. They can’t be used for anything. They look nice when driving by, but other than that, they do nothing. If they had moved it to the side of the road, it would at least increase the space between pedestrians and cars, but this way, it does nothing but increase speeding, because it separates cars from the oncoming traffic visually.
• They added bike stands, but no bike paths even though there’s more than enough space to do so.
• They added two lights. Well… Better than nothing I guess.
• Continuing with the motif of wasted space: That roundabout center island is a huge one.

Looks like a redesign by a rookie designer who has never been to a place that actually does it right. It looks like something that was built in the 60s in Europe.

Btw, most browsers allow you to disable video auto-play in the settings.

As lower/middle management, you are crushed from both sides. Upper management demands from you what to do, and the people under you hate what you are forced to implement. It’s actually really annoying and difficult. I was department lead and went back to just developing.

The brand name also includes “Berne,” which is the historical English spelling for the city of Bern.

The brand name also includes “Bern”, which is the historical German spelling for the city of Bern.

So you built your own location tracking service for privacy, and then you post your tracking online? ;)

Seriously though, well done, quite impressive!

On the one hand, tree shaking is often not used, even in large corporate projects.

On the other hand, tree shaking is much less effective than what a good compiler does. Tree shaking only works on a per-module basis, while compilers can optimize down to a code-line basis. Unused functions are not included, and not even variables that can be optimized out are included.

But the biggest issue (and one that tree shaking can also not really help against) is that due to the weak standard library of JS a ton of very simple things are implemented in lots of different ways. It’s not uncommon for a decently sized project (including all of the dependencies) to contain a dozen or so implementations of a padding function or some other small helper functions.

And since all of them are used somewhere in the dependency tree, none of them can be optimized out.

That’s not really a problem of the runtime or the language itself, but since the language and its environment are quite tightly coupled, it is a big problem when developing on JS.

Add to the list: doing native development most often means doing it twice. Native apps are better in pretty much every metric, but rarely are they so much better that management decides it’s worth doing the same work multiple times.

If you do native, you usually need a web version, Android, iOS, and if you are lucky you can develop Windows/Linux/Mac only once and only have to take the variation between them into account.

Do the same in Electon and a single reactive web version works for everything. It’s hard to justify multiple app development teams if a single one suffices too.