Advice For Programmers Right Out of School
ari1981 writes "I recently graduated from school with a CS degree, and several of my classes were very theoretical in nature. There was some programming, but it seems not as much as in other schools. I'm currently working at a company where I'm doing primarily c/c++ app development on unix. But as I read slashdot, and other tech sites / articles, and realize for some of the software being written nowadays, I would have absolutely NO IDEA how to even begin writing it. I remember first time I saw them, I thought console emulators were really cool. After my education, I have no idea how someone would begin writing one. With the work I'm doing now, it doesn't seem I'm going to be using (or creating) any of the really cool technology I hear about. How did everyone here begin learning / teaching themselves about different aspects of programming, that they initially had no clue about? How did you improve? Programming on your own? Through work?"
The problem with getting your code off of internet tutorial sites is that that code is crap. It is good enough to serve an illustrative purpose. I can't tell you how many times I've been working with somebody else's code and thought to myself, "Boy, that's sure a lazy approach." Or, "What an awkward way to do that." I ask the developer and they just puff out their chest, "Well I got that idea from QuickAndEasyTutorials. And those guys are smart."
Every website has different naming conventions for their code. Some have you use the IDE's designer a lot, some not at all. The resulting software is such a patchwork of Internet examples it makes me puke. And worst of all, the developer think's he's the stuff because he figured it all out without any professional training.
The best thing I ever did was to work for a couple large companies that did cutting edge software development. They had a team of real engineers with many many years of experience. They understood the value of Best Practices. They had documented development standards. They forced us developers to follow the conventions. The software I write now is very much what I learned then. I own my own software dev company now and I absolutely love writing software. People who work with my code are thrilled by the consistant patterns and well-thought-out design.
The best software is designed well by experienced engineer-minded professionals. Don't fall into the trap of thinking that you can learn much of value from Google. Google is only a basic starting point. People who cut their teeth on Google end up being self-taught hackers (as in, ugly, hacked up code). And it shows. Want to be a great developer? Work under highly-skilled and experienced professionals.
read LOTS of other people's code (DL a smallish OSS project at first, then larger ones).
Especially here: http://thedailywtf.com/
Learning what not to do can be as valuable as learning what you should do. The comments can be useful too, the problems get picked apart pretty extensively and can be quite educational. If anything you ever write never ends up on a site like that, you can't be that bad off.
I decided to reply here rather than anywhere else because I have several things I wanted to say. First, and most directly relevant to this branch of the conversation, is that the memory management of Java is not always as great as everyone who bashes C++ thinks it is. I recently spent six months working out the bugs in a J2ME MIDlet only to discover that it was still vomiting blood after a random number of hours because of a poorly coded garbage collector causing a null pointer exception. No way to fix it, no way to disable it or go around it, maybe $20.000USD (including salaries, test equipment, and repeated calls to Nokia and Sun's support centres for absolutely fruitless attempts by their people to figure out what was wrong) down the toilet on the project as it had to be scrapped because of a buggy implementation of the GC. Nokia's advice? "Tell your customers to buy newer mobiles with an updated version of the Java virtual machine." I love Ruby, and it's possibly my favourite language for proof of concept and quick testing, but I've had similar problems since 1.8x with variables local to a function suddenly disappearing halfway down the function's code because Ruby decided arbitrarily that they weren't necessary any longer...and the only way to avoid them being recycled and losing the data was to explicitly copy them to another variable and use that instead. It's not a language I'd rely on for mission-critical programming--yet. I'm checking the site once every week or so to see the latest status on 2.0.
As for C++ pointers being a "hassle" to call new and remembering to call delete on, all you have to do is use the auto_ptr provided by the Standard Template Library, which is 100% compatible with any C++ compiler that supports the Standard (GNU's ISO99 C++ support is fantastic), or use the safe pointers in the Boost Library. They'll know by themselves when to delete without you ever having to mess with it--and you can rest assured that if the program throws an exception and exits a function abnormally there's no pointer mess leftover because they'll call the deconstructor automatically in the stack unwind. The fact is, there are features in C++ that most people either don't use because they don't bother to learn them, or simply have never heard of. Vectors, strings, hash maps, associative arrays, linked lists, safe pointers, throw-catch exception handling, etc. Yeah the code can get a little harder to read, but that's the programmer's fault rather than the language.
My advice to the OP would be that the best experience comes from the workplace. You'll be given assignments for things that seem impossible to you and that you'd never be able to do. And sometimes you can't do them. But when you're faced with a challenge like that you'll find yourself being forced to become an expert on the subject very rapidly. And experience and confidence like that are hard to come by easily or as quickly in an academic environment.
brandelf: invalid ELF type 'KEEBLER'