Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Advice For Programmers Right Out of School

Hemos posted more than 7 years ago | from the words-of-advice-for-young-people dept.

Programming 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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


My Advice (Though You May Not Agree) (5, Insightful)

eldavojohn (898314) | more than 7 years ago | (#17194676)

I'm just going to throw something out there about your attitude towards computer science. I thought console emulators were cool also but I never took the time to dive into how they worked. I did take the time to dive into some OSS projects (like Weka) and find out how they 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 [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?

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.
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 services that replace older code from days of yore. It's simpler & easier to maintain (in my opinion but that's not an flame war I want to fight here).

In the end, I recommend you do a lot of programming in your free time. I personally run a little bit of everything at home. I have Windows, Linux, Mac ... you name it I've tried it. I host a simple web server, I've played with JBoss, Tomcat, Weblogic & know my way around them. I'm not an expert in them until I'm tasked to do something in them at work. But you know, I'm always trying new things at home like Ruby on Rails. The important thing to note here is that I do this for enjoyment not because I have to.

I'm currently working at a company where I'm doing primarily c/c++ app development on unix.
For your wallet's sake, take whatever job you can find at first. Get your foot in the door, test out the waters and all that jazz. Get out there and work on the boringest thing if you have to. If it pays the bills, do it. If you hate it, test the waters and send your resume to other companies. Avoid a potential rutt.

Programming on your own? Through work?
My final advice is to diversify what you know. Try out implementing stuff in your free time. But that should cause you to realize whether you like that type of programming or not. If you get a job developing web services but find yourself working on MIPS emulators and transcoding byte code at home--look for work on writing BIOS for chipsets--it's out there. It's truly a joy though when you realize that the differences between work and what you do for fun at home are very little. That's when you'll find yourself really producing quality stuff for your boss, making bank & loving life.

Re:My Advice (Though You May Not Agree) (3, Insightful)

