Slashdot Log In
Advice For Programmers Right Out of School
Posted by
Hemos
on Mon Dec 11, 2006 10:26 AM
from the words-of-advice-for-young-people dept.
from the words-of-advice-for-young-people dept.
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
|
Log In/Create an Account
| Top
| 469 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
My Advice (Though You May Not Agree) (Score:5, Insightful)
(http://slashdot.org/~eldavojohn/ | Last Journal: Tuesday October 16, @03:26PM)
While this wasn't what pulled me into computing, it may be your addiction. Here's what I would suggest doing--take a well developed open source emulator (you know, like an NES emulator [sourceforge.net]) and pick apart the source tree. You might find that the code is obviously doing some low level translation of the ROM which essentially changes its executable language to be IA32 or some such thing. It may be that you don't understand the architecture of the NES itself and therefor you can't really develop this yourself. So there's some insider information you lack but it will still be a good learning experience and may prompt you to figure out how to A) dump ROMs and B) reverse engineer a console architecture. Even if these are fruitless searches, how far you're willing to go will be a good indicator of whether or not CS is for you. Yeah, I hate to say this but I know people with CS degrees that simply don't have the debugging mentality to be programmers. A simple test is to think back to the times you saw something neat. Did you ever have a strong internal urge to find out how it worked or to try and modify it to augment its task?
Fear not your own ignorance. Only fear your acceptance of it. I am confident that if I wanted to build an emulator I could. I personally find other things more interesting but you just have to buckle down and really pick it apart and look for answers. As I said above, these emulators might have proprietary reverse engineering so these backwards black boxes might not be the best place to start as you may be met with frustration. On top of that, the newer consoles are now fighting a war & implementing encryption scheme which just makes the emulator all that more complicated. Why don't you pick a project like Firefox? Get the source, find out what the common developing environment is and step through the code when you visit a page. That's where it all starts.
Most importantly, you don't need to do everything from the ground up. It helps to know everything that's going on below the abstractions you sit upon but you don't need to think about that every time you write code. Learn to use libraries & frameworks. To quote Salvador Dali: "Those who do not want to imitate anything, produce nothing." I couldn't start writing an emulater either. But if I looked at the source trees and structures of the more popular ones out there, I'm damn sure I could figure it out. That confidence I have in myself is infallible and that's important to me. Sorry to sound like Dr. Phil but you asked for my opinion.
There are different tricks to different applications. Some are more simple than others. In my opinion, the less tricks you need to get started in a language, the better. Because we're not all world class magicians (although every language has some players that could rock your world in said language). This is why Java, while not as efficient as C, is probably taught to you first. There are very few tricks one needs to know in Java. But you know what? Java is still quite useful. Those responsible for implementing it did a decent job and now the web service programmer needs to know very little about them because configuring them has been abstracted and made easier by many UI & IDE tools out there. But web services are a very practical and widely accepted concept out there today. In fact, pay the bills by writing some very inane web se
From the Ground Up? (Score:5, Insightful)
(http://bbaggins.net/)
There has only been one program ever written from from scratch, and that was "Hello World." Everything other program has been cut-n-pasted from that.
(Well, that's true at least from the advent of "high level" languages like "C", but it's probably true with respect to most Assembly programs too.)
Re:digg around (Score:5, Funny)
(Last Journal: Thursday January 06 2005, @07:29PM)
You, sir, must not be a true programmer. If you were, you would know that goto has long been considered evil. Instead, you should make sourceforge into a function, and call it as such: sourceforge().
Write new code (Score:5, Insightful)
write more code of your own
write more code
read more code
read LOTS of other people's code (DL a smallish OSS project at first, then larger ones).
rinse, lather, repeat.
If you're concerned that you're not learning "cool new things" on the job, learn them off the job. Your destiny is your own, as hokey as that sounds...
love your work.
Re:Write new code (Score:4, Insightful)
That's pretty sound advice.
Re:Write new code (Score:5, Informative)
Re:Write new code (Score:5, Interesting)
(http://tru7h.org)
Especially here: http://thedailywtf.com/ [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.
Books, Books, Books... and Notes. (Score:4, Insightful)
(Last Journal: Tuesday January 16 2007, @10:33AM)
You may also want to read is The Elements of Programming Style by Kernighan and Plauger. I've only skimmed through it, but it talks about writing code so that its function is obvious to other programmers. (Trust me, few people can look back on code they wrote five years ago and remember why they wrote a particular routine that way.)
Another book I would recommend is Structured Computer Organization by Andrew Tanenbaum. It will take you from circuits and logic gates, through how a CPU works, to how Operating Systems work.
The only other recommendation I would make, is to become an organized note taker. The top programmer in one of the companies I worked for was such a person. If there was a question with the way something worked, he could pull out a notepad, flip through a few pages, and tell you what issues he was dealing with in the code, and why he made certain design choices. If he got an error message, he would write it down, and what steps he used to correct it.
I'm sure others have mentioned continually educating and upgrading yourself, and that an IT career these days means having lots of short term jobs, rather than a single lifelong job, joining clubs and associations, etc. The only thing I would add to that is Practice, Practice, Practice. Write code until it is second nature to bang out high quality code.
Re:Write new code (Score:5, Informative)
(Last Journal: Monday October 22, @12:27PM)
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...
Refund? (Score:4, Funny)
Sounds like you should ask your school for a refund.
Re:Refund? (Score:4, Funny)
(Last Journal: Saturday February 25 2006, @11:02PM)
Re:Refund? (Score:5, Insightful)
(http://www-cdf.fnal.gov/ | Last Journal: Wednesday June 13, @11:39AM)
Re:Refund? (Score:4, Insightful)
(http://theravensnest.org/ | Last Journal: Sunday October 07, @07:05AM)
A real Computer Science degree should have taught him the principle of Turing-equivalence. It should have had at least some assignments expressing algorithms on Turing Machines, Unlimited Register Machines, Petri Nets, Lambda expressions, etc. The principles of converting between one universal mechanism for computation and another should be deeply ingrained. How do you prove that a model of computation is universal? You implement an emulator for an existing universal model of computation (typically a Turing Machine) in it.
That covers the basic theory. Then you need to understand how a real computer works. Any half-decent CompSci programme should have explained the basics of a relatively modern architecture. From there, it's just a matter of learning the instruction set, memory layout, devices present and how to communicate with them; anyone who actually gets a CompSci degree should have the ability to read the relevant documentation and understand the architecture.
Past the theory is implementation. The first bit of that is understanding how to parse an instruction stream. Any CompSci course that doesn't cover the automata theory required for this should be regarded with suspicion. Once you've parsed the instructions, and understand what they are meant to do, it's just a matter of implementing functions that handle them, which is time-consuming, but not conceptually difficult.
Now, the emulator produced using these steps would be slow. I would estimate between 1% and 0.1% of the native CPU speed. Fortunately, on a modern CPU that is fast enough. If you want to get in to dynamic (JIT) recompilation and caching, it's a little bit harder, but the compilers course (plus some reading of the documentation for the target architecture) should provide the requisite knowledge.
To me, it sounds like the original poster has sat through a Computer Science degree and managed to gain some of the knowledge but none of the understanding that it was meant to impart.
Re:Refund? (Score:5, Insightful)
(http://127.31.33.7/)
At most schools, Computer Science is mostly the study of algorithms. My school, however, had a degree called "Computer Science and Engineering." In this program, students learned not only algorithms, but also digital logic, electronics, and computer architecture. Students had to design an entire computer using basic digital logic components (by first building multiplexers, decoders from and/or/not gates). Then we had to write an emulator for a simple computer. Finally, we wrote a compiler/linker for the emulator.
FYI, the BSCS&E is a significantly harder program than the B.Arts in CS program. While we were taking extra physics and EE courses, the CS people were taking French, Theatre, and other easy courses that had real, live girls in them. We got the better education, sure, but I'm not sure it was worth it
Get a job in an advanced development team (Score:5, Interesting)
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.
Starting is HARD. (Score:5, Informative)
(http://www.xdesignlabs.com/)
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.
Re:What school did you go to? (Score:5, Informative)
(http://harun.abd.assami.googlepages.com/ | Last Journal: Thursday November 25 2004, @12:07AM)
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.
You just need practical experience (Score:5, Insightful)
(http://www.intelligentblogger.com/ | Last Journal: Monday August 27, @11:47AM)
Yes you do. You just don't know it yet. (Assuming your school wasn't out and out terrible.) There's a huge divide between theory and practice that every new programmer has to overcome. The best way to overcome it is to dive in and learn about the practical designs of today's technologies.
For example, you want to write an emulator. Many of the early game consoles were based on the 6502 microprocessor. If that scares you, it shouldn't. Read this webpage:
http://www.obelisk.demon.co.uk/6502/ [demon.co.uk]
It will introduce you to 6502 assembly. It explains not only the text commands you can use, but also the hex codes that will be output by the assembler. You can get an assembler like DASM [atari2600.org] and try it out for yourself. Try writing a simple program like: Next, run it through the assembler. Open it in a hex editor [handshake.de] and you should be able to see the direct mappings between your code and the program output. If you target a specific platform like the Atari 2600, you can use an existing emulator with a debugger like Stella [sourceforge.net] to watch your code execute line by line.
Remember, learning doesn't end when you exit school. It just begins. So start digging up everything from reverse engineered documentation to documents put out by standards commities like the IETF's RFCs, the W3C standards, and the ECMA standards. You'll gain a much greater appreciation for how things work after you take them apart and understand them.
Invest in yourself. Assume no one else will. (Score:5, Informative)
(Last Journal: Sunday November 06 2005, @05:24PM)
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.
Re:Invest in yourself. Assume no one else will. (Score:5, Insightful)
I don't know where the big cubicle farm comes into play, here. Working as an independent contractor has led me to the exact same conclusion. Always learn, ALWAYS teach yourself. It's pretty much ALWAYS worth it.
And don't limit yourself to Comp Sci, either. For example, I'm currently training to be a private pilot. Why? I don't know, and never do. It's fun, I like to fly, and having more skills and experience has always paid me well. One of the best things you can do is to spend a few bux at the local Barnes and Nobles on a subject you know little about. B & N is a goldmine of business plans, technology information, and income opportunities!
I've attended numerous business courses in salesmanship and capital investment. They've also served me well, and helped me identify a startup with real potential, and gave me the skills to sell my way into partial ownership of the company. (that's now growing by leaps and bounds)
Another example - I did some research into using PHP as a scripting language for an SMTP daemon. I wanted to do some dynamic proxying that I didn't see elsewhere. I got it to work, using PHP as a script under xinet.d on Linux. Although that original business idea went nowhere, I used that very same software code to build a daemon that today transfers many gigabytes of data in a distributed software database, with about a thousand daily users.
Having more saleable skills will always pay.
Re:Invest in yourself. Assume no one else will. (Score:5, Insightful)
(http://www.christophermahan.com/)
> I guarantee I'm a much happier person than you. Oh, by the way, go fuck yourself asshole.
That is by far the most contradictory statement I have ever read on slashdot. (and I've been coming here for many years)
Copying, translating, teaching (Score:3, Insightful)
(http://www.digitalhermit.com/)
Teaching it was also useful because it made me convert awk, korn, bash and sed functionality *and* taught me that Perl wasn't the slowpoke I'd thought an interpreted language would be.
Yoda advice (Score:4, Insightful)
Just start and be prepared to fail. (Score:5, Insightful)
(http://www.jmagar.com/)
You need to write a mountain of code before you reach the level where you can debate the finer points for or against C# / Java / Python / LISP... You will learn the most from your mistakes, so go forth and screw it up. Do it often. And then fix it. Each iteration will make you better, and remember it takes time.
Fear. (Score:5, Insightful)
That's called 'fear' in the world of programming. Instead of digging into an open source project, or just jumping in and seeing what you could do, you turned away, and asked others to make it easy for you. Learn to recognize your fear, and you can master it.
All programmers feel it, some of the best just mastered it without ever thinking about it. None of us were handed this information on a silver platter. If you spent enough time in college to learn enough programming to be a master, you'd be retired when you were done.
The fastest way to learn programming is to jump in, not to go to school.
Reading and Writing , Arithmatic (Score:5, Insightful)
(Last Journal: Tuesday June 06 2006, @01:50PM)
2) Reading - get books. Educate yourself. Self-starters are valuable.
3) Writing - don't just read, but practice by coding. It's the only way to learn. The more senses you invoke the more you comprehend.
4) Arithmatic - (depending on your field, but for 99% of them...) keep up on your math skills. Sharp math skills will make your job easier
I've been employed for a year, so I'm fairly fresh in the field but those are the things I've found and am taking to heart. They seem to work for me.
You want advice? Here's advice (Score:3, Insightful)
some tips. If you don't like them, stick to what you're doing
and be happy.
1) Learn assembly language. Play with it. Think in terms of
what you can and cannot do with it. Read the -S output of
your compiler and understand it in terms of your source.
2) Play with algorithms. Can you code up a heapsort without
referring to a book? Can you do it in assembly? Read Jon
Bentley's "Programming Pearls".
3) Know your platforms' hardware and software. Install a
from-source Linux distro like Gentoo. Configure, build,
and install kernels from source. Play with the kernel;
even a simple thing like adding your name in a printk()
can be exciting.
4) Iterate. Keep current on the basics. Do you really know
your programming language? If you don't know how something
works, read up on it and read the sources. It's all just
ones and zeros.
5) Read "Hacker's Delight". Slowly. Enjoy it.
6) When low-level stuff gets to not be fun, play with high
level things. Write some Emacs Lisp. Learn Prolog.
Play with Squeak. Think about how they're implemented.
I have been doing this for a long time and I cannot emphasize
strongly enough the importance of refreshing your basic skills.
And play. Computers are fun. I have written compilers and
kernels from scratch, worked on instruction set architectures,
and a bunch of other stuff, and haven't yet exhausted the fun
that computers can be.
But they're not fun for everybody. If all this sounds dull to
you, it probably will be, and maybe you should pursue some other
hobby while pounding out C++ to pay the bills.
College doesn't teach you a trade (Score:5, Insightful)
College teaches you how to learn. Once you realize that, your education truly begins.
I know a site... (Score:5, Funny)
Hmmmmm (Score:4, Insightful)
(Last Journal: Saturday August 18 2001, @11:04AM)
There are many details in a real emulator, but then, there are many details in GCC, too. The fundamental structure is still there.
If you missed compilers in your "theory heavy" education, that could be a problem. (I think compilers ought to still be a required course; the requisite skills form the basis of far, far more programs than just your C compiler. Almost every text to text converter is better written as a compiler than a series of regexes or some other such hack, and with proper tools and the understanding to use them it's usually easier, too.)
Wh