Imagine a world not dissimilar from the one you know. Same styles, same social standards, same society. It looks, feels, and tastes exactly like the world you see when you walk out your front door, except for one small difference: the traffic laws have quadrupled. The right-of-way at a stop sign depends on the color and make of your car, not who arrived first. You must blink your turn signal four times before a turn, and seven before a U-turn. If you want to change lanes, blink twice, wait a full second, then twice more. You are only allowed to raise the volume of your stereo to 6dB above the ambient road noise, and you can only use your windshield washing spray if your view is obscured to less than 60% opacity.

Absurd, I know, but bear with me.

Because of all of these laws, you are required to get re-licensed to drive. It's a much more complicated test, and an astonishing 80% fail. One enterprising DMV employee decides that the test is simply too complicated for more than 20% of the population to understand, so he builds a simulator. The simulator operates just like your car, but it makes all those new rules easier. The turn signal blinks automatically, a voice tells you when it's your turn at a stop light, the windshield cleans itself when its dirty, and your radio volume is self-controlled.

This brings about an exciting new era in driving, suddenly hundreds of people can get their license! There are only a few additional rules you need to know, and everything else is just like before. Aunt Edna passed on her first try, and your club-hopping cousin, who has a cell phone glued to her ear, only takes seventeen attempts to pass. The DMV employee is lauded by the press for freeing the populace from the tyranny of government regulations.

Two days later, you get a call from your cousin: she's in jail and needs you to bail her out. Apparently, after twenty-seven unpaid traffic violations, the police issue a warrant. Aunt Edna was pulled over just yesterday for listening to Hanson's "MMMBop" too loud. In fact, you got a ticket this morning on the way to work because the barista forgot the cinnamon-jalapeno spread on your peach and raspberry bagel, so you made a U-turn, and blinked eight times.

Seems everyone is having these problems for some reason. Meanwhile, the 20% that passed the hard test are watching, and they're laughing.

At you.

They know the truth: as cool as the simulator is, as much as it feels like, tastes like, and smells like driving, it isn't driving. They know that its important to know how loud the road noise is, even if you don't usually turn your radio up that loud. They know that the real reason you use your blinker seven times while making a U-turn is so that the traffic cameras don't ticket you for running a red light. They know that using your windshield washer fluid before the 60% mark actually makes it worse. They know all this because they learned the real rules, the rules the real world is going to judge you by, not the simple rules the simulator uses so that you can get your license easier. It turns out, the devil is in the details, and to be a good driver, you need to know the details.

Now this is an absurd example, but you get my point: you can't play in the big leagues using minor league rules. Some rules are aggravating, some have no point, some are even completely inefficient and only got passed because a senator's son has a yellow fiat and never wants to wait at stop signs. The harsh reality, however, is that if you don't follow the rules, you'll get in trouble, and eventually, no one will ride with you.

This is what the incredible, exceptional world of hardware engineering has been reduced to.

I completely understand the draw of "computing platforms" like the Arduinio. I love the Lego Mindstorms, and they certainly have their place. But sticking two shields together and making your toilet tweet, is not the same as understanding the IP stack or chip-to-chip communication. And making a motion-detecting velociraptor is not the same as understanding sensor design or interrupt vector tables.

My ultimate point is that you don't really want to make your toilet tweet, you want to see if you can make your toilet tweet. The hobbyist community is all about self- and community-education, and if you ignore the rules, you aren't really learning anything.

I've taken quite a few programming classes, and there are two major pass/fail moments in each student's progress where you can tell fairly easily if they are going to cut the mustard. One is the concept of pointers, which tells you if they have the mental capacity for real programming, but to judge the heart of the programmer, ask them to build a stack using nothing but native types. Some will give up, "what do I need this for?" Some will complain that STL or Java already has a Stack class, "why do I need to build this when its already done?" But the true programmers will keep their head down and struggle mightily to produce working code. These students realize that the Stack isn't the point of the exercise. The point is to teach you that you can build a Stack. Granted, the chances of you using it again when someone else has one pre-built that also takes into account templating and inheritance is slim to none, but it taught you about dynamic memory allocation. And someday you're going to be able to laugh at a "programmer" who taught himself by reading Internet how-tos and is confused why adding  1000 elements to his stack takes so long. You'll laugh and tell him about the wonders of malloc, and how memory isn't flat or contiguous, and then hand him that Stack assignment you hated so much in college.

