Interesting but many issues which have been listed here are valid. This is my take on the largest of them.
Preventive testing is not always positive.
False negatives creates a false sense of security and false positives drives unnecessary medical procedures. For example, what if this instrument sees "something" and a doctor then follows up with a biopsy, x-ray or explorative surgery. These will all have negative side effects. There has even been a debate of if mammography is a net positive. I think it might be but I'm just saying that even such a thing is debatable. The question is not only if the these early tests find anything, its also a question of whether detecting it early changes the prognosis. Maybe its untreatable anyway? Or maybe it would still be treatable if detected later? And then comes the cost of course, is it economical to do these scans on a population level relative to the alternative cost.
Building medical systems is not for the faint of heart.
I was part of a startup building a Micro CT system with the long term goal of using it to detect tumors in biopsies live during surgery (1 um resolution for cm-sized samples) without waiting a week for the normal analysis. We also started with non-medical instrument (general research) and we never got to the medical instrument before we ran out of money (we engineers were too bad at sales). But we did study up on the (European) standards quite a bit. They are not crazy in any way. Its simply that you follow good engineering practice BUT it is hard to move from building a non-medical system to medical system after the fact. The standard is a process standard so it basically says "You should have followed this process when you designed your product". And you need be real careful setting your Intended Use and showing that you have Verified and Validated that your system can be used for the intended use. So most likely they need to build one product now (Body Composition Analysis), use that for research and then set up their Quality Management System before they rebuild everything from requirements to risk analysis to test plans to hardware to software. 10 years is probably on the low side for this and quite the cost.
And if one were to compare cost of a dev vs cost of an LLM, the dev comes with the cost of workspace, computers, sick pay, summer party, conferences and etc etc.
It is easy to say that we shouldn't limit what a person is allowed to do. That a person should be allowed to use their free will. That sounds nice because nobody want to be controlled by anyone else. But let's turn it upside down and instead say that we disallow companies from doing certain things.
- 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.
I’ve looked at confidence outputs for the chosen words from several STT providers and it’s definitely so that low confidence indicate that there is a risk that it has misheard.
Not always though. Let’s say that someone is saying ”1 2 3 4 <unintelligible> 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.
I would differentiate between iterative development and incremental development.
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.
Guy here with kids in Swedish school. In general I support the direction of learning basic analogue skills and detoxing from the constant dopamine hits of the digital world.
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 just tried out your app for the first time. First time trying to learn Spanish. I feel exactly like the user you describe but it is because I have to click Don’t remember for 70-80% of the words.
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.
How about in-app purchases and subscriptions? The code is already there. Is it abusive?
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?
I did some benchmarking on BlobFuse2 vs NFS vs azcopy on Azure for a CT imaging reconstruction a year back or so. As I remember it, it was not clear if Fuse (copy on demand) or azcopy (copy all necessary data before starting the workload) was the winner. The use case and specific application access pattern really mattered A LOT:
* Reading full files favored azcopy (even if reading parts just when they were needed).
* If the application closed and opened each file multiple times it favored azcopy.
* If only a small part of many files were read, it favored fuse
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.
This!
When you are doing something simple (as in there are known best practices) you do want people to have the same formal education. They’ll talk the same language and everything will be smooth. Nobody wants a self taught surgeon or pilot on the team. There is a best practice for washing your hands and you want your surgeon to know it.
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.
I worked in the telecom business 15 years ago on 4G (LTE) and there it was considered a big savior compared to how it was done before.
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.
I loved the books as a child and as a father I love reading them for my children. And they love them too.
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”.
I think complexity frameworks (like Cynefin) describes it pretty good. When the complexity is low, there are best practices (use a specific gauge of wires in an electric installation in a house or surgeons cleaning according to a specific process before a surgery) but as the complexity goes up best practices are replaced with different good practices and good practices with the exploration of different ideas. Certificates are very good when there are best practices but the value diminishes as the complexity increases.
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.
The job for an embedded engineer can vary wildly and it gets hard to define what embedded software even is. I’ve worked on microcontrollers in elevators and battery management systems for battery packs on the low end and I’ve worked on application processors, many-core processors DSPs and soft cores in FPGAs in telecom on the high end. Sometimes you don’t even notice the hardware. All depends on the job and the size of the company (do they have a platform team abstracting all the hardware away?).
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.
Sweden here also. Quite common with 25 days and paid overtime or 30 days with unpaid overtime.
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.
We’re using KEDA and ScaledJob to scale tomographic reconstructions in the cloud. When a CT scanner has finished uploading a scan, we let a ScaledJob create a Job to process the data. A scan is maybe 8 hours and during that time we don’t need any compute resources. But when it’s done we need both lots of CPU and GPU power to process GBs and TBs of data rapidly to show previews to the user.
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.
One of my sons had a heart defect needing open heart surgery when he was 5 days old (it went fine!). In connection to that he was enrolled in a scientific study. Apparently when you are in a heart and lung machine as an infant (<1 month old) the pressure in the machine is so great compare to the normal pressure that the blood cells break creating free radicals. These free radicals can in turn create damage in the brain which can later on cause problems with executive functions and complex reasoning. Autistic people also have problems with executive functions (my other son has Asperger’s). Now I’m not saying that free radicals cause autism but maybe they modulate it when the same parts of the brain are affected by them during infancy.
I think there are a few things to note to take the Eisenhower matrix from “oh, that’s a nice model” to really gain some serious value from it.
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.
I’m highly safety critical systems you have software (and hardware) diversity were multiple pieces of software, developed independently, have to vote on the result. Maybe highly critical pieces of Linux like the login process should be designed the same way. So that two binaries without common dependencies would need to accept the login for the user to get privileges.
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.
Preventive testing is not always positive. False negatives creates a false sense of security and false positives drives unnecessary medical procedures. For example, what if this instrument sees "something" and a doctor then follows up with a biopsy, x-ray or explorative surgery. These will all have negative side effects. There has even been a debate of if mammography is a net positive. I think it might be but I'm just saying that even such a thing is debatable. The question is not only if the these early tests find anything, its also a question of whether detecting it early changes the prognosis. Maybe its untreatable anyway? Or maybe it would still be treatable if detected later? And then comes the cost of course, is it economical to do these scans on a population level relative to the alternative cost.
Building medical systems is not for the faint of heart. I was part of a startup building a Micro CT system with the long term goal of using it to detect tumors in biopsies live during surgery (1 um resolution for cm-sized samples) without waiting a week for the normal analysis. We also started with non-medical instrument (general research) and we never got to the medical instrument before we ran out of money (we engineers were too bad at sales). But we did study up on the (European) standards quite a bit. They are not crazy in any way. Its simply that you follow good engineering practice BUT it is hard to move from building a non-medical system to medical system after the fact. The standard is a process standard so it basically says "You should have followed this process when you designed your product". And you need be real careful setting your Intended Use and showing that you have Verified and Validated that your system can be used for the intended use. So most likely they need to build one product now (Body Composition Analysis), use that for research and then set up their Quality Management System before they rebuild everything from requirements to risk analysis to test plans to hardware to software. 10 years is probably on the low side for this and quite the cost.