Why I Keep Coming Back to Arduino Projects

I’ve always enjoyed projects that combine software, electronics, and problem solving.

That’s probably why I keep finding myself buying Arduino kits, even when I already have unfinished projects sitting in drawers.

But when "The Most Complete Arduino Starter Kit" appears on Amazon prime at more than 50% off, Hey it would be rude not to. I looked at all the accessories and found myself clicking the buy with one click button and less than 24 hrs later it arrived.

Tech Christmas Day... The box was full of all sorts of colored bits.

This is the 3rd Arduino I've bought over a number of years. The first was a simple learn-to program an Arduino kit and came with some basic electronic components.

Why Arduino Interested Me

An Arduino is a solid-state microcomputer with onboard input and output pins exposed. It's basically a circuit board with a controller about the size of a playing card. It's blue, not that it matters. It's like a mini PLC or Programmable Logic Controller. It can sense the outside world with connected sensors and be programmed to do something that can affect that world. 

What fascinated me was the connection between software and the physical world. Code could suddenly control motors, lights, sensors, and real objects rather than just things on a screen.

So you could connect a light sensor and measure when it gets dark. When it does it can switch on a light. It can be so much cleverer than that though. It can measure how dark it is and can be programmed to adjust how bright the light is.

That was about as far as my projects got with the first one. Although I did make a bubble machine for the boys. It used a servo to dip a bubble eye in a bowl of fairy liquid, raise it up rotate it and a fan would turn on and blow bubbles. It would then lower back into the liquid and repeat. It wrecked the servo eventually as the fairy liquid dripped into its gears of the servo. It was fun when it lasted and the boys enjoyed it.

Projects That Never Quite Finished

The second one I bought a few years later was an Arduino Yun (posh model with Wifi) it was bought with a plan to solve my leaving the garage door opener problem. I can't see the door from the house so would forget and go to bed and wake in the morning to the realization that the door had been open all night.

The door is electric so the plan is to add a couple of limit switches and feed them to the Arduino. It would be programmed to tell me past a certain time that the door was still open. It would tell me via wifi and I would be able to press a button and it would close. This project will still happen someday. I've probably had the Yun for 3 years now.

And on to the third Arduino. It's an R3. I have no idea what's this means. I guess it's probably revision 3 but I still have to read the manual. Out of the box, it looked the same, it plugged into my Mac with a USB cable that provided power and the ability to download programs. I skimmed through the 3 pages of windows installation to get to the Mac installation. Which was 1. download the zip. File 2. extract and run the programming package.

So what came in the box besides the Arduino? Lots of things.

Learning Through Experimentation

The manual comes with 100 or so tutorials on things to make.

Building Things Together

Why did I buy another Arduino? Here comes the excuse... I would like Jamie (age 9) to get involved and what better way to get some son Dad time with Tech than to build things together.

We have done the first couple of projects and so far so good. Jamie has learned a resistor can change the brightness of an LED... The bigger the resistor the less bright the LED gets.

There’s something satisfying about learning these concepts physically rather than just reading about them. Changing a resistor and immediately seeing the LED dim makes electronics feel real very quickly.

I'm looking forward to getting into the more complicated projects and hopefully, as I/we will learn more about the Arduino programming language Also hopefully the Yun will be pulled from my desk drawer and be put into action for its original purpose of telling me when I have left the garage door open. Who knows I might get Jamie to build this project.

Looking back, Arduino projects were never really about finishing perfect products.

They were about experimenting, learning, solving small problems, and understanding how software and hardware interact with the real world.

That curiosity has never really gone away.

This also connects closely to my reflections on LEGO Technic and engineering mindset, where my fascination with mechanisms and systems probably began.

It links naturally to my thoughts on early computing and programming and how experimentation shaped the way I learned technology.

A lot of the same mindset also appears in my post about fixing things instead of replacing them.

I’ve always enjoyed experimenting with technology, understanding how systems work, and solving practical problems.

A lot of that same thinking now goes into helping simplify technical issues and improve digital systems.

You can take a look at my TechFix service if that sounds useful.

Why We Stopped Tracking Bugs in Excel

One thing I’ve noticed over the years is that software projects often become harder to manage because the systems around them become unnecessarily complicated.

At the time, we were tracking bugs in spreadsheets, and it quickly became messy with multiple versions, email chains, and poor visibility across the team.

