Straight into sensors or master the basics first?

I did the same traffic light thing years back with a starter kit and got bored of it fast, so my take is go for the sensor. Blinking LEDs stopped being interesting for me after about two evenings, but the moment I wired up a DHT11 and watched numbers change on the serial monitor, something clicked. Real data feels diferent, even when the data is just your living room being 21 degrees.

That said, the pedestrian button idea is not wasted time. Inputs are half of everything you will ever build, and debounce alone taught me more patience than any tutorial. I burned a whole Saturday once wondering why my button registered three presses for every one, turned out I needed a tiny delay and a state check in the loop.

What worked best for me was mixing both. I added the button to the traffic light, then made the light respond differently at night using a cheap photoresistor. Two inputs, one output, still a small project, but it stopped feeling like a toy exercise.

The googling-your-way-through-it approach works, just expect to copy code you do not fully understand at first. Going back a month later and finally getting why a line did what it did was half the fun for me.

I'd push back gently on jumping straight to sensors. When I got my first Uno about four years ago I did exactly that, bought a pile of parts in a bundle and got overwhelmed fast. I had an LDR and a servo wired up with no real understanding of why anything worked, and every time it misbehaved I had no clue where to start looking. That frustration nearly killed the hobby for me.

The button idea in your original post is honestly the better move in my experience. A pedestrian crossing button forces you to learn interrupts or at least polling, plus state machines, which is where the traffic light project naturally wants to go anyway. My light stayed a boring toy until I added a button, then suddenly it became a proper little program with logic I actually understood line by line. The other poster is right that serial output makes things click, but you can get that same buzz from printing button presses and state changes before you ever touch a sensor. Understanding inputs first means when you do wire up that temperature sensor, you'll actually know why your code does what it does instead of pasting a library example and hoping. Grinding small variations sounds dull, but a week on buttons and timing with millis instead of delay will pay off more than a month of copy-paste sensor sketches. That delay-to-millis jump was my personal wall, and I wish I'd hit it on something simple.

Honestly the thing that kept me going early on was a cheap multimeter. My wiring was just as messy and half my early projects failed because of a bad connection I couldn't see. Being able to poke around and check wether voltage was actually where I thought it was turned hours of blind guessing into five minute fixes. Also, if you do the button route, print the button state to the serial monitor while testing. Watching it flicker between pressed and released when it should sit still is how I first learned about contact bounce, and it made the whole idea of debugging feel less scary.

Do both, honestly. My day job is programming signal controllers, been doing it about 14 years now, and the thing that separates people who get it from people who copy paste is learning to ditch delay(). Once your light can blink on its own schedule AND watch for a button press at the same time, you've basially learned the core skill. Try making the yellow last 2 seconds on a millis() timer instead of delay, and have the pedestrian button shorten the green. That one little change kept me busy for a week back when I started and it scales all the way up to real stuff.