Working for The Man

Working for Google is full of surprises. When I first arrived I started to get to know my office-mate. He's a laid back, rather cool but studious-looking guy with longish hair. I asked him what he did and learned a lot about how students were taught parallel processing in a cluster environment.

Politely he responded with the same question and I started to tell him about Samba and what I was currently working on. "You remember around 1988 when AT&T came out with a file-sharing protocol called RFS (Remote File System) to compete with NFS (Sun's Network File System)..." I continued.

"I was eight years old in 1988", he replied.

After I'd finished checking for obvious facial wrinkles in the bathroom I decided to go on a quest to find other engineers in the building who were at least as old as I was, and felt much better when I found some. But it set me thinking about what kind of advice I would give if I could meet myself at his age, in order to guide the young Allison into a promising engineering career. So in the best spirit of "The Screwtape Letters", here is some of what I've learned so far about making yourself a career in writing software.

If it's not what you love, don't do it

I've worked with many programmers during my career. Without a doubt, the only ones who are any good at it are those who see writing code as art, a creative process. I know it's an obvious lesson, but it's really important. If you want to make lots of money and retire early, don't start by writing software; learn about business and start a company instead. I've run into so many poor programmers, in both senses of the word, who got into the field because they "wanted to be the next Bill Gates". Bill Gates didn't get rich by programming, he got very rich by being very good at running a company. I've had to fix code created by these people and it isn't pretty. Eventually they usually move into management where they might have a chance to find their true calling.

Learn the architecture of the machine

Many programmers, especially those who write for virtual machines such as Java or the .NET CLI, think that low-level machine architecture and processor instructions don't matter anymore. That's still not true, and I don't believe it ever will be. Someone who understands what the machine is really doing underneath all the modern layers of glop such as virtual machines, garbage collection algorithms, network and threading abstractions, will always be able to solve problems better than someone who lets the compiler or the "execution environment" they're using make all the decisions for them. These days the effects of processor caches and memory bandwidth mean that it's even more important to understand the lower levels of computer architecture than it used to be in order to be a good programmer. The good news is that modern tools like the amazing Free Software tool "valgrind" can emulate an entire processor in software and make understanding what is going on at each line of code as simple as looking at a visualization of execution time. Using resources efficiently matters when you're dealing with modern clusters containing thousands of machines.

Reputation is important

The days of starting at IBM after college and working there in obscurity until you retire are long gone. Any modern programmer will move between many companies in his or her career. It is very important to be able to show your next employer what you have done, and what you are able to do in a team. Free Software/Open Source is the ideal way of doing this. It's not just a better way of producing software, it's actually better for the reputation of the people creating it. One of the first things I do when evaluating someone is to look for samples of their code out there on the Internet. If you work on proprietary software you can't show anyone anything, and real code speaks louder than any list of projects you claim to have worked on.

Proprietary environments are a trap

I used to be a Microsoft Windows programmer, as well as a UNIX/POSIX programmer.
The knowledge I've gained about programming POSIX is still useful, even though I learned a lot of it over twenty years ago. My Windows knowledge is now rather out of date, and getting more so over the years. It isn't worth my time anymore to keep up with each increasingly baroque change to the Windows environment. Just as an example, over this time the latest "hot" communication paradigm that Microsoft recommended developers use in Windows changed from NetBEUI, to NetDDE, then OLE, followed by OLE2, then COM, DCE/RPC, DCOM, and now currently seems to be Web Services (SOAP and the like). Meanwhile, in the UNIX world the Berkeley socket API was useful in the 1980's and is still the core of all communications frameworks in the open standards world. All the UNIX RPC, object and Web Service environments are built on that stable base. Learn as much about the proprietary environments as you need to be able to help people port programs over to open standards. You'll never be lost for work. The same is true of any proprietary environment, not just Windows. Windows just happens to be the one I know best. What will get very interesting in the future is the effect a fully open Java platform will have on the software environment in the next ten years. After initially ignoring Java due to its proprietary restrictions, I now believe Java and it's associated libraries have the potential to be the next POSIX.

The network really is the computer

There are now no interesting non-networked applications. Standalone computers are devices for watching stored video or listening to music, usually on airplanes. People doing offline email are simply working in an extreme case of a network disconnect, a rather large network latency if you will. The Internet has become the real computing environment of the next century and all programming will become network programming. This is a more challenging environment than programmers have been used to, with connection, latency and concurrency problems making our work much more interesting than it used to be on the standalone DOS box. All entertainment and communications such as television, radio and the telephone network will move onto the Internet. Poor Sun Microsystems were twenty years too early with their "the network is the computer" slogan, but they will eventually be proven right.

The community is more important than your employer

Are corporations fundamentally amoral? If they can make more money by outsourcing your job to India or China, or recycling employees into fertilizer for the rose garden at corporate headquarters then will they do it? I once had to listen to several high-level executives (for a previous company that shall remain nameless) waiting for the private corporate jet complain how inefficient it was that the country was run by democratically elected politicians as "they just didn't understand business". Corporations are great places to work when things are going well, and I enjoy the perks as well as the next employee, but I'm very careful even in my optimism to not make the mistake of thinking this is the way things will always stay. In the Free Software/Open Source community the people you're collaborating with and creating code with are the people you can really depend on. Whilst you might not get on with all of them personally they share your common goal of making sure that the code is the greatest, most beautiful work of art that all of you can create together. Smart corporations, at least the ones you'd want to work for, hire from that pool of people, and even though individual corporations may stumble and fall, if you're part of our community you should be able to successfully manage your career between the occasional stormy periods of corporate upheaval.

If you come from a coal mining area as I do, you can't finish a piece like this without paying homage to Merle Travis's wonderful song about really having to work for a living. No matter how much complaining we do, at least we're not "workin' for the man" :-).

Good luck young Mr. Allison, and let me know if you have any more advice for him. I'd love to hear it.

"You load sixteen tons, what do you get?
Another day older and deeper in debt"
"Saint Peter don't you call me 'cause I can't go
I owe my soul to the company store" -- Merle Travis

Jeremy Allison


Learn the architecture of the machine

In my career, I have seen that "Learn the architecture of the machine" is something which is missing from even experienced programmers. 5 years back, I could find many who were interested in knowing things under the hood. But not anymore (May be because I work in the software services not products)


Double edged sword

Knowing the architecture cuts both ways. I've seen a Windows 9x program that refused to run on NT because it knew that this half of the theoretical 4GB address space is for the application, and the other half is for the system. So as "hacking protection", it validates all pointers to make sure they were in the proper half of the memory space.

Trouble is, NT swapped the halves. So the program is no longer able to validate any pointers. Everything is pointed at the wrong part of memory, and the whole thing crashes. It can't even generate a meaningful error message, because it thinks the pointer's invalid.

Now, if you didn't know the architecture, and instead simply assumed - as Windows API docs recommend - that the application has a 4GB memory space and 2GB of it is available for the application, you would never try to validate that something was in the right part of memory. The resulting program would run just fine on both versions of Windows.

That's not because he

That's not because he understood the low level details, its because he DIDN'T. He had just enough information to be dangerous, he didn't actually have deep knowledge, experience and understanding, or he would have known not to do something so dumb.

Do you know how much you don't know?

Of course, the real problem is that it is hard to know when you have "just enough information to be dangerous" instead of "deep knowledge". There's nowhere you can look that says "you are here, there are 2,574 more bits of knowledge to go before you have deep knowledge".

here here! There's always

here here!
There's always room for another bit.


Fortunately, the right way to deal with hardware is the same as the right way to deal with software: you depend on what is documented and guaranteed in the system, and you may measure and exploit, but never depend on, undocumented behavior. Read the documentation, measure performance, and use the interface. just like in software.