The Problem with Spreadsheet Tracking

I hate managing software faults with a spreadsheet. It normally ends in a mess, with multiple versions, poorly formatted, emailed here there, and everywhere.

The real issue wasn’t the spreadsheet itself—it was the lack of visibility, ownership, and workflow around the process.

To avoid this and not having access to a real software bug-tracking tool like fogbugz I quickly set up something in Trello.

Why Trello Worked Better

Trello is brilliant and I have many boards for various jobs on the go at one time. It is a simple free-to-use tool for managing simple tasks and workflows.

 

I set up 6 lists flowing from left to right. New bugs can be added by the team or by the customer. They can be entered directly as a new card or via email by links provided. The email to the board facility is brilliant and it will create a new card automatically.

Visual Workflows and Team Collaboration

The bug tracker board can be accessed by anyone who has access to the team. When connected to the team they can then take control of individual bugs and they can be assigned a bug. So at a glance, you can see John is working on bug #27, and Tom is testing #32. When John has completed the fix for bug #27 he can move the bug to the ready for test list and assign the bug to Tom. When Tom tests the bug and it passes the test Tom can move it to Done. If it is not fixed he can move it back to in progress and assign it back to John and add a comment as to why it did not pass the test.

What made the system effective wasn’t complexity—it was visibility. Everyone could immediately see what was happening, who owned what, and where bottlenecks were appearing.

Colors can be added to each bug indicating the criticality of the fault. So at a glance, you quickly see the red for critical and can concentrate on these first.

Bugs can include attachments, so you can take a screenshot of a fault and quickly add it to the bug to help with the resolution. You can add multiple items to a bug, so if there are a number of similar faults these can be grouped into one bug and make use of the checklist facility. Tick them off as they are resolved.

What Stayed With Me

So there you go. Trello as a bug tracker. It's not perfect, but I set up ours in under 10 minutes, you can have your whole team collaborating together working through problems or changes. It's much better than yet another Excel spreadsheet and you can see at a glance visually the status of the bugs.

Looking back, this probably reinforced something I still believe now: simple systems that people actually use are often more effective than complicated processes designed for perfection.

A surprising amount of software delivery problems are really workflow and communication problems underneath.

This also connects closely to my thoughts on overcomplication in systems and how unnecessary complexity often creates more problems than it solves.

It links naturally to my reflections on understanding systems properly rather than simply adding more layers around them.

A lot of the same thinking also appears in my posts about organisation and workflow simplification.

Good systems are often simpler and more visible than people expect.

I spend a lot of time helping simplify workflows, untangle technical problems, and make systems easier to manage and maintain.

You can take a look at my TechFix service if that sounds useful.

I Have the Maker’s Itch

I’ve always had the urge to make things.

If I see something interesting, my first thought is rarely “I should buy one.” It’s usually “How could I build that?”

Projects tend to sit in my head for weeks, months, or sometimes years before I finally start building them.

So I have an affliction with making stuff. I always have some project or other on the go. I get a whacky desire to make something and mull it over for weeks, months, or years before having to start.

If I don’t start I just keep thinking about it and thinking about it! I am either planning, making, fixing, or repurposing something. I have many projects on the go at one time.

I have to say I enjoy the whole process. I see something and think I can make one of those. I don't have much of a desire to buy it but given the chance to build or make it. How can I build that? and then I'm off.

Projects That Stay in My Head

The perfect project is something that takes a long time and has many stages to it. It can evolve and be shaped. I love to spend time subconsciously sketching out in my mind how I can make parts, how I can adapt parts, and how I can engineer something. It's those moments when I am waiting or daydreaming I will be engineering something in my head.

Looking back now, I can see this connects strongly to how I think visually. A lot of projects are mentally assembled long before anything physical gets built.

Learning Through Making

Building the boy's Jeep was a perfect example of this. It had lots of parts, it required research, it needed different types of skills and I had to adapt and repurpose things. The front steering mechanism was a problem I spent ages thinking about. I needed a way of having a 3 axis mount that could swivel in all three directions. I'd sketch out diagrams, play with bits of metal, Lie in bed awake thinking how to solve the problem. Inspiration and a final solution came while in the local hardware store. Large eye bolts normally used for gates bolted together in an X-Y-Z orientation were a quick reasonably cheap and strong solution. Relief, I can stop thinking about that problem.

The Joy of Solving Problems

