The Rules

General Embedded Design Tips

DISCLAIMER: For reference and a few laughs only. Stuff I have learned over the years through my own and others' painful experiences. Also a few reminders of what I probably should and should not be doing.The only difference between a useless feature and an unimplemented feature is you wasted time developing the useless feature.
Optimizing is pointless if you haven't run out of room yet.
If you run out of room just buy the next larger device for a nickel extra instead of wasting time optimizing.
If you really, really don't want to upsize a part a viable alternative to optimizing is to remove some of the useless features that nobody uses.
Working on code that utilizes over 90% of the device's full capacity takes twice as long. Working at 95% takes three or four times as long.
Make changes one at a time.
There is no such thing is a minor software change.
Have somebody else validate your changes.
Get your gatekeeper code working first and working reliably and then rarely change it, if at all.
Development tools are your friends. Be nice to them.
If your hardware suddenly stops working check all your supply voltages first. An even better idea is continually monitor them while your working.
When writing code if you think that a problem is due to the last change you made, you're probably right.
When writing code if you think that a problem is due to a broken IC, you're probably wrong. Take a five minute break and get a fresh look at the problem.
When writing code if you think that a problem is due to a compiler bug you're probably really wrong. Work on something else for the rest of the day and look at it again in the morning.
When writing code if you think that that a problem is due to somebody sneaking in and making changes to your code at night and not telling you, your going nuts. Take the afternoon off.
When you do find a compiler bug, don't bother telling the tool vendor about it unless you are using the latest version of the compiler, have compact exact source files that reproduce the problem, and can speak to the errant assembly code the compiler generated.
Build and test at least a few of the products you are working on from start to finish personally. After that, try using them for a week or two. If your able, do the same for the competitor's product.
Not all good ideas intended for 64bit 3.5GHz hex-core processors apply to 8bit 10Mhz microcontrollers, but many of them do.
Religious wars about coding styles are pointless. Picking one and being consistent is more important than situation specific and subjective arguments.
When a product is new, don't spend time on something you can buy off the shelf.
Reference designs are there to be stolen - be shameless about doing so.
Not all reference designs come from chip vendors and textbooks.
When a product is mature, find somebody else to optimize out the stuff you bought off the shelf or stole from a reference design.
Unexplained fudge factors WILL come back to haunt you sometime in the future.
A few of these rules are probably ego-fueled rubbish.
For big changes ask somebody else for an opinion on your approach before you start writing anything to avoid creating a big horrible mess.
If you think you have implemented a big horrible mess, ask somebody else for a second opinion before abandoning it. Even if you are a solitary embedded developer don't think that nobody else at your company can help you.
Even if do end up creating a big horrible mess its ok, as long as you are willing to fix it and learned something from the mistake.
Whenever you find a big horrible mess tell everybody as soon as possible.
Whenever you find a big horrible mess have Plan A through Plan F ready to fix it. Every problem has a solution so don't ever tell somebody about a problem without immediately offering the solution(s) afterwords.
Anybody can have a good idea, but your idea probably won't be tried out unless you try it yourself.
If somebody else has a good idea they are sitting on, let them know you are going to steal it, and then do so if they don't start working on it.
If you come across a good idea but don't have spare time to work on it, work on it anyway then put it on the shelf until its politically ok to tell people about it.
Good embedded software gives up once in awhile. Bad embedded software doesn't know when to.
Nobody cares that you can do in one line of code what most people do three lines of code.
Everybody cares if your coding style is inconsistent or obscure.
Getting the source files to compile for the first time probably means you have 5% or less of the project done.
Getting buy-in on the completed specification probably means you have 50% or more of the project done.
Odds are you will never get a complete spec so instead of waiting make some assumptions and start prototyping.
If you ask two competent developers to implement the same task you will get the same end result from both, but the implementation details will never be identical. This doesn't mean the developers are not equally good or bad.
Don't start writing any code until your development environment can withstand your office being firebombed.
Put your development tools under version control along with your source files and have somebody else test your recovery process before you need it.
Never write any line of code that you would be ashamed to have scrutinized by your peers.
Make sure your code gets scrutinized by your peers.
Worthy peers will understand rough code in a prototype.
Never write any line of code that you would not want to still be maintaining in 15 years.
Never write a line of code that you will not be able to demo for the marketroids.
Everything is replaceable including implementations, algorithms, processors, platforms, developers, and Bill Gates. The only difference is how painful the replacement process is.
If you have the misfortune of having to work with an "irreplaceable" person make the best of it. Odds are your not the only person they have abused and it will catch up with them in a reasonable company. Leave the the attitude readjustments to management.
If you sometimes make backup copies outside your main version control software you are probably wasting time. If you don't trust your tools find new ones or educate yourself until you do trust them.
Microsoft products are not designed to be useful to you, they are designed to addict you.
GNU products are not designed to be useful to you, they are design to be useful to whoever wrote them, which means they are pretty much always useful to you as well.
The old adage of "time, cost, or performance: pick two" still applies.
Be able to estimate anything instantly.
Always qualify your estimates.
When you start your career you will probably overestimate how much work you can do and underestimate how much work needs to be done. Don't keep the delta a secret and know you can usually power work your way out of that situation.
Eventually you will need to learn to keep your engineering ego in check and not overestimate. Keep up the power work pace anyway because really good engineers over deliver.
You will make mistakes, just make sure the mistakes you make don't kill people or bankrupt the company.
9 out of 10 times people blame your code for a problem they will be wrong.
Always take somebody seriously when they blame your code because 1 out 10 times they will be right.
Just because you designed something that does not mean that you will always be the leading expert on it.
Never say "I told you so" after determining that a problem is not due to your code because sometimes it really will be and you will never hear the end of it.
Regardless of how technical your job is, if you can't explain what you are working on to the average person in less than 30 seconds you don't know what your doing.
If a co-worker is genuinely interested in what you're working on, take the time to explain what your doing to them until they get bored and walk away, regardless if its the CEO or the janitor.
Rather than telling a coworker to RTFM (read the fine manual) if they have a question, spend some time explaining it. Odds are you will answer five questions they would have come back to ask you over the next week.
If a salesman had a 99% success rate on quotes he would end up owning the company. A piece of software where only 99% of the code is bug free is probably unusable or at the very least hated by the people who have to use it.
Remember your audience when designing your user interface.
For user interfaces more automation isn't always better, there is a reason people still buy stick shifts.
User interface buttons should be labeled with what they actually do. Don't make them all the same for consistency sake alone.
For interfaces you will use yourself make it the way you want it. Being original or creative is an ok means to that end.
For interfaces other people want just steal it. Microsoft probably spends more on usability studies in one week than any company you work for ever will in 20 years. Don't kid yourself into thinking you know better. You will just end up annoying people by trying to reinvent the wheel that they are happy with.
It is possible for one person who is really into what they are doing to outperform a department full of people doing the same thing who are only there for the paycheck.
When designing anything make sure that no expensive part is being limited by a cheap part. For example a cars top speed should not be limited because the pedal physically can't be pushed down any farther but because the engine will start on fire if it runs any faster.
If an engineer says "any job worth doing is worth doing well" know that is a red flag. If you accept that statement from an engineer with no scrutiny you are likely to become their janitor/blame dumpster.
If the hardware people have a problem and you as a software person can reasonably/easily/cheaply fix it always offer to do so. Vice versa of you're a hardware person.
Regardless if you are a high level hardware person or high level software person or high level whatever person know that there will be occasions where the most efficient use of your time will be to pick up a screw driver, soldering iron, or a broom and do the low level work.
Make sure people understand that a software change does not always equate to a problem with the software.
The first solution that works probably isn't the right solution but may be a good enough solution.
Don't be so busy digging a ditch with a shovel that you don't have time to talk to the guy with the backhoe.
Your RX and TX UART signals between the two major chips on your brand new control board are flipped. Check them again before you finalize the layout.
A prototype is worth a hundred power point slides.
A working prototype is worth a thousand power point slides.
If you are in a market where prototypes are not feasible you will probably be happier overall if you find a new career.
If you become a coding phenom and lots of people tell you are a coding phenom and your code is held up as a god like, universal example of design beauty and perfection remember that celebrity only applies to your design skill. People will let you get get away with more but in other arenas like social interaction, business development, product line development, personal hygiene, etc... your true standing is probably still that of brain-damaged software developer.