Sometimes the 80/20 rule actually works, and real-world problems are one example. Yeah, 80% of the time you'll be able to ignore most of those pesky rules, but as soon as you try to do something interesting, you'll need to know about traffic cameras and turn signal blink rates.

In closing, the Arduinio may seem like a great thing; for only a few dollars you can get an easy-to-use platform that makes rapid prototyping a breeze. But two projects later, after you've used your PS2 controller to blink LEDs, and changed the speed of a motor based on the humidity of the air, you're going to realize that there isn't a shield to do all the cool things you wanted to do when you started, and you don't know how to build a shield. And if you ask online for advice on building a touchscreen, you're going to get asked if its resistive, capacitive or inductive, and you're not going to know the answer, or why it even matters. Do yourself a favor and start at the bottom; learn why a stylus doesn't work on a capacitive screen. Its a bit more work at first, but you'll be well served by it.

In my reading, I've come across some common mistakes. Not grammatical, which I can surprisingly ignore, but stylistic mistakes that instantly pull me out of the narrative. Here is a list of the most infamous.

1. Don't write about what your story isn't about

It sounds simple, but many new authors break this rule. A common theme in fiction is to place an otherwise normal character into an extraordinary situation. This involves some kind of life change, and most authors like to set this change up as the first part of their story. If you're doing this, remember, no one is going to care about what happened before the event, your story is about after it. If you must setup, do it briefly. A much better choice is to simply drop the reader into the middle of the story. They'll figure out the details as they go along. In media res worked for Homer, and it'll work for you.

2. Your readers care about your characters, not you

Another very common mistake is "name dropping" or using so much detail about a specific topic in your writing, that it is obvious to the reader that this topic is a favorite of the author's. This mistake has a very obvious exception: if the topic is the topic of the story, describe away, Crichton made a very good living writing technically researched fiction. However, I really don't care about the dual overhead cams in your protagonist's car when he's going to spend the rest of the novel stranded on a desert island.

3. You will never own your characters, don't even try

No matter how clear the picture of your characters is in your head, the reader will come up with their own, and it will be vastly different than yours. Please don't describe the physical appearance of your characters unless it has real value to the plot. There are only two ways this works out, either you describe them early, and your story reads like a bad personal ad, or you describe them late, and your readers start wondering when your lead female dyed her hair. Remember how disappointed you were with the casting of your favorite book-turned-film? Your readers will be too.

4. Bows are boring

Basic fiction: a protagonist has a problem and she solves it. Sometimes this takes a few tries, or even a few books, but every discrete story has a problem that gets solved. That is where the story ends. Don't write another word unless it leads to another problem, and don't stop until that next problem is solved. Ideally, this would be in a sequel. Don't frustrate your readers by forcing them through another 50 pages of fluff because you can't flesh out those last few ideas floating in your head. If you haven't sealed the deal by the time you walk her to the door, be polite, say goodnight, and leave. Twenty minutes of smalltalk is not going to change her mind.

5. Even Jesus ended up on a cross

Nobody likes perfect people. Perfect people have boring lives that remind everyone else of how not-perfect they are. If your protagonist doesn't have at least a few small and one large negative character traits, your plot will seem forced at best, and your story will have a very finite shelf life. This was important enough that the Greeks set aside an entire category of drama for the fatal flaw called tragedies, and they're way smarter than you.