Both my boys sleep in custom beds I have made. Jamie wanted a high sleeper in the shape of a Campervan, and Thomas wanted a Pirate Ship. Both required research, planning, and design. The Campervan was drawn out using a digital projector that beamed the outline of a Campervan onto a giant sheet of MDF that I then traced around with a black Sharpie.

It has working lights a real sliding door, and a surfboard as a ladder to get to the top bunk.

Thomas's Pirate Ship bed is a similar construction and has an anchor, a ship's wheel, and a bell (last orders at the bar type bell from eBay). The anchor and ship's wheel were cut out on my mini X-carve CNC machine.

I am a bit of a petrol head and one of the big projects I wanted to do was build my own car (I mentioned this in previous posts). My first attempt was to dismantle my mum's Mini Clubman estate when it was parked up after terminally failing its MOT. I didn’t get very far. I was only 12 and had a limited budget and tools. Years later I set about researching and choosing something new I could build, I had the maker's itch that needed to be scratched. It was a long project that took 4 years to build and get on the road. I took my time and enjoyed all the detailed parts of the build. Again I loved all the little projects and spent lots of time daydreaming solutions along the way.

Why I Keep Making Things

This year is no exception. I started collecting materials to make a “Mega Den" for the boys... A sheltered hangout In the garden that we can escape to, we can draw, play games, and pretend we are on holiday all while still in the garden at home. It needed to be bigger than the fort (another scrap wood project I made a few years ago).

I found some windows free from Gumtree, and some old doors also from Gumtree, and they sat under a tarpaulin for over a year as I planned out in my head how I could use them. A chance discussion with a farmer saw me collecting 12 scaffold boards and I had enough to get started.

I have spent a few happy weeks and evenings sawing, hammering, and drilling to get to the stage of something resembling a "summerhouse" no MegaDen in the back of the garden. Roofing materials arrive next week and it will be fully watertight and ready for action.

Electrics arrived this week (thanks to Amazon Prime) and a length of armored cable that I have squirreled away in the garage for over 10 years will see power running up under the grass for lights and sockets.

A couple of weeks should see it finished and that will be another project completed, and I can stop thinking about it.

There is more in the pipeline…

I have to build another Jeep. I have all the parts. The boys are bigger now and starting to outgrow the first one. I want to make something all metal and try to use the full 900W capacity of the motor's power in this one. (The Jeep currently is only using a third of that)
I need to build a double computer desk for the boys. They will have a workstation and storage each for homework and school projects

I have an Arduino Yun bought with the sole purpose of warning when the garage door has been left open and it's dark. I can’t see the door from the house unless I go outside. It has an electric opener and the plan is for it to email me to tell me it is open and from my phone, I'll be able to close it. It will involve some wiring and some code but I have planned out in my head what it needs to do. I am tempted to also connect the Arduino to a Speaker and have it play the Thunderbirds theme via WAV file when the door is opened. But that might annoy my neighbors

So yeah, I have the maker's itch and the only way to stop it is to keep on making.

I think of projects as good therapy, and if you remember that 80's kid's TV program "Why Don't You"...

P.S... top marks if anyone knows the next line?

Looking back, I think making things has always been a form of problem solving, creativity, and probably even therapy for me.

Some people switch off by relaxing. I seem to switch off by building, fixing, planning, and figuring things out.

The only real cure for the maker’s itch is to keep making.

A lot of this connects closely to my reflections on LEGO Technic and engineering mindset, where my fascination with systems and mechanisms probably began.

It also links naturally to my thoughts on visual thinking and mentally modelling projects before building them.

Many of these ideas also appear in my posts about fixing things instead of replacing them and building the Megaden.

I’ve always enjoyed building, fixing, adapting, and simplifying things—whether physical or digital.

A lot of the same mindset now goes into helping people untangle technical problems and improve systems.

You can take a look at my TechFix service if that sounds useful.

How I Became a Chartered Engineer (CEng)

For years, becoming a Chartered Engineer was something I kept meaning to do but never quite started.

I had the qualifications, the experience, and the professional membership. What I really lacked was momentum.

I just lacked the personal motivation to get my finger out. I was "comfortable" in my job I didn't need to be chartered. It would be nice but not a must-have.

Why I Put It Off for So Long

The biggest blocker was compiling my experience in chronological order on the application form. I had been working for 20 years so remembering and cramming it all into a few pages was daunting.

