Benjamin Juang (ibneko) wrote,
Benjamin Juang

Verizon stupidity aside, here's something useful..

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


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

While this wasn't what pulled me into computing, it may be your addiction. Here's what I would suggest doing--take a well developed open source emulator (you know, like an NES emulator []) and pick apart the source tree. You might find that the code is obviously doing some low level translation of the ROM which essentially changes its executable language to be IA32 or some such thing. It may be that you don't understand the architecture of the NES itself and therefor you can't really develop this yourself. So there's some insider information you lack but it will still be a good learning experience and may prompt you to figure out how to A) dump ROMs and B) reverse engineer a console architecture. Even if these are fruitless searches, how far you're willing to go will be a good indicator of whether or not CS is for you. Yeah, I hate to say this but I know people with CS degrees that simply don't have the debugging mentality to be programmers. A simple test is to think back to the times you saw something neat. Did you ever have a strong internal urge to find out how it worked or to try and modify it to augment its task?

But as I read slashdot, and other tech sites / articles, and realize for some of the software being written nowadays, I would have absolutely NO IDEA how to even begin writing it.
Fear not your own ignorance. Only fear your acceptance of it. I am confident that if I wanted to build an emulator I could. I personally find other things more interesting but you just have to buckle down and really pick it apart and look for answers. As I said above, these emulators might have proprietary reverse engineering so these backwards black boxes might not be the best place to start as you may be met with frustration. On top of that, the newer consoles are now fighting a war & implementing encryption scheme which just makes the emulator all that more complicated. Why don't you pick a project like Firefox? Get the source, find out what the common developing environment is and step through the code when you visit a page. That's where it all starts.

Most importantly, you don't need to do everything from the ground up. It helps to know everything that's going on below the abstractions you sit upon but you don't need to think about that every time you write code. Learn to use libraries & frameworks. To quote Salvador Dali: "Those who do not want to imitate anything, produce nothing." I couldn't start writing an emulater either. But if I looked at the source trees and structures of the more popular ones out there, I'm damn sure I could figure it out. That confidence I have in myself is infallible and that's important to me. Sorry to sound like Dr. Phil but you asked for my opinion.

There are different tricks to different applications. Some are more simple than others. In my opinion, the less tricks you need to get started in a language, the better. Because we're not all world class magicians (although every language has some players that could rock your world in said language). This is why Java, while not as efficient as C, is probably taught to you first. There are very few tricks one needs to know in Java. But you know what? Java is still quite useful. Those responsible for implementing it did a decent job and now the web service programmer needs to know very little about them because configuring them has been abstracted and made easier by many UI & IDE tools out there. But web services are a very practical and widely accepted concept out there today. In fact, pay the bills by writing some very inane web services that replace older code from days of yore. It's simpler & easier to maintain (in my opinion but that's not an flame war I want to fight here).

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

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

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


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


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


1. Don't confuse "Computer Science" with commercial programming. They are NOT the same thing.
Especially these days. When I received my degree, all IT-related degrees were CS degrees at a fair number of schools, and one simply chose a specialized track (systems, scientific, business) after finishing the CS core, but that's not the approach used at many schools today.

I liked the mix of practical and theoretical classes I took in the program I went through, though, since I think I've derived a lot of benefit from both types of classes over the years.

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.
Yes, unless you're a dedicated code monkey (something I've never personally encountered), you will be expected to do design work, create specifications, do support, talk to customers, help to coordinate tasks on complex projects, etc.

3. Do not ignore the business/finance side of your job. The business side keeps you employed.
Probably sound advice. In a large IT shop, you won't necessarily USE that type of knowledge in an overt manner, but it never hurts to be able to understand the business process and how it relates to your current position, and in future positions it could be tremendously helpful.

4. As you learn more, you will realize how little you actually know.
There's always someone else out there who's been doing it longer or better than you have. Or both. :-)

Pay attention to them -- such people are valuable teachers and resources, and I've learned a lot from people like that myself. Some programming tricks might be as old as YOU are. :-)

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.
In all the shops I've worked in over the years, we NEVER had folks who did software in an assembly-line manner. Even folks like me right out of school were doing (mentored) design work for the live system. Other shops may be different, obviously, but even the folks I've seen who were writing software from a func spec that someone else created had a certain amount of latitude in terms of its actual implementation (even if screens and inputs/outputs were all predefined, the internal structure was often left up to the coder).

Don't be afraid of trying to create things on your own. I've seen folks right out of school make a huge difference by writing a little utility or by applying something they learned from another platform, and sometimes even something small can make a large difference. Experienced people are often very smart, but their tred-and-true experience (while often relevant) can also blind them to new approaches at times. I'm guilty of that as much as anyone at times. :-(

6. "Engineering" software and "programming" are more different than you realize.
Both should involve a formal process (although not all processes which people have in place are constructive or even useful). However, real "engineering" seems to rarely apply to software development. I still haven't decided if that's a good thing or a bad thing overall.

7. Coding is the easy part. You can teach a cat to bang out code. It takes an artist to design good software.
Absolutely. The top priority should be readable code that is easy for someone unfamiliar with the gory details to maintain. That means relevant comments in the source and (hopefully) a good set of programmer support documents written in parallel with the software. I've had the privilege to work in two shops where that was done quite well, but that's the exception, not the rule.

My approach: I try to assume that someone I'll never meet will be trying to support the stuff I write ten years from now, and I try to write the code for them. In the real world that could happen -- I've modified code that was almost 40 (yes, forty) years old in past positions!

8. You have one of the best jobs in the world. Your technology base allows *you* the ability to build wondrous applications. Use it!
The ability to create something out of nothing is a wonderful thing. I know how it all works, most of the time, but it sometimes still seems like magic. :-)

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.
I've been able to treat my work as a game, mainly because I enjoy the puzzles that it enables me to play with and solve, but while I have a lot of fun, I also realize that there are times where formal processes have a place. There are reasons why QA and PROD systems tend to be locked down, and while it's tempting to play cowboy and go around the rules, you need to be very careful about choosing the times and places to do so. Pick your battles carefully.

Tags: life, programming, slashdot

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded