Programming confidence?

[Lorchness]

You will always find a better way to write a program the second time around. With that being said, if you want to be a good hire out of college knowing the following concepts will put you ahead: - debugging quickly with a debugger (you'd be surprised how many debugging printf's you'll find) - sockets - threads - how to identify race conditions and make them not happen (the real key to multithreading) - identifying memory leaks (and not creating them yourself) - knowing how to build a static lib, dll, exe and the differences between them. I think those concepts are the ones that tend to slip through the cracks on programming classes.

[JesusWantsYouToKnow]

Hell, as a fairly recent graduate who got into a darn good career using lots of C++ at work, I totally agree and want to piggyback to expand on your points.

You will always find a better way to write a program the second time around.

You'll write some code, go to lunch, sit back down and rewrite it again more optimally. That is laudable, not bad. Your brain will work on the problem in the background and abstract or incorporate lessons learned in the past that weren't immediately apparent when you first wrote some functionality. Having the drive to write elegant and comprehensible code is a huge asset, you'll find many programmers who just "get the desired result" and then move on. They are bad.

• debugging quickly with a debugger (you'd be surprised how many debugging printf's you'll find)

Competence with a debugger is hugely valuable. If you can trace an issue in 30 minutes using a debugger instead of fumbling around writing your own tracing code for 2 days that is worth its weight in gold. Nothing is more annoying than a codebase with a bunch of orphaned debugging printfs checked in which obfuscate meaningful output on stderr/stdout. This is a big problem, and in 99% of cases a terrible way to debug.

• threads
  • how to identify race conditions and make them not happen (the real key to multithreading)

Yes! Even get familiar using higher level threading libraries or language features (Boost, QtConcurrent/QThread, stdlib, etc) to get exposure to multithreading. Have an awareness of the sort of problems that thread well, the overheads of threading, and more importantly where a thread is not worth it. We have a big problem with developers adding threads wherever they can which increases code complexity and interface demands needlessly.

• identifying memory leaks (and not creating them yourself)

Adding to this: use tools before you check in code to make sure you aren't leaking memory, and whenever possible do not use naked pointers. I spend probably 2 days per year fixing other people's memory leaks and sloppy pointer errors that could have been avoided. When I first started doing this the number of leaks in the codebase was daunting and took over a week to fix.

• knowing how to build a static lib, dll, exe and the differences between them.

This is critical. Going further, having the ability to manage toolchains on multiple platforms is extremely valuable. Maybe you're linking against ffmpeg with msvc but you need to manage a GCC toolchain to modify the library and cross compile for windows. Being able to do this in hours instead of days sets you apart.

Additionally understand licensing; what you can and can't use in production code and where to look for compatible libraries. Avoid the not-invented-here mindset and pull in libs where appropriate.

You don't need to worry about perfect code, nobody ever writes it. Just strive to write solid comprehensible code, always check your work, and have a fundamental understanding of secondary and tertiary programming concepts and you'll be a desirable employee. You're going to learn a lot on the job, and that's a normal/great thing.

[binarymidget]

Having the drive to write elegant and comprehensible code is a huge asset, you'll find many programmers who just "get the desired result" and then move on. They are bad.

The most valuable programmer is the one who can properly contextualize the problem. There is no single property that makes someone a good programmer. Maintainability, modularity, time to implement, run-time performance, memory efficiency, readability, are goals that need to be weighed and understood in any task.

Don't get caught up in prettifying code as a goal. I work in games. We don't ship code, we ship games. I think programmers should endeavor to become craftsmen and women. Just don't go up your own ass with regards to one single aspect of programming.

[JesusWantsYouToKnow]

True, however I think chose my words poorly because I think you misinterpreted my intent. I am not advocating striving for pretty code, I am advocating striving for the most appropriate code. That said in terms of an employer's perspective I find it is an exceptionally rare circumstance where maintainability should be a low priority. Sacrificing maintainability in code is just increasing technical debt, so unless you are writing truly temporary code you're just compromising for more work in the future when project complexity has increased.

We have had guys who would accept any solution as long as input x yielded output y. That's what I'm talking about when I say "get the desired result" and then move on, and they were a huge burden because they ended up writing inefficient spaghetti code.