[The opinions expressed here are mine alone, and not those of Google, Inc. my employer.]
Commentary -- Making a career out of writing software? Remember that the community is more important than your employer.
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 itI'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 machineMany 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 importantThe 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 trapI 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 20 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 10 years. After initially ignoring Java due to its proprietary restrictions, I now believe Java and its associated libraries have the potential to be the next POSIX.
The network really is the computerThere 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 20 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 employerAre 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, 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. While 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" :-).
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
Good luck young Mr. Allison, and let me know if you have any more advice for him. I'd love to hear it.
Jeremy Allison is one of the lead developers on the Samba Team, a group of programmers developing an Open Source Windows compatible file and print server product for UNIX systems. Developed over the Internet in a distributed manner similar to the Linux system, Samba is used by all Linux distributions as well as many thousands of corporations worldwide. Jeremy handles the co-ordination of Samba development efforts and acts as a corporate liason to companies using the Samba code commercially. He works for Google, Inc. who fund him to work full-time on improving Samba and solving the problems of Windows and Linux interoperability.
.