Unfortunately, the way programmers are taught encourages them to take the opposite approach. Schools give CS majors a broad overview of implementation technologies, because they want you to get the flavor of how hardware engineers do their job. The *flavor* is great, but the *information* is just a random snapshot of trivia -- how things happen to be at a given moment in time, like learning the internals of a library. From that, most software guys get the impression that thinking about hardware means giving up documentation, abstraction, and layering and moving into faith-based programming that uses third-hand legends about how the hardware operates. Unfortunately, that's how most "arrrr I'm close to the metal" software guys operate -- through superstition. In such a situation you're much better off ignoring all of your "knowledge" and depending on measurement instead.

In practice, taking a sensible approach to hardware often means throwing up your hands and declaring ignorance. You may be able to depend on a particular ISA -- or not. You may know something about the architecture of the machine the software runs on -- or not. You may know the OS you're running on -- or not. Your employer may find it acceptable that moving from Linux 2.4 to Linux 2.6 requires a minor porting effort -- or not. Tomorrow your software might be running on a virtual Linux box on an IBM mainframe, so you might not even know which metal is the "real" metal.

Legacy Systems are more closer

I have not too much of experience coding. It has been just 5 years since I started. Yes, I was only 8 in 1988. But, I can tell you for sure, if someone has to be aware of the architecture, if someone wants to learn it then you I suggest you to work on Legacy systems for a while. May it be OS390, ZOS or AS400. Coding is an art, a craft, sometimes a music, it is well written when well understood.

Chicken Soup for the Coding Soul

This was a great read for someone just starting out on the path of the code slinger. It mirrors alot of what I'm already feeling about working in the industry and my general outlook on the future.

I don't make a great deal of money, and don't expect I ever will. But I feel rich some times because of the challenges I get to work with in combination with the flexibility I'm given in dealing with them. I get to be creative every day, learn new skills and then apply them to solve real world problems in a creative way. If satisfaction is a real measure of wealth, I feel fairly rich as it is.

Thanks for the prospective Jeremy

I'm finishing my tenth year as a programmer and I don't see myself doing anything else for a long time. Sure I will probably work for a number of companies going forward and god knows what will happen with outsourcing.

Anyway, I work for the man during the day and at night and weekends I work for myself (as a programmer). I make good money and feel blessed to be able to do something I love and have the ability to more than provide for my family. I've never had time to "give back" to the Open Source "community" that I call on regularly for my projects. I never really thought about doing it to gain a reputation and be able to show you stuff as you suggest. I need to rethink and make time I guess. One thing I always run into is the inability to show off what I've done to prospective clients or corporations I may want to work for. I want to give back and need to be able to show more of what I can do. Thanks for the fresh prospective

Jason Darrow

Re: Thanks for the prospective Jeremy

Anyway, I work for the man during the day and at night and weekends I work for myself (as a programmer). I make good money and feel blessed to be able to do something I love and have the ability to more than provide for my family. I've never had time to "give back" to the Open Source "community" that I call on regularly for my projects. I never really thought about doing it to gain a reputation and be able to show you stuff as you suggest. I need to rethink and make time I guess.

A few words of note for this. I am the author of PlaneDisaster.NET, a MS Access and SQLite frontend written in .NET. I put it on my resume and it was brought up on an interview where I was offered a job that I accepted. So I can say it did help.

First of all, it was mentioned by the person who did the technical interview. He said he downloaded it, installed it, started it up, was impressed by it and closed it. He did not use it, nor did he read the source code. The person that was asking me about stacks and boxing did not bother to read the source code. So make sure you can handle the crushed ego that comes from your work not being properly appreciated.

That brings me to my second point, don't expect anyone to actually use your project. Even if they do, they won't tell you they are. I get a handful of downloads a day, and all I have to show for it is one anonymous bug report on sourceforge, and mentions on two usenet threads. Write a program that is useful to you. Then put it on sourceforge, register it on SWIK and ohloh, write about it on technical wiki's and blogs in the hopes that other will find it useful. Don't worry about support issues, because there will probably be none. If there are, I have no advice on handling it, but let me know how you actually got users to interact with you.

Also, you don't have to write code to give back, you can also write documentation. I highly recommend this to system administrators, as they are the ones that actually use our software. But programmers can document the APIs they use. We always complain about bad documentation, so why not do something about it.

One final note. If you want to contribute to other peoples work, and not your own, don't talk about it, just "show them the code." Write the patch and send it in. Assuming the patch is good, and the project is small, the author will probably accept it. By the third patch, you will have a SVN account.

Justin Dearing

It's the Company You Keep

The .Net crowd is made up of individuals (I've found). The GNU crowd is made up of teams, cultures, fluidity of ideas, etc. Do something creative in the GNU sphere and you'll see a difference.

Re: It's the Company You Keep

The .Net crowd is made up of individuals (I've found). The GNU crowd is made up of teams, cultures, fluidity of ideas, etc. Do something creative in the GNU sphere and you'll see a difference.

Thats not what I've found. Both sides have there share of individuals. They also have there share of teams, cultures, fluidity of ideas, etc. The SharpDevelop team has a nice community. I've written a few project and file templates for it. Why do they have a community and I don't? Because I get 10 downloads on a good day and they get thousands. The vast majority of users never giver feedback or file a bug report. The problem is I am just not filling a great need. More people want an open source .NET IDE than want a SQL front end to MS access. There are many superior front ends to SQLite to chose from. I'm sure if I wrote a program for doing LDAP queries in java, it would not be very popular because there is a very small market for that.

Common refrain

"Learn the architecture of the machine"

And Yegge says: "I've said it before, and I'm sticking with it: having a deep understanding of compilers is what separates the wheat from the chaff. I say that without having the slightest frigging clue what "chaff" is, but let's assume it's some sort of inferior wheat substitute, possibly made from tofu."

Just two of the many well-respected developers who feel low level understanding is incredibly useful to your programmer's chops - regardless of the n-th level abstractions used today. Methinks it's about time to dust off the compiler & OS books.

Great post!


Chaff is anything that isn't

Chaff is anything that isn't wheat berries when you finish harvesting the wheat, e.g. wheat hulls, dirt, stems, bugs, and wee little Irish people. Clearly you want to separate the wheat from the chaff before you throw it into the grinding wheel.

Nothing wrong with knowing compilers

What's wrong is having a concrete idea of what "low-level" means. Is the ISA low-level? It depends. Some microprocessors translate legacy ISAs into an entirely different machine instruction language. Sometimes the ISA is executing on a virtual machine. It's often an illusion to think you know where the metal is. It's also an illusion to think that you can label any particular layer to be "low-level" and another layer as "not low-level." When you're writing an embedded app, low-level means setting register bits on hardware peripherals like DMA controllers. Using system calls is high-level, since having an OS is practically a luxury. When you're writing a Java servlet, low-level means knowing which system call your deployment JVM uses on your deployment OS to implement polling.

Dig Deeper

I think the point is not to find out the One True Reality under all the abstraction; it's more a general admonition to dig deeper than you nominally have to, to not be satisfied with the uppermost layer of the stack of abstractions you're currently using.

Machine Architecture

I advocate understanding the underlying architecture of the machine. However, I also advocate understanding the "underlying glop." If you are programming in a language with garbage collection and a virtual machine, then it really behooves you to understand garbage collection and virtual machines -- to the extent that you could implement your own.

Whenever I teach friends to program, I point them at Core Wars first!

keep a library of example programs

Perhaps a bit low level in the advice department, but ...

You know all those little example programs you write whenever you are learning how to use a new library, language, or tool? Like a pair of C programs to open a TCP socket and send/receive a string typed on the command line? Or a program to use the PCAP library to sniff a packet from an ethernet interface and write out the IP header fields?

Don't throw them away. Save them in a directory of examples. Under the top level example directory, have a subdir for each language, and under that, have a subdir for each library, tool, or concept.

When you write such a program, and the first few attempts to get it working fail, add comments to the code recording what you were confused about and why.

You will be amazed how quickly your personal library of example programs grows, and what a valuable resource it will be when you need to come back to a topic you haven't touched in months or years.

You'll be writing your own text book as you go along, one perfectly matched to your own tripping points and interests.

You wouldn't believe how many short example programs I have in my personal library just to keep straight how the various features of C++ work. Any how long it took me to stumble across some of the finer points.

Chris Marshall

Brilliant advice !

Keeping a "junk code" directory is wonderful advice. It's something I learned from tridge, who has been doing this for years.

It's amazing how often you end up looking in there for a snippet of code or remembering how to do something/use an API.

One more thing I didn't get time to add in the article - "there's always someone smarter than you" - learn from them :-).



Its a great read!

Its a great read!

And myself at the crossroads as to continue with software or to move onto management, this perspective gave me some valuable information. And since i love coding, guess i will continue with it! :)

Thanks for the insight.

Amruthraj Belaldavar

really good article !

Its a really neat article but i am still in a delimma , i want to ask you few things that involve my path as a programmer ( i know the chances of you answering them is very minimal , but still i am posting it ) . I want to learn and do many many things as a programmer . From writing computer games , to compilers to tweaking with OS kernel code , playing with design patterns , language design , algorithms etc .. the list is endless

My day job is with an enterprise company which writes business apps , but having written interpreter, crawler etc .. in my college days i get very little time for all the things i mentioned above , and that i want to persue . Its hardly been 2 yrs out of college , but learning new technologies .. exploring my passion .. contributing to opensource , doing projects i like ... is making my life a curry

People I ask , say , do 1 thing at a time . But .. when i want to do everythin .. doing 1 thin jus doesnt sink in .. wld u share ur thoughts on this .. plz plz .. :)

