Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Programming IT Technology

Advice For Programmers Right Out of School 469

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?"
This discussion has been archived. No new comments can be posted.

Advice For Programmers Right Out of School

Comments Filter:
  • by ckotchey ( 184135 ) on Monday December 11, 2006 @10:46AM (#17194976)
    I can say that I often felt the same way you did. I got my BS degree from a very good school, and yes, most of it was theoretical in nature (data structures, algorithms, big-O). While working at my job the last 15 years, I've worked on a wide variety of different projects, all requiring different skills in different areas. For me, this has worked out nicely. I'm glad I had a more general, wide-ranging initial background. I can adapt and learn different things as need be. I feel it makes me more broad and nimble and able to adapt to new projects that have come my way. I, for one, am more than happy that my education focussed more on the theoretical than the ins-and-outs of some particular language.
    Of course, this is a different path than some would take. I've seen people who work on, for example, file systems, and they have done nothing but work on file systems their whole careers. I'm sure the same would be true of people who work on other software projects, like word processors, spreadsheets, web browsers, and such. Often times I envy them the depth of their knowledge in their particular fields, but wonder if they would flounder if moved out of their element.
    To each his own. I guess that's a choice you make at some point - be the jack-of-all-trades, or the master of one. It all depends on your own tastes, and what you perceive as your job security down the road.
    I've learned C and C++, perl, shell scripts, and all the bits of tools here and there that I've needed through the years, and have bought books along the way to learn about other topics I've been curious about (Qt, GTK, Windows Game Programming, and more). One of the best things to come down the pike these last 10 years or so, in my opinion, has been Linux and the whole open source movement. Why? Because once and for all, if you want to know how works, you can simply crack open the source code and see for your self! In short, it's the best self-study tool available to you, and you can learn about ANYTHING you want.
  • by hey! ( 33014 ) on Monday December 11, 2006 @10:53AM (#17195098) Homepage Journal
    If you took a course in carpentry, you wouldn't be able to design and build a fine chest of drawers right away, although you could make dovetail joints and the like. You'd work under a master cabinet maker, who would start you off doing very menial things like rough sawing planks. Gradually he'd let you do some of the things you'd learned in school, like cutting mortise and tenon joints. Once you'd perfected these, you'd have absorbed a lot of other things like strategy; and he'd give you fewer tasks and more problems, e.g. affix this mirror to this vanity.

    The reason for this gradual approach is that there are multiple elements of craft: materials, patterns, tools and workplace practices. It takes at least ten years in any reasonably sophisticated craft for all these elements to fall into place.

    You could, right out of your vo-tech class, attempt a piece of fine furniture all on your own. And with enough determination, you would succeed. But you would not succeed fast enough to make a living at it. You'd waste a lot of material with trial and error. You'd waste a lot of time with the wrong tools, or unknowingly fritter it away because of a poorly organized workspace. All of your attention would be consumed by small problems of a single project, where a master craftsman may have several projects in various stages of completion.

    Speed, organization and economy are what set the master craftsman apart from the journeyman. You don't need mastery to do something original; but having it makes originality much more practical.

    Software is a somewhat different animal than carpentry. You may even have an idea that nobody has ever had before, one that is simple, yet original, that with journeyman skills you can bring to fruition. But you still have a decade or more of hard work ahead to achive your full potential.

    So -- separate out the meta problem from the problems at hand. If you have an idea for creating a console emulator -- that's a problem at hand, that even as a beginner you can make some progress upon. If, however, the problem is to become the kind of programmer that can create a console emulator, that's not a problem to be addressed by sitting down and writing one. It's one to be addressed by contributing to an existing project, under the guidance of somebody more experienced.
  • by EraserMouseMan ( 847479 ) on Monday December 11, 2006 @11:09AM (#17195330)
    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.
  • Re:Write new code (Score:5, Interesting)

    by Xzzy ( 111297 ) <> on Monday December 11, 2006 @11:27AM (#17195622) Homepage
    read LOTS of other people's code (DL a smallish OSS project at first, then larger ones).

    Especially here: []

    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.
  • by suggsjc ( 726146 ) on Monday December 11, 2006 @12:16PM (#17196366) Homepage
    Great points. I learned quite a bit from some very experienced people. However, don't get overly caught in the trap of likemindedness.

    What I mean is this. The people and environment you learned in/from is quite possibly ideal. However, just because you've got a room full of smart people that think things through doesn't necessarily mean that they will always come out with the best solutions. They will come out with great solutions, but will likely all have common patterns (a good thing to some extent).

    The only way to possibly improve that environment is to bring in some people that think completely differently than your core group of engineers and have them justify their thinking. Have a diverse group of people will create unique solutions and viewpoints...most likely the "innovative" ones.

    This isn't intended to contradict what you said. It is just a reminder that having diversity of thought is a Good Thing.
  • Re:digg around (Score:3, Interesting)

    by fbjon ( 692006 ) on Monday December 11, 2006 @12:16PM (#17196380) Homepage Journal
    findProject :: [Project] -> Project
    findProject [] = []
    findProject (p:ps)
    | not ((checkProj p)=="suitable") = findProject ps
    | otherwise = p

    -- now just implement the trivial function checkProj::Project->String and off you go:

    findProject sourceforge

  • Wrong priorities (Score:3, Interesting)

    by mabu ( 178417 ) on Monday December 11, 2006 @12:24PM (#17196494)
    A good programmer will start with a "problem" and then design a solution.

    It sounds to me like you are looking for a solution without identifying the problem. Because there are so many programmers like this, ones who feel compelled to create something for the sake of creating something, for their own ego or amusement, in lieu of any real world application, the industry is filled with crappy technology that doesn't serve any significant purpose. So let me be the first to discourage you path before you even start and add another dingleberry to the crop of mediocre technology that's out there that will fail.

    No disrespect, but you're going about it wrong. If you want to program a console emulator, hook up with the teams online involved in that. Oh you want to create your own? This kind of thinking won't get you anywhere. The real cool technology is what you learn from other people through experience both in coding and (most importantly) through an *understanding of the application and the market you're addressing*. So what you need to do before anything else is not whine about how you haven't created the next Halo, and figure out what field, in addition to programming, in which you're an authority, and what void in that field can you develop something that addresses a real need or solves a problem, and then and only then, should you be asking people how to develop such technology.

    The best software in the market will have always been created by people identifying a niche, a need, a problem, and then designing software to address it. Not the other way around.
  • Re:Write new code (Score:3, Interesting)

    by tobiasly ( 524456 ) on Monday December 11, 2006 @12:35PM (#17196656) Homepage
    read LOTS of other people's code (DL a smallish OSS project at first, then larger ones).

    You've gotta be careful with that approach. I've seen some very poorly-coded OSS projects, and they tend to be the smaller ones. Just because it's open source doesn't mean it's well-coded!

    Rather, it may be more helpful to look at large OSS projects, but one where you can concentrate only on a smaller module. Something like Apache, Subversion, the Linux kernel, etc. These projects tend to have much better coding guidelines in place, and their development lists are very active with good discussions on best practices, refactoring methods, etc.

    The smaller projects are more often run by just a single person or two, which means that they aren't as diligent in discussing changes beforehand and following well-established development practices.

  • by Dasupalouie ( 1038538 ) on Monday December 11, 2006 @01:19PM (#17197346)
    Hi, I just signed up so I can share my honest opinion.
    I recently just graduated from a technical school 2 years ago completing my Computer Engineering Technology diploma and finished my Bachelor of Applied Information Systems Technology degree. You're probably going to look at me as nothing and say that my papers are clichéd compared to your CS degrees, but I can say I am glad I went this route instead of going the CS route.
    There are two key differences with a university program vs a techincal program. Universities focus more towards theory rather than hands on approach. While technical programs focus more on real life situations any developer would be faced with. Universities would be focused on what is the purpose of using things like linked-lists or algorithm's for searches and how to make it better and ignore how to apply the syntax to actual applications. When I was doing labs, I never learned anything from scratch, they had the walls full of library posters so we knew which libraries to use and they gave us small sample programs to start us off.
    Just recently I sat in a technet session in a room of 50+ people and the M$ guy asked the entire room "Who has a CS degree?" and no one put up their hand which was surprising. But one important fact is that you ALWAYS have to dedicate yourself to learning, especially in IT. I am always learning new things to keep myself up-to-date with the market so I always have opportunities for myself. I graduated with mostly C++, VB.NET, C#.NET and SQL knowledge, but at my occupation I am a COBOL developer and I am currently learning from books and online courses.
    I would say that if you want to become a researcher or theorist, go with the university route, but if you want a job right off the bat, go for the technical route but be faced with updating yourself with courses every couple of years. It is likely for a person with 2+ years experience with anything in IT to get more priority over a CS grad when it comes to getting hired. No matter what, you can't avoid the fact that you always have to teach yourself and learn on your own. The professors are there to set you in the right direction and you have to love what you are doing.
  • Some advices (Score:2, Interesting)

    by rnd0110 ( 805179 ) on Monday December 11, 2006 @01:54PM (#17197824)
    Whatever you do, try to undestand the root of the problem, the larger picture, understand why certain thing need to be written at all. What is the place of your component in the whole. What the whole do.

    Its very easy for a programmer to bias toward "cool" things. With some experience thinking on the problem you solve you will start to get the pleasure of doing things in harmony with the objectives of the whole system.

    Do not try to learn too much: programming is such a field that one need to learn ones own way. Try to be open to new things, intuition will grow with years of experience.

    Programming is highly intellectual work and is often rooted in deep insights to larger extent than on logical reasoning.

    In other words, try gather your own wisdom. Perhaps, its greater asset for programmers than remembering numerous patterns and idioms.
  • by eric76 ( 679787 ) on Monday December 11, 2006 @02:16PM (#17198150)
    When I first got into programming in 1972, I never heard of a "Hello, World" program. In the 70s, I suspect it was more common to write a first program that printed out your name.

    The first time I ever saw a "Hello, World" program was in the 1980s.

    I wonder when they originated.
  • by Dasupalouie ( 1038538 ) on Monday December 11, 2006 @03:57PM (#17199576)
    I am not whining about pratical job skills. I am just saying you NEED pratical job skills to get anywhere, do you expect us all to be picaso's without paintbrushes? Programming is an art and if you just expect me to be a like robot typing in code, I wouldn't end up with a developer job. What I see is that the majority of people that enter university just care about salaries, and also tuition is another factor of the idea "you get what you pay for" and they expect themselves to be spoonfed but end up failing because they are not prepared to take dedicate themselves to a career. I am not saying professors shouldn't get us ready solely as "9-5 slaves" (you need to rethink the career you took if you're refering IT jobs as slavery). I've seen students fail because they followed that ideology.
  • by heroofhyr ( 777687 ) on Monday December 11, 2006 @06:52PM (#17201890)
    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.
  • by tepples ( 727027 ) < minus pi> on Monday December 11, 2006 @08:37PM (#17202806) Homepage Journal

    There is never, under ANY circumstances a justifiable use of a "goto".

    Without goto, how would you do the following?

    • Break out of nested loops
    • Build exception handling macros in C, on a handheld or embedded architecture where C++ exceptions have been shown to have too much overhead
    • Build a coroutine simulator in C or C++ []
    • Code in assembly language for a microcontroller

"When the going gets tough, the tough get empirical." -- Jon Carroll