Introduction: 3 Beginner Arduino Mistakes

In my decade of experience building with and teaching Arduino, I see three mistakes more often than any others. Beginners typically:

  1. bite off more than they can chew by attempting to build a project with too many elements at once,
  2. make incorrect assumptions during prototyping,
  3. and underutilize the resources available to them online.

Read more about each one in the Instructable that follows, including how to avoid making these mistakes yourself.

If you're just starting out in Arduino, try my free Instructables Arduino Class! It'll bring you up to speed on the basics and best practices, further enhancing your Arduino fun-to-frustrating ratio.

If you've got tips for beginners, we'd all love to hear about them in the comments!

Step 1: Sensible Bites

Picture of Sensible Bites

The most common beginner Arduino mistake is biting off more than you can chew by attempting to build a project with too many elements at once. You get frustrated and overwhelmed, and the project never gets finished. If you want to build a quadcopter, you need to break it down into simpler systems first. Quadcopters have GPS, inertial measurement units with accelerometers and gyroscopes, not to mention variable speed motor control. You should honestly reflect on your abilities, and then look up examples and tutorials for each component of your project, and build them successfully before attempting to combine them.

Step 2: Don't Assume It's Right

Picture of Don't Assume It's Right

The second mistake I see frequently is making assumptions during prototyping. I know it can be really tough to learn all the things that possibly could go wrong, whether it be your wiring, or your code, or your software settings-- but when you're circuit's not behaving like you expect, don't just assume your wiring is right without checking. Double check the pin number you specified in software is the same pin connected to your LED, or sensor, etc. Double check power and ground, especially. Get into a detective mindset, hunt for missing semicolons, get out your multimeter, add in some serial debugging to your code to help figure out what's going on.

Prototyping resources:

Step 3: Look It Up

Picture of Look It Up

The last mistake I see a lot with Arduino beginners is underutilizing the resources available to you online. The Arduino site has a reference section that breaks down the whole programming language by groups of commands with simple samples demonstrating each one. I look up stuff all the time, like how modulo works. But there're also community resources you should be taking advantage of as well, like researching your questions in forums online, and posting Instructables about your projects!

Thanks for reading. Don't forget to check out my free Instructables Arduino Class, IoT Class, and my other projects, too. I look forward to reading your feedback in the comments!

To keep up with what I'm working on, follow me on YouTube, Instagram, Twitter, Pinterest, and Snapchat.


German_MX made it! (author)2017-10-10

Hi there.

I built an event counter, and had some trouble, but then i readed the "DigitalReadSerial" tutorial, and learned that "=" is not the same that "==".

Thank you for the advices.

Ah yes, and the compiler doesn't always warn you of such mistakes

if (x = y)

Is way different than

if (x == y)

