Slashdot Mirror
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?"
An open source project is a good idea as a starting point. Pick away at something that already works.
:)
Where that isn't an option; I've always turned to O'Reilly books, and online tutorials to learn some new skills. I've written some tutorials for people who are interested in getting started with embedded electronics, for example. It's not hard to do, but you need to know about a half dozen things before you can get started.
I suspect you're either giving up too easy, or not looking online enough, or in the wrong places. For console emulation, there's a LOT of documentaion in the source code for MAME, and I am sure the others are similar.
Most of the people who are doing complicated OS programming have 10, 15, or even 20+ years of hacking away. Spending thousands and thousands of hours in front of a computer helps. Unless it's spent playing WoW, maybe.
..don't panic
Congratulations on earning your degree.
An entire generation of creative software people who had great ideas and deaf employers grew sick of their cubicles and started the open-source software revolution. They wanted to learn stuff and do stuff, just like you do.
Grab the code, read it, mess with it. Invest in yourself and assume no one else will.
My experience has been that you MUST teach yourself... especially if you work for the big cubicle farms. Teach yourself so you become better, so you keep your skills current, so you energize your imagination, and so you can go elsewhere when your employer enters the BRED ("Beancounters Rule Every Decision") Stage Of Atrophy.
BRED means that your employer is unlikely to pay for you to learn anything useful, especially not during the sunny hours when their BMWs and Porsches are in the parking lot. BRED means that good ideas die unless you happen to drink whisky with the CEO once a week.
Cowardly employees and consitutionally cheerful employees are easier to flog and much less frightening and expensive than people who want their employer to invest in them. People who have the latest skills aren't chained heavily enough. And when the expenses grow and the balance-sheets and Powerpoint slides don't show the Beancounters at the top any benefit ("any chance of getting more stock options"), you can bet that your Red Swingline Stapler is going to Bangalore.
Rich And Stupid is not so bad as Working For Rich And Stupid.
What large software project doesn't already start with a huge number of the pieces being already written? Nearly all modern software is taking building blocks, tools, libraries that exist or are bought and then using them to get whatever task done.
The vast majority of work is done this way so a program concentrating on that type of work would not be as relevant. Very little work is done actually starting from scratch on anything.
Like others have pointed out the best way to learn these other areas is with OSS projects and you don't need to pay a college to teach you how to get involved with them. You can do them on your own time.
As quickly as you can, get in a position of supporting your own code when it goes out into the world onto customer machines. This will teach you a profoundly important set of convictions that CS professors -- having never done the aforementioned -- are clueless about:
- bad: "Error: operation failed."
- bad: "Error 0x8009000b during update!"
- good: "Error: the mailslot update failed, probably because the mailbox is locked by another process; please contact technical support. (COM synchronize call returned 0x8009000b)"
Every low-quality error message equals ten calls to tech-support and probably two days of some support programmer's time and remaining hair pigmentation.Most programmers never acquire these convictions, because they never retain ownership of their code long enough to see the patterns that occur during field support. Hopefully you will be different... because honestly, in the long run it's easier to write supportable code than it is to have to check under your car for bombs every morning.
FATMOUSE + YOU = FATMOUSE
I think you missed two key points:
Pick something with realistic goals for whatever sized team you have (or self) and set goals
Design your work first
If you don't do those, you'll probably never learn to finish code. Setting goals with a team usually needs to be done based on time and skill levels of members. If it's just you, set goals for yourself and stick with them as best as possible. Don't worry too much about missing a date as long as you made progress towards your goal (but make sure to set a new goal).
Also don't be afraid to axe a project if you have to. I had a flight sim with some beautiful code in it (the blitter was fantastic... too bad blitters died with that era of hardware) and over a year of work and I killed the project even though completion was probably only a few months away. Why? because it had a problem at the core of the engine that was unfix-able and needed to be recoded from scratch to boost it to optimal framerates (specifically, I used virtuals at a low level not knowing that they have an expensive look-up table). I also had bought my first Voodoo card by that point and knew that was the future, not painter's algorithm and blitters. As sad as I was killing what I hoped would be a shareware quality flight sim, I learned so many lessons that it was worth the time spent.
I can't tell you how many kids I've talked to that want to make a commercial quality MMORPG or a 3D shooter in a few months...
I got to disagree with this "Also don't allow your self to become too specialized, you want a broad skill-set. Excessive specialization is leads to trouble." This is EXACTLY what I have done in my 24 yrs in IT and Software by working at a number of places and a lot of contracts. What employers want now IS Specialization, say .NET with C# and SQL and Exchange, etc. or J2EE with a certain Java server and certain appplication types. I see a LOT less jobs for folks like me who know software, hardware, networks, Project Management, Sales, different methodologies, 25yrs of IT technologies and I also hold an Advanced degree. I suppose my downfall is I'm not a Java or .Net "pro" as I was in Management and Architecture when these technolgies were emerging and never practiced them. I would say find a solid progrgramming niche and MASTER it but beware of the things that are coming to replace what you know. Today's hot stuff is tomorrow's warmed over crap.