- Instead of saying that a person may not install unsafe wall sockets, we can say that companies are not allowed to sell unsafe wall sockets. - Instead of saying that a person may not take any job they like, we can say that companies must provide workplace safety. - Instead of saying that people are not allowed to smoke or use social media, we can say that companies are not allowed to sell addictive products.

So it is a question of perspective where both viewpoints are valid.

And of course addictive is a scale from nicotine to deep fried chicken to infinite scroll. And then it is a question about the customer's ability to see through and make rational choices which of course depend on age, knowledge, existing alternatives etc. It is not that easy for a teenager to resist the works of thousands of engineers and data statisticians who are working on increasing retention.

So just saying that it should be allowed because of Free Will is to ignore all the complexities around it.

Not always though. Let’s say that someone is saying ”1 2 3 4 6 7 8” then it will happily write 5 in the middle and give it good confidence as based on the context, it is the only likely word. Varies between TTS providers though.

Basically, why they are so good in average is that they estimate what is said most often based on the context. The context being then not only the audio but what was transcribed previously.

And if you don’t want it to be based on what is most likely to be said in context and only based on the audio around 1 word it is going to be awfully wrong most of the time.

Incremental development is like panting a picture line by line like a printer where you add new pieces to the final result without affecting old pieces.

Iterative is where you do the big brush strokes first and then add more and more detail dependent on what to learn from each previous brush strokes. You can also stop at any time when you think that the final result is good enough.

If you are making a new type of system and don’t know what issues will come up and what customers will value (highly complex environment) iterative is the thing to do.

But if you have a very predictable environment and you are implementing a standard or a very well specified system (van be highly complicated yet not very complex), you might as will do incremental development.

Roughly speaking though as there is of course no perfect specification which is not the final implementation so there are always learnings so there is always some iterative parts of it.

BUT one of my kids has Asperger’s and it is extremely hard for him to muster up the energy to do something ”boring”. So gamified learning on an iPad works very well for him. Also doing math on an iPad where, instead of seeing full pages of equations to solve, he sees only one equation makes it much easier for him to get started.

With these kids you learn to not focus on parenting/teaching principles and instead focus on the goals. I’ll do whatever to get him to go to school and learn, no matter if I’ll have to drive him the 700 m to school while he is watching YouTube or having him to math on an iPad.

So as long as the push for more analogue tools is just a direction and not without individual exceptions I’m all for it.

Sadly today’s Swedish government seems more focused on being seen as hard on kids, crime, immigrants etc (basically everything except environmental protections) than actually following scientific principles.

I’ve always had difficulty remembering vocabulary. I remember cramming German in School 30 years back. We had 20 words we had to learn per week and I could sit a whole night repeating and repeating them just because they wouldn’t stick. And then in the morning they were all gone anyway. So I gather I am a bad language learner.

In your algorithm, do you assume everyone’s recall is the same or do you optimize for a recall rate which make everyone fail a certain percentage of the word? If so, knowing that I am supposed to not remember 70% would be a good reminder in the app to not feel bad.

Is it abusive because it is tied to hardware?

No, I see it as the opposite. I see it as Volkswagen simplifying production by limiting variability and giving you the option to get a less capable product at at a cheaper price.

A 6 and a 8 core processor is probably the same die also and produced at the same cost. Maybe 2 cord were turned off because they were faulty or maybe they were turned off because some people don’t have the need and money for 8 cores. Does it matter? Now they can still buy a computer. Is that a bad thing?

Also, the 3rd party library we were calling to do the reconstruction had a limit in the number of threads reading in parallell when preloading projection image data (optimized for what was reasonable on local storage) so that favored azcopy.

Don’t remember that NFS ever came out ahead.

So, benchmark, benchmark, benchmark and see what possibilities you have in adapting the preloading behavior before choosing.

But when you are in the complex domain (as in there are no known good practices), what you want is many different viewpoints on the team. So getting people with different backgrounds (different academic background, tinkerers, different cultures, different work experience etc) together is the way to go.