programming path

So you are interested in lots of different software topics and want suggestions on which path to take?

I suggest you start using and studying slackware linux. A modern linux distribution represents an amazing collection of software and the system init and package build scripts are a treasure trove of detailed information about how it all fits together.

The reason I suggest slackware is that the whole distribution is held together by well commented, straight forward bash scripts. The package system, for example, is just a collection of a few bash scripts. Most other distributions use custom programs written in C that by comparison are much harder to learn from.

slackware is well put-together and easy to inspect a piece at a time to learn from. It has guided my explorations of the software world for the past 9 years now.

You might want to buy the OReilly book on bash first and get comfortable writing complex bash scripts. You will find that single skill a key to many others. Especially when you find yourself wanting to explore everything, the skills that act as keys to many others are more important to focus on.

Chris Marshall

Thanks for the comment.

You're going to have to specialize at some point. I did eventually, after doing work on such varied things as Windows, OpenLook, X Server internals, SunView, IEEE-GPIB interfaces, and a million other things.

Do as much as you can on varied technologies - eventually you'll start to recognise the core things that are important under all of them. That's why I'm happy specializing, as I know I can dig into the details on things like Linux kernel i/o scheduling if I really have to (and sometimes I do :-).


You can't do everything

You can't do everything. There just aren't enough hours in the day. If you try you'll make no significant forward progress in any of them. Pick one that looks especially interesting or that can be tackled quickly. Do it until you have a good feel for it then move on to the next one.


Amen Brother!

Yep. Great post.

On the other hand, since there aren't that many young programmers who really know hardware, who have ever heard of Von Neumann and Harvard architectures, much less what those things might be, who think pipelining has something to do with surfing, I have a very busy and profitable embedded systerms consultancy.

And I'm sitting here chuckling away as I look at my bookshelf. There I have, and occasionally refer to, my BSD 4.3 manuals. Heh heh heh.

Waving the Flag

I found this post very interesting.

I am a first year student studying an Information Systems Degree and although its focus is much more business related this term during our first term we did a Computer Fudementals module in which we studied Assembly Language, Computer Arch - including the much loved Von Neumann and Babbage history - along with principles of programming languages.

I never aspire to be a programmer I find the 'techie' side of computing to hard and am much more relaxed in my Fudamentals of Information Systems and Organisational Behaviour modules. I find Java to be a little complex for my liking and would much prefer to build a website over a java application.

But I am just doing my best to wave the flag for those that are learning about the core principles of computing and say that we do exist in today's day and age!

Future Career

This is one of my future career choices, depending on how I feel in 3 years time after I graduate from High-school. I'm a software fanatic and I've taught myself HTML and learning Javascript, however software is the true goal I seek.

Thanks for the advice!


My advice.

It's better to be doing what you want, for less money, then to make bank and hate your life.

At least, in my opinion.

That said, money still matters, so do what you can, early on, to negotiate a high a starting salary as possible.

Re: Bill Gates

Bill Gates owes his success to a shrewd business sense, a complete lack of morals and rich parents. Think carefully about that before attempting to emulate him.

My final advice is, don't underestimate the role of luck and timing with regards to success. For every Larry Page and Sergey Brin I know a few hundred folks that are just as smart and worked just as hard that didn't make it. Don't take it personally if you aren't an internet billionaire at age 30.


A few years ago I was in college. I came to some stunning realizations: I not only sucked at math, I HATED math. Also, C++ was all the rage and people at my U were also all about "elegant" programming solutions. I so had it drilled into my head that I'd have to get with the program or I'd never go anywhere, that I went lateral and changed majors. Now I work for a small newspaper for not much pay and my wife and I barely scrape by.

But you know what? I don't really regret it. Not really. I've heard too many horror stories written and told by people who worked for a few years, and by 28 they were burned-out husks working at McDonalds.

Not that the newspaper life is good for the soul, but at least I'm not being judged on how many thousands of lines of code I write. That has to be the stupidest metric I've ever heard of. Thank God I had the sense to get away from that.

Programmers are certainly

Programmers are certainly not judged by how many thousands of lines of code that they write. Anyone that does that is clearly not capable of judging a programmer.

The myth of the KSLOC

It's true that "Anyone that judges programmers by how many thousands of lines of code that they write is clearly not capable of judging a programmer." The people who do this are software project managers. Why should we even consider them to be more capable of evaluating programmers than any other PHB? ;-)

Unfortunately, KSLOCs (thousand source lines of code) is the standard way to evaluate programmer productivity. It is a very objective measurement. Any boob, or even a PHB, can count lines and (probably) come up the with correct answer. It has it's base in one of the first large software engineering studies, wherein the conclusion was made that the cost of writing a fully tested and documented SLOC was roughly constant, no matter what language the line was written in.

While working on my graduate degree in SW engineering, I was reminded of this. At the time I also was working on a moderately sized software project. Wondering if the study conclusion could possibly be correct, I considered the most recent project I completed. It was an "object" written in FORTRAN77. It was fully documented, moderately tested and comprised of 1000 lines of F77 code. It took me two weeks to complete.

Next, I approached another programmer in the department and asked about the last fully tested and documented project she completed. It turns out to have been a maintenance effort that took six months to complete and produced three (3) lines of assembly code.

"Roughly constant" apparently means "within a few orders of magnitude" where KSLOCs are concerned... Of course, without this myth, the PHB's have nothing to measure programmer productivity, at least, nothing they can understand. Without that, they have no basis to estimate cost & schedule for software projects, something they are critically interested in doing.

No wonder software cost & schedule estimates are legendary for their lack of accuracy!

-Anon E. Mouse

...well, indeed.

A few years ago, I too was in college. I also sucked at math. It was COBOL and ColdFusion where I went, where the university was _very_ fixated on business, and I hated business - accounting, marketing, bleh. I too had it drilled into my head that I'd have to get with the program or I'd never go anywhere, and I went lateral and changed majors to journalism.

Now I work for a small newspaper for not much pay - but I'm single and debtless, living with my old college roommate for next-to-no rent, so I'm stacking away a little bit of cash, with just enough now for three years of college tuition.

