Who should learn unmanaged code?

Larsenal wrote:

Do you think I'd be shooting myself in the foot if I didn't make sure I knew unmanaged windows programming of some sort?  While managed code may be a big part of tomorrow, will I get into trouble if I don't feel totally comfortable with yesterday?

Funny you should mention this. Jeff Atwood and myself have been having a conversation about the importance of learning C/C++ in a managed world. He's more 'anti' and I'm more 'pro' C/C++. I don't think there's a boolean answer to the question. I plan on commenting more over on his blog, but my general stance is that the current abstractions, the .NET Framework, Java runtime, even to a certain extent Smalltalk, are incomplete enough that you still have to know HOW the computer works if you are really serious about troubleshooting your code (or more importantly, other peoples code). I think that C/C++ get you a little "closer to the metal" and force you to think about where you data is going and, more importantly, when it is going away.

So you took the red pill and decided to become a software developer?

If you are not into Drivers stuff I think you can live with managed code. And I think it's difficult to be outstanding in everything so pick your field now. Your academic knowledge of unmanaged code will only help you in the managed world, but being an expert is not required.

Good luck.

Lazycoder2, thanks for the link to Jeff's blog.  I'll read it more when I haven't got so much work to be done at work.

I started with basic and assembler on my C64 8bit, then my Amiga with a motorola 68000 - assembler, then assembler with 8086, then from that point moved into Pascal, C, C++, Java, Visual Basic 6.0 and now C#.

Let me tell you this, the low level stuff is the most important if you want to know what you are actually doing at the higher level.  When something goes wrong you know the internals and why that something has gone wrong.

My CS gave me my the 8086 assembler, Pascal, C, C++ and Java skills.

The rest were self taught.

I also did 68HC11 - which is a microcontroller

Don't stick with the one platform either, as I have had experiance with both Windows and Unix.

Larsenal - I'm straight out of college as well. PLEASE, by all means - get the design patterns book.

BUT FIRST. You will find the design patterns book a bit vague and/or abstract. Take my advice, get this book 1st. "Head First Design Patterns".

This book is completely based off of GoF's and is certainly geared toward our age group and skillset (assuming you're 24ish and know OOP).

I cannot stress how important these books are. For one, they will help you establish a "protocol" or language for communicating with colleagues. Dude, I could go on and on.

Just spend the $100 on these two books.

-chad

In recap - sure you could go out and learn assembly, or you could go out and C++ it til your eyes bleed --- BUT DONT.

Go with the Design patterns books. Because dude, lets be real - if you are in here asking about unmanaged code use -- you are in no position to be applying for hardware develoipment positions.

Which more than likely puts you in my category. Client Server DataBase code monkey.

Learn assembly later. C++ too.....

for NOW -- focus on being hired - and making a living.

I'm not saying there is anything wrong with C++ and Assembly. I'm just being practical for our friend here....

-chad

Thanks for the input.

A while back (2001?) I set out to teach myself MFC.  I just went back today, fired up VS with a new MFC project and was like, "Whoa, it's been a while" followed by "C# is a wonderful thing".

Just ordered the suggested starter book.  I'll get the other one once I'm done with that one.

Hopefully I'm not with the one lone Amazon.com reviewer who found it to frilly.

Sorry to reccomend something and kinda drop off the face of the planet for a while.
The design patterns book is important.  The GOF book and maybe a language specific one is good.  Design patterns should be a part of the college cirriculum, but sadly, none do.
Just the other day I used design patterns.  Instead of solving the problem from scratch, I thought and said, "Oh!  This class should be a singleton, along with a factory interface dealy!"  The code that came out of this line of thought was simple to write, and worked the first time (really).
Also, you'll run into the concepts and vocabulary used by the GOF after a while.  Even if you don't read the book, you'll learn the patterns by yourself (often the hard way...)
Anyhow, sorry to rant on about it...
And to be honest, I'm an intern for a software company, but I've been far beyond most college courses I have to take.

The bottom line is you're already using patterns. In fact, your ALWAYS using them. The Design Patterns book is meant to catalog a collection of particular patterns in software architecture which have been proven to work. Honestly, its great! In particular, why reinvent the wheel? This way you can leverage the expertise that "gurus" having been using since the early 90s. Also - here's my favorite part. Think of this scenario. DoomBringer and I are both working together. All DoomBringer has to say is, "Oh!  This class should be a singleton, along with a factory interface dealy!" BAM!! I know instantly what DoomBringer is talking about. Its extremely powerful when two developers can convey an entire code structure with 1 sentence. No whiteboard, no bull(I need to watch my language) UML drawing the same drab OO specs. Just communication -- and trust me. If you cant communicate well with others - find another field. (But you know that already.)

On the unmanged code tip however -- If I can ever find some hobby code time. I swear I'll crank out an WMA to MP3, or WMA to OGG application =). I think the cool thing is that I can probally call managed code for decoding WMAs. Which only leaves the OGG and MP3 as unmanaged...

-cseeger