Same with the discussion about remote work. People do not seem to get that they’re no best way but it depends on the type of work. If it’s simple or complicated, let people stay at home to concentrate. If it is complex, give them the opportunity, and the knowledge it’s good, meet up by a whiteboard. And what’s best may of course differ from day to day.

Basically before they had a lot of error handling code and it was a significant part of the code base (don’t remember but let’s say 50%) and this error handling code had the worst quality because it is very hard to inject faults everywhere. So basically the error handling code had a lot of bugs in it which made the system fail to recover properly.

But DbC was a godsend in the way that now you didn’t try to handle errors inside the program any longer. Now the only thing that mattered was that a service should be able to handle clients and other services failing. And failure in a few well defined interfaces is much easier to handle. So the quality became much better.

What about the crashes then? Well, by actually crashing and getting really good failure point detection it was much easier to find bugs and remove them. So the failures grew less and less. Also, at that time I believe there were 70 ms between voice packages so as long as the service could recover within that timeframe, no cell phone users would suffer.

Plus of course much less error prone error handling code to write.

And as someone else said, DbC should never be turned of in production. Of course, in embedded systems, speed is not so important as long as it is fast enough to not miss any deadlines. And you need to code it so it doesn’t miss deadlines during integration and verification with DbC so there is no reason to turn them off in production.

Some things have not aged well in them though. Thinking specifically around the gender roles. Not matching Sweden of today. Basically all men are working and having a good time and the women are taking care of children and their husbands. But I sometimes make a lesson of that and tell them that it used to be more like that and ask them whom of my wife and I do different chores and takes care of them. Then we can laugh about it a bit together instead of me grinding my teeth. “Mom’s work is never done”.

So, how complex is software production? I’d say that there are seldom best practises but often good practices (in example DDD, clean code and the testing pyramid) on the technical side. And then a lot of exploration on the business side (iterative development).

So is a certificate of value? Maybe if you do Wordpress templates but not when you push the boundary of LLMs. And there’s a gray zone in between.

As others say, many companies in the embedded space have had a very hard time realizing they are software companies and their practices are very old school and frustrating.

Talking salaries (Sweden), yeah it’s a bit higher in the cloud but not wildly so.

My recommendation is to start working in a not tiny company and on an existing product. Then it’s more about adding logic rather than knowing everything about RTOS and bootloaders. Them you will pick these things up as you go.

And then you have parental days which are 480 in total per child which can be used both before they start preschool and for longer vacations when they are older. In Sweden it’s also quite common that both parents split it 50-50.

So 4-5 weeks of time off in the summer is not uncommon at all for parents and totally accepted by companies.

Also, when a user triggers new previews we scale up nodes to process that data. The problem there though is the scale up time of the node pool which is a few minutes for a GPU node on Azure.

We payed to have a GPU running all the time before but that got too expensive.

As a side note, would I do it again I probably wouldn’t build a data pipeline on top of KEDA ScaledJobs and possibly not use Kubernetes at all.

First of all, you need to really work with finding the most important goals for you in your context. Then you figure out what the most important things you could do to achieve this goal in for example the next two years.

Then you will realize you don’t have time to add these things on top of your current workload (like in Scrum, you don’t add new tasks to a sprint without removing other tasks). And when you’ve done that, it’s time to bring forth the Eisenhower matrix.

And in the light of what is truly important, sort your tasks according to the matrix. A key here is also to really think about the Important axis as not important in general but important that You do. Then your job is to delete or delegate enough to be able to fit the new tasks that are the most valuable to achieve your goal.

Also, in the article it says to do the non urgent important tasks after the urgent ones. I think this is really bad thinking. Instead, in the matrix you can see it tells you to plan these things. That’s what you should listen to. The things that are important but not urgent needs to be planned, otherwise they will never get done as there are always too much urgent things to do.

Exactly how to do it (especially transparently for the user), I have no idea though. Maybe sending ssh login requests to two different sshd implementations and if they don’t do the same things (same system calls), they are both killed.

Or some kind of two step login process where the first login only gives access to the sandbox of the second login process.

But in general I assume the Linux attack surface is too big to do software diversity for all of it.