If you use "if (x = y)" by mistake, instead of comparing x to y, it assigns the value of y to x and returns true based on the value of x - after setting it to y (or maybe it returns y, I can't remember, which is a good reason not to do this on purpose.

The reason the compiler doesn't give you an error is that it's perfectly valid syntactically. And there are actually cases where you might want to do it (I never do it. It's confusing.)

Don't mean to be a troll .....I am an old man, learned IBM/DEC hex and octal assembler code, COBOL, FORTRAN, RPGII and powerful versions of BASIC language - so I ain't stupid. Then I went into management. Then I came back out to re-learn coding so I could do some web scrapping and the kewl world of IoT.

Whoever designed the current languages and the syntax of such should shot (or at least severely stockaded with tomatoes).

Just picking on Arduino's C language. I am a human bean, I am thinking the big picture. IMHO languages should support me - not me figuring out how to sprinkle "xyzzy" syntax. Back in the day with 4 hour turnaround on batch punch cards - I did a lot of desk-checking to be sure - so I can play computer and ain't lazy.

Languages (especially IDEs) should not allow me to mix up = assignment function with a "==" comparison function. I don't care that If(x=y) saves an assignment clause and is quite powerful and "elegant" a term used by prima-donna developers to show how smart / different they are.

Regarding the frigging semi-colons to close off a code line, Give me a break!- past languages have lived very well without any "end of code" delimiter.

Why do I have to remember that the following is "correct"?

nameOfKey[i] = Serial.readString(); // read Name of key as String from

To this simple minded Missouri boy. All of the following, should us HELP us Human Beans to get our big picture J O B done. Not be so picky

Valid NameOfKey[i] = Serial.readString(); // read
Name of key as String


bad NameOfKey[i] = Serial.ReadString() // read
Name of key as String

bad nameofkey[i] = serial.readstring() //
read name of key as string from…

bad NaMeOfKeY [I ] = SeRiAl.rEaDsTriNg( ) //.....

I bet everyone of you readers (even the ones from Arkansas) can read the "BAD" statements and know what it means

Has the Arduino IDE heard of the terribly complex upcase(trim(codeline))

Yes, I know there are reserved words. And that NameOfKey is not the same as NameOfTheKey.

If there are any aspiring future Computer Science Majors out there - the language is a tool to help the CUSTOMER.

Sorry for hijacking - but it just struck a raw nerve, t,.,

DonX-Developer (author)tdolan0012017-10-21

I do not normally add comments to the forum but I couldn't resist this one.

I too have been around quite a while and used many programming languages over the 40+ years in the trade.

The = assignment and == comparison are just that; and you can have an assignment in an if condition, strange but perfectly valid.

Languages that use and end of line delimiter (which actually include COBOL, sorry) do so to save space and compiling time.

Languages that do not use one, take the carriage return and line feed and add it to your code.

Most BASIC languages add other information to the beginning and end of the line to let the compiler know where the line starts and ends.

The net result of this is that the code file is longer and compile time, or in BASIC, interpretation time, also takes longer.

As for your code examples, only the first one would compile anyway, regardless of your variable naming conventions.

The naming of variables is always a sore topic with some people. Camel case versus Pascal case etc.

But the point here is that the coder chooses what and how to call the variable and uses it, especially in the world of Arduino where they are not professional coders.

Personally I would use Camel case for variable names and have done for over 20 years now, so none of your examples are right for me, but if I looked at a piece of code that just called a variable x, then that is fine too, because it is not my code.

Arduino uses Camel case for method or function names where I would use Pascal case.

I don't complain about it, I adjust to whatever I am using.

I have been using C#.NET, Javascript, SQL Server and Oracle to name a few, for the last 12 years now and they all have their own quirks, = and == being one of them.

I am surprised that you did not mention the curly brackets to denote code blocks, maybe you prefer typing a } to typing ENDIF or END SUB etc.

Becky's item No 3 is maybe where you should start.

German_MX (author)tdolan0012017-10-18

We hear you brother. Well, in fact Yukihiro "Matz" Matsumoto, creator of Ruby, heard you.

Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run fast. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

At this point, i believe that Arduino is a "easier" way to do stuff that in other times where more complicated, but on the run, Massimo Banzi (Arduino creator) forgot that you need some background at programming.

YES, programing on C is way more easier than assembly code, no doubt; but you still need to know C, and all the ups and downs that come with it.

P.S. Don't want to be rude, but couldn't look away from the mistake of "human beans" instead of "human beings".

tdolan001 (author)German_MX2017-10-18

Last hijacking comments on this.....My time and brain cells are more valuable thinking of the big / creative picture rather than worrying about proper up/low case on cmds. Regarding the ability to do an implicit "LET A = B" in an IF(A=B) statement -- To what purpose is this being served? Yes, I know bytes on a micro are valuable but my time is more valuable. If I am too sloppy/wasteful with my coding then I need to graduate to a higher platform. e.g. Pi or go back to 96 column punch cards. (no mistake both 80 and 96 are valid sizes.)

I am not an expert in recent languages structured or OO. But I CANNOT think of ANY languages I have written, read or lurked that requires a silly ";" delimiter to indicate "end of code" . I welcome the opportunity to be wrong Tim Dolan Email (remove all previous spaces) "AtSign" Gmail using the usual domain convention.

I do not blame Banzi - he chose a language that would produce nice tight BIN code. I enjoy Arduino hacking. I blame the compiler and syntax folks. But I have other windmills to fight.

Thank you for your last comment - but I rarely make mistakes in business communication. Human Beans is accepted as are the words, InterWeb or InterGore.

Sorry for the hijacking - I will behave......"We Now Return You To Your Regularly Scheduled Program, Already In Progress".

I remember reading:
"Computers do what you tell them to do, not what you want them to do."

Seo10 (author)2017-10-10

I have a couple of projects I would love todo. On the surface they do not look that complicated. I am however 75 and I also know, as you said, if I get into it and I get overwhelmed If 'lol set it aside and never finish it. Sometimes It's think old dogs can't learn. New tricks.

GabrielC190 (author)Seo102017-10-10

Check those classes

He has the best tutorials that I've found on internet about Arduino and Raspberry. Don't give up man!

tdolan001 (author)GabrielC1902017-10-17

I agree Paul W. is an excellent YouTuber. I have gone most of all his Arduino shows.

Basho317 (author)2017-10-17

As a recent retiree, I decided to learn a new skill. Electronics. I bought heaps of sensors, I'm embarrassed to mention how many different stepper motors I have bought, soldering systems, adjustable power sources and on and on.

I have yet to make anything work. I really appreciate your instructable, I'm off to the hall of mirrors.

NeilM29 (author)2017-10-10

My method is to keep things simple and build it up in stages. Start with a basic arrangement that works then save it. You can then add the next stage and if it all goes horribly wrong you can always go back to your previous design and work from there. Keep adding stages until you have something amazing! Also don't be afraid to copy or adapt someone elses ideas.

JohnW51 (author)NeilM292017-10-10

I'm a retired electronics engineer with 40+ years of experience in system design and some programming. What you describe is EXACTLY how engineers go about designing and developing a project. It would be next to impossible to design an entire complicated piece of machinery and test it in final form without making the "building blocks" one at a time and testing each, then going on to gradually link them together into the final working product. This can literally take years for a very large, complex project.

TGit-Tech (author)JohnW512017-10-16

GRADUALLY link them together into the final working product. I still struggle with this and do a lot of refactoring in an effort to create a more perfect model. Can't seem to find the ideal "flowchart" without many refactor attempts. If theirs a secret to this - please share.

AndrewA167 (author)NeilM292017-10-10

I want to add here that even for small development like embedded programming of 8-bit microcontrollers, using git or some other version control system should be embraced for projects; that way, you can always branch and/or roll back as needed.

LarryF29 (author)2017-10-10

For me it is the coding, cannot make heads or tails about it. Seems very technical and unless I can visualize and actually do it hands on it don’t make sense. Writing the code I see as very difficult, copy someone else’s work is not an issue but to take an idea and put it to code is a whole different story

ny_rebel (author)LarryF292017-10-10


I'm no expert but an easy way to learn coding is to take a known working sketch and then "play around" with it. Use a simple sketch such as moving single servo and make changes to the code and observe the result. Do the same with a LED. These are easy to manipulate and the visual feedback will help you to get a "feel" for the code.

LarryF29 (author)ny_rebel2017-10-10

Thanks for your comment,I guess I am just intimidated by writing the code and getting any understanding of all the wording and concepts of the code. This may sound crazy but I can take an IC chip and understand if I put and input on a pin weather it is voltage or current and get the resulting output but to incorporate any coding to this is confusing to me anyway.

TGit-Tech (author)LarryF292017-10-16

I don't know if this will help in your confusion - but when you say, "if I put and input on a pin weather it is voltage or current and get the resulting output" - ask yourself, "is this the 'resulting output'" I expected to get and how did I know what I expected to get ( datasheet )?

Code is just a matter of creating the datasheet. Defining what you expect a 'resulting output' to be and thus it also requires testing ( as you mentioned doing ) that the actual is what you expected as defined by your code.

nb109 (author)LarryF292017-10-10

Might be of interest to you:

The gist of the article is about how we limit our potential to get our head around a subject well within our reach because we have this bias-based assumption that the subject is difficult:

bekathwia (author)nb1092017-10-10

Interesting article!

aeroman2010 (author)2017-10-14

Thanks for these points

Treknology (author)2017-10-12

This is sound advice. I have yet to enter the world of custom processors. I've been working on a custom keyboard for a very long time, and someone else suggested that laying out and scanning a set of keys was extremely easy.

The problem was that I needed a massive lookup table to convert the key scan to a code for the PC, as well as driving a small LCD to show specific statuses. How it was going to cope with high enough scanning and performing the lookup followed by generating the code was going to be cumbersome and probably too slow.

I elected, for simplicity, that my output would be PS/2 based so that I don't have to fight with the USB protocol. I know the AT-PS/2 protocol very well, so a simple PS/2 to USB adaptor would suffice for most computers. Eventually, I realized that instead of having to write masses of code to read a key matrix, I could use an existing decoder chip straight off the shelf, and use the PS/2 as the input as well.

So, as you've suggested, I've broken it down into smaller modules. I just need to learn enough code to read PS/2 input, make decisions on that input possibly updating the LCD in the process, and then feeding the translated output back into PS/2.

When I get to the prototyping stage, the only coding that I really have to learn is that which is necessary to interpret the PS/2 signal, and how to drive the LCD. Everything else should just be a huge IF...THEN list.

Mex5150 (author)2017-10-12

My best advice is if you are having problems, use rubber duck debugging. It feels a bit silly at first, but it really does work

tutdude98 (author)Mex51502017-10-12

yep, when i used to learn c++ for college i used to pretend like im explaining everything to professor, and it worked, i passed it :D

JEMCA (author)2017-10-10

I have been teaching students how to use arduino processors in their projects for a number of years. Generating the needed code is usually the hardest part of the project.

I always strongly suggest creating a flow chart of the activities that you want to perform. Breaking down each operation needed into a series of simple steps. Using a flow chart you can visually see how the various parts of the code will flow and interact. Each step of the flow chart should be an action or decision point. Once the flow chart is done, coding each action or decision is much simpler. Often it reduces to replacing each action or decision step with a single line of code. If you can clearly follow the logical progression of the flow chart and it completes the intended function, then generating the code is much easier. Also, troubling shooting the code, if needed, is much easier as you can more easily follow the intended actions and see where things did not go as planned.

One other suggestion. Always place comments in you source code that simply describe what the code is intended to do. If I have a block of code that is fairly complex, I will add a comment lines to describe what the block of code is doing, what inputs it should receive from other portions of the code and what results it should generate.

Commenting your code will allow you to better understand what you wanted the code to do when you go back later to modify or change the code. Or if someone else might have to look at you code and try to determine what you were trying to accomplish.

AndrewA167 (author)JEMCA2017-10-10

Making a flow chart is a good practice to get into; it should also be noted that at times sub-processes in a flow chart can be represented as referencing another flow chart (can be done using any of the symbols in flow charting, as long as the symbol represents what that sub-process is for). Doing this can keep the flow chart(s) easier to understand and maintain.

Also, when flow charting processes, it is important to remember any "soft processes" - that is, capturing the inputs and outputs of processes which happen external to the process on the computer (usually things humans do, but which aren't recognized as part of the process - these soft actions typically occur organically without anyone realizing it). These may or may not be able to be identified prior to development, but if they can be, then they should be noted.

When flow charting processes, the flow of the chart should follow some standard; top to bottom, left to right are common "flows". I have also found that flow charts which are "balanced" - that is, have relatively equal left and right (or top/bottom) paths or flows, tend to be well designed, easy to maintain, and represent the process well. Note that this isn't an absolute; sometimes a flow won't be balanced, and it may not need to be.

When lines of a flow chart overlap or cross over one another, it's almost a sure sign that the process flow needs to be refactored; you are literally looking at a graphical representation of "spaghetti code" - if you see this, try to fix it or simplify the process immediately.

Lastly, in regards to flow charts, there are more than one form of flow charting styles, and each has its own place. Learn about all the styles and representations; some can be used to represent concurrent processes which feed data back and forth between parallel process flows, for instance.

Finally - when it comes to commenting, it is best practice to follow some form of "doxygen" standard, so that the comments can be run thru a translator, and the code can form its own documentation. C/C++ has its own form, other languages have theirs. You don't need to follow all of the intricacies for embedded development like you would for larger projects, but adding in the "syntactical sugar" can be helpful for maintenance further on down the line. Comments should also be worded so that they convey the what and the why, not the how (the code itself shows the "how").

Hemlock_Tea (author)AndrewA1672017-10-11

I completely agree with you. I am a retired automation / PLC programmer. The first thing I prepared was an Operating Concept and Logic Diagram (the names varied depending on the customer). These were used to discuss what the machinery was expected to do, and were often used in the board room, the engineering and maintenance shop and the factory floor - the same document. They were expanded and detailed through repeated discussions long before any coding happened. My greatest thrill came when a line operator, the "lowest" person in this one factory - she just kept the line fed with supplies - made a suggestion to improve the process after she said she had " gone over it all night because something didn't quite add up". You see, people understand logic and flow but would be completely crushed by code.

So. Think about what you want to do, refine and debug your idea then start coding. You will have more than enough work debugging your code. Of course, you will most often find that you have to revisit your logic/flow a few times before you are done but separating the two activities helps to keep your brain from exploding (or reduces the number of explosions) as you go along.

JohnW51 (author)JEMCA2017-10-10

YES! That is definitely the best approach and, as a retired electronics engineer, I can tell you it's how professionals do it.

Zaphod Beetlebrox (author)2017-10-10

I'd like to add that you can only draw 40mA (not much) from an Arduino pin. You cannot run motors or magnets or other high current devices directly from the board.

LghtSpeed (author)2017-10-10

Good points ,there, Beky. As far as the quad copter, i would add the GPS as the final stage, after everything else has been verified as functional
And airworthy. Thank you.

bekathwia (author)LghtSpeed2017-10-10

Sure, makes sense. I used it as an example because I frequently get asked how to build one by beginners! =D

davereiser (author)2017-10-10

Very informative. I want to take regular classes (not online). How do I find them? The local community college does not have them. I live in 20877.

bekathwia (author)davereiser2017-10-10

Try looking for makerspaces near you. I found this one in Reston, VA which has Arduino classes:

davereiser (author)bekathwia2017-10-10

Thank you. Interesting, I used to work in Reston. It's a little far.
I have enrolled in an Instrucktables class. I prefer classroom.

knygl (author)2017-10-10

I'm falling in love!


ohoilett (author)2017-10-10

Great points!

bekathwia (author)ohoilett2017-10-10

Thank you!

martingharris (author)2017-10-10

Thanks for this. I have been the worst Arduino builder in the world! I could hardly get anything to work. I later found that all the black wires I bought were not connected at one end! and with one red and black starting most projects failure was a dead cert. ASSUME nothing.

randofo (author)2017-10-09

Words to live by! Thanks for posting this. :)

bekathwia (author)randofo2017-10-10

Thanks Randy!

ohoilett (author)2017-10-10

Good points.

About This Instructable




Bio: Becky Stern is a content creator at Instructables. She has authored hundreds of tutorials about everything from wearable electronics to knitting. Before joining Instructables, Becky ... More »
More by bekathwia:3D Printer Filament Dry BoxSolar Soil Moisture Meter With ESP8266Solar Engraving
Add instructable to: