High-school math has changed greatly over the last 50+ years, so I decided to find out what's new in form and teaching techniques. Many of the books I saw use calculators to plot and compare functions.  (Plots would have helped me get through college calculus with less pain.)

During the last few weeks I looked at several high-end graphing calculators from TI, HP, and Casio but decided against buying a device I'd use for a while and then forget how to use. While looking around I discovered a science/engineering graphing calculator app for $5 that runs on Android devices. I put it on my Kindle Fire and have started to learn how to use it.  No calculator could beat the price, so I thought you and your readers might like to know about it.  Here's the link: http://www.mathlab.us/calc/index.html.

Think about the system changing as it runs. Sequence matters. You're probably maintaining some code that uses global variables and interrupts. Think of what could happen if your code gets interrupted, could a global you're using be changed? If you're writing a routine that implements a state machine, think of what might happen between calls. Can something else change your state, maybe for you to a reset state? Is it safe to do that from any state?

Think about error conditions and recovery paths.

I've mentored university engineering students in embedded systems for 16 years. The observation that I share with them is that as students, you write a lot of code and are surprised when it works. As engineers, we write a lot of code and are surprised if it doesn't work. This is just another way of saying what is at the root of Michael's thoughts: we need to spend time designing, learning, and understanding every aspect of our hardware and firmware. Doing this work up front and incorporating it into the design is the essence of "a little effort at the start saves a lot of effort at the end."

1/ Start with knowing and WRITING DOWN
a) What overall the complete system has to do
b) Write down the facts you DO know including system and part response times
c) Write down the things you DON'T know
d) Write down the LIMITS (real world, system, software) you know

2/ Understand each part of the system and follow the RAR principles: Resolution, Accuracy, Response Time (of parts and system)

3/ Think hard on what relates to what and find out what is easy and what is hard
a) To appease managers, get some of the easy stuff going quickly to show some results that may change later.
b) Get to understand and TEST and DOCUMENT parts of the HARD stuff until you can combine it.
c) Measure and Document RESPONSE TIMES of EVERY PART

4/ THINK and WRITE down results. Review what you have. See what can and cannot be done

5/ NOW consider thinking about your solution(s) and how to implement them. Working downwards and WRITE down the details of each section from the BOTTOM UP.

On tips for aspiring developers, I have a bit of a different view on it now, than I did years ago, when I would have said something similar to what Michael James wrote.  I now think that it is important to stress the iterative nature of the development process.  Otherwise, aspirants think of "writing the code" as a step, that once completed, is not returned to again, or at least not very much.  By planning for iteration from the beginning they learn to attack a problem in bite-sized pieces.  It can help keep them from going days and days down the wrong path, only to find late that an early assumption is wrong.

In the style James used:

We homeschooled our kids. As an embedded developer with two sons (now in their 20s) with an interest in engineering, programming etc, I was often asked by other homeschooling parents about things they could do with their children who had an interest in programming/embedded.

The first point I always made to them is that embedded development is primarily about breaking design down, understanding design and problem solving. These are transferable skills. Younger kids can learn that playing with Lego, especially if they do problem solving in a reasonably structured way: How can you make that lighter? stronger? Why did that wall break? Why did it break here and not there?

The other critical skill is the ability to view software as a physical entity (a huge Rube Goldberg machine) rather than code on a bit of paper. If kids are working with robots then get them to actually physically do the actions the robot has to perform (eg. actually walk along, bump into something, then back up and turn around). This helps them be able to experience algorithms much deeper than just looking at it on paper or a screen.

Once a child gets to, say, mid teens and can really do some programming the first thing to do, IMHO, is to set up a github account. Apart from getting the source management skill going early, this also gives them a way to share code or discuss code (eg. with a mentor).

There are excellent courses on the www for teaching simple Python etc.

Something simple like an Arduino is a good way to cut embedded teeth, but an Arduino doesn't have long legs and might need to be replaced by something more capable.

I'd say:  Assiduously learn your target machine's architecture!  Sooner or later, high-level debugging will be inadequate and you need to single-step through machine code.  If you don't understand the disassembly, then you are well and truly up the creek without a paddle.

1. Find a company/position where there are already experienced programmers/engineers, so that you have "real-time" access to people who can help you.

2. This is controversial, but it might be beneficial for others like me: spend perhaps less time reading/studying, and more time actually writing code for a real project. Find some application and figure out to implement the code. Most can only retain so much without the added impression derived from using something. It is kind of like riding a bicycle - you can read about how to do it, the physics involved, etc., but at some point you have to get on the bike and actually ride!

3. Learn about the varieties of hardware interfaces - serial, I2C, SPI, and others, and do small projects that allow you to experiment with, and become comfortable with, them.

4. Work on deliberately adding to your capabilities. For example, I am not a fan of pointers, but I pushed myself to learn to use them as necessary for my projects.

5. Remember that online search is your friend! Don't be afraid to ask questions about things that don't seem to make sense, but make the effort to find the answer yourself before posting in a forum or user group.

• Have a wide ranging curiosity outside engineering and software: architecture, history and "why is that like it is" lead you all kinds of directions, make you more rounded, and lead to inspiration in the least expected places.

• Study more than just software, or engineering. If still in a university, try and pick wide ranging subjects including some that challenge your abilities. In a long lifetime you never know where those things will take you, but having some knowledge that's outside the norm is likely to make you more employable.

• Read widely, keep abreast of technology, techniques, systems, security and processes. (Don't ever stop trying to learn).

• Develop a good BS detector – especially for methodologies, experts (!), trends, and predictions of the future.

• Write a lot of code, outside your comfort zone.

• Ask "what if" and "why". Dig into the output of compilers to look at the generated code, and see what happens if you change the source.

• Always write code assuming that the next person to maintain it is a homicidal maniac who will come looking for  you if it is unintelligible, poorly commented, uses variables like "i" and "frob", has lousy layout, or does not use whitespace.

Think *far* more about testing than you're doing. If you cannot figure out how to test the program/system, then it's broken (Owen's second law). Since it is *acknowledged* that software development is at least 50% debugging -- more like 95% in my experience -- testing is of supreme importance.

Imagine that your hardware and firmware is driving you and your car on a highway, and gets struck by lightning or your wheels pass over a hole. Robustness is the ability to take some reasonable countermeasure and correction, and a good design should always try to foresee troubles.

I have a colleague that recalls to others how he's good at testing user interfaces, cause when he tries something new he always finds some click/push/move action that triggers an unexpected behavior. Leave your product in some unexperienced hands and begin testing real robustness -- sometimes even mechanical: had some customers who managed real world examples where supposedly "touch" controls where daily hammered with a screwdriver, as an "ordinary" way to push it.

I lost a job where I made their product get on the internet-ethernet - I was thought to have taken too much time to get it working. But part of what I did was make it automatically not crash when "script kiddies" and other general internet worms would hit some of the units that were not behind a firewall - I had also built in a lot of flexibility to handle being behind different kinds of routers, hitting different time servers, making up for crystals that aren't accurate, supporting different versions of web browsers. They not only weren't willing to pay for security - they kicked my ass out for putting it in and don't even realize now they have less remote headaches because of what they canned me for doing. For another company, I offered to put in protection against Chinese manufacturers surreptitiously running off extra product that they sell gray market against your own (another worthy column topic) - again, I got "let's not worry about that now". Your point about customers willing to put in 0 months for security is well taken. I think part of it is related to my quote "many customers don't understand the full journey from "demonstration grade" to "shipping high volume with out being swamped with embarrassing service calls". - I see a huge distance from "proof of concept" to ready for prime time.

I can confirm that among our customers (mainly deeply embedded devices) at first there is no budget for security. However, in combination with bootloaders and updates security suddenly gets more attention. Majority of our customers want to be able to update the firmware in their deeply embedded products, just in case something goes really wrong with their firmware. And now, security becomes an issue - as the FW contains IP, it needs to be secured. And once a mechanism is in place for security, the additional effort to have the application use security features is less, at it already is part of the system. But this is a very slow process...

What you have described is ubiquitous where costs are hidden, deferred or un-accountable.  In this there is no difference between security, underfunded pension costs, productivity in "open" offices, deferred maintenance, unethical behavior…it doesn't matter.

In his recently published book about decision making, "Pre-Suasion," Robert Cialdini is perplexed by unethical executive behavior of the kind recently exposed at Wells Fargo and Volkswagen.  Cialdini's only explanation, speculative and at least partially supported by research, is that executives can't conceive of getting caught.

My 2 cents, that's true but it is slightly more accurate to think of it in terms of never being held accountable.  "Getting caught" implies a moral issue, but "not being held accountable" covers both moral failures and incompetence.

As much as cynicism is justified, it's also my experience that a huge number of people make the right decisions day in and day out, sometimes in secret.  As a consultant, I've worked in over 300 industrial plants on 4 continents and have perhaps thousands of war stories.  Sometimes it's a battle, but engineers, plant managers, floor supervisors, hourly people, even executives regularly do the right thing but it is simply unheralded and you'll never read about it because the consequences of doing the right thing are only apparent in contrast.  The headline is "Engineers fired at Volkswagen" not "Engineers at Mercedes Benz, Honda, Ford and Hyundai didn't cheat."  It is also true that I've seen people fired, or who have resigned, because they insisted on doing the right thing or refused to do the wrong.