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?"
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) 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
My work here is dung.
If you want to be a coder...
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.
Sounds like you should ask your school for a refund.
Can we get a "-1 Wrong" moderation option?
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
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/
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 and try it out for yourself. Try writing a simple program like: Next, run it through the assembler. Open it in a hex editor 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 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.
Javascript + Nintendo DSi = DSiCade
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.
No. Try not. Do... or do not. There is no try
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.
www.jmagar.com
-
" I would have absolutely NO IDEA how to even begin writing it. "
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.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
1) Jump right back into school and get your masters. I did it. Zero regrets (Heading to my last final exam in a few hours... I haven't even graduated and the rewards are in plain sight, not to mention the rise in pay next review)
..
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.
College teaches you how to learn. Once you realize that, your education truly begins.
Weaselmancer
rediculous.
I know a site with lots of great snippets to learn from!
If your education truly focused on theory, you ought to know more about writing an emulator than you think. An emulator is basically just an interpreter/compiler. Emulators often then use a whole bunch of tricks to speed things up, but at their core, all they are doing is taking in the memory image of a program and interpreting it in the context of a software implementation of the hardware. In theory, writing a console emulator starts out the same as writing any other interpreter, and while there may be special graphics or audio tricks you have to use, much of the rest of the optimization issues looks just like an optimizing compiler. Emulators have been doing Just-In-Time compilation for a long time now, for instance.
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.)
While you may not quite know enough to correlate them, many other programs use fundamental constructs from computer science too.
What you probably lack is experience, and there's only one way to get that. Fortunately, there's a large body of open source to study. As others have said, grab and interesting program and read it. As I haven't seen others say, after you've poked around for a bit, take the program and make a change to it. Emulators are probably not the best target here because at best you'll probably just degrade the performance, but who knows? Maybe SNES will let you plug in to their resolution upsampling framework easily and you can add your own interpolator or something. You'll find the first change is harder than you think, but this too is a valuable skill you'll use over and over again in real life; you will frequently be called on to make a change to a codebase you don't really understand. (One could argue that that is actually the general case....)
A few suggestions:
1. Don't confuse "Computer Science" with commercial programming. They are NOT the same thing.
2. You will soon realize that coding is a far smaller portion of your job then you expect. The coding portion decreases as you move up the food chain.
3. Do not ignore the business/finance side of your job. The business side keeps you employed.
4. As you learn more, you will realize how little you actually know.
5. Your current position is nothing more than a software assembly line job. All of those "cool" technologies are being developed by more experienced engineers.
6. "Engineering" software and "programming" are more different than you realize.
7. Coding is the easy part. You can teach a cat to bang out code. It takes an artist to design good software.
8. You have one of the best jobs in the world. Your technology base allows *you* the ability to build wondrous applications. Use it!
9. Have fun coding. Make it a personal challenge. Reallize a job is just for paying the bills. Your much more free than you realize.
Good luck.
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.
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.
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.)
Your Servant, B. Baggins
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().
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
Either you didn't pay attention or your school wasn't that good. Sorry.
A "console emulator" can be a straight forward emulator in which case, you should know enough from just your basic architecture courses. Did you discuss instruction decoding and ISAs?
Modern console emulators are probably Just In Time compilers. You should have had a compilers class and the prof should have at least mentioned binary translation. Even if they didn't, you should have spent a little time on JITs in an architecture class.
A college education is not necessarily about knowing how to solve problems, but how to decompose a problem into a series of problems that you can then figure out how to solve. For a console emulator, that may mean that first you know you have to read about the architecture your emulation (what's the ISA, what are the components, etc.). Then you realize you have to parse the actual ROMs (here's where your automata/compiler background kicks in). Then either emulate each instruction (tedious) or do dynamic translation.
If you wouldn't even know where to start, you didn't get the right education. I'd recommend trying to find a masters program or pick up some text books.
The most important decision to make now is "what do I want to do". It's a hard one, but start by looking into what field you want to go after? Game programming? Any that give you lots of money? IT?
Next thing you need to do after deciding that is start focusing on it. If you want to be a game programmer, start programming your own game. A company that hires you won't just look at your education, they'll look what else you've done, and a big bonus is "self starting". It doesn't matter if you don't know how to make a finished game or a finished project you can learn how to do the final stuff, and most of the time they don't care. What will matter is that you've designed something and worked towards it. In addition the code can show the employers "I know how to code".
If you want to go into IT start looking for work now. Anything you do outside of the field isn't going to help you too much in the long run, but be sure to learn as much as you can about networks and hardware for it (routers and so on, not just lan adapters). Try to learn Linux as well for IT, that might not help you but it's good to know it so you can work with networking apps with out dealing with the BS that Microsoft gives developers (dear god, what ever you do don't expect CSocket to be all you need for networking experience).
If you want to make money start networking. And I mean P2P.. Or rather that's person to person. Talk to people who can help you get jobs in major companies. You want a job in finance to make the most money the fastest.
Overall it's important to take a direction and start working towards it. The biggest mistake you can make is think your goal is to radical to start working towards it (something I had to learn.. Now I work at a video game company. What I always wanted to do.)
The second mistake you can make is undervaluing your skills. Don't take a job for 24K, even if they promise a pay raise in 3 monthes (finance, personal experience.) Demand 40K a year at the minimum. Short and simple that's the bare minimum you deserve and that's even low. If you're in a good job, you should be making more.
Also always be willing to move, that'll give you many more options, and don't be afraid to seek out big name companies to apply to. Nothing is wrong with apply somewhere expecting relocation expense. They should be provided.
Don't worry if you get into something and don't like it. You're still learning and no one expects you to be a good coder yet, school is to teach you the basics, they'll train you to be the programmer they want (or they arn't worth working for).
I assume graduate school is not a consideration right now since you're working.
Do you like tinkering? That is the essential skill/attitude. Everyone that I know who is happy and successful in software is a tinkerer. A hacker, in the old and honourable sense of the word. When we were kids (before computers, if you can believe that!) we amused ourselves with homebrew "chemistry experiments" and electronics and taking apart household appliances, especially clocks. Now we do the same thing but in software. (Most of us continue to hack in other fields as well, building airplanes and clocks and furniture.)
The other vital skill is learning. Things keep changing. If you enjoy learning about cool new stuff you'll have no trouble staying employed. If you've written some non-trivial chunks of C/C++ and you have a CS degree from a decent school like Berkeley you'll do fine. Be good at your assigned tasks so you can get it done early and done well. (Try not to get involved in office politics if there is any.) This frees up time to think about cool stuff, whether that's free software or work-related extra credit.
And don't forget there's life out there beyond software and work.
Unlimited growth == Cancer.
Well, I've been programming professionally for over 25 years, so ...
The real skill in programming is knowing how to break down a complex project into suitable pieces - top down modular design. The skill is not just being able to do this at all for arbitrarily complex projects, but being able to do it well - to select a breakdown that will be easy to develop and maintain, easy to debug, easy to modify and extend.
I really don't think there's any substitute for experience in learning this, since that's the only way it's really going to sink in and become second nature. The best thing you can do therefore is to practice, and push yourself with new challenges all the time. At work push to get on the most demanding projects, and out of work do hobbyist projects that push yourself too. When you switch jobs, don't shy away from switching industries and into new areas. You'll become a stronger programmer by being a generalist rather than a specialist, as long as there's also plenty of depth (don't skip around *too* fast).
What you're really learning via experience is a set of design patterns and approaches, so that when you look at new problems they will intuitively fall apart into "obvious" breakdowns. Nowadays it's fashionable to read books on design patterns, and that can maybe help, but I'd tend so suggest a more back to basics approach of just paying attention to the interfaces between your modules... A good modular breakdown is one that results in modules that may have a fair degree of internal complexity (but not too much - break it down further), but have simple/thin external interfaces. An overly complex module interface is often a sign of choosing a sub-optimal modular breakdown (you've drawn the dividing lines in the wrong place). Good modular design will also hide as much internal design as possible to keep things simple and flexible - if you've kept the interface simple and abstract, then you have more flexibility to change the implemenation.
One book you should definitely read is Writing Solid Code by Steve Maguire. It will help you train yourself to be aware of how bugs can creep into your programs, and what to do when you encounter them. Instead of just blundering ahead with a fix, you should be asking yourself "How could I have prevented this bug?" and "How could I have automatically detected this bug?".
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.
When our name is on the back of your car, we're behind you all the way!
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'