Slashdot Mirror
Advice For Programmers Right Out of School
ari1981 writes "I recently graduated from school with a CS degree, and several of my classes were very theoretical in nature. There was some programming, but it seems not as much as in other schools. I'm currently working at a company where I'm doing primarily c/c++ app development on unix. But as I read slashdot, and other tech sites / articles, and realize for some of the software being written nowadays, I would have absolutely NO IDEA how to even begin writing it. I remember first time I saw them, I thought console emulators were really cool. After my education, I have no idea how someone would begin writing one. With the work I'm doing now, it doesn't seem I'm going to be using (or creating) any of the really cool technology I hear about. How did everyone here begin learning / teaching themselves about different aspects of programming, that they initially had no clue about? How did you improve? Programming on your own? Through work?"
While this wasn't what pulled me into computing, it may be your addiction. Here's what I would suggest doing--take a well developed open source emulator (you know, like an NES emulator) and pick apart the source tree. You might find that the code is obviously doing some low level translation of the ROM which essentially changes its executable language to be IA32 or some such thing. It may be that you don't understand the architecture of the NES itself and therefor you can't really develop this yourself. So there's some insider information you lack but it will still be a good learning experience and may prompt you to figure out how to A) dump ROMs and B) reverse engineer a console architecture. Even if these are fruitless searches, how far you're willing to go will be a good indicator of whether or not CS is for you. Yeah, I hate to say this but I know people with CS degrees that simply don't have the debugging mentality to be programmers. A simple test is to think back to the times you saw something neat. Did you ever have a strong internal urge to find out how it worked or to try and modify it to augment its task?
Fear not your own ignorance. Only fear your acceptance of it. I am confident that if I wanted to build an emulator I could. I personally find other things more interesting but you just have to buckle down and really pick it apart and look for answers. As I said above, these emulators might have proprietary reverse engineering so these backwards black boxes might not be the best place to start as you may be met with frustration. On top of that, the newer consoles are now fighting a war & implementing encryption scheme which just makes the emulator all that more complicated. Why don't you pick a project like Firefox? Get the source, find out what the common developing environment is and step through the code when you visit a page. That's where it all starts.
Most importantly, you don't need to do everything from the ground up. It helps to know everything that's going on below the abstractions you sit upon but you don't need to think about that every time you write code. Learn to use libraries & frameworks. To quote Salvador Dali: "Those who do not want to imitate anything, produce nothing." I couldn't start writing an emulater either. But if I looked at the source trees and structures of the more popular ones out there, I'm damn sure I could figure it out. That confidence I have in myself is infallible and that's important to me. Sorry to sound like Dr. Phil but you asked for my opinion.
There are different tricks to different applications. Some are more simple than others. In my opinion, the less tricks you need to get started in a language, the better. Because we're not all world class magicians (although every language has some players that could rock your world in said language). This is why Java, while not as efficient as C, is probably taught to you first. There are very few tricks one needs to know in Java. But you know what? Java is still quite useful. Those responsible for implementing it did a decent job and now the web service programmer needs to know very little about them because configuring them has been abstracted and made easier by many UI & IDE tools out there. But web services are a very practical and widely accepted concept out there today. In fact, pay the bills by writing some very inane web se
My work here is dung.
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
WulframII - Free Online Mutiplayer 3D Tank Shooting Game
making things you are interested in on your own makes most sense.
You can't handle the truth.
If you want to be a coder...
write more code of your own
write more code
read more code
read LOTS of other people's code (DL a smallish OSS project at first, then larger ones).
rinse, lather, repeat.
If you're concerned that you're not learning "cool new things" on the job, learn them off the job. Your destiny is your own, as hokey as that sounds...
love your work.
Sounds like you should ask your school for a refund.
Can we get a "-1 Wrong" moderation option?
Be sure not to forget the cover sheet on your TPS Reports!
(They sent a memo, you know.)
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.
Figure out what you need, and get some good libraries.
:)
.net, which is not very conducive to any heavy programming.
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
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.
Just three more hours seapeople and you can finally take me away from this crappy God Damned planet full of hippies
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.
An open source project is a good idea as a starting point. Pick away at something that already works.
:)
Where that isn't an option; I've always turned to O'Reilly books, and online tutorials to learn some new skills. I've written some tutorials for people who are interested in getting started with embedded electronics, for example. It's not hard to do, but you need to know about a half dozen things before you can get started.
I suspect you're either giving up too easy, or not looking online enough, or in the wrong places. For console emulation, there's a LOT of documentaion in the source code for MAME, and I am sure the others are similar.
Most of the people who are doing complicated OS programming have 10, 15, or even 20+ years of hacking away. Spending thousands and thousands of hours in front of a computer helps. Unless it's spent playing WoW, maybe.
..don't panic
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.
"Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive." - C.S. Lewis
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.
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.
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.
...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.It's supposed to be completely automatic, but actually you have to press this button.
Yes you do. You just don't know it yet. (Assuming your school wasn't out and out terrible.) There's a huge divide between theory and practice that every new programmer has to overcome. The best way to overcome it is to dive in and learn about the practical designs of today's technologies.
For example, you want to write an emulator. Many of the early game consoles were based on the 6502 microprocessor. If that scares you, it shouldn't. Read this webpage:
http://www.obelisk.demon.co.uk/6502/
It will introduce you to 6502 assembly. It explains not only the text commands you can use, but also the hex codes that will be output by the assembler. You can get an assembler like DASM and try it out for yourself. Try writing a simple program like: Next, run it through the assembler. Open it in a hex editor and you should be able to see the direct mappings between your code and the program output. If you target a specific platform like the Atari 2600, you can use an existing emulator with a debugger like Stella to watch your code execute line by line.
Remember, learning doesn't end when you exit school. It just begins. So start digging up everything from reverse engineered documentation to documents put out by standards commities like the IETF's RFCs, the W3C standards, and the ECMA standards. You'll gain a much greater appreciation for how things work after you take them apart and understand them.
Javascript + Nintendo DSi = DSiCade
Congratulations on earning your degree.
An entire generation of creative software people who had great ideas and deaf employers grew sick of their cubicles and started the open-source software revolution. They wanted to learn stuff and do stuff, just like you do.
Grab the code, read it, mess with it. Invest in yourself and assume no one else will.
My experience has been that you MUST teach yourself... especially if you work for the big cubicle farms. Teach yourself so you become better, so you keep your skills current, so you energize your imagination, and so you can go elsewhere when your employer enters the BRED ("Beancounters Rule Every Decision") Stage Of Atrophy.
BRED means that your employer is unlikely to pay for you to learn anything useful, especially not during the sunny hours when their BMWs and Porsches are in the parking lot. BRED means that good ideas die unless you happen to drink whisky with the CEO once a week.
Cowardly employees and consitutionally cheerful employees are easier to flog and much less frightening and expensive than people who want their employer to invest in them. People who have the latest skills aren't chained heavily enough. And when the expenses grow and the balance-sheets and Powerpoint slides don't show the Beancounters at the top any benefit ("any chance of getting more stock options"), you can bet that your Red Swingline Stapler is going to Bangalore.
Rich And Stupid is not so bad as Working For Rich And Stupid.
Being put on teams with senior programmers who delegate your work and workload.
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.
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.
To the making of books there is no end, so let's get started
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.
No. Try not. Do... or do not. There is no try
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.
You need to write a mountain of code before you reach the level where you can debate the finer points for or against C# / Java / Python / LISP... You will learn the most from your mistakes, so go forth and screw it up. Do it often. And then fix it. Each iteration will make you better, and remember it takes time.
www.jmagar.com
-
" I would have absolutely NO IDEA how to even begin writing it. "
That's called 'fear' in the world of programming. Instead of digging into an open source project, or just jumping in and seeing what you could do, you turned away, and asked others to make it easy for you. Learn to recognize your fear, and you can master it.
All programmers feel it, some of the best just mastered it without ever thinking about it. None of us were handed this information on a silver platter. If you spent enough time in college to learn enough programming to be a master, you'd be retired when you were done.
The fastest way to learn programming is to jump in, not to go to school.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
1) Jump right back into school and get your masters. I did it. Zero regrets (Heading to my last final exam in a few hours... I haven't even graduated and the rewards are in plain sight, not to mention the rise in pay next review)
..
2) Reading - get books. Educate yourself. Self-starters are valuable.
3) Writing - don't just read, but practice by coding. It's the only way to learn. The more senses you invoke the more you comprehend.
4) Arithmatic - (depending on your field, but for 99% of them...) keep up on your math skills. Sharp math skills will make your job easier
I've been employed for a year, so I'm fairly fresh in the field but those are the things I've found and am taking to heart. They seem to work for me.
give up programming and get a MBA? more work for me :-)
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!
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.
"Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
I been going to school part-time for the last five years to learn computer programming. I keep myself sharp by using my website 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.
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.
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/), 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.
Unitarian Church: Freethinkers Congregate!
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.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
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.
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.
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?)
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 teaches you how to learn. Once you realize that, your education truly begins.
Weaselmancer
rediculous.
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.
Its Deluxe, son. Deluxe!
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.
I know a site with lots of great snippets to learn from!
If your education truly focused on theory, you ought to know more about writing an emulator than you think. An emulator is basically just an interpreter/compiler. Emulators often then use a whole bunch of tricks to speed things up, but at their core, all they are doing is taking in the memory image of a program and interpreting it in the context of a software implementation of the hardware. In theory, writing a console emulator starts out the same as writing any other interpreter, and while there may be special graphics or audio tricks you have to use, much of the rest of the optimization issues looks just like an optimizing compiler. Emulators have been doing Just-In-Time compilation for a long time now, for instance.
There are many details in a real emulator, but then, there are many details in GCC, too. The fundamental structure is still there.
If you missed compilers in your "theory heavy" education, that could be a problem. (I think compilers ought to still be a required course; the requisite skills form the basis of far, far more programs than just your C compiler. Almost every text to text converter is better written as a compiler than a series of regexes or some other such hack, and with proper tools and the understanding to use them it's usually easier, too.)
While you may not quite know enough to correlate them, many other programs use fundamental constructs from computer science too.
What you probably lack is experience, and there's only one way to get that. Fortunately, there's a large body of open source to study. As others have said, grab and interesting program and read it. As I haven't seen others say, after you've poked around for a bit, take the program and make a change to it. Emulators are probably not the best target here because at best you'll probably just degrade the performance, but who knows? Maybe SNES will let you plug in to their resolution upsampling framework easily and you can add your own interpolator or something. You'll find the first change is harder than you think, but this too is a valuable skill you'll use over and over again in real life; you will frequently be called on to make a change to a codebase you don't really understand. (One could argue that that is actually the general case....)
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
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.
LOAD "SIG",8,1
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.
Work smarter, not harder.
... 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!
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.
:) 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.
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
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.
Follow your dreams. You can meet your goals. I am living proof. Beefcake! BEEFCAKE!
...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.
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...
+++ MELON MELON MELON +++ Out of Cheese Error +++ redo from start +++
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.
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.
Computers are useless. They can only give you answers.
-- Pablo Picasso
...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.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
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.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
"Flee at once, all is discovered."
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 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.
.NET, LAMP lock you in to a way of doing things. Is that OK?
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,
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.
Basically: program something you care about or enjoy.
The more time you spend designing/coding, the better you'll be at it.
See also my advice for CS students,
http://www.kegel.com/academy/getting-hired.html
Stop loosing your time on slashdot ;)
"Insanity in individuals is something rare, but in groups, parties, nations, and epochs it is the rule." - Nietzsche
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.
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.
Looking back on 15+ years of industry experience...
... and were pulled off mostly by a few people devoted to the task for years.
- 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
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.
Can we get a "-1 Wrong" moderation option?
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.
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
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.
Did you know you can super-size that combo for another 35 cents?
:D
Would you like fries with that?
(and the karma suffers...)
Karma: Chameleon (mostly due to the fact that you come and go).
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.
org.slashdot.post.SignatureNotFoundException: ewg
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
My mom always said, "Jim, you're 1 in a million." Given the current population, there are 7000 of me. God help us all!
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
Just junk food for thought...
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.
try to make ends meet, you're a slave to money, then you die
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.
IMarv
Trusting software vendors is no smarter than trus
Start with the code. Download and install the "thing" that has you captivated. .. "How ....
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
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.....
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.
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.
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.
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.
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.
Visit My Blog at http://spaces.msn.com/members/chrisharries
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, 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!
boxlight
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.
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.
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.
Duh.
For me programming is not an ideal, it's an ends to a goal.
I didn't have any formal education, when I was younger, there were certain aspects of the computer that bothered me, and I decided to write small programs to do small things that would make the computing experience more friendly (to me and me alone).
As years gone by, the programs grew bigger and eventually they were good enough that I thought other people may want to use them as well. And that was that.
Also, the internet is just great at problem solving. Usually you wouldn't look at a whole project when starting out as it will overwhelm you. However, if you have a specific code problem, there are a lot of sites that explain how to do small & specific things which help your code move along and evolve.
Zoom Player Lead Dev.
I just finished my Thesis for my Electrical Engineering degree. I was mainly tackling with MATLAB language. It is one of the worst language to start programming with due to its lack of support in many of the problems we usually face in programming.
However, my approach was to write the code (or algorithms) in a normal way at first and verify its accuracy in results. Then optimise it in the next step. This approach helps in building a very reliable set of codes.
I was developing a software model for the WCDMA system with Rake Receiver. It was a massive coding project. Most importantly I had to test the results thouroughly. Because it is the only way I can verify the model is correct. After I fully develop the model, I found out simulation takes months. That's where I started thinking about how to improve the code. Which was pretty easy since the code is very straight forward and easily you can pin point where can be improved. (however coding improvements wasn't enough due to MATLAB's inherited problems.. I had to employ Distributed Computing to get things done faster)
This method of coding usually referred as "Evolutionary Coding" in text books. Because code it self evolves with time. Which is one of the most reliable method from what I experienced.
So my general idea is... do try to implement small algorithms (yes.. try something like prime number algorithm. Try to improve it such that within 100 seconds you calculate prime numbers upto 1 million, it should be 78499... try it) and see how far you can improve. This way you learn a lot. Because you are finding the "cure for the itch".
p.s. unfortunately my coding effort wasn't appreciated much because stupid Telecom lecturers were only impressed by the simulation results rather the marvelous piece of coding I have done. Shame.
There has only been one program ever written from from scratch, and that was "Hello World." Everything other program has been cut-n-pasted from that.
(Well, that's true at least from the advent of "high level" languages like "C", but it's probably true with respect to most Assembly programs too.)
Your Servant, B. Baggins
1.) Go back to school.
2.) Get your MBA.
3.) Outsource all the programmers' jobs.
4.) Profit!
Red to red, black to black. Switch it on, but stand well back.
When I started years ago, that's exactly what I did: coded all the time, looked at code, learned every new tech that came out, all the while working my (required) 9+ hour days....
After a few years of that, I learned to hate programming.
Now, I don't bother upgrading my Linux Box, actually, I don't even turn it on anymore, I don't even care about a new programming languages or network tech.
Nutshell: all that time in IT made me hate it. Then salaries decreased - it wasn't worth it anymore - I was just in it for the money. Maybe I didn't love it as much as you, but I hate it! Which is why I'm not in IT anymore.
Again there is proof positive that college is what you make of it. I am going to go ahead and shoot myself in my own foot on this one, but I skipped college and Now I am doing pretty well and an iSeries Systems Admin with a little UNIX here and there too. I have seen plenty of college grads who could not build aPC from scratch much less handle things in the real world of IT. I think the best coders out there today are the one who live it day in and day out. They code at work and they code even more at home. College is a place to teach you how to learn. Not a place to teach you how to work. I would suggest this to you. Learn to be confident in your abilities or at least fake it and puff out your chest a bit when you talk. Also you might want to lock the doors and stop washing and get knee deep in some code. Yo may be able to edit some C code but until you can get dirty in some god forsaken project and come out on top you going to be the first on out of a job when they resize the company. Either be a Geek and get busy or give it up and head over to sales. I think you prolly have the skills to be a pretty good geek! I mean you already read Slashdot and that is getting you half way there already.
David Vasta iSeries(AS/400) Admin & Junkie
The best way to sum up my experience is...
"If you build it, they will come."
I'm not just talking applications, but building myself. I bought lots and lots of books, and made progress with lots and lots of applications that I made because I wanted to learn and wanted to make something - Dabbling in areas that I found interesting and wanted to lean about.
Eventually, an employer noticed my efforts and offered me the chance to do it full time.
Keep learning and working new things. Dabble in unexplored areas - Even if it's on your off time. Eventually, if you keep at it, the right people will notice your talents and give you a shot in areas that you find really interesting and fun (because that's where you've been building).
While you were typing that response, I was spelling out a much longer and far more helpful posting. Go look for it. Where's yours?
Yes, I posted a snide comment at first. Honest truth? after 4 years and >$50,000 for a CS degree you'd darn well better be able to have SOME idea (note TFA insisted he had NO idea) how to start a project, how to examine the idea (no matter how bizzare) and break it down to manageable parts, and how to find relevant information.
There is growing concern that some technology-related degrees are increasingly about warm fuzzies and awfuly thin on hardcore engineering & science principles. I'm afraid we may be looking at exactly such a case; a CS degree and no idea where to begin developing a project using existing (albeit bleeding-edge) technology? A degree should give you a grounding in basic principles and problem solving, applicable to any goal; lacking that, I'd say he got gyped.
Can we get a "-1 Wrong" moderation option?
2.5 years later after school, and I *still* find that don't know very much about programming.
But I'm now very very well aware of how much I don't know, and how much I missed out on.
Lots of languages I never got to fool with. Great projects to hack to pieces, and learn how they fit back together.
I'm not a bad programmer--In fact I'm considered quite good at my job--but I'm lost and clueless as soon as I step out of the building.
So I've started to do things that remedy that. The advice you'll find here is what everyone else found works. YMMV.
From my experience, the vast majority of programmers learn how to actually program at work. Myself, for example... In school I learned to program in Ada and Fortran, which are both fairly useless in the industry unless you're doing some extremely specific things. Then I had an internship in the real world where I learned C and C++, which I use every day. But the real value in your CS education is learning general programming concepts like what a "heap" and a "stack" and a "linked list" and all those other abstract data structures are, as well as the difference between "object oriented" and "procedural" and "functional" programming paradigms, etc... None of it is extremely complicated, but I promise you, you'll be ahead of the game if you can see things from that level, as opposed to getting pigeon-holed into only knowing one specific thing, like writing HTML and Javascript. Yes, those specific things are useful, but if that's all you know, you'll find yourself very limited.
:)
Another thing to keep in mind is that there are two worlds of programming -- 1) Your work, and 2) your hobbies. If you're really, really, really lucky, then those two things will become the same thing. I've finally reached that point, and I can tell you, it's pure joy. I worked at various places in Silicon Valley for a few years, doing everything from writing BIOS code (assembly), to graphics driver code (C++), to designing web pages (perl and HTML). But all along, I put time and effort into my hobby programming, which is 3D game programming, and now that's what I do for a living. I work for myself and a good friend, and my work day consists of sitting in front of my PC in my underwear, firing up 3D Studio and creating some sort of monster character, or maybe a new weapon, then writing the code to make that model work in the 3D engine. What more could you want from a job?
And it's not as difficult as you might think to get to that point. Do your time out there in the computer industry. Learn as much as you can learn. Make as many talented and bright friends as you can, but don't be that guy who drives everyone crazy by constantly trying to ride their coattails. Pursue your own programming hobbies with passion. If emulators are your thing, dive in. There are plenty of resources out there that will keep you busy.
You: I am Jack's complete lack of surprise.
Boss: What?
You: Let's pretend.
[You find a juicy tidbit you don't want the boss others to find out and share it with him]
Boss: Are you threatening me?
You: No...
Boss: Get the fuck out of here. You're fired!
You: I have a better solution. Keep me
on the payroll as an outside consultant.
In exchange for my salary,
my job will be never to tell people
these things that I know.
I don't even have to come into the office.
I can do this job from home.
Boss: Who... Who the fuck do you think you are,
you crazy little shit?
Boss: Security!
You: I am Jack's smirking revenge.
Boss: What the hell are you doing?
[Punch yourself]
You: That hurt.
Boss: Why would you do that?
[Punch yourself some more. Make yourself bleed. Grab your shirt and start throwing yourself over the Bosses furniture breaking things and covering it in your blood]
You: Oh, my God! No! Please stop!
Boss: What are you doing?
[Make cries and make sure you get some blood on the Boss. Keep punching yourself]
You: Oh, God, no! Please! No!
You: Look. Give me the paychecks, like I asked,
and you won't ever see me again.
[And then when security comes in]
You: Thank God!
Please don't hit me again.
The first part is understanding how to solve the problem. This has nothing to do with the programming language you're using. You need to understand the problem well enough to break it down to the small, simple steps -- every one of them -- necessary to move from your input to your output.
The second part is then being able to express your solution in the necessary programming language.
While part 2 is different for every programming language, part 1 is always the same. What steps have to be taken to solve your problem. This means that you need a mind that likes always solving new puzzles. Programmers learn more than most other occupations because you have to know a good amount about someone else's occupation before you can program a solution for them.
While some basic techniques are necessary to every programmer, like how to program and utilize a data sort properly, I would say the best thing for any programmer is to work on how to solve each new problem they face. The programming language(s) you've already learned will guide you to know how much detail you solution needs to have, after which it's just your natural talent in this area. Some people are more cut out for this than others because of how they view and attack new problems. You may come to find that this really isn't your best field, but it sure is a fun one for people who like puzzles.
One clue: If every time you look at something new, the first question that comes to your mind is: "Okay, now how can I solve this on a computer?" then you're on the right track.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
I found that it's much better and easier to learn for yourself, doing things that maybe don't help anyone but teach you better. If you only learn through work, then you won't learn everything, plus you won't be driven by motivation, you'll be driven by work, and it will make the learning process more tedious.
:(){
I'm sorry, but there's a problem with the question. After having not been spoon fed know-how in systems at your school, you are now asking where you can get the spoon feeding from. The simple answer is, although it's nice that you're at least asking a question, really, go figure it out for yourself. It's the true mark of interest. You don't need people to tell you to read code or books on architecture and operating systems. If you haven't already gone through the local computer book shop and figured out how to tell the good books from the bad, then either do it now or give up.
School is a start. You can't learn everything you ever need to know in 4 years. I was fortunate enough to work with some very good programmers very early in my career. I knew C pretty well, and could structure small applications (as any reasonable CS program should be able to teach you). But the skills to write the larger apps come with time and experience.
There are some amazing bits of code in relatively mundane programs. Seek this out in what you're already working on, and figure out why the programmer did it that way. Ask him, ask if he'd do it differently now. Some people will find this annoying. Others will admire your curiosity and help you out.
That said, I think you'd be surprised what you've already learned at work.
After a life of coding (days, nights, weekends, holy days, etc)...Working in small, grey cubes in floors with artificial light, drinking coffe just to gain performance and not for enjoying it's flavor. And after doing that in many companies in many western countries, my best advice to you is... get into fashion photography. Those guys truly know how to live. Go to remote islands to shoot beauties in bikini, go to beach parties, make out with every single one of them, etc.
/. reader: What are you laughing at??
If I can only reach one kiddie with this advise. My job will be done here.
A low level job in a company is how you learn real programming, and ironically learn that 90% of the stuff they teach you in CS courses is either 20-30 years out of date or complete bullshit. Don't worry about it - we all went through that stage.
Seek out the best programmers you work with, look at their code and emulate it. Ask them how to do stuff. Over time you can learn what works and what doesn't.
Oh and remember your timesheets, status meetings and everything else. Fitting in with the company heirarchy is just as important if you want to make a career (sucks, but that's the way it is).
0. Go to your favorite terminal and access your account.
1. Create a new project in CVS or Subversion named my_projects.
2. Check out the project in a location of your choice.
3. Create the following sub-projects there.
c_and_device_drivers
cpp_apps
java
ruby
perl
docs
4. This is your portafolio. It's empty. What are you waiting for?
5. When your company asks you to code something also
code your own solutions in the language you think is best for what
you are trying to accomplish. Try to make your projects cross-platform,
you'll find out that with ruby and perl is almost trivial. When you code with
a team you can only go so far, here you are the boss, the sky is the limit.
If you are not sure where to start, concentrate in a client/server architecture.
They are fun and apply to almost anything out there.
6. Once each dir has 2 or 3 projects for each language add more for python or tcl
7. Move your repository around (port it) and share your favorite projects in sourceforge
8. Enjoy!
- these are not the droids you are looking for -
Start with the basics on simple machines:
Learn about display protocols (control code sets for VT, HP, even ADM).
Read "IBM 360 Principles of Operation".
Learn how to control hardware on a simple machine (like an old S100 system).
If you know how it works at that level, you can understand the rest.
At least not where I study. Personally I'm specializing in Bioinformatics, but there's quite much to chose from. Algorithms, AI study, Teaching, Computer mathematics and Game design just to name a few paths to take. As you might have guessed most of these are cross-disciplinary sciences. I'm studying math, biology and computer science.
The important thing to realize is that most programmers out there have no idea how to actually code 99% of the types of software out there. Most coders get very involved in whatever pays the bills and very little else.
I learned everything I needed to know about how to do my job by going out and doing research myself. First, I did a lot of background research on how the sorts of problems I had to solve had been solved by others, and then did a lot of reading until I was ready to start implementing things. And then I kept reading. I would say that in my last job I spent 75% of my time reading, and maybe 25% doing actual technical work.
The work I do is on REALLY huge computers and involves keeping them maxed out thinking about things. One of my oldest friends does graphics programming, which absolutley mystifies me. But he has no grasp of how to work with the huge computing resources I use in my job.
The point is that you are going to come across a lot of technologies that seem to be simply magic to you until you really dig into them and teach them to yourself. Its a question of having the time and motivation (which usually means employment) to learn new things. Just don't rely on your education to be your entire background. You have to go out and figure out new things by yourself.
Your place of work only provides a narrow slice of what's available, and often times that slice becomes stale. Staying updated on your own gives you greater flexibility to progress in your current job, or to change companies altogether. Most companies encourage continuing education because they benefit. But, they won't necessarily give you the direction you may expect.
As quickly as you can, get in a position of supporting your own code when it goes out into the world onto customer machines. This will teach you a profoundly important set of convictions that CS professors -- having never done the aforementioned -- are clueless about:
- bad: "Error: operation failed."
- bad: "Error 0x8009000b during update!"
- good: "Error: the mailslot update failed, probably because the mailbox is locked by another process; please contact technical support. (COM synchronize call returned 0x8009000b)"
Every low-quality error message equals ten calls to tech-support and probably two days of some support programmer's time and remaining hair pigmentation.Most programmers never acquire these convictions, because they never retain ownership of their code long enough to see the patterns that occur during field support. Hopefully you will be different... because honestly, in the long run it's easier to write supportable code than it is to have to check under your car for bombs every morning.
FATMOUSE + YOU = FATMOUSE
Where they force you to do a major project on your own for your thesis. People get to write some great software and learn a great deal - just on the thesis alone. Hope you can afford it.
If you want to learn more about programming, there's no substitute for writing code.
In real life, programming happens differently than in classes. Someone, for instance, needs to understand your code enough to be sure you're going down the right track and not incorporating too many bugs. That person with a broader view may be a manager or just a more senior programmer. In any case, you'll most likely start writing code with clearly defined problems and marching orders on how to solve the problem. The people you work with and work for will need to gain trust in your abilities before giving you more leeway. Simply put, you'll be a programmer.
Down the road, you may show some talent for defining problems, enumerating potential solutions, and writing code without being given prior guidance. At that point, you'll be a developer.
For some people, the road doesn't stop there. A very few can look at a large, hairy problem, and design systems that achieve desired results. That may mean a system of interoperating code modules, or interoperating applications, or applications that interact across different computers. Those people are architects.
Perhaps you'll take a detour in the vicinity of being a developer. Rather than pulling stuff out of thin air to create your own code, you'll decide you enjoy hunting down and squashing bugs. If that's the case, you could go into sustaining engineering. While some people find it boring, others find it pays the bills adequately without needing quite so many late nights and weekends spent coding as other types of programming work.
At the beginning of a career in programming, your options are wide open. Start doing some coding, and see what parts you enjoy the most. Find a job that lets you do as much of the fun parts as you can. Enjoying what you're doing will do a lot to help you keep going.
You have the source code for all the programs on a typical GNU/Linux box. You need to read code if you want to learn the "real" stuff. You don't need to read every lines of a program, you need to find your way and to study only the aspect that puzzle you. A good approach can be to run Doxygen on the source or just to use grep. When I started I used Doxygen a lot but now I find the overhead annoying so I mostly use grep. Anything that the program does is not that hard and most projects are well structured so you can study only one "module" without much thought about the rest. When I started Open Beat Box (defuct but there are still screenshots on freshmeat) I had absolutely no idea how a skinable GUI could be implemented.
I studied XMMS and it turned out to be an ugly hack with only two static image, the active and the inactive one, when a "button" is pressed that region on the active image is pasted over the inactive image. I studied Noatun and they opted to re-implement the whole widget set and used only Qt for events and blitting of static images. A complete multimedia player can be complicated, there is the visualization with FFTs, hot plugins loading, decoding of various file formats, network streaming and many other aspects. Taken individually all those features are easy to understand and you are lucky to have the source, use it. Most projects will answer implementation questions if you demonstrate any effort to study the code.
There are no books, if you want to learn you need to get your hands dirty. You can't become a blacksmith without playing with hot metal.
If you absolutely love coding, read coding books to relax after hours, it's the center of your life, then you need to avoid big corporations unless their main business is selling a software product. The bureaucracy will smother out all your happy feelings. The funnest places to work are small.
If you like coding, then your options are more open. Big companies often give you a shot at expensive training and new technologies.
Take frequent breaks to save your hands. Get books on carpal tunnel and read them *NOW* before you develop problems.
If you only "like" it, then learn about project management and when you get tired of programming you can move up instead of out.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
You'll have fun doing cool and interesting projects for a while, until you make the mistake of working on some large multi-tier database project to gain experience. Then you'll be stuck doing tedious database stuff FOREVER, and the days of whizzy 3D graphics and neat low-level stuff will be just a fond memory...
Cress, cress, lovely lovely cress
Don't have unrealistically high expectations for an undergrad education. There are many, many problem domains within computer science. And unless you spend 100% of your undergrad coursework taking CS courses like networks, database, graphics, machine vision, AI, embedded systems, compilers, operating systems, assembly language/computer architecture, etc., even to the exclusion of really important courses like graph theory, discrete math, and analysis of algorithms, then you just can't nail it all as a ugrad. Don't feel bad.
Working on various OSS projects, or working at a company that works in your area of interest, or reading books, is one approach. Another is to make sure you live reasonably close to a big-ish university, and take courses to fill in the areas that you feel ignorant on. Maybe you'll also meet most of the coursework requirements for a master's degree or a PhD in the process. But anyway, a undergrad degree just doesn't have enough time for ALL the courses that might be relevant to you.
Good luck!
I [may] disapprove of what you say, but I will defend to the death your right to say it.
I just had a crazy idea one day, that it'd be cool to write an emulator for that fancy new Nintendo DS that was yet to be released (this was mid-'04). And I said what the hell, and started on it; eventually, I ended up with DSemu. Of course the code wasn't massively good, and the design of the plugin architecture was horrid; that was the point. I learned much more in a year of writing an emulator, about code structure and good design, than ever I learned at college.
Many people on here have mentioned existing open-source projects to look at, including MAME; if you add DSemu and mic's Dualis to the list, I'd love to see the fruits of the DS emulation scene in your studies at some point. DSemu's maintained by Chris Double now, so feel free to throw any questions at either Chris or myself.
xkcdsw: the unofficial archive of Making xkcd Slightly Worse
Perhaps you mistyped a detail. The original IBM PC had one or two 5 1/4 inch 160KB floppy drives, but no hard drives.
The IBM PC XT added a 5MB or 10MB hard drive. Later models had 20MB or 30MB drives. They each had one floppy drive.
I would say that reverse engineering a console is hardly trivial. I would wager that a huge percentage of BS/BA of CS/CE/whatever grads would barely know where to start short of reading the source code.
Granted, if you're into something, geek out! That's what being a geek is right?
Anybody relying solely on their school to get them to the next level, is missing the point. Your school can only do so much. Sure, you can be quite competent, but if you're looking to do something truly remarkable, you alone are solely responsible for really jumping ahead of the average programming feats found in a lot of day jobs.
-Get into an OSS project you're interested in
-Do research, read books, join lists on specific technologies involved. Whatever you end up doing, you will no doubt end up learning arcane facts about the tech you're using.
-Dig through the code try tackling a couple changes. (Sometimes it can be helpful to do a diff between different the code bases between two incremental releases to see the kinds of changes made to implement a feature or bug fix.)
-Help with the testing and debugging or add a new feature for real.
-Eventually get more and more involved until you're one of the main folks adding new features or planning the next big version or spin off app.
It's a growth thing. Anybody can do it.
It's my experience that programming is about being good at studying new info and incorporating it quickly. You take your fundamentals, and use those to make sure you're not accidentally incorporating code you have no idea how to fix, and pull together what you need.
There aren't a hell of a lot of solutions out there that really require novelty. It is mostly being a quick study, settling on the solution that most resembles your approach to coding, and then breaking out your jigsaw to make the solution fit your problem. If you have time, you sand down the rough edges. You do that enough times and it becomes your standard response.
To the extent others recommend you look at OSS projects, I strongly agree. Not as much for the experience, but for the knowledge of where to start looking for code. The prime driving force behind OSS, contrary to other claims about liberty and sticking it to the man, is there is no good reason to reinvent the wheel every time you code.
And if that approach doesn't sound useful to you, then you probably picked the wrong profession.
For the purpose of knowing where I come from: I have two bachelor's and neither one is in a computer-related field.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
That doesn't help you now. Well with geezers like me the answer was, get a micro, and learn *everything* about it. I mean everything. Schematics, ROM source listings, whatever you can get your hands on. Learn how to program every single peripheral in the machine. Build boards to interface to it. Trace through the OS. Think of utilities it needs and write the fastest/smallest/best version you can. Sounds tedious and boring but actually it's tons of fun because you *love* everything about computers. Right? The bad news is, this might be where you find out you aren't as big a nerd as they told you you were in high school. Either you are or you aren't, you can fake it but then it'll always be an uphill battle.
The other bad news is, present-day computers come with so many layers of junk piled onto them that it's almost impossible for one person to learn everything. The OSes are vast and not well-documented, they don't give out schematics any more, and the bus can't be interfaced to with 95-cent 74LS245s any more. And the mishmash of high-level languages and libraries mean you're not programming a computer at all, but some crazy abstraction of what various armchair CompScis *think* computers should look like. Which can be fine but not if you end up with the kind of slippery brain that can't get a grip on anything real (like emulating a game console), and there's a lot of that going around.
OK so ideally I'd like to suggest that you go back in time and get an old computer that a mortal can understand, like a PC XT or an Apple ][ or TRaSh-80 or whatever, but I know you won't. What might be about as useful though, would be to get a developer's kit for a simple microcontroller IC. They're a blast, and not too expensive. The vendor is trying to you get you excited about their architecture so it usually comes with everything, even if some of the software is trial versions, and there's sample code and a debugger and some kind of download/debug cable and it's all intended to be fun. Now you've got a tiny computer (probably more powerful than those early PCs, except for the lack of a keyboard and screen) with schematics, and manuals for the CPU and all the I/O. You think this is irrelevant to C/C++ life but it's not.
Dump the C compiler though and program the little doohicky in assembly. You've probably been brainwashed by your schooling to hate assembly but that's a load of BS. It's not for everyone or everything, but neither is any other one language. You may never use it again, but getting good at it on one architecture is the best start for firming up a nice nerdly brain. Getting to the point where every single byte of code on the machine was written by you is a huge step.
The applications might be stupid -- blinking an LED, sending your name out an RS232 port, maybe driving a keypad or an LCD display. But once you've gotten really good at taking total command of a small computer, all the hocus-pocus is gone forever and even if you never learn any other architecture to the same level of detail, you'll be able to make educated guesses about what's hidden underneath all those layers of high-level facade. It'd be directly helpful to understanding a game console, and it would give you a great general ability to zero in on the specifics of any programming project.
When I graduated from college I had the same thoughts. I couldn't imagine that my school programming projects were going to prepare me for the "real" world of programming. After all, you are probably making the jump from projects that last one or two weeks with a handful of programming partners to projects that last months and years with possibly hundreds of people working on them. So you ask, how can I possibly make such a giant leap? The good news is that it's not like any company is going to make you lead programmer of a multi-million dollar project for your first job out of college. You'll probably get some pretty well-contained, narrowly-defined projects to work on to start. But over time you will get more responsibilities and work on more critical pieces of code.
I've worked with a lot of programmers just out of school. We sort of have to re-educate them to think about their decisions in a more global context. They are no longer working on projects that get tossed once they are graded, but ones that might be used for years to come. I'm only 4 years out of school myself, but I feel that I've learned a lot on the job that I never learned in school. So what use is a CS degree? It teaches you to think like an engineer. I believe a software company hires someone out of college, not for what they know, but for what the company can teach them. All that theory will actually come in handy because it taught you how to think and approach problems. So in short, don't worry about it.
"Oh dear, she's stuck in an infinite loop and he's an idiot" -Prof. Farnsworth (Futurama)
Write lots of code to develop your own style, even if it's only for your own use. Maybe you can volunteer at an agency that needs free programming support in your local area?.
As others have suggested, pull down some open source code and have a go if you can't get hold of lots of code at the office.
Seek out a mentor -- someone who enjoys and is good at explaining concepts that you might not have been exposed to at school
Read lots of books. I've spent thousands on books over the years. Sometimes there's only one or two good chapters, but if those chapters illuminate some critical point that you don't understand, it's money well spent. These days you have the advantage of things like Safari so that you can preview lots of things inexpensivley before plunking down hard cash for a dead tree copy.
Good luck!
The contest for ages has been to rescue liberty from the grasp of executive power. -- Daniel Webster
I know... Cliche, right? Well, in programming, it's usually true.
Everyone learns differently, but by particular method is to pick an interesting project that's just a few steps past what you already know, and figure out how to do it.
Don't start from Hello World and try to write a complete operating system. Add a piece at a time, and make sure you learn something new each time. When you find something unfamiliar, figure out the component parts.
For instance, with a console emulator:
1) You need a way to decode the ROM files (This would take a lot of research, as it's proprietary stuff that's been cracked)
2) You need a graphics engine
3) You need a sound engine
4) You need an input engine of some sort (Keyboard, gamepad, etc)
And so on... Each of these components has its own problems to overcome, but each one is also a lot simpler than the emulator as a whole.
Of course, an emulator might be too big a step, so what about just a graphics engine? One thing I wrote when I got bored was a partial physics engine with a graphical layer. I also messed around with maze generation, 3D rendering, genetic algorithms, etc.
Find something interesting, and teach yourself how to do it. Even if you don't succeed, you'll learn things along the way. If you hit a roadblock, spend some time trying to figure it out yourself, but if you can't handle it, search the web for a solution and LEARN from it.
I know I babble a bit in my posts, but the key is to just pick a project and do it. You can't become a guru overnight, but just keep learning.
"The amount of intelligence on this planet is a constant. The population is growing." -Cole's Axiom
Either you didn't pay attention or your school wasn't that good. Sorry.
A "console emulator" can be a straight forward emulator in which case, you should know enough from just your basic architecture courses. Did you discuss instruction decoding and ISAs?
Modern console emulators are probably Just In Time compilers. You should have had a compilers class and the prof should have at least mentioned binary translation. Even if they didn't, you should have spent a little time on JITs in an architecture class.
A college education is not necessarily about knowing how to solve problems, but how to decompose a problem into a series of problems that you can then figure out how to solve. For a console emulator, that may mean that first you know you have to read about the architecture your emulation (what's the ISA, what are the components, etc.). Then you realize you have to parse the actual ROMs (here's where your automata/compiler background kicks in). Then either emulate each instruction (tedious) or do dynamic translation.
If you wouldn't even know where to start, you didn't get the right education. I'd recommend trying to find a masters program or pick up some text books.
> realize for some of the software being written nowadays,
> I would have absolutely NO IDEA how to even begin writing it.
http://www.mcdonalds.com/
Bark less. Wag more.
It's probably the easiest system to emulate, but fundamentally works the same way as more complex systems.
A great way to learn is to watch somebody else, that's why Kyran and I founded ShowMeDo.com a year ago. We host tutorial videos (to date all 104 are free) made by our users, so you can watch a fellow geek introducing a subject.
We have videos for Python, Java, Ruby, Perl, a bunch of miscellaneous utilities and we've just started accepting videos on graphics programs (Blender 3D and Flash 8 so far). We'd love to have more submissions, naturally :-)
We put source code into the wiki and we'll begin to push the forums soon so that fellow learners can help each other to progress. If you like the videos then don't forget to leave a comment thanking authors for their time!
Both Kyran and I realised that it seems odd that we learn in seclusion via books (and hacking around, of course), yet we can learn so much more when we're with someone who can answer our questions. We can't give you a personal expert, but we can let experts share their knowledge with you. Our ears are always open for feedback, we'd love to build a better learning environment.
(posted anonymously of course)
..etc. This is where you want to bust your ass and really make an effort.
1) Make a decision about your work environment:
Is this a company that you'd like to grow up in or is it something that pays the bills?
There are some great companies with really smart people, where the environment fosters knowledge and growth. You will learn from others and will be given some latitude to explore your own ideas
And there are some other companies, where there is 3 'leads' for a programmer (trust me, I work at one!). Lead in my company means, a person, how just bounces around email, insists on being present at every meeting, and signing the programmer up for some impossible deadline, forcing the programmer to work long hours and weekends AND finally takes all the credit for your work in some fancy power point presentation. If this is your company, you should either consider moving to a better one or just treat work like, you know, WORK : like a 9-5 affair.
2) Pick an area that your a passionate about and work on it.
Are you passionate about user interfaces but your day time job is programming soul-less web services for an enterprise application? Then join an existing open source project. (I'd advice against starting your own, just yet. There are thousands of open source projects on SourceForge that were started out on a whim and stay stale after 2 weeks. I don't need a 100 incomplete, alpha version mp3 players, I need one or two kick ass ones). IN this example join some thing like KDE or Mozilla. Lurk in the mailing lists, learn, suggest _AND_ implement improvements. you will learn.
It is important to pick an area/project that you are passionate about for this. Because when coming home after 6 hours of sitting in front of a monitor at work, the last thing you want to do is sit in front of your laptop for another 4 hours. But if you really like/care about the project, you will find a way to spend time on it.
3) Pick an area that possibly might interest you and monitor its progress:
Lets say the field of Bio Metrics interests you. Join a news group and follow the industry progress. Who knows some day, your current experience and the 'domain knowledge' might lead you to do something on your own.
good luck
I think that it has a lot to do with the personality-type of the person involved.
I've been a "computer professional" for 15 years now. I started out in a software company's shipping and receiving. I moved to a hardware-assembly/quality-control position. From there, to tech support. In that era of computing, you generally had to really monkey around with DOS's startup files to get things to actually work. I think this is what really got me started sharpening my skills.
But there are different personality-types in this field. There are people who are generally more on the "business-side" whose skills focus more on network design, ordering hardware, working with vendors, etc. There are people who are more oriented towards system-admin tasks, including security, configuring network applications, accounts, etc. Some of these people take "the next step" and get into a lot of scripting and integration of systems. Then some of those people grasp that there's more to life than VBS and/or Perl, and dabble in programming. For me, this has been the most difficult step - and I feel like I've been struggling along this path for 15 years.
There's a lot to this that I just never "got" no matter how much I hacked around or scripted. There's always a "black-box-ish" element to the OS that you're dependent on, and you try to look into that black box and figure out what it's doing, so you can bend it to your will. API's are a path to that black box. You tend to select a tool based on it's ability to use a given API to talk to that one aspect of the OS you need to use. The scripting languages tend to cover about 70%. (at least on the Windows side).
Then there are people who somehow "get it" - they are programmers, they were programmers from the start. I don't really know what they "get" that I don't get. When I was 12, I just could not grasp C. I didn't really figure C out until I was about 25. And even since then, I've never encountered a situation where I could use C to solve a problem, that some other solution (scripting) couldn't solve for me. I'm sure there are situations, I just never encountered them. At certain times, I'd even look at the source code our coders were writing, in C++, and while I always felt that there was no way in hell I could ever write that stuff, I could "follow it" - and from time to time, I could spot places where mistakes were made.
Now, I'm going to school to get a CIS degree. And what I'm learning is that, you can learn to write a Java "Hello World" program in an hour or two. But diving in and writing a GUI application, or a game, something like that can take years of 10-hour-day experience. And then there's the Discrete Math. This is a class I just took, and a lot of bits and pieces that I've come to understand about software development really comes together under the ideas taught in this class. Set theory, functions, directed graphs and trees, logic, etc. Stuff I would never ever use in any kind of admin scripting. Sure - if I had to figure out a sorting algorithm for a report generator, or text-parsing, I might use that; but these are problems that have been canned and pre-packaged for script writers for decades. There's probably almost no benefit for me learning these things to keep the job I've been doing for the past 15 years. And most career-paths for higher level programmers START here - it's not a place for me to move to (as far as I can see) more of a place to start from.
So, among the programmers, there are many, many specializations. There's people who write microcode for hardware. There's people who write forms for database front-ends. There's database back-end folks. I could go on and on. There is not a lot of cross-fertilization among these disciplines.
Bottom line; for you to come out of school with some c/c++ experience and wonder where you're going to go - I suppose is probably natural. You find a job. Water flows downhill. You'll eventually settle into your niche, and apply your skillset, and your way of t
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
You probably do, you're just letting yourself get overwhelmed by the size of the problem. As the Arthur C. Clarke quote goes, "any suitably advanced technology is indistinguishable from magic". That's what you're dealing with here. Think back to the lectures that were about managing complexity... when I was in college, it was called functional decomposition, it might be called something else now ( OO A&D? ). That's how you proceed. Like anything else, its a skill that will improve the more you use it. It's the same thought process that leads you to organize your code into classes/modules/functions/methods, but on a larger scale.
As far as your question about how to learn about things that interest you... learn it on your own time! Most of the really good programmers I've known over the years, do it that way. If you're going to last in this field for any length of time, you have to keep your skills current. Don't count on your boss giving you training to help with that. It's rare. Equally, its unlikely that you'll get help acquiring the skills you need for your dream job (writing emu's or whatever). You'll need to do it on your own time, either with your own projects, helping with an OSS, etc.
Flowcharts, Sequence Diagrams, class diagrams, etc. So go out and do research, gather requirements, etc as if it were a "Real World" project. In your research, read how other people have solved the problem.
Basically break the problem down into a bunch of smaller, more manageable problems.
Integrate Keynote and LaTeX
...anger leads to hate, hate leads to suffering and suffering leads to Microsoft Visual Studio, which leads right back to suffering.
When it comes to work, you will more often than not take over, extend, expand and finish existing code rather than start from scratch. Especially as a new coder. You'll be dumped into a late project, expected to ship by yesterday.
Ok, without trying to be the jaded, disillusioned progger I am, it is usually the case that you'll be hired to fit into a team that's already working on something. Also, as the new guy you won't be the person designing stuff, your task will be to flesh things out, i.e. transfer the pipe dreams of your superiors into code.
So if you want to up your skills for work, go to sourceforge or any other source of sourcecode, find a project that interests you, download it and start expanding on it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I have a degree in CS as well, but I have used virtually nothing I learned in college in my programming career. I learned more in high school than I did college -- granted, by the time I went to college I was familiar with all sorts of basic concepts from sort types to mathematical formulas, and I worked in more than six different languages before I started to get ass-raped by a college that flipped its entire curriculum to center around the computer language ADA because they got some grant from the government to upgrade their computer center. I recognized then, as is obvious now, the politics involved in institutions like these that have very little to do with creating employable, productive, much less innovative members of the community.
More than ten years ago I received Editor's Choice in PC Magazine for a software program I wrote. I was working on this software as an independent consultant. Before and after that I worked for bigger companies and the programming was always the epitome of mundane, if not in some cases, dubious (building accounting systems with back doors at the request of corporate). It was only when I got out of the rat race and started doing independent work that I had any idea how innovative and creative I could be. There may be some good companies out there that break the mold, but IMO, they're few and far between.
I especially like the late-night commercial showing two reformed potheads playing a computer game and saying, "I can't believe we get paid to create computer games..." As if that really happens.
Most of the really good people I've worked with have had either (A) a really good education and have read a lot of good books, or (B) they are self-taught and have read a lot of good books.
It's just like school, really. Read. Do the exercises. There are tons of books (some even good) on how to write video game engines, for instance. (Just avoid the Sams "Learn game programming in 31 milliseconds!" crap). In the absence of helpful literature, well, I didn't know how games worked until I just sat down and wrote a few (a couple years later I had shipped several titles for a company you've definitely heard of).
You could do worse than to join the ACM and take advantage of their online library of journals and proceedings. It's a super way to come up to speed on just about anything in computing.
Any sufficiently advanced technology is insufficiently documented.
The most important decision to make now is "what do I want to do". It's a hard one, but start by looking into what field you want to go after? Game programming? Any that give you lots of money? IT?
Next thing you need to do after deciding that is start focusing on it. If you want to be a game programmer, start programming your own game. A company that hires you won't just look at your education, they'll look what else you've done, and a big bonus is "self starting". It doesn't matter if you don't know how to make a finished game or a finished project you can learn how to do the final stuff, and most of the time they don't care. What will matter is that you've designed something and worked towards it. In addition the code can show the employers "I know how to code".
If you want to go into IT start looking for work now. Anything you do outside of the field isn't going to help you too much in the long run, but be sure to learn as much as you can about networks and hardware for it (routers and so on, not just lan adapters). Try to learn Linux as well for IT, that might not help you but it's good to know it so you can work with networking apps with out dealing with the BS that Microsoft gives developers (dear god, what ever you do don't expect CSocket to be all you need for networking experience).
If you want to make money start networking. And I mean P2P.. Or rather that's person to person. Talk to people who can help you get jobs in major companies. You want a job in finance to make the most money the fastest.
Overall it's important to take a direction and start working towards it. The biggest mistake you can make is think your goal is to radical to start working towards it (something I had to learn.. Now I work at a video game company. What I always wanted to do.)
The second mistake you can make is undervaluing your skills. Don't take a job for 24K, even if they promise a pay raise in 3 monthes (finance, personal experience.) Demand 40K a year at the minimum. Short and simple that's the bare minimum you deserve and that's even low. If you're in a good job, you should be making more.
Also always be willing to move, that'll give you many more options, and don't be afraid to seek out big name companies to apply to. Nothing is wrong with apply somewhere expecting relocation expense. They should be provided.
Don't worry if you get into something and don't like it. You're still learning and no one expects you to be a good coder yet, school is to teach you the basics, they'll train you to be the programmer they want (or they arn't worth working for).
It may sound like voodoo at first, but it's actually quite simple (assuming the machine you're emulating is well documented!) but time consuming to get right.
Take a CPU emulator for instance with some code that runs on it. You have to have a very good knowledge of the opcodes of the CPU you are emulating (say, a 6502 for example). You need to know how many cycles each instruction takes, what arguments it accepts, what the output is, how many bytes the instruction is and the size of the arguments (can be variable depending on the instruction code), what the registers and CPU flags will contain after each instruction, etc. In short, you need to have detailed documentation on that CPU to understand it. If what you're emulating isn't completely documented, don't waste your time. Wait until you're far more experienced.
So, basically, your program will sort of work like this:
1. Read a byte (typically) of code from the program to be emulated.
2. Use a table lookup to determine what that instruction is.
3. Read X number of bytes (based on what was determined in step 2) that make up the operand.
4. Jump to the handler for that instruction, which will place a value in a memory location, do a mathematical operation, etc. Whatever it takes to duplicate the functionality of the original CPU instruction. This is the meat of your emulator and the tough part, especially if you want it to be cycle-exact. Handling the storing, modification, and retrieval of variables in memory is a big part of this.
5. Increment the virtual instruction pointer and read the next opcode in the program.
Extremely simple overview, but if you do some research on emulation and virtual machines, you'll find out a lot more. It's quite interesting!
Learning theory is being educated, learning how to program is being trained. You will need to know both to be a professional software developer. You learned exactly what you are supposed to learn in college. Your study has given you a wide array of tools that you will use to train yourself now. Don't be discouraged that you don't know how to program an emulator right out of school, as an educated individual you can learn how to do it on your own. Everything is based on theory one way or another... now that you've studied some of it, you are in a position learn more specific applications of what you already know.
I assume graduate school is not a consideration right now since you're working.
Do you like tinkering? That is the essential skill/attitude. Everyone that I know who is happy and successful in software is a tinkerer. A hacker, in the old and honourable sense of the word. When we were kids (before computers, if you can believe that!) we amused ourselves with homebrew "chemistry experiments" and electronics and taking apart household appliances, especially clocks. Now we do the same thing but in software. (Most of us continue to hack in other fields as well, building airplanes and clocks and furniture.)
The other vital skill is learning. Things keep changing. If you enjoy learning about cool new stuff you'll have no trouble staying employed. If you've written some non-trivial chunks of C/C++ and you have a CS degree from a decent school like Berkeley you'll do fine. Be good at your assigned tasks so you can get it done early and done well. (Try not to get involved in office politics if there is any.) This frees up time to think about cool stuff, whether that's free software or work-related extra credit.
And don't forget there's life out there beyond software and work.
Unlimited growth == Cancer.
A good programmer will start with a "problem" and then design a solution.
It sounds to me like you are looking for a solution without identifying the problem. Because there are so many programmers like this, ones who feel compelled to create something for the sake of creating something, for their own ego or amusement, in lieu of any real world application, the industry is filled with crappy technology that doesn't serve any significant purpose. So let me be the first to discourage you path before you even start and add another dingleberry to the crop of mediocre technology that's out there that will fail.
No disrespect, but you're going about it wrong. If you want to program a console emulator, hook up with the teams online involved in that. Oh you want to create your own? This kind of thinking won't get you anywhere. The real cool technology is what you learn from other people through experience both in coding and (most importantly) through an *understanding of the application and the market you're addressing*. So what you need to do before anything else is not whine about how you haven't created the next Halo, and figure out what field, in addition to programming, in which you're an authority, and what void in that field can you develop something that addresses a real need or solves a problem, and then and only then, should you be asking people how to develop such technology.
The best software in the market will have always been created by people identifying a niche, a need, a problem, and then designing software to address it. Not the other way around.
But with a Computer Engineering degree from a ranked school. I wanted to develop FPGAs, but there were no jobs for B.S.'s with low GPAs, so I had to make myself marketable and have a good time doing it. Most of the jobs where I was living (due to finances) only hired M$ programmers (vomits on shirt), so I learned how. I learned VC++, C#, VB (vomits again), the registry, the messaging stack, etc. I did most of this on my own through reading books and trying things, but I'm still learning. That's the point. I'm at my third job, and this one I'm going to stay at because I like it. The difference between when I started and now is my confidence. Even if you don't know how to "program" or whatever, you should understand that with the education and experience you have, you will not have a difficult time changing that. So, now, when I'm asked if I can do something, I always say "yes", because I can...even if I don't know what I'm doing at first. Getting your masters will help you land a "sweeter" job, but I'm making more money than any of the masters kids with the same experience as me because I'm not specialized, I can do what they do (maybe not as well), but I can also do things that don't involve programming like (ZOMG) talking with customers and writing requirements that suit their needs. No programmer is perfect in their code, and they're all learning new things. Books, groups.google.com, peers who wrote an application you liked, OSS, etc...use all of these resources to go where you want. It just takes time and (for me) a positive attitude towards it. Good luck!
Shocked I am, just shocked! Good lord, this means you'll have to actually, -gasp- develop experience!
;-)
Not to worry, my young friend. Your experience is relatively normal, except that you seemed to have moved to self-awareness of your lack of total knowledge rather quicker than some. Realizing that you don't know something is the first step to changing that situation.
As the others have said, a healthy dose of curiosity will take you a long way. So will realizing that you can't know about everything, so you have to focus down a bit. I have tended to read a lot about things that are on the periphery of whatever I am doing professionally at the time, which led me from COBOL to C, from C to various other languages, into the world of GUIs and databases, with some network and web along the way. Focus first on the problems that are problems for your employer, and the odds are good that you'll make more money, and get a reputation for figuring things out, which will cause harder, more interesting problems to come your way.
Also, realize that even though HR departments are asking about some list of technical skills, what the employers really want, and what you need, is the meta skill of figuring out how to get computers to do what your customers want, reliably and economically. This requires a contextual knowledge of the whole ecosystem, the players in the eco system that know things you don't, and a bit of focus on the actual human problems/goals that are motivating whatever project you find yourself on. One key measure for you is to look around at whatever place you end up, and look at what the more experienced folk do. Ask them for some recommendations of areas to look into, and for materials that they recommend. Odds are pretty good that you'll get some good pointers, and some suck up points as well.
Good luck, and enjoy the industry. Every job has it's down sides, but the whole world of bits and bytes has the advantages that George Bush Sr. once ascribed to the Vice Presidency: " It pays well, it's indoor work, and there's no heavy lifting."
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
Well, I've been programming professionally for over 25 years, so ...
The real skill in programming is knowing how to break down a complex project into suitable pieces - top down modular design. The skill is not just being able to do this at all for arbitrarily complex projects, but being able to do it well - to select a breakdown that will be easy to develop and maintain, easy to debug, easy to modify and extend.
I really don't think there's any substitute for experience in learning this, since that's the only way it's really going to sink in and become second nature. The best thing you can do therefore is to practice, and push yourself with new challenges all the time. At work push to get on the most demanding projects, and out of work do hobbyist projects that push yourself too. When you switch jobs, don't shy away from switching industries and into new areas. You'll become a stronger programmer by being a generalist rather than a specialist, as long as there's also plenty of depth (don't skip around *too* fast).
What you're really learning via experience is a set of design patterns and approaches, so that when you look at new problems they will intuitively fall apart into "obvious" breakdowns. Nowadays it's fashionable to read books on design patterns, and that can maybe help, but I'd tend so suggest a more back to basics approach of just paying attention to the interfaces between your modules... A good modular breakdown is one that results in modules that may have a fair degree of internal complexity (but not too much - break it down further), but have simple/thin external interfaces. An overly complex module interface is often a sign of choosing a sub-optimal modular breakdown (you've drawn the dividing lines in the wrong place). Good modular design will also hide as much internal design as possible to keep things simple and flexible - if you've kept the interface simple and abstract, then you have more flexibility to change the implemenation.
Ditto. Throwing my own 2 cents in:
I had some vague notions, and had even written some toy programs that implemented those notions. But otherwise I sorta jumped head first into writing my emulator, jzIntv. What made that even more exciting is that there wasn't much documentation out there, and basically only one person, Carl Mueller Jr., who had done any real reverse engineering work on it.
I built from his documentation and experiments using his emulator to produce my own. (His emulator was a closed-source, DOS-only implementation. Mine is open source and cross platform.) I think for me, the most interesting parts were in learning the system, reverse engineering it in the areas that were still quite grey, and documenting it for everyone. I also put together a development kit for the machine, because Carl's tools were, again, DOS-only and closed source.
It's been a hell of a trip, and I managed to learn a lot doing it. It's been my background project. As part of that, I've also written a couple of games, and am about to release probably my second largest non-work programming project, Space Patrol, pretty soon. (I consider jzIntv/SDK-1600 to be one very large project, although Space Patrol will get absorbed into that megaproject after it's released.)
Nobody taught me how to do any of that. I'm an EE by training. But, you pick up on things if you read and ask questions. It's what you gotta do. And if it's going to be a meaningful hobby, it's gotta hold your attention. So, on those points I highly agree w/ the parent to this comment.
--JoeProgram Intellivision!
3) Know your platforms' hardware and software. Install a
from-source Linux distro like Gentoo.
Might I suggest that you actually try a Linux-From-Scratch system for this purpose? By the time you're done with it, you'll know the
I am officially gone from
To become a master one must...
look to the master, follow the master, walk with the master, see through the master, only then will you become the master.
Have a friend sit down with you and help you out, learn from your mistakes, learn from others, learn from a master, and if you stay the course you WILL become a master!
Lots of people have already given you some great advice, especially downloading small-to-medium sized OSS projects (and then later a larger one) and examining their source.
I would explicitly add that you should watch how those programs behave under a debugger, to see what they're really doing at runtime. In my experience, even relatively terrifying programs can become comprehensible in a very short amount of time using this technique.
When I moderate, I only use "-1, Overrated". That way, I never get meta-moderated!
Spoken like a true geek. That's not a knock by the way. I think it's important to bring up the point that if a person is not enjoying his field of work then it's a good idea to evaluate what they really enjoy. Don't become a for life office stiff and be content with it. The sooner a person realizes what they want the happier they become. Don't let people fool you, your life is your job and you might as well enjoy it. Take risks and oh... Carpe Diem!
Morality, filters both ways.
College doesn't give you a career. Instead, college gives you the tools necessary to build a career in a specific field.
You don't know everything. Nobody does. An education gives you grounding in many disciplines, but not mastery. Believe it or not, any undergraduate degree is a survey degree. It isn't specialized.
My boss has a PhD in SQL. He teaches classes at universities. His students taught him how to better use different types of queries. They didn't teach him because he's dumb, but because nobody out there know everything, nor does anyone out there know all the tricks, nor does get all the possible implications of every technology all the time. Quite simply, there's a mindboggling mountain of information out there and you can't know it all.
I know perl. Well, I know a slice of perl. It's a very useful slice. I use regular expressions to text mash and save myself huge slices of time converting documents. I don't nearly know everything about regular expressions. I also know some basic HTML, but I'm nowhere near being an expert. I know mediawiki format, but I'm not expert in everything that it can do. However, I have learned each well enough to custom convert HTML documents into mediawiki format and auto-tag most recurring vocabulary that needs tagging. Note that I don't know how to build an interpreted languages and I don't know how to set up mediawiki templates. I depend on others to know these things.
That example above is the real world. I could choose any one of them, spend a year studying them, and still not know them in full detail.
So, like folks say, pick a place and start. You will know some of what you need, but you will need to learn many new things, too. That's normal.
You asked: How did you improve? Programming on your own? Through work?
Which is really a big question, but usually bears down to "programming on your own" in some capcity. Most work places take little interest in improving the quality of their coding staff. Everyone will pay for exams and some will pay for courses, but let's face it three days in a class room is not enough time to "learn .NET".
Of course, if you want to learn "cool stuff" and that's not what your workplace is doing, then it's on your own time. Most companies see no benefits in "over-training" their staff, they live under the concept that staff "can know too much".
So if you want to succeed, find your own way. Join an Open Source project, read a book on the subject, extend your degree with a Masters or PhD, target a professional exam and grab the training materials. Pick a subject and just do something. Pick a project you want to complete and learn what you need for that project. If you have a target and goal, you'll have fun doing it.
Learning how things work is one thing, and you'll learn how the relevant things work on the job. The real difference between school and the work day is people and process. When you're working for a company you have to deal with the tools that they use, the process (or lack thereof) that is in place, and the management structure that you will be forced to deal with day to day. These things make the difference from job to job and company to company. So being informed about how good companies run and what sorts of tools they use to do their jobs is useful. Often schools lack exposure to multiple development environments, revision and problem tracking solutions, and of course dealing with the business and sales forces that are often directly opposed to your opinions. This information might help you choose a good job over a poor one and, make no mistake, there is a difference. These days I think (as others have mentioned) that taking advantage of the wealth of open source projects out there is an excellent resource. Find one that is commercial level, not just a bunch of kids who want to do something cool. Something run by experienced professionals (who MIGHT be kids, it happens). Sign up and start taking on tasks and seeing how they actually keep the ship running. Get used to co-developing and merging code, documenting it for others to read, and testing in a different way than you might have on small projects in school. Keep in mind that each thing you check in ought to be as close to production quality as possible, and see how a large project can take a list of gazillions of problems and continue to chug away and produce releases. Learn how good projects are architected with growth in mind, but with concern for getting step 1 out the door before getting mired in step 2. The details fill themselves in, just get used to the environment. Oh, and more importantly, do this on a very part time level while working a junior position that pads your resumé(or while unemployed/at school). The rest of the time, go out and socialize and enjoy other hobbies. Don't burn out, and don't turn into a closet case, because nobody wants to work with uninteresting or antisocial people. I would always hire somebody smart but enjoyable who would go out for a beer with the team or help keep things friendly and loose at work over somebody who is much smarter but absolutely no fun to be around. There are places that hire purely on scores and grand ideas, but most business is a social endeavor. At any given job not everybody has to be a wizard (and somebody fresh out of school is not hired for their all-encompassing knowledge), in fact with too many chiefs nothing will ever get done and a business will tank. So you have plenty of time to learn while you work your way up, and lots of people to learn from. I see a lot of people giving you flack for coming out of school without a lot of knowledge. Well frankly most schools are not good for learning how everything works. There is too much out there for them to focus on how a NES emulator works. They are busy with fundamentals, with teaching you to work hard, and seeing if you can absorb and learn. Thats all a degree means. It means you can handle whats thrown at you, not that you already know how to do it.
My advice to you is the same I took:
Thanks, and good luck!
Keith
Support bacteria. They're the only culture some people have.
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.
Well, of course you wouldn't. One of the tough things about reading /. or anywhere else like this (and moderation makes this worse) is it makes you think everyone engaging in the discussion understands this stuff except you. (This extends beyond tech, as we get the meteorologists and the theoretical physicists poking around in articles about their expertise as well.) I know a few things well enough to make you feel out of your league (and in fact am old enough to have written applications that would run on some of these ancient emulators of which you speak), but I learn new stuff all the time. You're not as far behind as you might feel.
As for how to move beyond the academic stuff in your training -- I have an obvious answer and a non-obvious (hopefully not too vague) answer. The obvious answer is, learn stuff everywhere -- work, home, wherever you're poking around code. And learn every which way -- writing, reading, listening.
But I must say the way I think you'll learn the most is to look at every piece of software you encounter and wonder, "Is this the easiest way to do this?" In my experience, 90% of the time, the answer is no. Or maybe it's 100% but I'm only smart enough to see it 90% of the time. :) I guess what I'm saying is you'll learn more by attacking what you see and trying to improve it rather than by trying to imitate it. Because most stuff sucks (at least in the environments I've seen; maybe there are exceptions).
Good luck.
Stick to c/c++. Read and learn everything these guys did and wrote: D.Knut, B.Stroustrup, G.Booch and so on. Some links: http://www.techreview.com/InfoTech/17831/page1/ http://sztywny.titaniumhosting.com/2006/07/23/stif f-asks-great-programmers-answers/
As a developer for 10 years now in the semiconductor industry here's some advice: If you work at a big corporate cubicle environment your coding skills are much less important then your technical writing and communication skills. You will spend most of your time engineering software and writing endless specification, requirements, design, and test documents. Anything I'm not sure how to do gets worked out in the design phase so by the time you start coding there's not much question on what you are to do and the coding is finally the break (at least for me it is when I can sit in my cube listening to music for 8 hours while coding and being left alone) from endless meetings and paperwork. Learn constantly from the internet. If you wonder how to do something research 50 ways to do it on internet pages and read and understand as much code as you can. Even if it may not completely apply at the time it may come up later at some point. Be flexible. If other engineers critique your design (and they will trust me, everybody's way of doing things is better than everybody else's usually) be open minded about it and not as personal attack. Review as much of the other engineer's code as you can as well.
Take a complex problem and break it into smaller parts. Then, see what technologies/programs/libraries already exist to solve those problems. Anything that doesn't exist, make yourself. Anything that does exist but isn't quite right, either extend it so that it is, or review your requirements to make sure you're not thinking of it in the wrong way. Finally, combine all those technologies and make your solution. Use it, then six months-two years later start all over from step one.
You should have learned this in your Software Design course.
"Why Subscribe?" Good question...
The next most important thing is to look at those smaller logical issues and be able to say, "These are the things I need to know in order to work on those smaller tasks."
And finally, when you say, "These are the things I need to know", being able to honestly evaluate whether you actually know how to do them and being able to start to learn how to do them is the final step.
For example, I really don't know how I would go about writing an emulator. So, let's take that for the example. What are the things I would expect an emulator to be able to do?
So, what do I need to know in order to do these things?
Load a game: I need to figure out how to generate a ROM from a device -- cartrige, cd, DVD, etc. Then I need to be able to load that into storage of some kind (memory, hdd, etc) on my emulating device.
Execute the game code: Okay, so what kind of hardware and software did the original game code run on? Was it x86? Z80? MOS 6502? How do I go about mapping the binary instruction code for the original CPU platform to my current CPU platform?
Accept input: How do I take input from my keyboard/mouse/controller and map it to the input routines of the game code?
Display video game output: How do I display the kind of graphics that the original ROM would display on the emulator host? How would I map the graphics calls of the ROM to equivalent graphics calls on the emulator host?
Play audio output: How do I play the sound on the emulator system, and how do I map the ROM calls to the host system's audio output?
Intercepting "load"/"save": How does the original system handle save games? How can I transparently intercept ROM calls to those saved games and map them to something that makes sense to the host system?
And there's probably plenty more that I'm missing. But being able to just start like that is a huge deal, and being able to realize, "Gee, I really don't know how that would work. But maybe if I look at this resource here, I may begin to learn how to..."
You'll never get anything done "for real" until it's important. Whether it's a personal project like the console emulator you mentioned, or a for-hire piece of work, or a chunk of Mozilla you really care about, you'll do it when you have to.
26 years ago, I did part-time work on a PDP-11-based system as I entered college. I found that in my classes, I'd write a 1000-line program that produced ten lines of code... and at work, I'd have a 1000-line program that produces 10,000 pages of output a month, on a much more constrained system. And my 1000 lines of code were equivalent to 3000-line versions by other students (and yes, I had documentation in my code)
Constraints make you work better. Read 37Signals' blog to find out how to work with less.
Big projects happen in little steps. Take a project management class -- look at the Project Management Institute to understand "work units" and "earned value" -- understand how to get work done and measure it.
Design for Use, not Construction!
I was going to post some advice, but I read a bunch of the comments that have been posted and many are great and cover every thing I was going to say....
So, why am I posting? I am asking you to post the name of your school so that people who want to learn programming can run away from there as fast as possible.
I was in a meeting last Friday with a group of CS instructors and a group of game developers working out a game programming curriculum. One of the things the inudstry people kept bringing up is that recent CS graduates do no know how to program and they have no knowledge of computer architecture. One producer who is actively recruiting said that most new CS graduates could not answer the question "what is a byte?" I kid you not.
I know what CS professors say when challenged on this subject. They will tell you they are teaching computer *Science* not computer *programming*. All I can say is that if you are in a computer science school and want to be a programmer you might want to switch to a software engineering school. Or, you could finish the CS degree and take some programming courses at a trade school or junior college.
Stonewolf
I have been a Software Engineer for 20+ years.
My degree was in Biology (minor in Chemistry).
OJT, a couple of training classes here and there.....
I went from COBOL, to Assembly, to C, to C++, to whatever is next. You MUST NOT FEAR the unknown. IF you need it, learn it. If you can not do that, switch to IT.
C++, C, Java, COBOL,..... some language that you invented(this would fall under computer science) are tools that a computer scientist would use to solve a problem. Once you realize this you might find it embarrassing(fun maybe) to argue about which programming language is better than the other(Cola++ is better than Tab). Keep in mind that you are not a mechanic just because you can drive a car in the same sense that being a computer scientist does not mean you can write a program.
Come up with an idea, decide which programming language you want to learn/use. When you get stuck look at examples by other people or in some books you may or may not own.
Only about 25%(maybe less) of what you learned in college is important for your career. The most important thing that a diploma says is that you can do what it takes to get a 2+ year goal completed with a certain level of competence which is measured by your GPA. In the eyes of a good employer this means that you can learn how to use whatever tool it takes to get a project completed on time and on budget with a little initial guidance.
Read some code of others, just pick your area of interest at SourceForge. You have absolutely better conditions for self learning how to code than we had 30 years ago.
There you are, staring at me again.
As I have been told when I got out of the university, "Congratulations on getting a degree, now you can begin your education".
I have now been out for 5 years, and I can tell you a few things:
1- no express route: as has been said by someone else, it takes at least 10 years to get 10 years' experience
2- every field of CS is like a new discipline: you have to learn a lot before being good. i.e.: you will have to learn before doing emulation, then restart from scratch before you can do browsers, etc... but some knowledge bits will be transferable from one field to another (AKA experience)
3- nobody will make you learn, catch all the opportunities to do it.
4- Focus: there is always cool/interesting stuff floating around any project; if you want to be finished, learn to weed out the less useful stuff; on the other hand, be wary of pruning the stuff that will be useful later. (yes, it is a Kung-fu-master-type saying, but life is ambiguous)
5- have staying power, but don't let yourself be somebody's tool.
6- maintain your code, it helps you learn what are your mistakes.
And the one thing you will always have to keep in mind: there is always someone better than you at what you are doing. When you find them, learn.
You're not old until regret takes the place of your dreams.
First off, I'm not a programmer nor do I have a CS degree. I have a degree in general engineering. My classmates and I were taught that the difference between training and an education is training teaches you how to solve previously framed problems while education teaches you how to solve problems that aren't well defined.
Since you undoubtedly have received an education, there are two components to solving your problem:
A quote from my chemical engineering professor was: Let's convert that to Pound Mols per degree Rankine: that'll make it easier. Despite taking classes that taught me such useful lessons, I was able to reverse engineer an entire Concurrent (CCC) UNIX filesystem and write a program that could read it on an incompatible version of Solaris. It wasn't the fact that I know what a pound Mol or a degree Rankine is that made me educated, it was the fact that I was willing to pick up Lion's Commentary On UNIX 6th EDITION With Source Code (ISBN 1-57398-013-7) and figure out how the antique file system worked.
It is very seldom in your Career that you will know how to do what you want to do. The difference between success and failure is the willingness to figure out how to solve the problem in front of you regardless of whether it was in your knowledge area or not. One time for example, I found I needed a way to extract audio clips embedded in JPEG files from an old digital camera to make a web site of my cross country bicycling trip. I found the EXIF specification on the internet and wrote a lousy but functional program to extract the data.
In short, you were given a box of tools when you left college. Some of the tools in there are great, some are about as useful as an adz in modern construction. Your job isn't to take the tools in the box and go forth into the world: your job is to use the tools you have all the while filling the box with better tools at every opportunity. The box will never be full but as long as you keep filling it, you will always be on the road towards solving the problems you want to solve.
Few CS programs offer much in the way of software engineering training. You can get some basics, but real world experience is required.
Be careful and get a job where you can work with excellent developers. If their concerns are on quality, maintainability and meeting the end-user's needs - you may be on the right track. But make sure you get some mentorship from the best of the team - people with a minimum of 5 years experience (over 10 years would be better).
Always realize you have more to learn.
I graduated from one of the best CS programs in the country 20 years ago. I'm still learning and changing all of the time. Also, find new trends when your current path looks to be nearing an end or looks to be heading for offshoring.
Don't let yourself ever fall into the trap of compacency. Lots of COBOL programmers were confident in their jobs back in 1992!
Comment removed based on user account deletion
We're supposed to tell him to get out! Damnit, I want a higher salary. Morons who haven't coded x86 since they were 8 like me are what's wrong with the industry. GET OUT. NOW!
zo'o ko kurji ko
One book you should definitely read is Writing Solid Code by Steve Maguire. It will help you train yourself to be aware of how bugs can creep into your programs, and what to do when you encounter them. Instead of just blundering ahead with a fix, you should be asking yourself "How could I have prevented this bug?" and "How could I have automatically detected this bug?".
You may also want to read is The Elements of Programming Style by Kernighan and Plauger. I've only skimmed through it, but it talks about writing code so that its function is obvious to other programmers. (Trust me, few people can look back on code they wrote five years ago and remember why they wrote a particular routine that way.)
Another book I would recommend is Structured Computer Organization by Andrew Tanenbaum. It will take you from circuits and logic gates, through how a CPU works, to how Operating Systems work.
The only other recommendation I would make, is to become an organized note taker. The top programmer in one of the companies I worked for was such a person. If there was a question with the way something worked, he could pull out a notepad, flip through a few pages, and tell you what issues he was dealing with in the code, and why he made certain design choices. If he got an error message, he would write it down, and what steps he used to correct it.
I'm sure others have mentioned continually educating and upgrading yourself, and that an IT career these days means having lots of short term jobs, rather than a single lifelong job, joining clubs and associations, etc. The only thing I would add to that is Practice, Practice, Practice. Write code until it is second nature to bang out high quality code.
When our name is on the back of your car, we're behind you all the way!
The code will follow.
What does a computer do, after all. It manipulates data. That is ALLcode does.
It doesn't matter what language you use: Machine Code, Assembler, C, C++, Pascal, Java, C#, VB, Fourth, ADA, COBAL, Fortran, Ruby, Perl, Python any of them, its all just verbs and nouns. Some are more or less elegant, some are more or less useful. But none of them are anything without data structures.
There is NO substitute for properly designed and abstracted data structures, for without those your subsequent code as efficient and elegant as it might be, the resulting program will be useless.
Look at any program out there. Look at the source if you can get it. The vast majority of the modules are defining the various data structures required to organize and keep track of what the hell you are doing, not how to do it.
Hey KID! Yeah you, get the fuck off my lawn!
I'd say it broke down as 5% reading, 5% looking at BSD code, and 90% writing my own network sniffer and watching it crash. I'm enterring my 4th year as a programmer who works with network programming in BSD and Linux.
Don't underestimate the value of being a professional programmer. The technology you work on may not be flashy, but somebody needs you to deliver high quality software on time. Responsibility is often the best education.
Nope, didn't mistype a thing.
While there were bays available, my first IBM PC did _not_ have floppy drives - and yes, it came from the factory that way. Storage was on audio cassette; yes, the original models actually had a cassette interface port on the back, right next to the keyboard port. Floppy drives were optional (and yes, I got one a couple weeks later).
Can we get a "-1 Wrong" moderation option?
Obviously the two choices are to do the really cool stuff at work or to do it not at work. In a junior programming position, you probably don't have much ability to guide the technologies being used, unless you work for an extremely small company. OTOH, in a junior programming position, you're probably (hopefully?) not called upon to work more than 40 hrs per week, which leaves the remaining 128 hrs for doing cool stuff. Sleep is not cool, and there are great new pharmacological methods for eliminating it. I'm joking about that last part. Mostly.
I suggest coming up with something using cool technology that you think is marketable, and develop it, learning what you need to learn as you go. By trying to make it marketable, you will make yourself focus on the needs of the end user, which is vital to becoming a good software developer. Businesswise, you will probably fail miserably (but maybe not), but the point is to learn and get experience with cool technology. If you get users, even if it doesn't make a cent, then it can credibly go on your resume, and you can get a paying job using said cool technology.
But in general, if you want to a) stay employable and/or b) know and use cool technologies, you really need to take it upon yourself to make and keep your skillset a) relevent to employers and b) interesting to you. All it takes is a quick search on dice.com to see what technologies are currently being sought by employers.
I suggest gaining some experience in free open-source software development. Goto high-priority projects assisted by GNU, or goto Savannah. Get an IRC account at FreeNode and meet other hackers.
Then, I suggest investing about $400 per year on a Safari subscription. This is a site where you can legally read O'Reilly IT e-books. It will come handy if you have a PDA, like HTC Universal with a 3G broadband connection for reading Safari while you commute (note: Here in Europe we commute by taking a taxi, riding a bus, or using a train, if you are in North America most probably you won't be able to use a PDA during commuting as you ought to drive, unless you are in New York City where mass transit is similar to Europe).
Finally, focus on the fundamentals. What's a queue and how it differs from an array? What is a relation? What is a finite state machine? What is a Turing machine, and what is a hypercube?
Armed with the fundamentals, assisted by a good e-books site like Safari, and practising on open-source projects, you will become a hacker in no time.
A caveat: Try to understand what kind of company your employer is. Do they pass the Joel Test? Do they have good Management and do they use Software Engineering methodologies, and if not why not? Many companies are just hiring a bunch of underpaid engineers, put them in a noisy environment, and tell them to write code all day. This is a recipe for bugs! Good companies act on bugs proactively, via test-driven development, etc.
Another important thing you must achieve is the state of flow, coding in the zone, or hack-mode. It is, in fact, more important to be able to achieve flow easily rather than have advanced degrees in computers.
There is no substitute for experience...
In college they give you a background on how we got to here. Algorithms, data structures, operating system, database...
After college you are thrown to the wolfs, sink or swim, you know the rest.
So to learn the new or cool stuff. Follow these steps.
1) Find something that interests you. (small at first)
2) Write the problem down in a doc. (should be no more then 1 or 2 pages)
3) Write a little code at a time to solve the problem. (Keep a journal)
4) If or when you get stuck... Google.
Good Luck.
Whatever you do, try to undestand the root of the problem, the larger picture, understand why certain thing need to be written at all. What is the place of your component in the whole. What the whole do.
Its very easy for a programmer to bias toward "cool" things. With some experience thinking on the problem you solve you will start to get the pleasure of doing things in harmony with the objectives of the whole system.
Do not try to learn too much: programming is such a field that one need to learn ones own way. Try to be open to new things, intuition will grow with years of experience.
Programming is highly intellectual work and is often rooted in deep insights to larger extent than on logical reasoning.
In other words, try gather your own wisdom. Perhaps, its greater asset for programmers than remembering numerous patterns and idioms.
The first step to becoming a real programmer is to learn that slashdot is comic relief first, and repetitive news second. It is never a place to ask for career guidance, unless you really enjoy listening to other people fart.
I would have absolutely NO IDEA how to even begin writing it.
The first step is to have the idea. Few, if any, projects ever started off with someone learning a language and going "Hmmm, think I'll write a web browser using this." Instead, you start with "I'd like to get a computer to do (fill in the blank)."
Once you've had the idea, everything else follows. Detail what you need to do to accomplish it, what tools you need to get there. If someone else has done it, check what they did. Using your console simulators as an example: The idea was "I'd like to play my console game on my PC." That's the starting point. Then you have to say "what do I need to do that?" You need the assembly for the console processor. You need to translate it into the processor on your PC. You need to (and so on). Each step is a building block, but it starts with the idea.
In school, you have probably written dozens of apps that already existed, and hundreds of functions that were already available. Now, it's time to learn where the short-cuts are. Of course you can't rely on cut-and-paste programming for everything, but the trick is to learn that, sometimes, there is a cheap or free architecture, API, etc that can save you time and money. It isn't cheating anymore...
As for the emulator, that may be an interesting project, but make sure you are up on the local laws. You will have a strike against you, because some employers will assume it's illegal and not want that risk on his shoulders (having an employee miss work because he is getting sued for copyright infringement is a risk). You may want to cnosider something that can be justified as good for the industry, or educational purposes, like mono(the *Nix implementation of .net), a cisco router emulator, or an OS/400 emulator (if it can legally be done).
Then, if the boss tries to read too much into your interests, you can say that you saw a need, and decided to hone your skills, while "giving back to society".
To do that you have to always look for a challenge. When you get to saying "I can do this standing on one ear" its time to go do something you don't think you can handle.
As a beginner though, the big thing to learn is that software experience doesn't scale. Writing a 100 line program does not prepare you to write a 1000 line program which is nothing like writing a 10,000 line program and when you get past about 20,000 lines its totally different because you can't keep it all in your head at once.
The next most important thing after learning to write bigger and bigger programs is learning to not write programs. This comes in two flavors. Some tasks can be reduced to a specification and a generator. Some tasks should not be automated at all because they are wrong - the first step is to work out what the task really is or should be, not to implement what its claimed to be.
Actually, that's a good principle in general - and one I have never seen a graduate understand. Programming is gathering of knowledge and codifying it. On all but trivial projects you won't have all the knowledge at the start and you can only get it by starting to implement the system - the system is an experiment.
So early in the project the most important thing is to try to work out what are the most important unknowns and what would be the worst surprizes so you can go after these early.
And while programming it is important to build in adaptability so you can react to new information. Make your system as generalized as possible, even at the expense of some performance and extra coding at first - tuning should be done late.
Squirrel!
Get an internship. That's what they're for. I've had some interns who were absoutely brilliant, but didn't know the first thing about real world programming.
p.s. If you're worried that you might get in over your head, it's just a normal part of the job. I start most assignments feeling like a deer in the headlights.
Don't blame me, I didn't vote for either of them!
It used to be you could locate in Silicon Valley and commute to various jobs you had without selling your house and buying a new one each time you changed jobs. No more. The price of real estate in Silicon Valley is so high and competition so heavy you now need to be from a wealthy family or part of an ethnic mafia to get anywhere if you're young -- so unless you are from a wealthy family, Asian or Latino, forget about S.V. as a way of avoiding real estate transaction costs between job changes.
Seastead this.
I know it's a bit late for you, but there is something to say about researching the courses you're taking at school.
I have no signature
I was one of the lucky kids of my generation, I was able to convince my parents that computers where 'the wave of the future' (this was in '79-80ish), and got some private lessons on programing from a programer for an oil company who had setup a small school on the side.
:) And maybe that is why I moved on... The coolness factor of controlling one little machine via a piece of software I wrote paled in comparision to excercise my skills over thousands of machines, and the people working on them...
I learned a LOT! I took programing in highschool as well... but when it came right down to it, programming is WAY too much work for too little reward. And there are TONS of programers. LOTS of competition. and the tools available for 'little hacks' have gotten to the point of being absurd. When a 6 year old can 'program' a web page with one of the many excellent frontpage like systems out there to do truley amazing things, I have to wonder what 'real' programers work with now days...
Java? Lots of cool 'interpeted' languages? Very few people code hard core machine code anymore because it just isnt necessary. All the low level functions have been mapped out for you, so you dont really NEED to know 'why things work'...
To my point: Whats the point of being an engineer of any type, if you dont know WHY things work? I always thought that was the whole point? Maybe coding is diffrent, I honestly havn't tried to keep up, as my own field has been growing in leaps and bounds, and actually knowing WHY things work on the network is a useable and profitable skill set I have managed to maintain.
For myself, I gain no enjoyment from makeing a single machine jump through figurative hoops in response to my wishes. Makeing entire networks of machines do that is another story
{Queue evil laughter}
MUHAHAHAHAHA
You would like to find a decent job as a programmer? I have two words for you - "Law School"
Seriously, I also graduated from a CS department that was very heavy on theory. It was also a very highly ranked and very good and tough university so I go my ass kicked but by the end I had very weak practical skills compared to my little brother who had been coding for a hobby.
The thing is, if you have a really strong theoretical foundation, you will find that you can chew up and spit out practical stuff with ease. The practical stuff can be (and will be) learned. Because of your theoretical strength you will learn new things much more easily than people who graduated from schools where they learned mostly practical skills.
Think of it this way, 6 or 7 years ago, in such a program, you would have been a real programmer the day you graduated kicking some serious butt with pascal all over anyone from one of those pansy theoretical schools. Well the problem is that they don't really *get* it as well as you will and although you may start out slower, after a couple years go by and whatever the language of the day is has passed you will be sitting pretty. Even if you do have to compete long term with those guys you will ultimately gain a mastery they won't be able to come within a mile of. Trust me, I work with a bunch of EE guys who "know how to program". Oh, shit I just puked in the back of my mouth! Fucking hell their code is horrible! And it always will be because they just don't have the framework no matter how much they code to ever be good at it.
So, don't worry, just pick something practical to cut your teeth on, dive in, be lost as hell for a few weeks, and then you will master it. (I have an idea, why not dive into fixing the piece of shit gnome-panel that can't seem to remember the order of my applets because I, gasp, change my monitor resolution when plugging my laptop into an external monitor. Hello!! Jesus.)
In any case, many employers understand that the better universities have this theoretical emphasis and they will hire you even you can't write HelloWorld in the language they want you to work in.
The professors are there to educate you (speaking of university, I suppose). They shouldn't, and they do not, seek to prepare you for a job. A job is what you get if you fail to enter the academia or are unable or afraid to start your own business. I see no reason why a university professor should prepare their students for the 9-to-5 slavery. There are two elements that lead to freedom: Education and wealth. You need both to be truly free. Professors are eager to give you education. Accept it and don't whine about "practical job skills". What do you prefer, be told how to operate a machine (like a monkey), or be told how to build the machine yourself? Skills are important and necessary, but theory is what makes you human.
Not many programmers will admit it -- but if you refuse to intentionally write shitty code the 1st time so that you can throw it away and do a better job later, you are almost certainly going to unintentionally write shitty code the 1st time and keep it forever.
This sounds really hard -- and its totally non-intuitive, but it is the truth.
Pick a project that you know little about....and follow these steps:
The reasoning behind this is as follows:
Rob Enderle's excellent new book: Everything I needed to know about Computer Science I learned in Marketing School
I should also add that in many of these different disciplines, aspects of the program architecture and implementation are purely arbitrary. One thing I discovered I needed to do to make progress on particular projects and ideas was to whip up a simple prototype, and rather than obsess on the "best" way to do something (because there may be no "best,") make some arbitrary choices, sufficient to get a working prototype. They might not be good choices, but if it's new territory for you, you won't understand why they're bad choices until later.
As Fred Brooks once put it: "Plan to throw one away. You will anyway."
Think of this aspect as being a corollary or companion to the "subdivide until you get to something you know" advice so many others have given. This is more of a "It's ok to baling-wire-and-chewing-gum the bits you don't know when you're prototyping." Once you have a working prototype, you have two very important things: A sense of accomplishment because you have something that works, and a sense of what you might do entirely differently the next time.
--JoeProgram Intellivision!
Most programmers have similar stories to tell, with the scars to show for it. If they pretend they actually worked in an office drinking Mountain Dew and eating snack food in their early career, it's just because the memories are too traumatic to talk about.
... and then they built the supercollider.
This isn't the answer to your big question but here's how I started writing emulators:
By writing a disassembler. A working disassembler is halfway to being an emulator... in one of those oh-so-common-in-programming 'half an iceberg' ways.
A disassembler
a) has one 'register' variable : the PC; it walks straight through the ROM image.
b) prints the current instruction and operands, and advances the PC.
An emulator
a) has a variable for each register, and arrays for RAM and other address-mapped hardware.
b) acts out the current instruction and operands, using the 'register' variables.
c) allows the PC to be changed when a branch/call/jump/return/interrupt is executed.
d) counts an appropriate number of instructions (usually a single scanline, or a complete TV scan) and then performs some output [such as rendering part of the RAM array into a bitmap].
This is pretty simplified but I would say you DON'T need to:
1) look at a completed open source emulator (at first). You may dig for a long time before you find the guts of it.
2) worry about digging into JIT or the assembly language of the host processor; a modern machine is fast enough to run one interpreted instruction at a time. If you're emulating one of the 8-bit era chips (Z80, 6502) or 68000 it almost doesn't matter how slow your code is. [Hint: you do need a jump table for the opcode handlers.]
If you're building your own emulation from the ground up (which I recommend if you want to find out how things work), you WILL eventually want to look at other people's CPU cores - they will generally act as verification, expansion, and correction to the official CPU manufacturers documentation.
First, I'll re-iterate what a lot of other posters said. A CS degree is not a programming degree. 'Nuff said. However, programming is the natural expression of what you larn in a CS class. For example you talk about AI, so now you implement a neural network as a class project. So, you need to know how to program at some level, but being able to understand and characterize the behavior of the NN on a particular problem is the real goal.
Second, I'll re-iterate what a lot of other posters have said: WRITE CODE. Write great heaping spoonfulls of it. Write it in different languages. For example, to understand those emulators, you might need to get a grounding in assembler. You'll need C/C++ to interact with the host O/S and graphics, or perhaps Java. You should have had a computer architectures class where you covered how a CPU works - now express it in code.
Third, programming is all about problem solving. Start with smaller related problem to help you along. For example, look at the assembler instructions for a set of chips? What's common about them? Could you emulate the CPU behavior? Could you translate the instructions to x86 assembler? Should you treat the assembler as a language to interprit or compile into x86 assembler? Break things down into manageable sub-problems and solve them.
Fourth, read books about programming. No one learns to work on their car without also reading about working on cars or watching car shows, or hanging out with other guys that work on cars. Read books on C++ to get you up to speed on C++, books on how to structure code so you don't paint yourself into a corner, books on specific technologies like Unix, and look for "classics" in each field. For example, Advanced Programming in the Unix Environment, or the dragon book on compilers.
Leave the gun, take the cannoli -- Clemenza, The Godfather
You say your programming seemed to be a bit theoretical. That might have been the best that happened to you.
I always have fun in interviewing situations, when someone asks how many or which programming languages I have experience in. My standard answer is "Any, just give me two weeks time". The stare in disbelieve I counter with the explanation, that my computer science study taught me (mandatory) how to design a programming language to a given problem space, its syntax and semantics and how to write the parser/compiler to translate it into machine language. If I can't learn a new programming language in two weeks, I'm not worth my degree. After that point I always got an offer.
Programming languages will always change, so do APIs, OS, etc. But understanding computational theory, language in the abstract and how people tick that are not programmers (also called clients, users or managers) will always be the stepping stones to your success.
Busy helping non technical users of OpenOffice.org - http://plan-b-for-openoffice.org/
You should learn to write first a CPU emulator. And for that you must first learn what machine code is.
Then the hard work will be to emulate very accurately the rest of the hardware
of your console. You will obviously need to find the documentation on the hardware of your console.
Then when all will work, you will need workarounds to the lawsuits.
in fifty years, you will be thinkering on how to emulate the univers.
First of all, don't worry too much if your breadth of knowledge doesn't cover the entire field of computer science. It's just too huge a topic to be an expert in everything.
It's good to understand how low level things work, I think. Especially if you're interested in emulators, you might want to involve yourself in some open source project that emulates simple hardware. If you're just concerned that you don't know how an emulator works, a few days of research will help you there.
Part of being a good programmer though, is knowing your limits. It's OK not to know how to do everything, as long as you're able to incorporate the work of others who are experts. You'll likely never know how to write a really fast FFT algorithm on your own better than people who have already done so, but if you're able to incorporate a good open source version in your work, it won't matter.
But do try to become an expert in something. If emulators interest you, dive into that.
My point is mostly that you can't really be an expert in everything, as tempting as that may be. But if you do pick something you're interested in and become an expert in that, the knowledge you gain will likely carry over to other areas, making learning easier.
If moderation could change anything, it would be illegal.
Mea culpa - /me graduated from college with a computer science degree in the 20th Century.
... college classes to teach you programming. Because it's the nuances of the particular programming language, things like how pointers work in C or how you have to align memory data for assembler instructions, those are the bits of knowledge that constitute the essence of programming a
Second, an observation - you went to a college with a crappy CS curriculum. If you didn't take at *least* half a dozen courses programming multiple assignments in at least half a dozen languages, you got ripped off buddy. When I went through my undergrad, I wrote programming assignments in ALGOL, BASIC, COBOL, FORTRAN, IBM assembler, LISP, PASCAL, PL/1, and SNOBOL. Now, that's an education!
I can teach you how to program in under one minute. Don't believe me? Here it is - start your timer.
There are three kinds of computer code - straight code, iterative code,
and conditional code. Straight code is what it sounds like, serial
instructions - do this, do that, in a particular order. Iterative code
is repetition - do this, then repeat the same instructions until or
unless some condition changes. Conditional code is a single or multiple
either-or construct - if this, do something, otherwise do something
else. Of course each of these three types of code can be combined.
Done.
Oh, did I neglect to mention the *syntax* of the programming language?
Yeah, see, that's why they have O'Reilly books and the Internet and
computer.
Contrary to popular belief (as I just illustrated a couple of paragraphs ago), it's not the structured paradigm or the OOP paradigm that defines "how to program". Rather your expert PERL coder has the in depth understanding of the PERL programming language that allows them to craft elegant code, while your novice PERL coder does not know how to take advantage of the language and will write less efficient code. The same applies to any programming language - an understanding of the language (and to a lesser extend an understanding of how the computer processes the instructions (which is how printf format string vulnerabilities were identified) is what allows a programmer to instruct the computer to do what the programmers desires.
Just like a natural language, you're communicating with a recipient, and the accuracy of your communication is directly proportional to your grasp of the language that you are using, not to your recipient's ability to grasp what you're trying to communicate.
So, advice for programmers - you need to do two things, in order. First, research which programming languages are most prevalent in the field where you wish to work. Second, learn to program in that language backwards and forwards.
For example, if you want to work in banking or credit card processing you might consider COBOL (Happy B'Day grace Hopper, you miserable old skank) and mainframe IBM assembler. If you want to do k3wl K-R4d bleeding edge work at SUN, start studying JAVA (and pay particular attention to multiple inheritance). If you're going to do funky ASP work in PERL, read the Camel book and the PERL man pages and as much PERL code as you can find.
Above all, start coding and code until it hurts. Because you can bet that at least one person interviewing you for your job has been coding for a long time and understands the pitfalls of the particular language, and wants to hire someone else who understands and can work in that language.
=;^)
MMMM... Nothing like being behind a computer for 8+ hours writing code.
Is that what you want to do? The reason a CS degree does not prepare you "enough" for programming is because CS is not the same thing as programming. It is one aspect of a huge field. If programming is what you want to do, your CS studies should have taught you how to learn in this area. The rest of your development is up to you and your employer(s).
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.
Didn't you have a computer organization and architecture class? You know, one the professor talked about low-level CPU stuff and you had to memorize the stages of the original MIPS pipeline? The one where they had discussions of Von Neumann vs. Harvard architecture, caching, ALU operations, fundamental logic, port- vs. memory-mapped I/O, etc? If not, your "theory"-based education left you a very big blind spot.
If you did have this particular class, it should seem quite obvious how to proceed with writing an emulator.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
All in all, you chose the wrong path by going to college to enhance your coding skills. How does a carpenter learn to build houses? How does painter learn to paint? How does a an author learn to write a bestselling novel? All rhetorics here, but my point is college is not the end-all-be-all of learning how to do work in life. College is all theoretical, and in some aspects research and experiments are applied to get nearer to truth. If you go to college and major in Computer Science, don't think you're going in order to learn how to program. You're there to embellish upon computer concepts and theory. Think of the new binary system. Who made that up? Not some low-level programmer who wrote console emulators. College trained computer scientists are meant to break the computer technology barrier by being more abstract. Invent!!! I'd get your money back!
When I started when I was a kid I had absolutely no guidance. It was probably middle school then. I started with a small desire to make web pages and it went from there. First was just formatting pages and learning about html "syntax." Although it wasn't exactly programming, it did at least get my pallet wet and made me understand how the computer was thinking. After that I moved onto wanting to use JavaScript and that eventually lead to wanting to make my first guest book. That's when I ran into the wall of needing server side code. I was stuck for a while since I was only a kid and didn't own a server (I was using Tripod/Angelfire back then, I had no money to rent space). Years passed and I was able to start learning c++ and some vb. Although I regret learning more vb so early on in my programming career I can't say it's entirely hurt me since I am much more involved and interested in non GUI driven applications now because of that. I agree with everyones opinion of getting a job working with developers. I got a job doing so and I have never made such large strides in my programming abilities. Start with something that is achievable. There are many times when I have started a project only to recognize it's true breadth. Nothing is more demeaning when you feel you can't complete a project, which you may have learned from the emulator. I also don't know if getting a CS degree was appropriate when wanting to have a serious coding job. You may have to do a lot of research/real coding to sharpen your skills in that case.
I will forever be a student.
Keep on moving forward... Some replies have been very insightful and others have been just plain cruel. Pay no attention to mean people. At the age of 18, I don't know how anyone is supposed to know the difference between CS and programming, especially since CS classes in high school teach you how to program. After getting my CS degree, I never got into a pure programming job. I fell into a configuration management role and often wondered if I would have been "good enough" as a programmer. Thankfully, I like what I'm doing, so I don't have to worry about that. The important thing is that if you are willing to learn, there will be a place for you in software development - it may take you some time to figure it out since people think that a CS degree locks you into being a programmer. Also, if you feel you are in a job where you are no longer learning anything, then it is time to get out! Hang out with people whose jobs you would love to have. Good luck to you!
"I recently graduated from school with a CS degree, 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."
You was robbed, son!
Comment removed based on user account deletion
Code Complete 2 by Steve McConnel. An invaluable book for the beginner.
Mythical Man Month. Another good one.
Learn another language or three. C++ is a good language, really. But there are other languages that are used more often. Java, C#, Visual Basic.NET (pick 2, preferable Java being one of them). Also a good scripting language or two (perl, Ruby, Python, JavaScript, VBScript) never hurts.
Also, figure out the whole relational database thing. Means you need to learn SQL. Microsoft SQL Server Express, Oracle Express, MySQL, and Postgres are all good places to start.
The key is versatility, and coming out of college you have none.
Finally, if open source has done one thing for all of us, and you, it has contributed tons of code for you to read thru. Find a project on source forge that you find interesting in a language that you know and download the source.
BTW, as soon as you are done with this list, there will be a new one. Programming is all about being willing to learn.
Bad User. No biscuit!
There's a been a lot of good advice posted. I learned a lot on my own about programming, but I didn't really learn software engineering until I worked with people on cool projects who knew a lot more than I did. Then I really learned how to write the big applications. How to write modular code, how to do good testing. The whole lifecycle process. And it took several jobs with different approaches, but eventually, I developed the way I write software and it works for me.
My first job was a suck-ass boring job too. I wrote simple, boring apps for Army logistics. My second job was a little more interesting and as time went on, the jobs got progressively more interesting and eventually I ended up working with really amazing programmers. In fact, two of the guy that were my mentors about 11 years ago, I'm working with again now. One of them I brought in to a company I worked at about 6 years ago, and then about 2 1/2 years ago, they both hired me to work for the company they were at. One has gone management (and manages the current project), but he still has his chops and they're both still teaching me stuff. And I'd like to think from time to time, I teach them a thing or two.
If you want to really get better at programming, try to find mentors like that, and if you do, consider yourself very lucky. It's hard to find jobs with the really bright ones because they're usually looking for the really bright ones to work with themselves. You'll have to cut your teeth on some of the crap projects for a while and build up your resume, but if you want it, you'll find it.
My advice for recent CS graduates:
There are 2 steps to software development design and programming. Programming isn't hard, design is hard. You need to make sure that you have a sufficent base in design. I recently graduated with a CS degree as well and UML was the key to allow me to actually create worthwhile quality projects.
Oh yea and learn a scripting language like python if you haven't gotten around to it, they come in handy for dinking around.
I graduated from school exactly 2 years ago with a CS degree, and I had the same fear and trepidation. I'd learned tons of theory, I could write any number of sorting procedures in Java, and calculate the asymptotic bounds for an algorithm... but none of that helped me go from idea to design to implementation and beyond. I couldn't find a book to tell me how to do that, and I really would doubt one existed that was useful in any case (software development is not unilaterally similar in every environment), so when I took my first job I had to hit the ground running and take my best stab at things. At my school (Oklahoma State University), not too many CS students were very interested in unix systems, open source software, and low level programming; and I was one of a very few people that actually spent any time working with that environment.
In my work environment now, everything I do involves open source software and Linux systems. Technically, I'm an analyst rather than a pure developer because the team here is so small. I have to wear all the hats because there's not enough staff to segregate the duties. Everything I do now is done in languages that were completely unfamiliar to me, and the applications are much larger and more complete than any of the exercises I did in school. That's a tall order for anyone right out of the oven. The best thing I did for myself was establishing the precedent that everything didn't have to be perfect. You don't start out knowing everything. The software you read about is made by teams of people that have taken many years (sometimes decades) to grow to the point that they are able to do what they do. Take your time, and take on the challenges as they come along. If you have old timers in your work environment, ask them for advice. Always keep reading. I'd suggest "The Pragmatic Programmer" by Andrew Hunt and David Thomas. A lot of the recommendations in this book are great. The authors suggest learning a new language each year, keeping up to speed with new technologies - basically keeping yourself versatile. I've found that this does a lot for me. When you learn a new language, and force yourself to be immersed in it, you'll inadvertently learn things about the languages you already know and you'll get better at solving programming problems. You'll also expand your list of tools that you have at your disposal, which is a great advantage.
As another poster identified, you might find an open source project out there that you enjoy, and grab the code and start trying to understand it. Pay attention to mailing lists about the project, and try to follow its development. You'll find after a while that you just start understanding parts of it. You might even be able to contribute to it. The most important thing is to take some kind of action. As long as you act on your desire to be more capable, you'll increase your potential. You can't go backwards, but you can come to a standstill if you don't challenge yourself.
perl -e "eval pack(q{H*},join q{},qw{70 72696e74207061636b28717b482a7d2c717b343 637323635363534323533343430617d293b})"
Just as with any scientific discipline, Computer Science is much more focused on teaching the theoretical aspects rather than the real world applications. From my personal experience (being a CS major), a lot of people have the misconception that a degree is CS is all about learning how to program. CS isn't about learning *how* to program, it's about learning *why* programs work the way that they do and how hardware/software interface. You inevitably end up gaining programming skills in various languages; however, at it's heart, CS is language agnostic. If you just wanted to learn about how to program very specific applications, perhaps you should have focused on researching material (books, internet, classes, etc.) on that particular subject.
Seriously, think about it and try to come up with an answer. What is the POINT of programming. If your answer is "to tell a computer what to do and how to do it" then perhaps you need to figure out something of value to tell it. Find an enjoyable niche, preferably one with a bright future, (maybe not emulators) and learn about that subject, then you will have a marketable skill that you enjoy. Writing useful and valuable software requires as much or more domain expertise as programming ability.
People who think they know everything really piss off those of us that actually do.
Hi ari1981,
:o)
I understand your plight. It's been a few moons since my 'graduation' from a CS tech school, armed with the latest array of books and labwork spanning Assembler to COBOL to CICS to C (C was the sexy new class that was cutting edge at the time).
However the issue is the same, as in "what the heck did I get myself into"? Especially when staring blank-eyed at my new project manager who didn't know or care about my skillset (or interests!) but discussed what I thought to be unimportant - the business process and how its changes needed to be represented in the reports I was to build. That feeling I think is pretty much universal no matter the education and the dawning realization that expectations and reality are not comfortable dancers.
Continuing education? Use that internet connection to its fullest. Back when I started my IT career around 1990 or so the Internet was still for gov't-only use; I was therefore quite busy trying to understand how to flop around the (free) dial-up BBS'es. There wasn't any real online programmer library to delve into so it was tough (and even if there was I doubt that anyone would really have pointers for mainframe developers anyway, but I may be wrong there). You've got a tool that is incredible - but I'm also aware that everyone else has access to that tool, which doesn't make it easier for you than it did for me as a new starter. Keep studying though all the time, I do.
The first thing I learned on getting out of school was to change my expectations. I wasn't going to be writing font-generators or text-based gaming adventures in the 'real world' (although I did create these on my spare time on my Dad's home PC, a powerful one with almost A FULL MEG of memory, hee hee). The labwork was dreadfully boring by comparison to the things I liked to do, but haha, it was actually like 'real life' I found out.
I started off working in, of all things, ACCOUNTING. Ugh. With no business understanding of accounting (although it's very straightforward) learning the business as well as practicing my developer skills was a double challenge.
Now, 16 years from there, I'm still not writing the code that I thought I would be when I started this adventure. But that's ok - I'm earning a healthy income, survived the market fluctuations of 2002-2003 and now have the cash to, well, PLAY a lot with the software that I wanted to write but don't have the time to do so. So that's ok with me but for others this may not be acceptable. It's a personal choice.
I could have stayed as a game/graphics/etc. developer but I decided instead to change my goals and to go after a career in the finance area. Why? In 1989-1990 there was not as big a market for game/graphics developers as there was a market for accounting programmers. And like you I had bills to pay.
Regardless of the type of development you find yourself doing, I believe there are come common ideas that you will be required to learn if you are to survive (or better yet, THRIVE!) and enjoy your career.
You'll note that there is little mention below of how to sharpen your development skills. This is on purpose, as the technical fiddly bits of learning to be a codeslinger are well documented by our fellow posters and a huge number of web sites. Access to this is easy and I can't give pointers on your unique coding requirements.
However, the tips below will give you a solid footing that you may not have been taught in school, as I learned this by painful experience. With this footing you can establish a position at your company as a respected and needed team member - and then you will have the freedom to do more studying in your area of interest - software development - without worrying about keeping your job or where you will be moved if your position is made redundant.
And as you get older these skills will be more important when the young pups some fresh out of school earning 1/4 of your bill rate.
1. Learn the busine
Comment removed based on user account deletion
Comment removed based on user account deletion
I would like to remind you of a great literary passage by Oscar Wilde. The preface to "The Picture of Dorian Gray" by Oscar Wilde. The last statment says "We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely." Think on that one and then read the book. Hopefully it will open your mind up momentarily to give you a different perspective on the artistic side of software development.
The Preface
The artist is the creator of beautiful things. To reveal art and conceal the artist is art's aim. The critic is he who can translate into another manner or a new material his impression of beautiful things.
The highest as the lowest form of criticism is a mode of autobiography. Those who find ugly meanings in beautiful things are corrupt without being charming. This is a fault.
Those who find beautiful meanings in beautiful things are the cultivated. For these there is hope. They are the elect to whom beautiful things mean only beauty.
There is no such thing as a moral or an immoral book. Books are well written, or badly written. That is all.
The nineteenth century dislike of realism is the rage of Caliban seeing his own face in a glass.
The nineteenth century dislike of romanticism is the rage of Caliban not seeing his own face in a glass. The moral life of man forms part of the subject-matter of the artist, but the morality of art consists in the perfect use of an imperfect medium.
No artist desires to prove anything. Even things that are true can be proved. No artist has ethical sympathies. An ethical sympathy in an artist is an unpardonable mannerism of style. No artist is ever morbid. The artist can express everything.
Thought and language are to the artist instruments of an art. Vice and virtue are to the artist materials for an art. From the point of view of form, the type of all the arts is the art of the musician. From the point of view of feeling, the actor's craft is the type. All art is at once surface and symbol. Those who go beneath the surface do so at their peril.
Those who read the symbol do so at their peril. It is the spectator, and not life, that art really mirrors. Diversity of opinion about a work of art shows that the work is new, complex, and vital. When critics disagree, the artist is in accord with himself. We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely.
All art is quite useless.
Where's the 0xBEEF
I have been consistently employed though.
I think that you need to accept that we can't all work on the space program, design the next big MMORPG, the next console. As Slartibartfast said, hang the sense of it all and try to be happy. So, my advice is, be realistic in your expectations. Learn, yes - but learn stuff that people will want to use. Good practices are among those skills. And welcome to the profession.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
FYI, the BSCS&E is a significantly harder program than the B.Arts in CS program. While we were taking extra physics and EE courses, the CS people were taking French, Theatre,
You can be in a science program and still take French and Theatre. While working on a BSCE I took 1 1/2 years of French; 1 of both German and Theatre; and 1/2 year of ASL, American Sign Language, and biology. Also because only two more classes each were required for minors in physics and math I had planned on taking them as well. Some of my friends called me a professional student.
FalconShould there be a Law?
I just graduated as well with a fairly theoretical CS Master's degree, and have rather dismal work experience on my CV. Currently I feel like that despite my "advanced age" compared to some other people in the field, I am actually very much out there and useless to an employer who would want me to actually know something of immediate practical value. Unfortunately, I don't feel like I am good enough or like "school" enough to pursue a research career, so the alternatives are trying to get into industry or start something of my own.
;-)
;-)
One of the reasons why the situation is as it is, is that I genuinely don't find programming all that fascinating. During my studies, I always just abandoned all of my hobby projects immediately after I had figured out how to implement the (algorithmically) tricky parts. The practicalities involved are often messy and time-consuming, and I had better things to do with my time than do something uninspired.
On the other hand, I don't regret my studies at all despite feeling outright incompetent about the day-to-day grind of software design and development. "Real" CS degree people -- in particular in the algorithmic fundamentals, and advanced applications -- are more rare than you'd think these days, because all these fancy "new media" -related vocational programmes sucked in everyone during the bubble. Although most software developed these days do not try to solve fancy algorithmic problems from scratch, I'm pretty sure I'll find my niche as someone who is able to recognize and tackle these issues when they arise. A proper CS degree gives you the background you'll need to go to the library and find the solution to your problem there, and I think this is the greatest asset I have. Then I just need some code monkeys to implement my ideas
Better yet, these skills don't age... I don't think Turing's work, say, is going to be rendered obsolete anytime in the near future. It's quite different from being "certified" in some tool du jour. Picking up those skills shouldn't be an issue if you've graduated with a degree; you just need to get your hands dirty. Sorry, but it seems to me that even with an academic background it's tough avoiding real work one doesn't always enjoy
I want to play Free Market with a drowning Libertarian.
I have found over the years that the way I learn, specifically, is by creating change. Take a "Hello World" program, and change it to say, "Hello Frackhead!". You just learned something about literal strings in that given language. Next, change the way variables are assigned, or add an ELSE to an IF loop. Finally, change the way subroutines are called, or change a class that is instantiated to inherit something different (like, override a method or something). If you can learn the debugger in the tool you are using, all the better. The debugger in VB 3.0 taught me a ton, and that made sure I learned the debugger in Delphi, Visual Foxpro, and now Visual Studio the same way.
It's the ultimate in bottom-up learning. Yes, it is basically just a different form of trial and error, and is somewhat haphazard. But if nothing else, it will tell you where you need to bone up, and where you don't need to waste your time. You might find that picking up loops or variable assignment is easy for you, and that you can morph it into something different with ease. Then, you might find you suck at objected-oriented stuff, or have trouble with function/variable scope. The beauty of chipping away with small steps is manifold:
-- It's easy, and you can do it a little at a time.
-- It teaches you good skills for debugging and troubleshooting, which is what a LOT of programmers spend a LOT of time doing.
-- It let's you learn at your own speed, and you can go as slow or as fast in certain areas as you wish.
To sum this up by summing up the other, much better, posts on this thread:
-- Start small, like a small-yet-mature OSS project.
-- Don't fear your own ignorance, just shift that ignorance to a new spot in the code to "play", and make that ignorance go away (it takes time, be patient).
-- Have fun with the stuff you learn! If you figure out something cool, play with it for a while, explore it deeply! It will make you happy, teach you more, and prepare you for the next bout of ignorance that is invariably around the corner. *smile*
You can use this methodology at a job or in your free time... Good luck!
What Would Sutekh Do?
In my experience, the best developers are those who are good at learning something new. Learning to use the Internet to develop a new piece of code or learn about a new practice is just as important as actually coding. The aphorism about "good poets borrow, great poets steal" is doubly true for programmers. Look at other peoples' code and learn what works best.
Just jump into an interesting Open Source project, something you can use (or already use). Look for areas they are lacking, and start helping.
Don't turn your nose up at documentation or QA either--They are fantastic learning experiences that every programmer should experience at some times.
Don't stick with what you are familiar with. If you like C & C++, maybe go for a ride on the Rails or maybe a VB or Java based web system. If you have only worked with VB, try C#/J#
Learn all the parts of development. Submitting patches, altering build files, dealing with CMS, dealing with various levels of coders and particularly users--deal with user feedback, talk to them, read support boards!
Open Source is a fantastic opportunity for those trying to figure out how "Real World" Coding works--I think colleges should require a year or two on an open source project before you graduate with a CS degree. It's not quite the "Corporate environment", but you get guidelines and existing code to reference and fix, plus mentoring from some very good developers.
Down, not across.
Village idiot in some extremely smart villages.
Read Debugging (I wrote it just for people like yourself), and put the free (as in beer) poster up on your cube wall. www.debuggingrules.com
"Debugging" by Dave Agans - the perfect gift for your favorite imperfect engineer.
in the 'real world', make sure you don't start by reading Paul Graham's or Joel Spolsky's blogs on what makes an excellent programmer, unless you want to have a bruised ego for the better part of your (early) career. Later in your career, if you become as good as they'd like you to be, you'll realize that a small percent of the software engineering population is good at marketing (as well as self-marketing).
Herein comes the joy of hacking (no not breaking into computers or that kind of thing). It you like what a coll thing does, read about it. If you can, buy it. Get on the net and look up books that can be downloaded (Hint: don't be afraid of using Bittorrent, Azeurus, or the like and Google). I'm learning about neural networks. It's slow and frustrating, but it is also very rewarding. I have worked as a software engineer for a small company, yet I have no degree or formal education in Computer Science. All of my education has been learn by doing, reading, etc. I really have no use for a college degree except that it is (unfortunately) today's work permit.
First of all you should write (in a human language) what you want to create. Lets say a simulator. At this point you should look into the nearest library or wikipedia to learn somethign about simulation. You will learn that there are different types of simulators. For instance time discret, event base simulations and simulations which use a continuous time model. Also you should look on what you want to simulate.
Lets say a simple computer thing. The best thing would be now to decompose the problem in smaller parts. You need a CPU and RAM and a cache, a harddrive, a keyboard and a graphic adaptor.
Now look at each of them and think what they do. etc.
This approach is similar to any other software engineering concept. Get the problem, devide it in smaller pieces, design an architecture, write a detailed design for your pieces and then implement them using whatever language you want.
May I ask one humble question? No offence but didn't you hear anything about software engineering, UML and project planning at university?
I didn't do an engineering degree to learn to be a top class welder instead of an engineer - and if the CS courses were all about practicality I would be a highly skilled Modula-2 programmer with no prospect of a job. You learn the theory so you can have many skills and not just work on one assembly line task for the rest of your lives. The problem is you have to get those other skills elsewhere.
I will post this on every Slashdot story I see about learning how to program or improving your computer skills:
Go to this website for the 2006 ICFP programming contest:
http://icfpcontest.org/task.shtml
and try to accomplish as much of the task as possible. This is an amazing way to practice programming skills, as it is open-ended yet manages to cover a huge breadth of skills necessary to be a good programmer and computer scientist. The first task is to write an emulator. I suggest you start here.
Did you ever notice that *nix doesn't even cover Linux?
Without goto, how would you do the following?
That's probably the best thing you can do to get practical. Scrounge up an old Arm-based dev board, you might be able to get one cheap from eBay or get a friend who works for an embedded company to get an old one from his/her workplace.
And with that, start writing your own Mini-OS. Build on newer parts as you have time, you'll learn a lot and make lots of mistakes. However, someone once told me that as a new programmer, you have to make all the normal mistakes when you start, so that you don't them later on.
I've got a Bachelor of Engineering in Computer Science & Electronics.
That was one hell of a course - of the 26 that started only two of us ever graduated with it.
I did a small amount of contract programming in high school and was a fairly competant programmer before i started the theoretical stuff. That worked very well for me because i could sit there hearing about things like inheritance and mutexes and while most people's eyes were glazed over i was thinking of all the useful things I could do with them.
Being unecumbered by the technical aspects of programming made it so much easier to complete practical assignments while focusing on the theory.
The electronics side of it was very different. Before getting to college I could scarcely string up a few logic chips to make an LED flash. I probably had to work 5 times harder on that than I did on the comp sci side.
It's not that difficult. First start by opening your copy of Knuth's The Art Of Computer Programming Volume 1, and read chapter 1.3, it's only about 30 pages. You'll find on page 126 a paper based MIX emulator. Make some photocopies of it and with a pencil, execute program P (on page 148) directly on one of these photocopies, you don't want to write directly in the book. This should probably take an hour if you're a fast writer. Don't laugh, it's the quickest way I know to teach people how an emulator works.
The big thing I learned was that programming isn't everything.
Absolutely, you need to read "Writing Solid Code" and "Code Complete" and the other coding books, and write lots of code to spec and to deadline, but remember that getting a good program is a lot more than just writing good code.
Understand the requirements. Look behind the requirements to see what the customer really needs. Learn to distinguish "good" from "cool". Write tests! Write documentation (even if it's just documentation comments). Know how the delivery process works. Use a source code control system. Talk to people! Work in a team. Understand how the user thinks about the task that's going on. Study usability!
Oh, and google for "How to Write Unmaintanable Code", have a good laugh, and then resolve never to do anything that you have just seen.
Sean Ellis
Follow OfQuack's antics on Twitter.
But they are variables, which reside either in a register or on the stack. Using more registers than your CPU architecture has may have a negative impact on throughput. Once you've discovered that this has become a problem in your program's innermost loop, rolling out a million units of hardware with enough registers that flags do not negatively impact runtime does compare in difficulty to aerospace engineering. Or should this have been taken into account before as one of the overhead costs of a policy of blind adherence to structured programming guidelines?
I wrote my first 3d engine in 1996 when I was in high school ... well I cheated because I took it all from a book ... "Black Art of 3D Programming." It was curiosity which drove me. I sat there typing code in word for word. I spend the time debuging. Over a period of 6 months I began to realize what good C/C++ was.
... project managers, product managers, networking, security, database management ...
;)
Looking back at that time I was failing most of my classes. They were not of interest to me. The time I spent awake at school I read about programming so that I could go home and test it. That was my passion.
One my most respected instructors at the University I attended said that there are many people who are not programmers by nature. He said that is ok, there are still a large need for you in other areas of IT
Coding is much like a relationship, if you truely love your partner, the difficult aspects of the relationship won't interfear. However, it's anything but true love, it is bound to fail.
Hi. I'm an C++ expert with several successful start-ups in my history and what I can say is you should never make design or development decissions based on how cool code looks and how interesting it is to try new stuff. In most cases it hurts the project. What you can do is to find the job where you will develop something you're interested in (you're young and you don't have anything to lose anyway) OR you may participate Open Source project. There are plenty on them of www.sf.net. By the way I had unlucky chance to work with young and opinionated Harvard graduates and it was something. Now I truly belive that main major in Harvard on CS is self-convincing where they're trained to repeat "I'm so cool. Everyone is stupid."