I think a lot of experienced engineers fall into the same trap. The more experience you have, the harder it feels to summarise it all into a few pages.

What Finally Changed

The shove I needed was when I looked to move up a grade at work. My "boss" blocked me with a job description. Basically, a badly written list of must-haves to perform the upgrade in position. Lots of airy-fairy statements plucked out of thin air that the person must meet to perform the job. I was doing the job already but had to prove it.

So I set about formulating a case that showed and was backed with evidence of my experience that I could meet the must-haves. I spent a few weeks with a text document open on the side of my desktop, quickly adding experience when I remembered..., reliving my past 20 years.

The document grew and grew and gradually I recounted all the projects I had worked on. I had ticked off all the job requirements (must-haves) and provided real evidence of how I met them.

I polished it a bit adding in real must-haves the job holder should have and forwarded it to my "boss" and was moved up a grade. The bonus was I now had a full career review down on paper (or digitally). The dreaded application form for chartered engineer would be easy now.

What initially felt overwhelming suddenly became manageable once I realised I already had most of the evidence—I just needed to organise and present it properly.

I sought out 2 sponsors as a reference, added all my details, did some more polishing to my career history, and sent it off and waited...

I was invited for an interview shortly after. A time and date were set for me to be at a hotel in Altens to be "grilled".

I had a few weeks to prepare for my interview. The format would be for me to present for 15 minutes and then answer questions for an hour.

The application pack I had downloaded from the IET website had a guide to what was expected in the presentation and what the interview would cover.

Preparing for the Interview

I prepared a pack of 5 slides covering projects (maximum allowed) I have worked on and ticked off all the skills I needed to have. I then printed 3 packs with my slides, my application, training evidence, work evidence, and my CV and presented them neatly in a clear plastic folder.

I also added a couple of pics of my Tiger, the kit car I built. I felt like a software engineer I wanted to be able to show I also have electrical and mechanical hands-on skills too.

A few weeks later, I donned my suit and tie and headed for my interview. Confident I had prepared well it was time to be a shining example of a potential chartered engineer.

I met with a panel of 3 interviewers. The IET guide said there would be 2! Oh well, the more the merrier.

We introduced each other and I sat at one side of the table and they at the other. I did my presentation and quickly talked through all my slides.

The Interview Wasn’t What I Expected

The next part I was dreading, what if I couldn't answer the questions? What if I wasn't qualified? It didn't matter. What happened was a good conversation about my experience. One interviewer was leading the conversation and another was checking off where I met the skills required as I gave my answers.

What surprised me most was that it didn’t feel like an interrogation. It felt more like an experienced conversation about projects, decisions, and engineering work I had already done.

The main point I had to quickly adapt to was to say I rather than we. Working as a team for so long I am accustomed to saying 'we' rather than 'I'd, which caught me out a couple of times. I had said we had created some procedure and had to correct myself and said I, one interviewer said are you sure, while the other chipped in with the front page of the procedure showing my name on the front cover as the author. Thankfully I had put a copy In the interview pack.

The rest is a bit of a blur but an enjoyable blur. It was a great opportunity to talk about what you have been doing for the last 20 years.

In the end, the interviewers came across the pictures of my Tiger and probably had just as many questions about it and how I had built it, an easy subject to talk about without any prep.

So that was it, it was about 1hr 45min when we finished, and I left confident I had done my best. My interviewers couldn't give me any indication of whether I had passed or failed. I would be contacted in due course.

6 weeks later I received an email. My application must have been good, my presentation and interview must have been good. I was invited to join the engineering council as a chartered engineer.

What I Learned From the Process

Go me! Why didn't I do that a long time ago? With a bit of effort and lots of preparation, the whole process is very straightforward and not as daunting as first thought.

Looking back, the process was far less intimidating than I had built it up to be in my head.

Most of the challenge was simply taking the time to reflect properly on years of experience and organise it into evidence.

If you’re considering becoming chartered but keep putting it off, my advice would simply be to start gathering your experience together. Once you begin, it becomes much more manageable.

This also connects closely to my reflections on career change and professional growth.

A lot of the practical engineering mindset behind chartership also appears in my posts about making and problem solving.

Professional development often feels more intimidating before you start than it does once you begin.

I know how intimidating the process can feel at the start, so if you're stuck or procrastinating on chartership, you can drop me a message here.