C++ (or C) has been and will continue to be pretty much the only game in town for embedded.

For me it's jeans and T-shirts every day, regardless of their policy. It has been since I started work in 1983. Formal attire is when the T-shirt isn't stained. It just goes well with the pony tail and Snuffy Smith beard.

You don't have to give a "true" answer to the security questions. You just have to give an answer you remember. When does your drivers license expire? On your birthday in 2028. What's your electric company's account number? 12345. And the best way to keep it all straight - a password manager program like KeePass.

I don't know if this is Mob programming or Design by The Giraffe Committee but the way it often works here is I get 15 emails a day about how everyone thinks it should work while I try to keep up with implementing what they want.

I am self taught in Basic as a kid on a Commodore 64 and later a Trash 80. After high school I went and got a BS in Electrical Engineering and that came with some actual classroom training in Basic, Fortran, and assembly language but the focus was not computer science. Around that time I built an Apple II clone and Pascal was the hot ticket so I took a night course in that as well as COBOL (who knows why?). I was also employed working on diagnostic software for high volume printers in Forth and C. I decided I wanted an MSCS degree so I went at night. Learning the theory was worth it for me. Thirty years later I'm still working on embedded software but these days it's mostly C++, assembly and Python. I fool around at home with some robotics and when I retire next year I plan to do even more with that.

My only advice is that learning the "how" of programming is relatively easy. In fact it's expected that you be able to pick up a new language, IDE, VCS, framework etc. on your own pretty quick. But in my opinion what separates the men from the boys and allows you to go further faster in a software career (if you want to stay technical and not be a manager) is a strong theoretical background. And I think the "why" can be harder to learn on your own. For this reason I don't think I would recommend boot camps to someone who already can program a bit.

+1 for KeePass - I love it

+1 for Python

I think the biggest problem with good code reviews are finding reviewers that are familiar enough with the problem or subject matter to give good feedback. Since we are one deep in all positions where I work and everyone is working at 120% capacity that isn't easy. Without that code reviews degenerate into trivial complaints about variable naming, code factoring, and the like. For me having the time to do good unit testing is more valuable than code reviews.

I don't care what way you do it as long as it is not: if (something) { DoA() } Yuck! But seriously - if the biggest problem your project has is where people put or don't put the braces you are doing pretty good.

That is sort of like asking "what is the best book to learn about PC programming?". There isn't one because the field is broad. If you feel pretty good about C especially pointers and bit operations you are probably fine there. Frankly very little is done with assembly these days. Many embedded programmers are actually Electrical Engineers (I am). I think the one thing that defines embedded programmers is a deeper understanding of computer architecture and operating systems. Every RTOS implements the same things differently so without knowing what one you will use understanding POSIX is a good start. I'm not an embedded Linux fan. You'll probably want some type of background in serial communications or networking. You also need to think about the domain you want to go after. A motor control guy is much different that a video processing expert. Same with processors. If I had to pick a good processor to learn it would be ARM because that architecture is used in many applications. There are lots of embedded book lists out there. Try www.ganssle.com/bkreviews.htm Another thing to think about is debug tools. Debugging generally is not like it is for a PC. Baseline is JTAG debugging but a good embedded guy can also use a multimeter and oscilloscope. A great one can use a logic analyzer. Once you narrow your focus a bit I would go research the relevant technologies that you are interested in. I'd also go buy myself a SBC Development kit preferably one with a good manual and a prototyping area to play around with, maybe even a JTAG interface. PIC kits are fun and there is lots of learning info out there but don't expect to find lots of jobs with them. Good luck.

I took BASIC and COBOL on a PDP-11 when I went to community college back in the mid 70s. I bought an Apple 2 when they first came out while working on a 4 year degree. Between the Apple 2 and Pascal I was hooked. I was studying electrical engineering at the time and learned a little about assembly language by punching hex codes into an 8080 development board. As far as programming goes, I never looked back. Graduated in 1978 then went on for an MSCS and have been doing embedded programming since 1980. I also owned a TRS80 Model 100 which was one of the first (the first?) portable computers. It had built in BASIC and 32K or so of persistent storage, even had a text editor and some simple business apps built in. Unfortunately what used to be tremendous fun for me is now just a way to earn a living. I'm going to retire soon and hopefully start doing it again for enjoyment instead of for pay.

I gave up last week, took early retirement, and waved goodbye with one finger.

I understand completely. Last week I told them I'm retiring (I'm only 55). I wanted to work another 5 years or so but I just can't stand engineering any more.

Don't lose sight of the fact that the main purpose of what you study is to make a living. The Computer Engineering degree will probably create more opportunities for you simply because it has the boardest scope.

+1 for me on the Commodore 64. Soon after I bought myself a Trash-80 and I thought I was really living large until I built myself an Apple II clone. It was so much fun back then.

Shark Tank

As an older embedded developer I feel your pain. The technologies that drive the need for "big iron" when it is not needed have hardware and software costs that go right to the bottom line. Unfortunately many new engineers only know how to approach a problem with a sledgehammer. Today's students would be well served by a semester or two doing projects for PICs or 8 bit microcontrollers no matter what field they go into.

What I like best about Excel is the ability to sort and do metrics and statistics easily. So for low cost simple issue tracking I prefer Excel over just a plain editor. With Excel the world is my oyster. If project managemnet is the main thing then I like Microsoft Project. The best heavyweight issue tracking system I ever used was home grown by a previous company in Lotus Notes. I don't like JIRA, although I have only used it a few months. It seems like too much flash and not enough of what I need - searching and sorting primarily. ClearQuest was also a monster but seemed easier to use than JIRA.

That is why I alias goto to JMP!