Ontology42 (964454) | more than 7 years ago | (#17194910)

Ok, Myself, well I was "Perscribed" the use of a computer for my deslexiya at 7 years of age. Since I'm almost 30 now that was a long time ago. Bieng Deslexic (IE: a visual thinker??) and completely unable to spell, despite the horrid use of speak and spells. I stumbled into boolen logic via a video game. From there I found out about Basic, C/C++ and Delphi. Now the adivce above is excellent however if you are new to the field it's always a good idea to study the classics: http://catb.org/~esr/faqs/loginataka.html [catb.org] Now I know it's a bit dated at this time, hopefully your school prepared you to think, it's not a university's job to give you "Job Skills" the education of the Computer Science graduates is basically to teach them how to Learn and Re-learn everything very quickly since the field you are going into has a habbit of reinventing itself every 18 months (thank you gordon). As to what or how you should learn, I highly suggest you start with the Unified Modeling language. It's a good place to start, then drill down. Good programmers always tackle large problems as a series of smaller ones. And if your using C/C++ remember to focus on security and creating a portable API!!! Happy Hunting

digg around (2, Informative)

jrwr00 (1035020) | more than 7 years ago | (#17194682)

Goto source forge and have a field day! you can find many projects with tons of different ways to do different things. just drive into the code of ZSNES or Nethack and explore the code, and see how they did it

Write new code (5, Insightful)

stibrian (848620) | more than 7 years ago | (#17194702)

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.

Refund? (4, Funny)

dazedNconfuzed (154242) | more than 7 years ago | (#17194716)

realize for some of the software being written nowadays, I would have absolutely NO IDEA how to even begin writing it.

Sounds like you should ask your school for a refund.

Re:Refund? (0)

Anonymous Coward | more than 7 years ago | (#17194904)

Mod parent up, pls.

Did you expect to pay money for someone to read you a book? I would balk at any school who only taught language syntax.

You should have learned how computers worked. You did cover things like compilier theory, right? Maybe some EE classes thrown in for good measure?

On the job front: maybe you should look into code maintainance, not generation.

Re:Refund? (4, Funny)

TubeSteak (669689) | more than 7 years ago | (#17194932)

Sounds like you should ask your school for a refund.
Or he could apply to their PhD program :op

seriously (2)

Nasarius (593729) | more than 7 years ago | (#17195038)

Did you sleep through your courses on operating systems and computer organization? Because I have no trouble understanding how a console emulator works, even though I don't know the details.

Re:Refund? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17195096)

Sounds like you should ask your school for a refund.
Remember: if you're going to ask a question for Slashdot and you aren't afraid to be realistic and reveal you have shortcomings, the only highly modded comments will be the ones making fun of you.

Seriously, you pretty much fit the Comic Book Guy stereotype of a nerd with no social capabilities who only feels good when he makes fun of other people. Not everyone knows everything about everything, you know. If you told me you only have Pi friends, I wouldn't be surprised.

I wish the stereotypical nerd was helpful. Instead our stereotype is that of an asshole.

My advice (2, Funny)

wayward_son (146338) | more than 7 years ago | (#17194720)

Be sure not to forget the cover sheet on your TPS Reports!

(They sent a memo, you know.)

Re:My advice (0)

Anonymous Coward | more than 7 years ago | (#17194902)

Well you're missing the point here. The point is there is a NEW coversheet for the TPS reports. That's the important thing here.

Re:My advice (1)

CptNerd (455084) | more than 7 years ago | (#17195026)

And always, always keep your red Swingline stapler. Otherwise you'll have to burn the building down.

Remember the decimal point... (1)

Vexler (127353) | more than 7 years ago | (#17195072)

...cuz otherwise you'd be sweating about those beancounters finding out that you just laundered money (by first looking it up in a dictionary, no less). And those federal POUND-ME-IN-THE-ASS prisons are no white-collar resorts, either.

Focus. (2)

Elentari (1037226) | more than 7 years ago | (#17194724)

One piece of advice is not to try and learn everything at once. It's easy to see how many possibilities there are regarding programming, and end up confusing yourself with vast amounts of information. You're best off finding one area that you're interested in - such as emulators - and do a lot of research to get a feel for what it entails.

Find a development community if you don't like working alone, and see what you can contribute, or lurk for a little while until you pick up enough knowledge to feel more confident about asking.

Its all about your libraries (1, Insightful)

Steepe (114037) | more than 7 years ago | (#17194726)

Figure out what you need, and get some good libraries.

No one codes anything from scratch anymore. You combine libraries together and thats about it. :)

You ARE in the correct spot though, doing C / C++ actually teaches you how to code a bit. Here we use mostly java and some .net, which is not very conducive to any heavy programming.

Once you get some experience, start looking for jobs that fit the bill of what you want to do, find some OS projects doing what you want to do and volunteer to do some coding in those. Take the crap work, that teaches you the hard stuff. The rock star stuff comes later.

Curiousity + google (1)

bryz (730558) | more than 7 years ago | (#17194734)

Most things that can be done with software have already been done with software. Fortunately the internet is full of source, examples, and discussions.

It sounds like you have an eagerness to learn, and I think if you start poking around with Google, you'll find that that you'll be able to learn most things you would like to know.

Then pick a project and either convince your company that it is worth developing or investigating or at the very least try and develop it in your free time.

Get a job in an advanced development team (4, Interesting)

EraserMouseMan (847479) | more than 7 years ago | (#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.

Starting is HARD. (4, Informative)

xtal (49134) | more than 7 years ago | (#17194738)

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. :)

More education maybe? (1)

Tanmi-Daiow (802793) | more than 7 years ago | (#17194748)

I am currently a freshman at a private college and am a CS/Math Double Major. The CS department seems to be much similar to yours, e.g. it is more theoretical in nature as opposed to programming oriented. My teachers have suggested this is much better suited for further education. I am personally planning to go on and get at least a Masters if not a PhD, though both of those are aways down the road for me, probably 8 years or more... That is my plan for the time being, hope it helps.

Re:More education maybe? (1)

EraserMouseMan (847479) | more than 7 years ago | (#17195066)

Dude, go to a different school. The one I attended had me fully equipped in 4 years. If you are already planning on spending the bucks to get a masters you'd be better off just going to a better school.

Re:More education maybe? (1)

Tanmi-Daiow (802793) | more than 7 years ago | (#17195244)

I believe you misunderstand me, I want a more theoretical approach to CS. I want to be a researcher as opposed to just a worker bee in an IT firm or other business. This school works for me and that is why I am here. The Math major also helps on the theoretical side too.

As someone else might say (0)

Anonymous Coward | more than 7 years ago | (#17194750)

Scratch an itch!
Most of the coolest software has come into existence through a programmer having an 'itch' to scratch.
So find a project you would like to work on and go.
Work may help you along too but in general you'll only do asked-for specific kinds of development at work and that may not be enough to keep you really interested.

scratch an itch (1)

devstuff (1004268) | more than 7 years ago | (#17194766)

Most 'really cool' things that I compose are just because I am really interested in writing what ever the program is. A famous quote is that good software is made when a developer would "scratch their own itch.". As for what I lack in technical knowledge then you can never read enough. Get books on subjects you are interested in and they will reference similar authors on the subject or branches off. As your programming experience grows so will your ability to just code the ideas that you have. You will learn patterns and methods to create some of the largest of software projects.

Don't worry - you'll learn. (0)

Anonymous Coward | more than 7 years ago | (#17194772)

My advice - don't worry so much about it. Until you actually work in the wonderful world of commercial software development, a lot of how it comes into existence is overwhelmingly mysterious. Hell, when I graduated, I was absolutely terrified by the same thing. But, a few months after I got my first serious software development job, I realized that getting that job was just the last piece of my education.

You're not going to start out as a project lead. You're not going to start writing a piece of software from scratch on your first day, or the second day... and probably not until someone above you feels you're ready. You're going to have plenty of time and plenty of people to help you along when you have that first position, so don't worry so much about it now. Get the job, look at it as a learning experience, and worry about meeting deadlines, not about understanding how each and every bit of software come into existence.

What school did you go to? (0, Troll)

new death barbie (240326) | more than 7 years ago | (#17194774)

...several of my classes were very theoretical in nature...

...for some of the software being written nowadays, I would have absolutely NO IDEA how to even begin writing it.
I have to wonder about the quality of your degree..., seriously.

Re:What school did you go to? (4, Informative)

mbrod (19122) | more than 7 years ago | (#17195102)

I have to wonder about the quality of your degree..., seriously.
I don't.

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.

Re:What school did you go to? (1)

TheDreadSlashdotterD (966361) | more than 7 years ago | (#17195150)

Understand that theory is not the same as practice. If all you wanted was practice, there are schools for it. Said schools are usually crap though.

You learn to program by reading and understanding code. By understanding code written by someone else, you gain insight as to how a project should be structured and what tools you will need.

An example, although a poor one, is the internship I landed about six months ago. I've been doing web development work using .NET for about three months now and I came into it from a C++ background. I essentially learned the quirks of C# by reading example code, some company code that was confirmed functional, and generally brute mental force. Amazingly, the past semester I took a C# class that taught me nothing. I already knew how to write the code discussed because they had already taught me the way to learn new computer languages effectively.

Now, you're talking about new techniques and cool whiz-bang projects. That's not what they should be teaching in CS classes. That should be pursued due to an interest by the student. If you can't do that, and want all the CoOl L337 H4x0R stuff spoon fed to you, look up IADT. I'm sure they have a college program for you.

(Disclaimer: I'm an unsatisfied IADT graduate that went to a four-year college after being unable to find a job with that awful degree. Take that as you will.)

You just need practical experience (5, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#17194802)

I recently graduated from school with a CS degree, and several of my classes were very theoretical in nature. I remember first time I saw them, I thought console emulators were really cool. I have no idea how someone would begin writing one.

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:

  lda #2
  adc #2
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. ;)

Re:You just need practical experience (2, Insightful)

flynt (248848) | more than 7 years ago | (#17195078)

This is a great comment. No one is born knowing these things. It is not surprising that CS undergraduate program did not teach you exactly how to write an emulator. But as parent said, don't be scared of not knowing. None of us knew anything until we sat down, invested serious time and thought, and actually did something about it. You don't learn everything overnight, that's not the point. But if you have a goal, just dive in and see where it takes you. You probably know more than you think, just don't fear fear.

Re:You just need practical experience (1)

brewstate (1018558) | more than 7 years ago | (#17195288)

I agree you just have to get practical knowledge. You will be surprised at how quickly you catch on to projects that you are working on. Learn to relate what you are seeing to things you know. If you have a good background in algorithms almost everything you see will have similarities to something you learned in theory. Or if you know how to program a compiler then you will notice that the emulator that you fear is very much like an interpretor. Most schools don't teach you everything you need to know to survive. They teach you how to gain the knowledge to survive and excel at what you do, if you so choose.

Invest in yourself. Assume no one else will. (5, Informative)

Dystopian Rebel (714995) | more than 7 years ago | (#17194808)

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.

Re:Invest in yourself. Assume no one else will. (1, Funny)

singingjim (957822) | more than 7 years ago | (#17194940)

Holy shit are you friggin' cynical. Time to drop a Paxil and drink a beer dude. The security and benefits of working in a cubicle farm like us cowards do sure beats living life with an attitude like yours. I guarantee I'm a much happier person than you. Oh, by the way, go fuck yourself asshole.

Re:Invest in yourself. Assume no one else will. (5, Insightful)

chris_mahan (256577) | more than 7 years ago | (#17195186)

Calm down. I work in a cubicle as a programmer for a fortune 500. I completely agree with everything he said.

> 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)

Re:Invest in yourself. Assume no one else will. (1)

lixee (863589) | more than 7 years ago | (#17195040)

This has got to be one of the most insightful post on this thread. Thank you Dystopian Rebel, you just made my day.

Copying, translating, teaching (2, Insightful)

digitalhermit (113459) | more than 7 years ago | (#17194814)

A few years ago I had to learn Perl in a hurry. There were some REXX based apps that needed to be moved and I got tasked with the job. In a few weeks I went from knowing that Perl was a useful scripting language to actually having to teach an introductory Perl course for the other team members. The translation process was extremely helpful. For one, it was doing useful stuff, not just what the textbook author thinks is appropriate. Second, it forced me to use "proper" methods if only because the REXX scripts were fairly mature and I needed equivalent stability.

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.

Follow Your Heart/Use The Force Luke (1)

blueZhift (652272) | more than 7 years ago | (#17194816)

It always helps me to have some specific problem or interest to which to apply a new technology I'm interested in. So as others have said already, if you're into console emulators, jump into the code of some well developed one and see how it ticks and muck around with it. I also have a few homegrown applications that I tend to port to whatever new language or platform interests me, sort of what people like to do with Minesweeper. The main thing though, is your heart has to be in it. It's a lot more fun that way, and you'll be able to stay fresh.

CO-OPs and Internships. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17194828)

A computer science degree is worthless if all it has you doing is ambling through by passing written exams; algorithms and formal languages are a single area of computer science.

Aside from not going to a school that has not redesigned their curriculum since 1985, one possible "fix" would have been to get non-classroom experience either outside the school or in a research lab.

Yoda advice (4, Insightful)

Anonymous Coward | more than 7 years ago | (#17194838)

No. Try not. Do... or do not. There is no try

A grad student's take... (0)

Anonymous Coward | more than 7 years ago | (#17194890)

I graduated with my BS in CS in May, and am currently pursuing an MS. CS is theoretical by nature. The whole purpose of the theory in CS education is the development problem-solving skills, to take what you know and apply it in meaningful, productive ways. As an undergrad, I was just as frustrated as you are, but after speaking to my graduate colleagues, I notice one thing in common. They are all very self-motivated and mostly self-taught. CS programs seem to just teach enough of the concepts to get you going, but it is up to the student to really succeed on his/her own. If you want to improve your knowledge base, either you can pursue a graduate degree (but it'll only take you so far), or you can pick up a pile of books and start reading. The more I read, the more I realize how much I don't know, and I believe you'll benefit just as well.

Just start and be prepared to fail. (5, Insightful)

jmagar.com (67146) | more than 7 years ago | (#17194894)

It takes 10 years to gain 10 years of experience. No short cuts.

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. (5, Insightful)

Aladrin (926209) | more than 7 years ago | (#17194896)

" 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.

Reading and Writing , Arithmatic (4, Insightful)

everphilski (877346) | more than 7 years ago | (#17194908)

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.

for me, a Masters really helped (1)

dioscaido (541037) | more than 7 years ago | (#17194924)

Might seem silly to suggest more school, but in my case a Masters in CS helped me considerably, both in coding and depth of understanding in the field. This is assuming you avoid specializing in the theoretical aspects where it can get even more detatched from the real world than your undergrad CS was. I was able to gain lots of hands-on experience in the fields of AI, Graphics, Networking, Databases, (and others) and finally settled on OS where I spent a year hacking away at the linux kernel while doing research. Way more experience than I would have gotten out in the field in that amount of time.

Coming out of the Masters I had the experience and confidence to get the job I wanted (developing in the field of OS), versus my experience out of undergrad where I could barely crack into the IT field.

Good luck!

You want advice? Here's advice (2, Insightful)

ColonelPanic (138077) | more than 7 years ago | (#17194930)

If you want to really learn the craft of programming, here are
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.

A website as an ongoing programming project... (1)

creimer (824291) | more than 7 years ago | (#17194934)

I been going to school part-time for the last five years to learn computer programming. I keep myself sharp by using my website [creimer.ws] as an ongoing programming project. I'm learning Python (which isn't taught at my school) so I can implement some heavy duty admin stuff for the backend. Once your website been up for a while and you have a good amount of programming invested, you start to learn how difficult "legacy" code can be and that maintance/upgrades may involve some painful decisions.

Read before you write. (1)

Ihlosi (895663) | more than 7 years ago | (#17194944)

After my education, I have no idea how someone would begin writing one.

A good point to start would be collecting and reading all kinds of datasheets, especially if you're doing something that hardware oriented. You'll need to know how the CPU and peripherals you want to emulate work on a hardware level.

That goes for many software projects. Once you've read and digested all the information you need, only then you can even think about writing any code. Ideally, you should start with diagrams and pseudocode so you don't get lost while writing the actual code.

Your work is your education (1)

justanyone (308934) | more than 7 years ago | (#17194950)

Yes, there's lots of "cool" technology that benefits someone somewhere, but how much of it will be useful? Impossible to know, since fads happen in programming just like any other industry: 4GL languages (application/code generators) (see Texas instruments ATI? ATL?), PowerBuilder, etc.

Your work will be your education. Pay attention to the failures you see and ask lots of questions. Of course, if you're an engineer in mindset, you're doing this already.

CODE READABILITY SHOULD BE YOUR PRIMARY OBJECTIVE. One of the biggest challenges I have with working with new grads is that they want to write "optimized" code. YUCK! I end up with unreadable gibberish that executes 2.51% faster. Remember that 50% (yes!) of software cost is in maintenance phase. That means that spending just a little extra effort designing and initially building something simple to understand, diagnose, and modify will save TONS over the life of the program.

Another problem I face is new programmers using the tool they know (like VB) rather than the tool that's optimal for the job. If you don't know Perl (at http://perl.org/ [perl.org]), learn it! it is the glue that holds servers and systems together - BUT WRITE HIGHLY READABLE CODE! If there's something easy to do in Perl, it's write obfuscated pieces of *(#&$ that no one can decypher afterwards, including you if you're not careful. A good way to get used to Perl is to browse the CPAN and find something in version 1.001 and look at their self-noted to-do list, fix it, and submit that code up. You gain great experience and the world ends up with better code.

As much as I complain about it, I've found that it really pays to know how to use VBA Excel and Word. Plumbing those apps into other apps can give you godlike status to the business users.

If you want a nice, practial OO language that lets you do lots of stuff, I'm really falling in love with Python. It's fast, it's got a viable OO strategy (as beautiful OO as Perl's OO is ugly), and it's growing fast. If you don't know Python, spend a while and write a quick 1000 lines in it that does something marginally useful.

Just my 5 cents.

Just my 2 cents (1)

OpenSourced (323149) | more than 7 years ago | (#17194952)

I don't think that's the proper question to ask. The proper question to ask, IMHO, is what you enjoy doing, and how you want to focus your life. I advice seriouly enjoying what you do at work. If not, change jobs. Specially if you like doing cool things. Because cool things are also (usually) difficult things, that are not so mainstream because most programmers (again in my experience) cannot/won't understand them. So if you like to do cool things you should be payed _more_ for doing them. If you aren't, is because you haven't found the proper employer, or you are rather obtusely working in a cool thing with no practical use whatsoever. If first, search a proper employer, if second, change cool thing, there are many and most of them with eminently practical (read valuable) content.

So my advice is search a place where you like what you are doing and are payed well for doing it. It may be self-employement, working in an insurance agency developing statistical models, working for IBM developing parallel processing algorithms, whatever. But whatever you love doing, try to leverage it into your revenue source, because usually days are too short to support a full-time work, a full-time hobby and a full-time relationship.

That's my experience, at least.

Re:Just my 2 cents (0)

Anonymous Coward | more than 7 years ago | (#17195114)

Relationship? Is that like a WoW account?

From a recent grad (1)

antadam (531507) | more than 7 years ago | (#17194956)

From my recent experiences, don't worry so much about the newest technologies. If you're in the same boat as I am, believe me, you're foundation for writing massive, expandable applications is extremely weak. This isn't gloating, but I graduated number 1 in my class of CS with a GPA .2 above the next highest person. I'm trying to say that it doesn't matter how well you did in school, there's still a lot uncovered. I graduated w/a BS in Computer Science about 3 years back and began working with a startup. I can say the only thing I found painful about working for a startup was that I was the only programmer. I found myself in a similar position as you; how do I even start a commercial app? Besides the obvious things you'll end up doing, research on the web, irc, etc., the number one suggestion I have for you is talk to all the senior programmers at your job and take them as seriously as possible. I found the hardest thing about writing code straight out of school wasn't actually writing the code, but writing the code such that 2-3 months (or even years) down the line you could easily expand on it. In general, you never really write an application that's used beyond 1 semester in undergrad. Those senior programmers are an awesome resource for writing modular, expandable code. I suggest you use them and strengthen your foundation. Learning the technology is a much simpler task than being able to design the code.

theory vs experience (1)

seanadams.com (463190) | more than 7 years ago | (#17194958)

If you are strong on comp sci theory but weak on "real world" programming experience, you may want to consider embedded systems development as opposed to the newfangled and rapidly changing world of server apps or windows/mac apps. The reason is you will be working with a smaller code base which is largely of your own writing, and the challenges are more in line with "classic" comp sci problems, as opposed to things like UI, web, etc. If you spend your first couple years getting C and a bit of hardware/assembler knowledge under your belt, you can then move to many interesting and highly paid fields with relative ease.

Trust me--your knowledge will increase... (0)

Anonymous Coward | more than 7 years ago | (#17194962)

I was fortunate to have a position with a software company as I worked through grad school. That being said, I look at my grad program as learning the underpinnings of how to do things like analyze a program, or a sql query. Where I learned 90% of my practical knowledge was through the grunt work and learning things from the trenches. For instance I had several classes on DBMS (intro and programming)...This gave me a foundation on where to look, where I gained a lot of the practical knowledge on SQL queries came from the trenches.

My point being, you need to look at college as a boostrapping process, and that you will gain knowledge as you go along.

One other word of advice, is if you are doing coding in your current job, this means you have access to source code--take advantage of this. Think of it this way

1) Whatever job you are doing requires that you generally need to gain knowledge to that system
2) Once you gain this systemic knowledge, having to figure out "what are they doing" becomes less of an issue
3) Then by examining other source code to this system, you can answer questions like "why did they do this in this way?" (Depending on your (political?) circumstances, and where you are working this may be as far as you can take it, but another natural step might be (assuming you find the WTF areas that are part of any engineering project, and you have a different solution), might be to approach colleagues about fixing it?)

Jack of All Trades, or Master of One (2, Interesting)

ckotchey (184135) | more than 7 years ago | (#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.

College doesn't teach you a trade (5, Insightful)

Weaselmancer (533834) | more than 7 years ago | (#17194978)

College teaches you how to learn. Once you realize that, your education truly begins.

Whatever works best for you (2, Insightful)

Deluxe_247 (743837) | more than 7 years ago | (#17194982)

Do whatever works best for you. Some people swear by reading coding books, improving your math skills (especially if you are interested in graphics programming) - and others tell you to work off other peoples code or take a class or something... I think working with other coders gives me the most benefit... As long as you aren't shy about asking 'why' and doing some legwork in looking things up yourself. When you are surrounded by people who have been coding for 10-20 years not tapping that resource is just stupid. Sure, they might have 'their way' of doing things, but like you should have learned in Comp Sci, there's more than one way to fry an egg (write some code, mix a drink, etc.) You get the point. Learn the concepts, look over other peoples code to 'see what they were doing', work on a project that will give you exposure to subject matter experts in areas you want to learn more about, and you'll be on your way. And honestly, I *DO* believe reading is beneficial. Even if you don't feel like you learn very well that way (some people dont), books are a great resource to learn new things or use as reference material. You might be overwhelmed at first, but the more effort you put into developing your skills, the more you will get out of it.

Could be a problem... (1)

Cereal Box (4286) | more than 7 years ago | (#17194984)

I know this sounds harsh, but bear with me here folks...

From the sounds of it, programming might not be for you. I don't mean to insult your intelligence, but there's more to programming than getting a four year CS degree. As you've found out, there's a lot that school doesn't teach you. In my opinion, the one skill you need to master is learning how to take an abstract concept (e.g., writing a console emulator) and utilizing your concrete understanding of CS concepts, algorithms, data structures, and the problem domain in order to synthesize a solution to the problem. I really don't think colleges teach this at all. But then again, how can you? Problem solving skills are something that you just have to "get" on your own (in my opinion) via challenging yourself with increasingly hard problems. I think that some people are just born with a better understanding of how to "get" programming. You see this a lot with mathematics: most people just don't understand the deeper meaning and connection behind all those symbols and equations, and some people can "get it".

What's more distressing is that you're asking people how to improve skills, while realizing that programming in your own free time is one such way to go about that. From the way the question was worded, I get the feeling that you didn't actually spend much of college doing that. That's troubling, in my opinion. I really think that if programming was your passion, you'd be juggling numerous "spare time" side projects all throughout school and, most likely, while you work. It shouldn't even be a question, you should've been doing that all along. But that's just my opinion. Sorry to sound harsh, but that's the way it looks to me.

Hmmmmm (3, Insightful)

Jerf (17166) | more than 7 years ago | (#17195024)

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....)

There is no try. (1)

Hushpuppy (1028670) | more than 7 years ago | (#17195034)

Here's how it worked for me:
1. Figure out what you like- no, what you *really* like.
2. Decide if you want to invest the time to do it, because it's going to take a lot of time.
3. Do it. Though you now know nothing about it- do it. All the hokey sayings apply: "The journey of 1000 miles begins with a single step," "There is no try. There is only do." (Yoda :-)

Learning anything technical is basically an exercise in some intelligence, a good deal more time, a great deal more perseverence, with an equal measure of proficiency in sniffing out answers. Remember, in the words of another great sage, "Google is your friend." Find code, and steal it! ...Open source code, and with proper attribution, of course :-).

I attempted to learn Java/Swing multiple times before I finally "got" it. I remember how opaque and utterly confusing/huge/unknowable it seemed. But now I can sling Java code around at will. I have little fear of ripping and rewriting huge chunks of my code, if necessary. There was a lot of road kill along the way... but eventually I got there.

To sum it up: First, focus. Then, persevere. In your darkest, most confused and frustrated moments, persevere. You'll break through.

As someone (Einstein?) once said, and I paraphrase, "Any idiot can come up with an idea. It takes hard work to get things done."

-Mike Schwager

The REAL value of university (2, Insightful)

Moggyboy (949119) | more than 7 years ago | (#17195044)

I can honestly say that I learnt more in the first six months of working than I did in 4 years of university, but I think the crux of getting a university education is learning how to learn. At my university (RMIT in Melbourne, Australia) we learnt a grand total of 6 languages over the first three years: Ada, C, C++, PERL, Java and LISP. Each student was expected to write a reasonably complex piece of software in each of these languages within 2-3 months of seeing it for the first time, gearing up with harder and harder assignments each month.

While I wouldn't say I came out of the experience with as a guru in any of these languages, I sure knew how to go about learning a new one. I also learnt lots of stuff that can be reapplied to every project you ever work on, i.e. design principles, design patterns, OO programming, defensive coding, etc. With every project I've worked on since then, these general concepts become honed, and you learn lots of neat tricks over the years that cumulatively turn you into someone that can work smarter, not harder.

There is always gonna be stuff that's outside your realm of experience; that you look at and think to yourself, WTF? Don't let it get you down if you have to work up to it. These things take time.

join a club... (1)

bfields (66644) | more than 7 years ago | (#17195048)

... find an open-source project, join the mailing list, and lurk for a month or two. Keep an eye out for easy projects that they need somebody to do--often there are simple things that desperately need doing that get neglected just because nobody has the time. Keep an eye out for technical terms everybody but you seems to know, and google them and/or find a relevant book at your local university library or technical bookstore. Don't expect people to lay out projects for you--the project maintainers are probably very busy, so even if you're a volunteer, your work isn't "free" to them if they have to take time to deal with it. Download the source and build it. Try tinkering with some small part of it to see what happens. Don't expect to do anything really huge at first. (But, what the heck, keep notes of your most ambitious ideas somewhere in case they later turn out to be easier than you thought.) Oh, and remember to have fun!

What I have Learned..So far (1)

Laoping (398603) | more than 7 years ago | (#17195050)

I graduated in 2003, and have been working since. I was also overwhelmed in what I did not know when I graduated. My suggestion would be to learn as much as you can about software in business. You graduated in C.S. so you probably have the skill you need to learn, which in my opinion is the most important skill you can pick up in school. Volunteer to work on the tough projects if you can.

Software in the business world is very different. I have worked for 4 places since I graduated(Yes, that is a lot, but I kept getting big raises :) The most important thing I picked up is how important the process is to software development. Once you understand this and start to learn what work and want does with the process, you will start to distinguish yourself from the coders. I think the biggest part missing from current C.S. education is the almost total neglect of actual software engineering.

I found once I started to understand software engineering all these project seemed much more doable. You start to move to a content neutral way of development. While the project and the language may change, you become more able to see the project in terms of "What process do I need to archive it", and not in terms of "What code do I need to write to do this".

Mainly, never stop learning and don't be afraid of failing. You will get to were you want to be.

My advice: (1)

Lord_Slepnir (585350) | more than 7 years ago | (#17195064)

Follow your dreams. You can meet your goals. I am living proof. Beefcake! BEEFCAKE!

Re:My advice: (1)

Xemu (50595) | more than 7 years ago | (#17195160)

Follow your dreams. You can meet your goals. I am living proof. Beefcake! BEEFCAKE!

This is a thread about programming. Are you sure you didn't mean to say 0xDEADBEEF?

Divide and Conquer... (1)

CharonX (522492) | more than 7 years ago | (#17195074)

While I don't have any experience with Emulators I can only guess that the writers applied one of the very simplest principles of "getting anything done" to coding it:
Divide and Conquer
Most humans can't deal with a gigantic trainload of work - they get caught up in details and start dropping important bits and pieces as they go along. Instead, partition the task in nice bite-sized chunks and deal with them one at a time - and while you worry about that one chunk, presume that anything farer away then, say, two references, somehow works automagically. Of course, if you want to get things done nicely you might add a bit more planning in the dividing, but the principle remains the same
Instead of programming a dynamic-webserver-gizmo, program a simple worker thread that listens to port 80. Then you expand that thread to reply when it recieves something. Then you rework it to be multi threaded with several worker threads...

Excuse me? (1)

Morgahastu (522162) | more than 7 years ago | (#17195076)

How does one get a 4 year degree in CS and not understand these concepts? This is supposed to be the difference between college graduated, and technical school graduates.

I would be writing a stern letter to your faculty if I were you, because you just wasted 4 years of your life.

jump into it (1)

lawpoop (604919) | more than 7 years ago | (#17195080)

The best way to figure out how to do something is to try to do it, fail, figure out how to get around the failure, and proceed to your next failure. Don't be too critical; these 'failures' are just hurdles or roadblocks. It's just like when you were learning to read.

How do you eat a cow? In bite size pieces. Instead of asking "How do I make an emulator?" ask yourself "What parts make up an emulator?" Keep breaking down the parts into smaller and smaller parts until you have a part that you are able to create.

I got my BSCS from 19 years ago... (1)

Richard Steiner (1585) | more than 7 years ago | (#17195084)

...and it's been a learning experience ever since. I've been "lucky" enough to actually be able to write software on a platform similar to what we used in college for much of my career, but the languages used and the scale/complexity of development I encountered in the "real world" (in my case writing custom software for a major airline) made me realize right away that college only gave me some basic tools -- the rest was up to me to learn on my own.

Much of what I've learned over the years has come in a work environment. I've been given some OJT flexibility and job function flexibility at work where I could work on pet projects to a certain extent, and that has allowed me to learn some non-mainstream languages and techniques on the main platform I work on. I've aso gone out of my way to ask questions of the folks I've run into who knew a lot in various areas, and that's been helpful.

However, I've also done a lot of learning at home (started playing with Linux in 1993, for example, mainly because we had no extended access to UNIX at the university I went to), and that has helped me tremendously as I've transitioned from mainframe programming to UNIX programming professionally. I've done both environments in parallel now for several years.

You can't keep up with it all. Once you get one trendy language or envirionment mastered, another three will materialize somewhere else. Just pick and choose things you think you might actually use and focus on them -- otherwise, you'll quickly find yourself overwhelmed.

CS vs Programming (5, Insightful)

grendel's mom (550034) | more than 7 years ago | (#17195088)

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.

It's a craft after all (2, Interesting)

hey! (33014) | more than 7 years ago | (#17195098)

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.

Why are you even asking? (1)

goodtim (458647) | more than 7 years ago | (#17195100)

The process to improve your ability to program computers is the same as improving anything else - practice. Write some damn code. In fact write lots.

here's a nickel's worth of free advice (1)

Aurisor (932566) | more than 7 years ago | (#17195104)

I've been programming C++ for 10 years, 3 of those professionally. These days I do a lot of Java, PHP, and Perl as well.

Unless your education was very different from the majority of CS programs out there, your education was not designed to help you develop software. To make an analogy, programmers are like writers; they rely on their ability to express their ideas to earn a living. Computer Scientists are like academic scholars; they rely on a broad knowledge of concepts to evaluate the effectiveness of certain ideas and approaches. A writer will write a book and a scholar will tell you objectively how it relates to various understandings of morality. A programmer will write a program, and a computer scientist will tell you mathematically how efficient it is.

The sad thing is that a lot of people out there who just want to write software end up getting these educations which prepare them to be computer scientists.

If you want to write software, the only way to get better is to write software. You are probably not going to be a professionally useful programmer until you have 10,000 lines of code under your belt. You will most likely not be capable of designing a 10,000 line software system until you have written 100,000 lines of code.

Pick something that interests you and start writing.

nehe.gamedev.net is a great site if you want to learn opengl.
gtk+ is a very friendly api for cross-platform guis.
the jabber protocol is fairly easy to implement if you're willing to do some research into writing c++ networking code.

If you have other interests reply here (or, hell, anywhere else in this discussion) and I'm sure people will point you in the right direction.

Starting an application is hard (2, Insightful)

mveloso (325617) | more than 7 years ago | (#17195110)

Starting to write a piece of software, especially an application used by end users (or, horrors, the public) is incredibly difficult. They don't teach it in school because the number of written-from-scratch applications is small. It's complicated, error-prone, and you don't know if you made the right decisions until weeks, or months, later.

It's exacerbated by the fact that you actually need to ship your product. You don't have the luxury, usually, of sitting around arguing the finer points of various architecures and algorithms. What toolset should you use? What framework? Libraries? Product dependencies? OS?

All of those require tradeoffs, and incur costs that may not be known for weeks, months, or years.

In fact, there are no right answers. There are things that make life easier or harder down the road. Unfortunately, those of us that have written multiple apps from scratch have a hard time explaining what the design choices were or even how to do it. Some things work, some things don't, and depending on your application, budget, and timeline you choose differently. If you're good, you keep up with the various technologies (on at least a passing basis) so you can learn new stuff/ideas/concepts that may help.

What are some of the factors to consider? Some simple ones are:
deployment - how do you deploy it?
Maintenance - how do you maintain the applcation?
How do you updates?
Are there enough people who know what you're using to hire? If not, is it easy to learn?
What features are requested, but not in this release? You can architect today for functionality tomorrow.
Toolset: are there too many moving parts? How many moving parts is too many?
Certain technologies, like J2EE, .NET, LAMP lock you in to a way of doing things. Is that OK?
If you use new stuff, is it stable enough to actually use in real life?

Then when you start writing your app, what do you start with? Again, it depends. Some people design and write from the inside out (internals to GUI), and some write from the outside in (GUI to internals). A user app should do the latter, since the capabilities of the UI have to be supported by the back-end. Blah blah blah.

In short, you have to learn by doing, making mistakes, and doing it again. Learn from other programs, etc, by asking: why do they do things that way? You can see design decisions and how they impact the application everywhere.

Yeah, it's rambling, but it's late for me.

Don't chase taillights (1)

foobarbaz (21227) | more than 7 years ago | (#17195132)

My advice: read books on computer stuff you find interesting, leave your job if you're bored, and just keep coding cool stuff and improving your professionalism.

If you chase what's hot now, you're already too late. Just enjoy yourself and keep learning, and sooner or later your own area of expertise will serve you well.

learn software engineering and design skills (1)

Uksi (68751) | more than 7 years ago | (#17195140)

I am sorry to sound like a complete ass, but you epitomize what's wrong with Computer Science education in the US today. Students graduate without design skills and software engineering skills. That's the huge gaping hole: lackluster design skills.

When I was taking a senior-level networks class, we had an assignment to emulate a physical layer, data link layer and the network layer. We had senior CS students who had trouble designing a prorgam to do that! The TAs spent more time explaining how to structure your program rather than how to deal with the tricky Unix socket calls! Now that is just messed up! A senior in computer science should not need instruction on how to design a program to consist of three layers!

I see this from the hiring side of the interview table. For me, a C.S. degree with a high GPA on a resume doesn't mean much. Sure, it means that many basics are there, which is good. However, it is far from a guarantee in being hired.

Yet, that degree (with a high GPA) could've meant so much more!

Sorry to espouse an unpopular opinion here.

Of course, you just need to learn that which you realize you don't know! (which is a good start)

Go and work on side projects. OSS or not, whatever scale. Go write your own utility or app of some size. Contribute to some OSS project, or try to understand how it works. Try to design an additional feature for some OSS project, not just fix a bug. Try to understand how you could add it and whether that addition is clean or hacky. The key is to practice the design skill and to get burnt many times by underdesigning, overdesigning, etc.

Read good books (Design Patterns by Erich, Gamma et all [essential], Effective C++ by Meyers [essential], Refactoring by Fowler, Refactoring to Patterns). Read the wiki on c2.com.

I see other posters have mentioned many good strategies.

not aimed at you (1)

Uksi (68751) | more than 7 years ago | (#17195324)

Just to be clear, I am criticising the CS education, and not you.

You have the motivation to go and learn, because you see a large area for improvement. So hopefully you will go and learn how to build that console emulator, or at least have a decent idea of how. And then you will be that much stronger for it.

Pick something. Do it. (1)

dazedNconfuzed (154242) | more than 7 years ago | (#17195148)

Looking back on 15+ years of industry experience...

- Find something interesting (hereafter "IT") to do. Just pick something that fascinates YOU, one thing, no matter how odd or far-fetched IT seems.
- Do IT. Completely. I mean, if it's gonna take 10 years to pull IT off, take a deep breath and start your 10 years. If IT requires a whole new technology, well then develop a whole new technology.
- Eradicate "can't" from your vocabulary. Lots of stuff exists precisely because someone didn't know it couldn't be done. Make IT happen.
- Live IT. IT is now your thing until your next career change.

A major problem of the Information Age is that there's so freaking much fascinating stuff going on out there that it's easy to constantly be distracted by "hey, that's neat..." and waste inordinate time in minor pursuits.

I've been in this since before the original IBM PC (as in: my first didn't even have floppy disk drives). In that time I've watched individuals create the World Wide Web, Google, Apple, digital movie characters, etc. - all things that were incomprehensible "you can't do that" tasks, and which are ubiquitous ... and were pulled off mostly by a few people devoted to the task for years.

It doesn't matter that you don't know where to start with the idea. The key is HAVING the idea, and being devoted to pulling it off. If you do it, it will pay off. Success comes to those devoted to making IT happen.

Greeting card (1)

COMON$ (806135) | more than 7 years ago | (#17195168)

Reminds me of a hallmark graduation card. "Welcome to the real world, it sucks, your gonna love it!"

Seriously, I am a CS major, graduated 2002. I don't even do dev work, but I work with a bunch of developers and for many of them it worked like this: Manager: I need you to build App X in .NET Developer: But I am a SQL admin. Manager: We need it by July. Developer: Sigh....ok.

6 months later...

Developer: Here is your app, had to learn .NET, work a couple hundred hours OT but it works as expected.

Manager:Oh, we decided to go in a different direction.

Moral of the story, Most of your dev experience is going to be due to poor management decisions or just having a project thrown your way. That is why the CS profs don't teach you language, it isnt a tech school. They teach you what you need to know to work on your feet. I don't do dev and I use my CS knowledge every day as a Network Admin.

However it has been my experience that the really good programmers are the ones that when they go home, dissect the Emulators, and Open Source Projects, get involved in them and end up doing something great in their spare time. It just takes a lot of patience and determination. Good luck.

Thats the problem with colleges. no real learning (1)

deiong (919381) | more than 7 years ago | (#17195172)

Thats the biggest problem with colleges, they teach basics and nothing more. sure if you want to make a program that calculates the speed and trajectory a plane needs to come down then you will get a head start there, but other then that programs teachers tech have absolutely no value outside, the way to learn is yourself research and learn. those who teach teach, those who do do, its great to learn the basics from college , but you will only learn the real substance on your own.

Upsell. (1)

numbski (515011) | more than 7 years ago | (#17195190)

Did you know you can super-size that combo for another 35 cents?

Would you like fries with that? :D

(and the karma suffers...)

Write a screensaver (1)

ewg (158266) | more than 7 years ago | (#17195198)

I recommend writing a screensaver. These are typically small, self-contained programs that work closely with the underlying operating system. The screen display can be as simple or elaborate as you like, and you get experience packaging and deploying your software to meet the requirements of the host system.

You should have a passion for programming (1)

jbarr (2233) | more than 7 years ago | (#17195230)

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?"
OK, I'm really showing my age here, but when I first "got into" programming, I was tinkering as a teen with a Commodore Vic-20. Learing to program in my spare time became a passion and a hobby. When I went to college, I was going down the CS path, then realized that in order to get a CS degree, I needed 2 semesters of Calculus. I'll admit that I'm not the swiftest when it came to math, so though I tried taking and dropping Calculus twice, I eventually gave up and switched my minor to my major: Psychology. But I kept my skills hoaned with programming, and my second job out of college was doing in-house software development for a housewares manufacturer--a job I kept for 10+ years.

Programming is both a science and an art, and to be effective, you need a passion about it. While work can provide the tools and the motivation to learn something new, more often than not, you are constrained by current requirements and issues that have nothing to do with learning something new. Programming as a hobby can be fun and beneficial if you stick with it, just don't let it get in the way of your work.

So how do you know you have a passion fro programming? Well, you started by asking /., so it's a start--at least you ahve the right mindset. ;-) When you lie in bed at night and can't sleep because you are manipulating algorithms in your head, or when someone at work gives you a problem, and you just "see" the program in your head, at that point, you are on your way to having the passion of being a good programmer.

Getting started (1)

Doctor Memory (6336) | more than 7 years ago | (#17195232)

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?
A little of both. What I used to do was to pick something I was interested in (say AJAX-enabled web sites), then try to do a project for work using that tech (the "through work" part). They were side projects I worked on during lunch or after normal work hours (the "on your own" part). Then, when I had something that worked, I'd show it to my manager. Usually they'd dismiss it with a "that's interesting, but we really don't need a web page to indicate who's in the office and who's sick/off-site/at lunch/on vacation". Which was fine, I didn't really want to document or maintain these things, but knowing that I was going to demo it gave me a little added incentive to not gloss over some of the details.

Lately, I find that lots of new tech comes with a tutorial project, so I start with that, then flesh it out into something real. If you want to learn Java/JEE, the Pet Shop app is a good place to start, likewise Sun's Blueprints series. I think they're a step above a random SourceForge project because they're designed to be easy to follow. Most of them aren't inherently useful once they're done, though, so you might find it easier to pick up a real project and play with that, since it's useful to start with, and you can work to improve it instead of just learning a coding technique with a project that ultimately doesn't do anything.

Lots of good info and (often) code snippets at specific tech web sites. Searching for "PHP programming site" brings up some good ones. Another thing to try is "XYZ (example | tutorial)" where XYZ is something you're interested in.

If you're really interested in something (or really think it's something you should learn about), try to find a local user group. Probably not practical for anything other than languages or specific products, though (think .NET or MySQL).

Console Emulator (1)

tubs (143128) | more than 7 years ago | (#17195248)

My first thought were, "Whats so cool about a console emulator? Really a vt100 emulator isn't that interesting."

Probably because I've just been searching through wires to find a null modem cable so I can hook up to a 4400 switch through the console port. *Note to self, put stickers on wires so I can quickly find a null modem cable in a box of serial cables.

Know your job. (1)

IMarvinTPA (104941) | more than 7 years ago | (#17195250)

Remember, your job is to make somebody else's job easier or possible. The user of your code isn't trying to make your job HARDER. He's trying to make his EASIER. That's the way it is supposed to be.

Also, try to understand the problem that is being solved. Don't trust the requirements. You can successfully implement the requirements and completely fail to solve the problem. Don't be afraid to find some way to get those who will be using what you make to give you feedback that you've actually made their task easier, better, or more complete. You may need to learn how to do their job so you can really sympathize with their problem.


Read the Code... (1)

corecaptain (135407) | more than 7 years ago | (#17195252)

Start with the code. Download and install the "thing" that has you captivated.
Spend some time doing a 30,000 foot reading of the code...you aren't trying
to understand every line, just trying to get a sense of how the beast operates.
Next, pick some feature/function of the app that has you asking/wondering .. "How
does it do that?"....trace that feature in the code line by line as much as possible...
until you understand it...maybe draw/diagram out any data structures/objects that seem
to keep showing up every 2-3 statements. Use the internet / book stores to get articles books
on subjects that will help you understand the application....After a while, you will find that you understand the code. You might even start to see design mistakes, even outright bugs...you submit a patch, then..... ....

What I did (long ago) (1)

Greyzone (851410) | more than 7 years ago | (#17195256)

When I came into the industry, microcomputers were just taking off. And it was microcomputers that drove my interest. Back in those days I wrote code, lots and lots of code. And I read code, lots and lots of code. My projects back then were rewriting my BIOS on my 64K RAM Z80 so I could squeeze in more features, replacing my BDOS and CCP with ZDOS and ZCPR (both public domain replacements for the core of the CP/M OS), writing modem software for telecommunications, and writing simple scripting tools.

Later on at work, I was fortunate enough to end up working on IBM mainframes that were running VM/CMS instead of MVS. I learned a huge amount about scripting languages there dabbling with Rexx and writing extensions to Xedit, the mainframe's default text editor. At home I skipped the entire MS-DOS period, staying with Z80s then jumping to Interactive Unix when I could buy my first 386. When Minux began to explode, I was there and reading people's code as well as contributing small bits. Until a few years ago I still had my "brick" of floppy disks that contained all the code from my Linux 0.12 build. By that time at work I was working exclusively on Unix workstations and servers and got into a professional project that ended up with some of my work going into the X11R4 release of the XServer. Again, I was writing lots of code and reading lots of code.

Along the way I was also reading the heavyweights of the industry as well. I got some insight into how and why they chose to do things and it greatly influenced my thinking.

If there is one thing I continually recommend to young computer science students I meet it is this - get a full Linux distribution, install it, then begin reading the code, and writing your own. Start small. Write a command line utility. Then write an application program with no GUI, just the core logic. Maybe manage all your CDs and DVDs with it. Then rewrite it with a GUI. Then go back and do it again with something more complex. If you think your application is slick and useful to someone, release it under an open source license, create a project for it on SourceForge, then read the criticisms that flow in. Along the way, learn to let go of your ego and not take technical criticism personally ever, at all. All of this will make you a far better programmer.

So in closing, let me simply recommend what most everyone else here is recommending - write lots of code and read lots of code. It's the best way to excel in this business.

Fear Not (1)

BioCS.Nerd (847372) | more than 7 years ago | (#17195262)

You have a CS degree, so you should know how to do experiments in CS. You should know that scientists everyday break down difficult problems and study them systematically. You didn't go to school to learn how to program (At least I hope not. You should have gone to college if you wanted to be a code monkey). Analyze, plan, execute. As numerous posters have suggested, get experience by practicing these skills on OSS projects.

Throw yourself into the deep end with both feet. (1)

GrizlyAdams (999280) | more than 7 years ago | (#17195268)

I didn't know much about how emulators worked either, until I wrote my first Apple II emulator from scratch. I've since ported it to two other platforms, and subsequently lost all the sourcecode. Emulators are not that interesting unless you are doing dynamic recompilation (generating native code that provides the same functionality as the original, then executing it) or have to emulate something not very well documented. Even then it can be more frustration than actually interesting code. It takes a lot of work to write an emulator that is compatible with every application for a specific system as there are quirks of the original hardware that get taken advantage of by at least one program usually. An example of this is the way you can read certain locations in the Apple II's memory that are invalid, but get back the last byte sent to the video system, providing something close to a software vsync. Several games used that for timing from what I remember.

My advice is to find some project you are interested in, and do everything you can to find out how the original hardware works. Get memory maps, cpu instruction sets, any SDKs you legally can, etc. If you are lucky you might even be able to find some system schematics. I have a handy reference that has schematics for every Apple II/II+ revision, and full sourcecode to the integer basic roms, and function table for the Applesoft roms.

Start with a simple system first, then work your way up if you must. Just be sure you have fun while you do it, or have enough motivation to keep going.

Programming is different than Technology (1)

wrook (134116) | more than 7 years ago | (#17195274)

I think you're liable to get a lot of really good advice here. But I'll throw in my 2 cents for what it's worth.

I've been programming for almost 30 years now - nearly 20 of that professionally. There are a lot of things I don't know about programming. In fact, every day that goes by I learn about something else I don't know. As you move higher, you can see more of the horizon. Similarly, as you learn more, you will discover more and more that you don't know.

Programming is not Computer Science. Programming *uses* computer science (and several other disciplines as well). Programming has more in common with writing than it does with math. As a software *author* you should endeavor to spend as much time reading and writing as you can. Free and Open Source software are excellent avenues for pursuing that. You should also take time out of your day to *practice* programming. If you see a nice method for expressing something, make an effort to copy the technique on your own. I use toy problems, sometimes referred to as "programming katas", to practice different techniques.

Finally, you should realize that just as there is a difference between "Computer Science" and "Programming", there is also a big difference between "Programming" and "Technology". "Technology" (as I'm using the term) refers to the *details* of some computer program, or genre of computer programs.

Often people choose to spend their time learning specific technologies. This might be the Windows API, Network protocols, 3D graphics programming, etc. There is some overlap with learning programming in that certain programming techniques are more or less useful in the technological domain. But learning specific technologies will *not* make you a better programmer. Learning *programming* is the *only* way to make yourself a better programmer.

Unfortunately there is much confusion between the two ideas. I know many programmers who are experts in a particular technology, but have no idea about programming. And even the best programmers have certain technologies which they know nothing about. Be conscious of the difference and it will help you in your career.

My view (1)

kicken18 (839808) | more than 7 years ago | (#17195300)

I think one important thing to remember is that unless you are very very talented,m or lucky, then your going to be starting at the bottom. I wouldn't expect anyone with only just a degree under their belt to be writing great cool news things right away, I mean, to be honest, you have a degree, but in the big bad world of programmers, you actually don't know much, as you still have little experiance. Its quite harsh, but its true, maybe otehrs agree or not, just how I see it.

confidence (0)

Anonymous Coward | more than 7 years ago | (#17195314)

I have seen the subject of confidence come up a few times on /. comments before, and I am repeating it now because it truly is important for developers and schools do not teach it. I think they don't because there is no way to teach this. Everyone does things differently.

You need to develop the confidence to start working on a project (in this case a programming project) with no idea what you are doing. There will be days where you get absolutely nowhere measurable. And in some cases there will be a lot of them and you will want to quit. But you have to keep trying until you get where you want to be.

If you want to learn to write a console emulator, read everything that you can get your hands on that has to do with emulators (books on console emulators, code from console emulators, etc...). And while you are going through it, do whatever makes you feel comfortable with the material. Take notes, relate it to something you already know, etc...

That's really all that I can tell you. Sorry if this was corny, and I kept it vague because like I said, everyone's different. One thing that helps me when I'm trying to learn something new and complex or confusing is reminding myself that someone HUMAN did this thing before me, and so there's no reason that I can't.

hope some of that helped.

Learning to program is like learning to draw ... (1)

boxlight (928484) | more than 7 years ago | (#17195316)

Learning to program is like learning to draw, you can read all the books you want, but until your pick up the pencil and practice practice practice you can do it.

Use books for reference, but don't rely on their tutorials to teach you how to code -- you need to learn how to create, not just follow the steps in a book. We learn by doing.

Think of a project, start building it. When you get 25% of the way through you will think of a better way to do it. Refactor or start over. When you get 50% through you will think of a better way to do it. Throw half of it out and re-write it.

Get a job where there's lots of little problems to solve, as the senior guys lots of questions, write lots of code, make lots of mistakes, erase the mistakes and re-write it.

You will get headaches, your stomach will hurt, and it will be incredibly stressful. Don't worry about all this, it just means you're learning.

Eventually (give it five to eight years) the world of design patterns will make a *lot* of sense to you -- you will stop thinking in objects and will start thinking in interfaces and patterns.

At this point you will feel bored and will consider getting into some kind of senior/architectural/management position, but you'll still want to spend your days coding instead of talking to suits in meetings all day long.

You will dream about starting your own software company, but you will not do it because you are being well paid, you get free coffee and soda, and you probably have a wife and house to pay for.

You may start a small "shareware" project as a creative outlet, but you will likely never make a finished product out of it.

Hope this helps!


Problem = Solution = Money = Power = Women/Men (0)

Anonymous Coward | more than 7 years ago | (#17195336)

Simple. Find a problem that actually needs a solution (and you think you can solve). That's the hard part. Then solve it. That's the easy part. Then give it out/sell it/etc. Wait for some street cred to build, then capitalize on it and get the women.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account