Comment I wish it was corruption - it's bad management (Score 5, Interesting) 72
You can fix corruption. I've been an embedded programmer on constrained devices for over 30 years. Mostly as a contractor fixing messed up projects. The quality of embedded projects slowly declined in the 2000s and 2010s but has fallen off a cliff over the last 5 years. It used that the quality of embedded developers was higher than enterprise developers (there was a higher minimum bar just to get your code to run). It used to be that you had to plan and organize your projects and the projects were run by engineers. You used to get support from your suppliers. In the 2010s part suppliers gave up on support and direct you to forums. When you do get documentation from suppliers you have to guess at which parts are correct and what steps they have left out. I had one formerly reputable supplier fail for 3 months to get "Hello World" to work on their dev board.
Then there is the management of projects. Now the de facto person in charge is the one in charge of the Jira tickets. They decide what tasks get resources and they decide which engineers do what tasks. They can't understand a development plan, they can't build the code, they usually can't even use the product. What they can do is take bugs from testing, create tickets and assign engineers to the tickets. Their only metric is how fast tickets are resolved. They don't care if the engineer they assign knows nothing about the project
The most successful embedded engineers today
Don't put useful comments their code (they may describe how the code works but the code says what it does)
They never document (and most projects don't even have a single place to put documents or have a way to find them)
They are good at volunteering for easy or high visible tickets
They close bugs by creating global variables that track the condition of the bug, then adding a function that is called all the time, a function that then checks the globals for the error condition, prevents (or masks) the error and then (hopefully) cleans up the globals without creating too many other bugs.
- This means they never have to understand the code. If there is automated testing they might never even need to know how to use the product.
Then there is the management of projects. Now the de facto person in charge is the one in charge of the Jira tickets. They decide what tasks get resources and they decide which engineers do what tasks. They can't understand a development plan, they can't build the code, they usually can't even use the product. What they can do is take bugs from testing, create tickets and assign engineers to the tickets. Their only metric is how fast tickets are resolved. They don't care if the engineer they assign knows nothing about the project
The most successful embedded engineers today
Don't put useful comments their code (they may describe how the code works but the code says what it does)
They never document (and most projects don't even have a single place to put documents or have a way to find them)
They are good at volunteering for easy or high visible tickets
They close bugs by creating global variables that track the condition of the bug, then adding a function that is called all the time, a function that then checks the globals for the error condition, prevents (or masks) the error and then (hopefully) cleans up the globals without creating too many other bugs.
- This means they never have to understand the code. If there is automated testing they might never even need to know how to use the product.