I just enrolled in college - a different one this time - to get back into computer science. I've seen too many horror stories written and told by _journalists_ who worked for a few years, and by 28 they were burned-out husks working at McDonalds, or burned-out husks in middle-management working 60 hours a week. I'm _becoming_ one - I just got off my third straight 12-hour day, and I've got at least three more coming in the next week, to go with six 55-hour weeks in my last 12 weeks of work.

We're understaffed and can't find anyone to hire at our pay rate. People are fleeing the company like rats from a ship - all young, frontline designers, editors and reporters - and fewer positions are opening up to replace them. Circulation is plummeting, our web hits spiked for the holidays and then plummeted, advertisers are cancelling accounts and all four of my colleagues are looking for ways out - none plan on being here by 2008.

Then we get the memos from our paper's executive to kill a controversial story from the paper, presumably to protect advertisers - not two weeks after all us underlings attended mandatory ethics training, where middle management stressed resisting the appearance of outside influence by advertisers. (All of this in just seven months of working here, too.)

That executive was just named a finalist for best executive in the chain, mostly because _his papers are failing slower than most of the rest of the chain's._

That has to be the stupidest metric I've ever heard of. Thank God I have the sense to get away from that.

I'm not attacking your point of view, or your decisions - I respect and understand them, having had them and made them myself, and I hope they work out better for you than it did for me. I wouldn't wish my experience on anyone, and from the sound of your post, things seem to be working out well enough for you. Either that, or you just started, and as they say, the best is yet to come.

I just hope you understand that newspaper life, or any kind of life, also can burn you out if you let it, and the only person who can judge you with any real success is yourself.

If someone wants to try to judge you on lines of code or missed deadlines, that's their problem. Take pride in your work, place value in it yourself, serve others the best you can, and let others do what they please about it. If you let someone else dictate your life, you're forfeiting it - that's what I've learned through my experience here, and that's why I'm getting out of this business and going back to what I loved so much in the first place.

Good luck to you, but please - don't let anyone push you around and out of something you really do enjoy, and if you can, try to find something that is good for your soul.

All work and no play....

If I may add an additional recommendation - Your job is not your entire life. Too many people in software these days clearly feel that if you're not contributing to at least one OSS project, planning your own start-up, and learning two new programming topics, all while working your full-time job, you're not a dedicated (i.e. 'good') programmer. " If you work on proprietary software you can't show anyone anything, and real code speaks louder than any list of projects you claim to have worked on." I love my job, I consider myself lucky to do the work I do and get paid for it. However, I love my wife, my daughter, and my dogs more than my job, and lately, that almost seems like a detriment to my employability.


ComputerWorld had an article many, many years ago that I always remember: "self flagellation or dp martyrdom?" Your users go home at 5 pm, and solve the problem the next day, but why do you have to spend all night fixing a problem?

Be happy


Why take software to your heart

The way i see it, software is just like any other industry and it feels stupid to be at the bottom level i.e. a programmer even at the end of the career. I would see it as a good starting point, but then one has to move on to do better things like managing and investing, rather than sticking to just writing code. Code is wonderful, i don't deny it, but you have to see the end result, what you are going to get through it. you can hire 100,000 developers to get a job done, i mean real good people if you pay them what they want. I just see software only to that extent, just like you pay your mechanic or your construction builder.

There are lots of challenges in management too and it takes more brains and emotional IQ to solve those problems.

Utter nonsense

> There are lots of challenges in management too and it takes more brains
> and emotional IQ to solve those problems.

What complete and utter garbage. "Emotional IQ" is a wanky term
for "how well people like you". It doesn't mean you're good at
dealing with the emotional aspects. It just means you're not a complete
and utter prick.

Code is wonderful!!! Moving into management is an escape clause for
programmers who don't have the inclination to excel at anything they do. I started
at the bottom nearly 10 years ago. In the current company I work for if
I leave the whole product line fails and they close up shop. Not because I've
made my self invaluable, but because nobody there, bar one or two have
the inclination to learn all the skills that I have. Still, I'm at the bottom because
the managers there are complete and utter pricks and are happy to promote
ass kissers and those who know this week's buzzword technology (NetBEUI,
COM, DCOM, whatever, to quote the example in the main article) rather than
those few who are doing all the work and holding the place together.

I am at the top rung as far as software development goes. I didn't go into
management because, quite frankly, I don't need the bullshit that goes along
with it. Saying that being a master developer still leaves you on the bottom
rung is insulting to me, and the thousands of other brilliant people out there
who are on the top rung. Sure, we don't get the status of "manager", but at
the moment I'm looking to move on and I have found that companies are
asking me to write my own cheque - and I can tell you that cheque is often
more than the CEO earns. Not one has complained so far. I have a number
of very good offers to consider in the next week.

So, piss off with your belittling of coders.

Now, back to the software. Knowing the machine is all-important. If you're
in a virtual machine then you need to know the VM and make some
assumptions about the hardware that will be underneath the VM. These days
piplining and cache structures are very important. Processors have moved
far past the performance of system memory. If the programmer doesn't
understand the limitations imposed they cannot write efficient code.

I got where I am by understanding what the compiler does to my code, and
how the machine will run it. Using those two important pieces of information
lets me write better code. The compiler will let you do anything - there is no
guarantee that it is efficient on the machine you are targetting.

A point to add to the discussion is know many languages, well. Knowing C
(or C++, ADA, etc) will only get you so far. You can sit at the machine
level all day but for high level tasks you should use a high level language.
Why spend a day writing in C something you can do in Perl in 10 minutes,
specially if it's only run a few times and execution time is non-critical?

Writing software is about emiminating the need to do a task manually - about
improving efficiency by getting the computer to do the task for you. If you're
going to be a serious programmer you need to know how to leverage the
tools available to improve your own efficiency.

Know the operating system you're developing for. Chances are that if you
need to make a particular sequence of system calls to (say) open a file then
there is already a system call to do that for you.

And finally: do not make yourself indispensable - you will just increase your
workload and number of parallel tasks to the point where you can't keep
up or burn out. If you're the only person that can do something or knows
something then you'll be the goto guy/gal whenever that needs doing.
Share information with your coworkers freely. Do not be scared that by
passing on information you will improve the promotion prospects of others.
In my experience it doesn't matter how good you are, but what buzzwords
you spout as to the seniority of your title.

Wow, just wow

Code is wonderful!!! Moving into management is an escape clause for programmers who don't have the inclination to excel at anything they do.

Or it's a natural progression for those who want to do more than code. I like doing both, but find that being part of management gives me greater control over my own destiny.

"Emotional IQ" is a wanky term for "how well people like you". It doesn't mean you're good at dealing with the emotional aspects. It just means you're not a complete and utter prick.

I'm guessing that your Emotional IQ isn't all that high then?

And finally: do not make yourself indispensable - you will just increase your workload and number of parallel tasks to the point where you can't keep up or burn out. If you're the only person that can do something or knows something then you'll be the goto guy/gal whenever that needs doing.

This I agree with. You never want to be the only one that knows how to do something. I work with someone in that situation, and she works 70 hour weeks quite regularly.

In my experience it doesn't matter how good you are, but what buzzwords you spout as to the seniority of your title.

All Aboard the bad attitude train! Man, you seem a bit bitter about something. I'd suggest taking some Emotional IQ classes.


They are swapping contracts here. All the programmers are going from one contract to the next. All the managers? Gone. This happens every few years.

"how well people like you"

I think you're both wrong. Many factors affect how well people like you. Emotional intelligence is your ability to use the factors under your control. Psychological research has demonstrated that how well people like, trust, and admire you is determined by many things outside your control, such as your height, race, and beauty. As social machines, people function pretty well. In my experience, the people with nasty antisocial attitudes are the ones who didn't stand to lose much by them. You can't honestly promise them a big change in status if they become all smiles and social skill. They will become happier and marginally more socially successful people, true, but they won't move out of their social stratum or discover that all of a sudden people are willing to trust and follow them.

