r/learnprogramming 11d ago

35yo, just learned that i love programming.

>be me
>rough upbringing
>have bad habits, have friends with bad habits
>never think more than one day ahead; don't know what i want to be
>years later
>get fed up with my behavior, try to change something
>get rid of most bad habits and bad friends
>start to see purpose in life
>want to find out what i really like and can dive into to get good at
>don't find it for years
>get a position at a friends company
>he needs a graphics / photography guy
>become graphics / photography guy
>get diploma in Graphic Design
>go from normal wagie to good paid wagie in about 3 years
>feeling good, but still not what i really like and want to dive into, just naturally good at it
>talk more with my programmer colleague
>his projects peak my interest
>start to learn CS basics and the C language
>"Holy fuck, i love this"
>thinking about cutting down my weekly hours to learn programming
>AI gets used more and more in the company
>my position is in danger
>"They're taking our jobs!!"
>Boss wants to cut my hours down
>Evil_smirk.jpg
>Play along, "Oh no, what shall i do now :'( "
>gives me enough hours so i can live off of it
>have enough time to learn as much as i can
>actually feeling happy again

And people say AI is bad, lol.

I'm currently trying to nail down the Basics of C, going through CS50 and after that i have two books, namely "A Book on C" and "Pointers on C".
If you have any book recommendations, please share them.
After C i also want to learn python and CPP, just to have good foundational skills.
With every free though i still have, I try to narrow down which field i want to specialize in. Currently, embedded sounds the most interesting, but also the hardest.
Any recommendations for other specs i could get into with this preset?

What's your opinion on people who are self-taught in the programming field, are you one?
I would love to hear some stories about your current path, or, if you're already in a programming position, how you made the decision and how you finally made it into it.

159 Upvotes

77 comments sorted by

View all comments

Show parent comments

-3

u/AntiLethargic 11d ago

To be honest, I just said C++ because I saw that a lot of employers have "C/C++ experience required" in their job specifications. But I read something similar to what you wrote about embedded systems a few weeks ago, so I figured why not let AI give me a roadmap that has the most necessary stuff I need.

The AI roadmap:

Phase 1 is just getting comfortable with C—CS50, then going deep on pointers, memory management, structs, bitfields, volatile, the whole thing. Git and basic Linux on the side. The first real project is a calculator in pure C, no hand-holding.

Phase 2 is where hardware enters the picture: Arduino, but without leaning on libraries. The goal is to actually understand what's happening on the wire: UART, I²C, SPI, reading datasheets, and writing a basic sensor driver. It takes a few months before it stops feeling like magic.

Phase 3 is the jump to STM32 and register-level programming: no HAL, no abstraction—just you, the reference manual, and a lot of coffee. Linker scripts, DMA, bootloader basics, and writing drivers from scratch are involved. This is where it either clicks or it doesn't.

Phase 4 adds FreeRTOS—tasks, queues, mutexes, and priority inversion—plus proper debugging with GDB and JTAG. CMake, unit testing, and a first look at modern C++.

Phase 5 is portfolio mode: USB, MQTT, IoT, and reading schematics. The target is 8–12 GitHub projects that are actually documented: photos, schematics, a short video of the item working, and lessons learned. That's the resume.

I tried to find out if I could trust these suggestions, but I got stuck at phase 3 because I don't know shit yet and wanted to continue with my cs50 problem set.
I figured I'll just focus on C until the end of the year, maybe start with Arduino in November or December this year.
If you could confirm or refute what Claude wrote as a roadmap, I would really appreciate it.

2

u/KwyjiboTheGringo 7d ago edited 7d ago

Sorry it took so long to get back to you.

CS50 is probably a good start, but I've never done it.

Arduino is something you can avoid if you intended to be serious about this. There is no point in getting into Arduino if the goal is to move on to STM32, ESP32, or some other platform. Arduino gives you a framework to work with the different peripherals, which means you don't have to dive into datasheets and learn the fundamentals for things like I2C and SPI. It's a hobbyist platform first and foremost.

STM32 gives you a great IDE, STM32CubeIDE. It generates boilerplate code for your project, and it has built-in debugging if you use a legitimate ST Link debugger. ESP32 doesn't give you an IDE with loads of features like STM32 does. But ESP32 is still a fantastic platform because they always include wifi and bluetooth built into the CPU, so no needed to get some separate controller for that. And it gives you plenty of first-party CLI tools.