I'm a firm believer that the ability to play with pointers is a talent, not a skill. I don't think it can be taught. Sure, you can lecture on it, and I can get you to pass any multiple choice, fill in the blank, "knowledge of pointers" test, but I've found, and smarter people agree, that less than half of all people are able to juggle pointer abstraction in their head. I did most of my early programming in high level languages, and never really had to deal with pointers. I understood them, but it took a few seconds on every line of code to dissect it and make sure I was using them correctly.

I realized last week that I get it. Totally. And I blame Assembler.

If you were taught Assembler well, alongside a decent CPU structure course, Assembler is all about pointers. You just don't call them that. You'll learn about addressing, memory locations, address registers and the Program Counter, and you'll figure it out, because you have to figure it out, you can't abstract them away, and at the end of it, without realizing it, you'll have mastered pointers. Even the literals you use are contained in an instruction in a memory location pointed to by the Program Counter. Everything in Assembler is a pointer.

A lot of my peers don't understand why I tell them, if they're only taking a few programming courses, to take the lowest-level languages possible. This is the reason. The closer you are to the silicon, the more real examples you'll get about why you're told to do things a certain way. Don't understand what's so bad about strings? Parse one in assembler. You'll never forget it. Why can't you assume a flat address space? Address more than 256 bytes with an 8-bit processor in assembler, and you'll be intimately familiar with paging and banking. Very soon you'll realize the elegance of arrays, that they're not just native to your language (unless you're unlucky enough that they're objects instead), they're native to your processor, and the inner loop of

while(*s++ = *t++);

is probably a single CPU instruction^[1].

I love assembler. I get a rush when I can imagine exactly how the MCU is tossing bits around with every instruction. It's weird, I know, but if you're programming in any real capacity, you should love it to.

[1] On the 68k, it (should be) compiled to something like:

strcpy:
  MOVE.b  (A1)+, (A2)+  ; 14D9
  CMPI.b  #0,(A1)       ; 0C11 0000
  BNE     strcpy        ; 66F8

However, I came to a startling revelation today, and that is that documentation is, 90% of the time, worthless.

Now I work in an industry that relies on documentation. Without datasheets from semiconductor manufacturers, I would be out of a job, and an industry. So when I speak of documentation here, I'm referring to "explaining to people what they should do," or, procedural and standards documentation.

It started today at work. A number of us in the lab are working on design/layout projects simultaneously for the next revision of the WiSARD. Part of this is generating schematics that not only are correct, but are readable when printed, and have some sort of versioning or tracking information printed on them. In my world, this is usually done with a sheet template (see below).

Circuit Schematic Title Block

Now, I was the first to reach this stage in my project (I had the easier project) and when I needed to know what the lab's standards were for this, I simply looked up previous schematics, and made mine match as closely as possible using the tools available. There might have been some document in the repository that explained exactly how I was supposed to accomplish this task, but I didn't even look. I simply figured it out.

I ignored the documentation because I'm intelligent enough not to need it.

A few minutes later, Dan needed to do the same thing, and Kenji asked me to show him what I did. I spent the next 5 minutes looking over his shoulder, explaining step-by-step which options to check and buttons to press. On the way back to my desk, I realized that I could have simply handed him my schematic, and had him match it. It would have saved me about 4.5 minutes, and he would have easily figured it out.

Dan could have ignored the documentation because he's intelligent enough, but I forced him to use it, and it wasted us both time.

Later that evening, I was having lunch with a friend who is involved in my school's switch between webmail providers. One of the issues they're facing is how to educate students so that they can transfer their address book between products. After only a few minutes of conversation, we declared that it didn't matter, because the intelligent users are going to take the 15 seconds to Google the answer, and the unintelligent ones aren't even going to try, they'll just call support.

The users who need the documentation, and can't figure it out on their own, aren't going to look for it. Any way you cut it, creating documentation is just a waste of time.

Now, this isn't a 100% rule, there are times, like component documentation, where you won't be able to sell your product without it. Other times, like in a reasearch or grant project, you will be required to document things. But in the cases where you have a choice, it's pretty much nailing Jello to the wall.