I say this as a guy who had to make a big attitude adjustment and who has been consciously working on my social skills for many years. I've made huge improvements, and some thing have really changed. I'm much happier. My friends and loved ones are happier. I'm able to circulate and enjoy myself in much larger circles. However, some things have not changed:

* the kinds of people who want to be good friends with me
* the class of women who want to date me
* the kinds of people who let me play a leadership role
* in general, the social roles I'm allowed to play

So basically, despite all my improvements, my social stratum has not changed at all. Nor has anyone liked or loved me who would not have liked or loved me before. They merely find it more enjoyable these days. I've also observed other people and have found very little evidence that people cling to bad attitudes that hold them down in the social heirarchy. They will hurt themselves and their friends, but not their social position.

So, before you recommend EQ training or an attitude adjustment as a way of changing one's career track, consider whether it would really make a difference.


I'm glad you don't mind management, that's probably where you belong. You sound like one of those pricks he describes who doesn't have the intelligence for anything except making condescending responses to others.

Utter nonsense or dependant on your company?

I think you're contradicting a bit. First you explain us how a good programmer doesn't directly have good loans, then you explain how other companies would give you, the good programmer, everything you want!

I think it is VERY company dependant whether the loans and promotions are "fair". The guy who wrote this article works for google, which seems, from the outside, like a "fair" company. Thus, whatever he says while drinking coffee, he's getting reward for what he knows and does.

A point to add to the discussion is know many languages, well. Knowing C
(or C++, ADA, etc) will only get you so far. You can sit at the machine
level all day but for high level tasks you should use a high level language.
Why spend a day writing in C something you can do in Perl in 10 minutes,
specially if it's only run a few times and execution time is non-critical?

SO true :)

Writing software is about emiminating the need to do a task manually - about
improving efficiency by getting the computer to do the task for you. If you're
going to be a serious programmer you need to know how to leverage the
tools available to improve your own efficiency.

True, but one should never overkill that. Using neural nets constantly to do whatever you want is not what i call programming. Programming is more like writing a book: you have some opinion or knowledge about some subject, and distribute that in a form everyone can use or understand. It's not all about making shells for the TCP/IP connection. It's not all about making the protocol useful.

All brains, right....

"There are lots of challenges in management too and it takes more brains and emotional IQ to solve those problems."

Way to take credit for how tall, confident, good-looking, and charismatic you are.

I once worked with a forty-year-old Chinese guy with one tooth, or maybe just one tooth you could see. He was a mathematician, a decent coder, and a brilliant software architect. He was also very good at keeping track of what everyone was doing and getting them working together with no friction. He had all the intellectual skills necessary for management, but he wasn't even our official team lead. Some young guy (who had the good grace to defer to our real leader) was the guy who talked to management.

Management means living in an interface (think chemical interface, not software interface). What matters is that people on both sides of the interface trust you. If you happen to have a few characteristics that cause external people to distrust you (watch "300" and look at the villains for a list of things that inspire knee-jerk distrust -- race, sexual ambiguity, and physical deformity, to start with), you're disqualified from management no matter what your skills or goals are. Don't assume it requires "more brains" just because so many people are incapable of doing it. It's true that emotional IQ plays into it -- it helps to be able to quickly understand people's reactions, and to figure out what they need to hear to trust you. Intelligence is only one factor, though. A one-toothed guy with a thick Chinese accent, if he were a management genius, would end up at about the same level as a tall, good-looking guy with no social sense at all.

...and this is quite true

...and this is quite true and sad!! :(

Merle Travis, just a cover

"You load sixteen tons, what do you get?
Another day older and deeper in debt"
"Saint Peter don't you call me 'cause I can't go
I owe my soul to the company store" -- Merle Travis

Try the original ... by Tennessee Ernie Ford


Actually, while Tennessee

Actually, while Tennessee Ernie Ford may have popularized it, he didn't write it. Merle Travis did.

You're right (as if you didn't already know that)

You said Merle Travis, I was thinking Merle Haggard -- and I knew he wasn't old enough to have written it.

"Knowing the machine" is a waste of time

Pop quiz:

  • How many transistors make up the machine you are currently sitting at?
  • How do you optimise instructions on drum memory?
  • How would you key in the program you are currently using on a panel of switches?
  • How do I break my code into overlays?
  • What special codes can I send to a teletype?
  • What is the function of each pin of the microprocessor in the computer you are sat at?
  • What is the voltage range for the Vcc pin on the 7400?
  • What are the advantages and disadvantages of TTL and CMOS?

At some stage in computing history, each of these questions would have been important. Nowadays, some are still important in some environments (eg overlays to embedded programmers), but you already know if you're working in a specialised enough environment to need such esoterica. The majority of business software development doesn't need this stuff.

Don't sweat the small stuff.


I came up programming on the System/38 and AS/400. The whole point of those architectures was that you didn't have to know the underlying machine.

I depend on the compiler to optimize the object. I've seen too many cases where someone has tried to optimize for the machine (or whatever) and written unmaintainable code. It was true in when I started in 1984 and it's true now - machine cycles are cheap, programmer time is expensive. Optimize for maintainability and the compiler should be able to do the rest.

More ancient Absolutely

And the same was true when I started in 1963 - there are still a few old programmers out there. You don't *have* to know the machine, but you *should* know *some* machine (it does not matter which) so that you can appreciate the levels of complexity between your code and what is actually happening. And, yes, maintainability is *far* more important that machine cycles.

And "if you don't love it, don't do it" is a perfect piece of advice. An excellent article.

Ian D K Kelly

Great article

Thanks for sharing your perpective... it's nice to have my instincts confirmed by someone who knows the terrain.