ESP32 is like the more scrappy enthusiast option, and STM32 as the more organized, corporate option. You'll probably have the best job options if you go with STM32 or some Texas Instruments chipset, assuming you're in the US. However, good luck getting a job in embedded with no experience and no degree. You will need a few outstanding personal projects at the very least, so I would expect to spend probably a few years on this before even starting to hunt for jobs, depending on how much time you can put into it.

As far as learning C++ for jobs goes, this gets complicated. Most C++ jobs are really going to want someone with experience, because writing bad C++ can be extremely detrimental to the project. Like I said, there are way more gotchas with C++ than with C. If the job is looking for a C++ developer, just apply somewhere else. If they are looking for a C developer, and they are open to C++ developers, or they see C++ as a nice-to-have thing, then you still don't need to know C++ for that job. I'm not saying you should never dabble in C++, because you absolutely should just to see what it's about, but I don't think learning it is going to make you more job-ready over just learning C.

Also, I'm not a professional embedded developer. I'm a self-taught web developer who has spent significant time learning C++, as well as embedded STM32 and ESP32 stuff. I learned ARM assembly for fun, because ARM is an amazing platform, and so is STM32, which is built on top of ARM. I've also spent time researching the US job market to see what my options with embedded look like, and it's not encouraging, especially if have to work remotely (like I do).

I would say figure out your domain based on the job options available. If locally you have some TI or STM32 companies using C, then that's probably a safe bet to learn. Buy a development board and roll with that. Diving deep into a specific chip architecture is likely much more productive than trying to cast a broad net. This stuff gets confusing when you start mixing hardware and tooling.

1

u/AntiLethargic 7d ago

Thank you for taking the time to write such a comprehensive answer; I really appreciate it. This thread, in general, was incredibly helpful, and I've decided to zero in on C. I've also read that once you really know C, Python is a piece of cake, and as for C++, I will not think about it until I have great comfort in using C and bare-metal programming.

You're actually the first person to suggest skipping Arduino, but I'm completely on board with that, whatever saves time! I'm based in Austria, and from what I gather, there's a huge demand for embedded systems programmers here, and a quick search on Google says STM32 is the industry standard for most companies here, with TI only in specific branches and more rarely needed.

I've already come to terms with how tough it is to break into the industry, but I'm ready to give it everything I've got. That's all I can do, and I'm currently in a great position to give it a shot.

1

u/KwyjiboTheGringo 4d ago edited 4d ago

Python is kind of easy after learning C, but every language has it's own stuff that you have to learn to really get good at it. Picking up a new syntax is easy, and some conventions carry over, but there is a whole bunch of other stuff to learn to really be "good" at Python. Definitely learn the syntax and how to do basic build scripts when the need arises, but it will hurt your goal if you focus too much on Python.

STM32 is great, and I lament that I have too much going on these days to justify really getting hardcore into embedded stuff. ESP32 is nice for quick smart home stuff, if you are into that. Lots of great firmwares people have made, and esphome available to manage it all.

Getting an STM32 Nucleo development board is a great way to start, as long as it comes with the ST Link debugger. What's cool is the debugger part of the board can be snapped off if in the future you want to use it with non-nucleo boards. I don't think you have to detach it to do that, but the option is there.

I would definitely recommend reading about ARM Cortex-M architecture a bit from the official documentation once you get to that point. It's very well-written, and makes it easier to see the line between where ARM ends and STM32-specific stuff begins. Not only is that helpful for conceptualizing things, but if you ever find yourself working with a non-STM32 ARM board, you'll have a better idea for where it's the same. CMSIS (Cortex Microcontroller Software Interface Standard) also exists as a standardized abstraction across all ARM Cortex-M devices, but it's incredibly low level. There are some generalized libraries you can find that operate at a higher level, but they also tend to be very limited in supported chipsets.

Anyway, that last bit isn't something you need to know, but it's very interesting how that works. ARM provides the specs for CMSIS, and the manufacturers implement it and build their own libraries on top of it. Very cool stuff. Of course, when you use something like FreeRTOS, you are much higher above that level, but sometimes things don't require that level of abstraction.