-Mike (

Learning from a Craftpersons by Russ Eckel

I am not a programmer. Not even close. But I was enthralled reading this post. This is an epistle in support of mastery and the art that is found in all good craft work. In this article one hears confidence without hubris, the joy of creativity built on a solid foundation of tacit knowlege, and the practical wisdom of someone with a sense of history. It may also be a prescient reply to the growing number of people concerned that all of this "left brain" work will find itself being done in the new "factories" where people will churn out code for a fraction of what people earn in this country.

I'll read this one several times. Thanks for your thoughtful perspective.


my advice for programmers is never forget that it is not the code or program that is important to your customer but a working solution that solves customer's problems

Find a mentor

Find a mentor; somebody who is older and wiser, and who is willing to share their knowledge freely and without obligation. Learn as much as you can from them.

Be prepared to be a mentor yourself. It is how you repay those who were mentors to you.

Recognise when you have exceeded your current or past mentors' knowledge. Humbly accept that, and continue to respect them - they still will have other areas of knowledge and expertise that will be valuable to you.

Don't complacently accept that you now are an authority on a topic once you exceed your mentors' knowledge - go looking for new mentors. There will always be somebody who knows more than you or has different experiences and knowledge that are of additional value to your body of knowledge.

"If I have seen further [than certain other men] it is by standing upon the shoulders of giants." - Isaac Newton (1642–1727)

"The more I learn, the more I realise what I don't know."

"A man's got to know his limitations." - "Dirty" Harry Callahan, Magnum Force

Mentor invaluable

This is another wonderful addition. When I was learning to code last century in the 80's :-) I hung around some guys who were really smart. At first I pretended to understand their conversations so I could be "cool" and fit into what they were saying. I understood only 10% of what they were saying so I'd smile and nod so as not to appear stupid. I didn't learn anything :-).

Eventually I just stopped one of them mid-sentence and said "actually I didn't understand anything you just said, could you explain it to me please ?". That's the point I actually started to learn. You have to lose your fear of looking a fool :-).


Contacts, contacts, contacts

You can program by yourself all day, but you will die without contacts. You can hire in without them from college, but after that forget about getting an interview without knowing someone or being the absolute best in a necessary niche. All other non-critical anonymous jobs will go to the cheap guys overseas. Besides, you can't think unless you do it with others, and contacts are fun to have.

Wow, that's horrible advice.

First, it's untrue in most markets. You can find work at senior level without a substantial contact network; I just did it. Maybe in a more competitive market it is different, but to make a blanket statement like that is irresponsible.

And, "You can't think unless you do it with others?" Not all of us are dependent on using groupthink to mask our personal deficiencies.

Programmers tend to be introverts and implying that they have to be tied down to frat-boy-style 'networking' is doing most of them a great disservice. Thankfully, the smart and experienced ones know you're full of it anyway.

Point of Order

I think you read too much into the original statement that "you can't think unless you do it with others". An idea that doesn't stand up to critical review - i.e., thinking with others - is lacking.

Yes, we're introverts. No, we don't need frat-boy networking.

At the same time, we do need to make sure that we are sharing the knowledge that we learn with those around us, and learning from the knowledge of those around us.

No group-think. Just a recognition that we don't know everything.


Just because you are an introvert doesn't mean that all programmers are. And what's up with the "frat-boy" comment - get rejected at rush or something?

I love a team environment - you not only get to have your ideas critiqued by others, but can learn from your team mates. If you are so insecure as to think that working with others is "group-think" then you are really limiting yourself. I learned more in my Topology and Number Theory classes in college when I was required to defend my proofs to the class. The same thing holds in programming.

I don't know what rush is so

I don't know what rush is so if you're flaming me it didn't work.

Learning from teammates is always positive. And there's a lot more room for collaboration in academic environments... But, in a real-world environment where everyone has their own responsibilities, too much reliance on teammates places pressure on the other members of the team. That's OK if you're a junior programmer and are in a role where you can learn on the job, but a senior person needs to be able to stand alone without having others cover their arse. Senior people collaborate, but they also lead, which requires confidence in one's knowledge, or ability to arrive at the right conclusion. You don't get that from other people - it's something that has to come from within. That's what I meant by "group-think"

Software Commodity

From what you perceived about software industry, I am pretty sure you work for a body shop. To find out what programming is truly about, find a job in a software production company for your next career move.

Sadly I'm only lacking one thing

I'm the same age as your office mate, but I must have had my head on straight when I was learning computers because everything in your article I know. Except for one thing:

If you want to make lots of money and retire early, don't start by writing software; learn about business and start a company instead.

Sigh, a lot of friends recommended business while I was planning for college, but computers were my thing so it was strictly computer science and math.

My town barely has any computer jobs. The few that are out there are all taken by middle-aged computer guys who couldn't cut it in a real city. Because they have the experience from their past they get the jobs. Honestly I haven't met any who actually know anything about modern computing.

And so I've floundered about with part-time jobs and gigs, while beefing up my resume with open source projects. After a decade my highest paying job has been temp work lugging boxes, and my highest grossing job has been 7-11.

I've been stuck here because of family and college, however we are seriously considering moving simply because I know in ANY big city I can get a decent job. My resume finally hit the point last year where it is certain. I've got a computer job now finally which actually adds yet another nice line to it, but again it's part time. And the pay...

I often wonder if I had taken business instead and just caught the classes I needed to round off my computer skills would I have done better in college and in life. This town actually needs good computer folk, and if I were to open a company providing just that I think I could easily be sitting pretty.

So my advice to the hotshot seventeen year old who already knows a few languages and cut his teeth on pure machine language because that was the only thing interesting to him/her.. when it comes to college time, consider art or business. Art will help you turn that ML into a beautiful program you can show to the non techs, instead of numbers crunching on the screen. Business will help you turn those skills into profits.


Llynix advice

Your attitude is what is holding you back. I work for a company that was a startup, then got acquired by a mid-size company and now is getting acquired by a big multi-national and the hardest part of my job is finding good developers. By good developers I’m talking about the ones being described in this article, the ones that have a passion for what they do and see writing software as the same thing as creating a fine piece of furniture.

I find it interesting that so many people disagree with the fact that you need to learn the internals of the machine; I think that is absolutely essential. Most people don’t even realize the order of magnitude difference, between memory and disk speeds/network speeds. You can be a good object oriented developer, have the perfect base classes, perfect inheritance pattern and have a terrible product because you don’t know how the overall system works. Most people do not have the patience it takes top learn this level of detail, the interrupt level in daily life makes this difficult. If you can’t do a google search and get back the exact information you are looking for in 55 milliseconds, then people move on to the next thing. There use to be a time before Google (BG), where any manual or book you got was treasured and squirreled away for the knowledge it possessed, I worry that Google searches are replacing that deep level of understanding most good developers had to build up…

Anyways you can still live in that small town and make good money developing software, but you do have to go after what you want. Start by trying to bid for some outsourced projects from Companies that can’t get everything done. Build up you contacts, write emails, send sample code, maybe even do a project for free to show people you can do it. It is not going to fall into you lap, but if you can make some mid level managers job easier by writing a test harness or a utility program, you will have people beating down you virtual door with work.

Good luck Hugh

Small town freelance work

I won't try to dissuade you from moving to a city--I'm probably doing the same mid-year. But then I said that last year and the year before. And small towns aren't a bad place to live, and you're right, they do need computer help.

The best thing you can probably do is learn accounting. This is not hard; like programming it takes a few basics and practice. My latest and best gig has been with a small farm mutual insurance company who needed help with systems, accounting, database, and in the end, an occasional calming voice. Most all businesses need an accounting system, and in a small town, many still don't know it!

Also, every process imaginable is going online. People who have used paper for decades must now fight with I.E., Flash, Javascript, etc. Yesterday I was in a small coal&gravel trucking company. They now have to process shipping manifest through the customs service online. Couldn't get the tutorial running. Couldn't follow it once it was running.

Here in Appalachia, prices can be tight. But if you're gonna work at poverty level, at least do it in a way that gives you free time. I bill at an incredibly low $40 per hour. But, I don't have to go to a store every day. In the past 3 years I've worked to:
Unhose peoples windows computers (least profitable)
Onsite network, installation, and repair service for government offices and small businesses
Websites for: County government, a newborn/infant program, a dairy sale, an insurance agency, a golf course, a tourism agency, a bed and breakfast...
A lot of training
One thing I don't do that you could is contract programming via leads on the net. I have bought such services.
Its not easy, and you have to find some steady customers who you can count on. But you also don't need a business degree--just a little knowledge of accounting and common business sense you can pick up at Borders/Barnes&Noble. Good luck whichever way you go!

All you need is a break

There are plenty of people looking for good programmers, but they don't trust resumes, and they don't trust talk. Plenty of people can talk the talk. What they trust is the opinion of technical people who know you well and above all the opinion of guys you've worked with in the past. When you get the chance, make sure you do a reliable job and are a pleasure to work with. Until then, just cross your fingers. I just got a new job through a guy I've known for years. He said, "The job posting is online, but don't even bother looking at it -- HR listed all the wrong skills and got it mixed up with another job we already filled, and it would be a huge hassle to correct it. The way the job is posted now, nobody is applying, which means I don't have to deal with any resumes." Once you get your first break, you'll have "contacts," which is just shorthand for, "People who liked working with you, would like to work with you again, and would recommend you to other people."

So what if your town barely has any computer jobs?

You are complaining that there are few computer jobs in your city. This is the twenty-first century. Clearly you have a net connection.

Go over to Paul Graham's webiste and read Why To Not Not Start a Startup.

You are young. You aren't carrying a crushing debt load. You don't have a bunch of people depending on your paycheck. Start a company.

A view from the Windows trenches :-)

1) If it's not what you love, don't do it - So true. It will drive you nuts if you are just doing the job to get paid. I tell people that I'd be doing this as a hobby even if I wasn't being paid for it (which is true although some people find it hard to grasp). If you can say that then you're in a good starting place.

2) I agree about machine architecture, up to a point. I missed the whole assembler coding boat (too young) and it's never stood in my way. I've written Windows apps the hard way (message loops, pointers to event handling functions etc) and it's good that I know how to do it but these days with .NET I call on those skills less and less. I think the "architecture" you need to know is dependent on the level of code you're writing at. It is good to understand the fundamentals of your platform but at a business level with .NET or Java apps your "architecture" becomes the framework, CLR/JVM, HTTP and SOAP protocols, garbage collection, SQL etc. You need to know how they work and what they do under the hood so that you can use resources efficiently but how that translates into x86 assembler I care less about...

If on the other hand you're writing something at a device driver level or fiddling with the kernel - then you'd better know the details of the machine you're running on. It's all about context.

3) - and this is where it gets contentious - Closed source software isn't a dead end! Truly proprietary systems like the bizarre languages some companies have to run their embedded machinery or whatever are no use on your CV, that much is true (unless you want to spend the rest of your working life in that industry). But enterprise application development on Windows has provided me with an enjoyable and decent living and shows every sign of continuing to do so, so it would be hypocritical of me to say that there's no future in it. (this may be the wrong blog to post that comment on but since it's a generic "when I was your age..." post I reckon it's still relevant!)

Sounds like you traded in humanity for Stanford Exclusivity

Given that it's a rarity to even hear of "Midwestern/Appalachian" backgrounds at Google, your background precedes you. While I have come from a similar (coal mining/manufacturing/large, humane conglomerate) family background, some things just do not line up - and they are with issues related to Stanford Style exclusivity and worker respect/loyalty.

I would have to disagree on requiring mobility through lack of job security, in that job security needs to be an untouchable "third rail" - again. Seeing places like IBM and its more localized and quite humane (until their AT&T merger/spinoff) counterpart NCR fall from being respectable, inclusive corporations that respected their communities to ethically bankrupt shadows of themselves.

Loyalty does go a long way, and it does not mean you're at a company town, or store. It means you have a community without the need to develop connections of exclusivity. It means that there is something expected of you and expected of others.

The first thing I do when evaluating someone is to look at their educational background and see how exclusive they are - those who welcome the unconnected/unanointed score highly, Ivies/Stanfordites go on rock bottom. Many times I have seen someone from an Ivy or some other "Gated Community" university bring things to ruin. Change is one thing, ruin is another.

The next is to then apply that same criteria to their work, noting humanity and openness to the unconnected first, "Stanford System" exclusivity dead last with their outside involvements. While this may sound like it's a bad case of Jante Law, too many of that background has caused ruin.

Mixing mobility as a requirement with Stanford System exclusivity is suicide if not a major CLM. "Working for IBM in obscurity for a long while" would be better as a viable option for those who do not have the blessing of high class ranking, wide reputation, or tons of money. Working for a humane conglomerate does have its benefits far and wide - and you don't have to lose your background for it. These days, you can even move from them. However, I value loyalty, encourage it, punish those who cross it, and forgive those who return to it.

I am quite surprised they even looked at your background until I saw you have thrown most of your history out. You sound like you would be the kind that would turn on his own, and has. You may be from coal country, but you'd be the one who'd not care if you seized the family farm in a tax hike.

As for Anonymous /122/55:
While there are some who get well-connected, you completely disregard those who would work well but do not have contacts all over, especially at exclusive places like Stanford and its pet project of many things exclusivist, Google.

What are you talking about ?

I grew up in the Sheffield/Rotherham/Doncaster/Barnsley connurbation in the UK. I have *no clue* what you're talking about with this "Stanford System" or "Stanford Style" ? Last time I looked Stanford was just a local university here in the Valley :-).

I go back home to visit the relatives at least once a year, so don't tell me I've lost track of my roots :-).


The network is not the computer.

The network really is the computer

There are now no interesting non-networked applications. Standalone computers are devices for watching stored video or listening to music, usually on airplanes.

There are many interesting non-networked applications. Any artist, musician, video editor, or animator has a pile of them. Applications for creating tend to do a lot of heavy lifting of data that lives on the same machine.

I find these to be pretty interesting applications from a user's perspective - and the fact that new entries in these fields pop up now and then indicates that there are programmers who find them interesting, as well.

Would you want to do your programming in a text box on a web page? Probably not. Serious creating is a task for local tools, polished for the task and configured to fit your hand. And some people find making these tools to be an interesting challenge.

Also, there are games. There must be something interesting there given how many people are out there writing them just for fun nowadays!

nice post!

I really enjoyed your post, as a just graduated programmer and as a computer geek in general! Thanks!

Also, "Know the process"

Like it or not, software development has a lot of process, so you might as well learn to like it, or at least take the time to understand the how's and why's of it. Every young developer should read books and articles on software engineering. Every young developer should be starting to understand the actual cost of development, how to gather and validate requirements, risk managment, ways to improve quality, factors that impact maintenance, etc.

There was a recent slashdot article discussing the fact that those job candidates who cannot code, *really* cannot code: they cannot even code fizzbuzz. Well, the same is true of process knowledge: I frequently reject candidates young and old who are unclear on things like the purpose of a release branch, code coverage, or use cases.

If you don't understand the software development process, you will always be limited to just doing little coding tasks given to you by others who do understand software engineering (or worse, those who do not).

Writing code is an art

I absolutelly believe it. It is true that everybody can learn languages and tools easily, but few programmers can write good code and solve problems stylishly.

    "Be code, my friend"

Jeremy, thanks for your post.

Inspiring :)

I find the article extremely inspiring in nature! Thanks for such a post.

I am from India and most of the software industry here is actually software services industry. There are really a handful of opportunities where you actually get to write codes. As third world country residents, people here are very much bothered about making quick money and securing a future. Needless to say that this idea attracts a lot of young people into the software industry. But one has to try really hard to find people who are in love with programming as a subject. (I don't know if this is the same elsewhere in the world) I suppose about 90% Computer Science, Information Technology and other conventional engineering disciplines like Civil or Mechanical engineering etc join the software services millions. The general trend is to strive for an on-site placement for about a year or more where you suddenly get 10 times your salary as long as you stay in US or Europe. The job profile there is providing support to your client, fixing some problems here and there and interacting and being nice to the persons who have the money to spare. Some people try to pursue some MBA program and join back in either software or other industries. If you notice, codes are not in the scenario at all! Coding more often then not is looked down upon in these companies. The most common quote about programming that I have heard is - "After all you are not going to write codes all your life." As if coding is like the worst thing that can happen to you and you are desperately looking for a way out to be some stupid manager with no idea or control over technology. "Hell Yes! I want to code all my life". Engineering graduates just don't seem to understand that there can be immense pleasure in creation, in creating beautiful architectures, in writing beautiful codes! Isn't that shocking?

I started my career about a year and a half back with a well known large software services company. I got very tired in about 6 months. My eyes were thirsty for some codes. The company employs about 80,000 software engineers now. I joined a company which has about 120 employees and I am actually using what I learned and learning a huge lot of stuff as I write codes. Maybe I am doing a lousy job with the code now but I am sure I am improving :) I get to create semaphores and threads with C++ on embedded Linux devices! Can life be more beautiful :)

This blog surely inspires me and tells me I am on the right track. Thanks again.

sendtoansu AT gmail DOT com

IBM until retirement

Strickly speaking, the days of working at IBM for your whole career are still here, but that doesn't mean you're wrong. I know lots of folks here who have changed careers several times and never left the company. That's what happens when a company has 300,000 employees.

Getting Paid for Open Source

I must admit I love to use open source but have never contributed to it. I love to program and would love to do it all day long, but I have a day job and a wife and 4 kids. What I want to know is how the heck are all you people out there contributing to these open source projects without getting paid? Which leads me to my real question, maybe you are getting paid and if so then by who? And how do I get a job where I can contribute to the open source community and get paid?

what a great post -- kudos

I'm surprised though, that nobody's pointed out that "learn the architecture of the machine" should really be "learn to see how the principles of computer science apply to whatever you happen to be doing." Notice the patterns that apply to whatever "glop" you happen to be working with, be it virtual or physical; stack or register; synchronous or not. Algorithms and data structures, if you like...

This isn't to say that theory substitutes for practice, and certainly not to say that the best way to learn that stuff is in school, but rather that theory is the thing that lets you see the connections between *seemingly different* architectures, languages, platforms, etc. More to the point, it lets you troubleshoot with confidence. If you know the fundamentals you can look past the top layer of glop, and maybe the layer under that, and so forth, to the layer that represents what you're looking for. You can tell the difference between rules which can be broken and rules which cannot (or should not).

The only things I learned back in the day (not in school, as it happens) but which still apply are fundamental theoretical things. Kernels and bare iron nowadays are practically opaque to me. There's hardly enough room in my 43-year old brain for the things that put bread on the table. But the same basic principles are everywhere, and they're more or less fractal. After twelve years of nothing but *n*x, I recently accepted a job which requires me to spend a lot of time wrestling with a .NET C# thing called CommunityServer. It's remarkably badly written, in a language that pretends to be Java but isn't, using a horribly overengineered framework that abuses HTTP and HTML in unspeakable ways, and yet it all pretty much made sense within a few weeks.

Also I would second what another anon said about process. Methodology will be your friend if you let it.

Are you Affiliated?

"You load sixteen tons, what do you get?
Another day older and deeper in debt"
"Saint Peter don't you call me 'cause I can't go
I owe my soul to the company store" -- Merle Travis

My mind is like a fruit machine,
Spinning round!
There are two plums on the bandit,
Lend me a pound,
(jackpot, jackpot)
Though I try to join the club of life,
They alway shut the door,
The little man wants my members car,
And the plums come round one more!
-- Howard Turn

My mind is like a fruit Machine, Spinning Round.

I do not write software, but am simply trying to find out the title of the above song that was posted on this site on April 7th. This is the only entry on the net I can find!

Inspirational Stuff

Mr. Allison in this blog note you provide great inspiration for your young self and confirmed one or two my suspicions of software development life. This blog note was an excellent read. I have been working as a contractor now in the UK in London for a few years. I definitely second that emotion "community is more important than your employer". There are those programmers who assume too much faith in an employer. When the wheel come undone from the truck then those programmers will feel the chill wind of change, if they especially have not prepare themselves for the fall. Best of luck to you, Sir.

Peter Pilgrim
Sun Java Champion

Know the low-level, know the high-level... The rest is easy!

Great entry!

I happen to have done my fair share of assembly language programming decades ago. I still follow the latest CPU developments (for example the more or less recent HPET high-precision x86 timer and how they were used in various Unix systems, including recent Linux kernel or the recent hardware virtualization technology).

I agree 100% with the two posters who noted that it's not about knowing how every single, say, Java instruction translates to Java bytecode then to x86 code (which is itself translated by the CPU ;) but that you better understand how API calls translates, at one point or another, to system calls. You can't simply say "I know Java, this is enough".

I think it's about understanding the low-level pretty well and also understanding the high-level pretty well. It's all about CS. Everything in between low-level and high-level is quite easy to grasp once you've got the big picture.

I'm a fan of language theory, I'm curious about many languages (Objective-C, Eiffel, Erlang, ...) and many scripting languages. I do most of my programming in Java (and some Unix shell scripts) though. And I do still learn (approaching 40) many things: OOA, OOD, why in some languages some Design Patterns are needed and useful, while some others aren't necessary in other languages, etc. Understanding how an OO design can be translated to OOP using a third generation language like Java, etc. Why Java and C# are not that great OO languages etc.

Since a few years I've been coding mostly in Java and I know the language, many of its APIs and many of its gotchas darn well. But I wouldn't say I've "specialized" in Java. I know the computer and the OS basics, I could switch to the next big thing in a heartbeat.

My advice (it's an opinion) would be: learn how the low-level works, learn your algorithms, learn the high-level concepts. And experiment with a few languages. Then you'll be able to adapt to anything.

On the new patronage economy

Great stuff. It was wonderful to see this blog, given i had used your name "in vain" in exactly this context...

Know the General and Learn the Specifics

Universal advice is difficult to come by, for any profession, once you get beyond the basics. I'm currently working in the defense industry, so let me use a few military parallels. The military differentiates between TTPs and higher order learning. TTPs are Tactics, Techniques, and Procedures. These are the Wax On - Wax Off stuff. You must learn this stuff well first before you can more on. This is what you should be learning in college. Stacks, Queues, linked lists, etc. Learn this stuff and you can do it in any language from assembly to python. If you get a solid education in the fundamentals in your four years, you can learn any language in days, weeks, or months, depending on the circumstances, well enough to get you 80% of the way to coding in that language.

Then you hit level two. Architecture. You may be able to code 80% of the way, but if you are coding in the wrong direction, it is all for naught. I'm sure you've heard the story about how the manager gets his team to hack through the jungle quickly and the leader climbs the tallest tree and tell the manager to shift 90 degrees to the left. Again, learn the basics of multi-tiered distributed computing and it doesn't much matter if it is implemented as EJB or Web Services. You learn the specifics depending on the task upon which you are currently focused on. Let me switch to construction. You may be able to use each of your tools well, but that doesn't mean you can build a house.

Also, in the Army, there is the concept of one up and two down. Know what your commander is doing and know what they are doing two echelons down under you. Many of the comments talk only about going down - know the API, know the hardware, etc. With only a very few exceptions, no body has commented on what's up. In order to do well, you need to know how your code fits into the bigger picture. You need to know where you fit in the architecture. And, in parallel, you need to know how the customer/user is going to use your code in particular and the application in general. It doesn't make much sense to cut seconds or even minutes off of a process that is runs at COB Monday, and the results aren't even viewed until the second cup of coffee on Tuesday.

And this isn't limited to just the code. Know what marketing does and why. Know how QA works. Learn sales and why it is important to not choose the most eloquent solution that takes one year when your biggest customer needs it in three months. Spend some time learning just how difficult it is to develop useful documentation that cuts down on the number of tech support calls. Oh, you did remember to ask for a few days away from your usual coding task to work the tech support call center for a week and find out how your stuff is used in the real world. Learn how all this interrelates and interacts at least to some degree beyond the cosmetic covering.

Then make a choice on how to best tackle the project on your plate. The one you have right now. On this hardware. In this architecture. At this company. And switch from the general to the specifics. Learn how to do it in C++ in Visual Studio 2005 .NET on Windows XP in a three-tiered architecture. And when you finish that project, you will be way behind on the general stuff. So buck up and get back on it.

Lather, Rinse, Repeat.


Learn debugging

I find that the thing fresh programmers invariably suck at is debugging code that doesn't work (which, truth to be told, happens 99% of the time when you try to make something). At best they're trying to insert print statements to understand what the code is doing, at worst just staring blankly at the source trying to figure out where it goes wrong. What they lack is a basic knowledge of the tools that are at their disposal, debuggers, static analysis (even compiling with -Wall seems to have escaped some...), profilers etc. What you need to learn is how to quickly form a hyothesis of what causes the malfunction and then test the hypothesis. This is easiest accomplished using a debugger, and in many cases require writing _more_ code which performs simple 'experiments' that can be analysed...

I can't for the life of me figure out why this isn't part of the standard education...

Working for the man

First of all, thanks Jeremy for putting in a lot of things that I would like my programmer
team to follow. Having worked on samba protocol implementation, I appreciate the
amount of hard work, coding and reverse engineering that Jeremy has done.

I would like to add only one more thing to it ( and while I follow the philosophy and
advice all the programmers to do so, I have first seen it on Linus's site ). Divide
functionality into smaller functions of 40-60 lines. I have found through experience
that this is immensely helpful and goes a long way in writing robust programs.


blu ray ripper

I like the post,add it to my bookmark. PDF to Docx Converter

Back to top