Jeremy Allison's Advice to Young Programmers
Hyram Graff writes "Jeremy Allison has written a wonderful piece with advice to young programmers. As someone who's been out of college for just over a year, I find it to be a very insightful piece. Please allow me to say, thanks Mr. Allison!"
Something tells me that account won't last long if you keep that up, but damn, it's been awhile since I've seen anyone audacious enough to post content like that, even as AC.
Now that you mention it, you DO offer sound advice. All the of the scenarios portrayed therein represent terrible situations which young programmers (or anyone else, really) would do well to avoid. The chain(saw) especially.
None of those images even fazed me. Go back to /b
It's not what you know, it's who you know. That advice is contained in the article in spades. You are much better off being part of a community. When you find yourself unemployed, your next job will be determined by your reputation. The article points out that the best way to build a reputation is to contribute to open source projects. Slaving away in the back room on proprietary projects is a crummy way to build your reputation.
On the other hand, the best way to make a lot of money has, up to now, been to know the right proprietary software. There was a time, not so long ago, when knowing Oracle would make the difference between making $30k or making $100k. I have a relative who made a lot of money because he was an expert in MUMPS. I think that is changing. Open source is the future. The article points out that jobs no longer last thirty years. You will probably work for many companies and your ability to get the next job is much enhanced if you are well known and respected in the community. The paradigm is changing and the old rules may not work much longer. In that respect I think the article has it exactly right.
Coding is a bit like sex. It's only satisfying when you do it for the joy of creating code, not if money's all that matters to you.
I've seen a fair lot of people who're trying to get into the biz (the key word here is trying) for the money. This was especially a disease during the dot.com times. People who didn't have any love for the art of creating code tried to squeeze into the biz because "That's where the big bucks are". They would have shoveled shit if that would've been the next gold mine.
That's not how it works. Writing code is painful at times when you love it, I can't even imagine what kind of hell it must be like if you don't like it in the first place. And when you don't do it out of love for the art, the product is going to be a living hell for those that have to suffer using it.
But there's another advice I'd give to aspiring programmers: Learn your math, learn your algos. When you know how to solve a problem, language is not an issue anymore. When you know how something is done efficiently, it doesn't matter at all what environment you get pushed into, it doesn't matter if someone comes up with the next generation of code creation tools, you will grow into it smoothly. If you only know how to hack together code, copy/paste style, if that's how you implement your algorithms, you will have to relearn it again and again every time the environment and coding style changes.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
- Yes, but does it run Lunix?
Grandparent "On the other hand, the best way to make a lot of money has, up to now, been to know the right proprietary software."
Parent "Open Source will not change this."
So you're saying that the best way to make a lot of money is to know the right proprietary software? Probably not. In any event, you're not even wrong.
Wear Sunscreen.
I wouldn't change a thing in what he said, and that is saying something! I put it right up there with The Tao of Programming as a worthwhile resource for new programmers.
Cragen
TFA is dead on. My advice is to work daily on your curiosity and creativity skills. Don't tell yourself you are better or the best. It isn't about that. Learn to be a good user and administrator of software, so you can walk in others' shoes (apt-get is your friend for this). test test test. When your emotions get the best of you this may help (it helps me): http://en.wikipedia.org/wiki/Noble_Eightfold_Path.
Have convictions and be prepared to defend them. The worst mistakes I've ever seen have been by people doing things they knew they ought not be doing and hoping that lack will keep them out of trouble.
I know this sounds like ridiculous advice to give to young people, who for perfectly understandable reasons tend to have more convictions than they have experience. But that changes all too rapidly, and the time will come when you will need your integrity muscles, and you don't want to find out they've gone flabby on you.
It is the job of the engineer to do the things that are too hard for most ordinary people to do: analyzing, calculating, planning and designing. Courage and integrity are a vital parts of the engineer's role. Integrity is simply this: fitting your deeds to your words, or in an engineering context, delivering what you promise. Much of business runs on denial; on promises made with no actual knowledge of whether they are possible to fulfill. As an engineer denial has to stop with you. It's your job to deal with things as they actually are, not as we wish them to be. This means sometimes you have to make the unlikely probable, or to deliver at least something of value when confronted with the impossible.
An easy way to have integrity is to play it safe. There is nothing wrong with playing it safe; its the best choice most of the time. But sometimes the reality is that the apparently safe course spells failure. From what I have seen, young engineers tend to either play it safe all the time or to take unnecessary risks. Aristotle said that courage is not the opposite of cowardice; it is the midpoint between cowardice and rashness. Every worthwhile project has an element of risk, but as an engineer it behooves you that this be a calculated risk. Leave the wishful thinking to others who don't have reality based professions.
In engineering, every interesting problem involves dealing with pairs of desirable things, of which you can't have both in unlimited quantities. An aircraft ought to be as light as possible and as strong as possible, but the lightest possible aircraft is not strong and the strongest possible aircraft is not light. An engineer ought to have integrity, but be flexible in his approach. He ought to have convictions, but work smoothly and professionally with others. He needs honesty, but also discretion about when and to whom the truth must be told.
All of which is damn near impossible. But if it were easy, everybody could do it.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Doing what you love is all well and good, but if you have a family, you have a responsibility to support them. This swings both ways, it means that a man may have to do a job that he doesn't like, and a woman may have to give up a job she likes in order to be there for her kids. To do otherwise is not only irresponsible, but it leads to the sort of families that get denounced on every game thread here.
Here's a better suggestion: find a job that is run by people who appreciate the fact that work is not the be all, end all thing in your life. You'll be a lot happier with an employer who asks you to only do 40 hours, unless there is an exigent circumstance.
And here's another... if you spend 12 hours a day at work and in commute, chances are you won't have a great relationship with your significant other after several years. Your kids won't know you. You'll be happy, but chances are, that happiness will be at work, not at home.
Generally, you're right. But the best a novice programmer can do is to reinvent the wheel. Over and over. Writing the billionth bubblesort surely will not add anything meaningful to the world's codebase, but it's a good way to improve yours.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
http://www.careerowlresources.ca/articles/articles 04-26-02.htm
Unless most career sites are wrong, most jobs aren't advertised. When I look back at my own career, a couple of my best job changes came because a friend said something like: "Why don't you come work over here." I certainly wouldn't be where I am without a little help from my friends.
Your success on the job is determined by your people skills. There have been studies documenting that for the last sixty years.
You can be the rugged individualist if you want but it will bite you in the ass sooner or later, if it hasn't already.
I would have expanded the section on community being more important to include something about the importance of computer lore.
You should learn about and know the stories which have been handed down from those who have gone before, because stories are a cornerstone of any community. If you've never heard of the programmer named "Mel" you should look him up. There's a whole pile of this.
Do you know what a scratch monkey is? Knuth and his obsession with fonts? How much is a binary dollar and how could you earn one? Would you have cashed that check? The first computer bug was famous, but what else do you know about the discover of that bug? Do you TOP POST (don't do it, it shows a lack of respect for convention and tradition.) How about the Tao of Programming? Do you know when the summer that never ended began? Can you become famous with grep like Kibo did? When is the first time you ever heard of David Rhodes or a green card lawyer? The University of
Texas has Dr. Dijkstra's papers online. Have you read them?http://www.cs.utexas.edu/users/EWD/ Do you know where the original Kremvax was located?
Have you ever purposely thought about how you could create some community folklore of your own?
If you don't give a crap about the folklore and history of the community you're thinking of becoming a part of, then that is one sign that maybe it's not for you.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
I agree with the "do what you love" statement, but I can't say that I really agree with any of his "technical" points. Sticking to non-proprietary standards works really well in some cases (like web-based development), but in some cases non-proprietary standards just don't exist or really suck. Plus, the "network is the computer" thing works well for Google, but if you're writing a client only app or embedded code on a small device (which is still a huge part of the software industry, despite what many believe) then that just doesn't make sense.
I agree with the general message of the article, but some of the points are too focused on the view from his limited perspective.
I think the amoral outsourcing characterization is a bit unqualified given recent leading thought on the subject:
Paul A. Samuelson, "Where Ricardo and Mill Rebut and Confirm Arguments of Mainstream Economists Supporting Globalization," Journal of Economic Perspectives 18(3), Summer 2004, pp. 135-46.
Jagdish Bhagwati, Arvind Panagariya and T.N. Srinivasan, "The Muddles over Outsourcing," Journal of Economic Perspectives 18(4), Fall 2004, pp. 93-114.
Alan S. Blinder, "Offshoring: The Next Industrial Revolution?" Foreign Affairs 85(2), March/April 2006, pp. 113-28.
As an old programmer, I'm not too impressed with that advice.
It's important today for a programmer to understand how top management thinks. Read the Wall Street Journal and the Economist. After about a year, both will start to make sense, as it takes about that long for all the major subjects to come around once or twice. Eventually, you'll probably want to move into management.
I'm not sure how much low-level knowledge really matters today. I understand what's going on down to the level of what happens in the wafer fab, but that's more because I'm in Silicon Valley. Understanding programming at the C level, definitely. At the machine code level, that may be too much detail to learn. A general notion of modern CPU architecture is useful; you should understand what caches do, why cache misses kill performance, and the implications of this at the program level. Detail beyond that level probably won't help you much. Understanding how an adder works is irrelevant to programming today.
It's probably more important to understand networking in some detail. Understanding Ethernet, DNS, WiFi, TCP, PPPoE, etc. is necessary, because they all can give trouble and you may have to diagnose that trouble.
I have to agree about the long-term value of UNIX knowledge vs. Microsoft-related knowledge. I first used UNIX in 1978, and programming on it has changed surprisingly little since then. We still have "make", we still have source control with check-in and check-out, and we still have a command line. And it doesn't go away. Since first using UNIX, I've used a half dozen other systems, most of them now defunct. Some were better. I keep getting forced back to UNIX, because it's still there after the others go away.
Asking for code samples from job applicants doesn't seem to work. A few years ago, I was asking for "a thousand lines of C++ code you're proud of." Few programmers could come up with much. Reading the code was sometimes painful. I sent one back with the note: "Your first buffer overflow is on line 22. Thank you for your interest."
Learning new programming languages isn't that hard, once you've learned a few different ones. What takes a long time is learning the quirks of a library. Today, each programming language comes with an library API with a few thousand objects and calls, some of which work reasonably. Finding out about the ones that don't is the most time-consuming part of learning a new environment today. This has led to a "ritual/taboo" style of programming, where huge books give sequences of code ("incantations") known to work, rather than development from first principles. This is the main source of career lock-in today. Be aware of that.
Bullshit.
Counterexamples:
Just because something isn't part of the "networked OS! AJAX! Live.com and Google! It's all about the network! Woo-hoo!" hype, that doesn't mean it's unneeded, not useful, uninteresting, or has exhausted its potential.
There's still a LOT of room for improvement in desktop software and OSes that has nothing to do with a focus on networking features, and that's still very exciting stuff to work on.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Really there are two different kinds of programming in the world, of which Mr. Allison only regularly traffics in one.
A small minority of programmers do things like write Operating Systems, Protocol Stacks, Embedded Systems, or ever have to give a flying fig about the POSIX spec. (Or the Windows counterpart, for that matter.) These people are well served by CsC degrees, a fondness for algorithms, CPU Arch. knowledge, a current IEEE membership, etc.
This is the sort of code created by what is generally referred to by the "tech industry". It is a pretty fair-sized industry, but is dwarfed by...
Corporate IT programming. The gigantic majority of code used in this world is not written by technology companies. It is written by folks working in corporate IT departments, small application shops, etc. These are folks that toil day in and day out in DB languages, VB, COBOL, the AJAX and LAMP stacks, etc. These folks really don't need to spend a great deal of time learning basic principles, because processor architecture really isn't relevant to SQL or LAMP. These folks can get by with a Community College degree where they will either learn to program properly, or not.
Both kinds of programmers can show great passion for work, both kinds can turn out really great code, or really pathetic code. The world certainly has need for both kinds or programmer, but tends to use a LOT more of the second. Look at job listings... how many openings are there for SQL, AJAX, COBOL, etc. gurus, vs. Low-level OS programmers?
Some of Mr. Allison's advice applies to both kinds of programmer. Certainly your resume will never be hurt by contributing to community-based projects, but learning the language-of-the-week can be far more lucrative skill for an IT programmer than burning time learning about processor registers.
For the record, I work in support, not development, but I work at a level low enough that I would be closer to the first kind of programmer, not the second. I eat bit-wise protocol traces for breakfast, chew on ANSI standards for lunch, and end the day with a hearty meal of high-speed network topologies capped with dessert of an IEEE journal or two.
SirWired
Not too bad advice, but some key points seem to be missing.
1. Get a degree or some sort, in ANYTHING to fall back on. Computer Science is still useful, being a branch of mathematics and all.
2. Do not let a n employer stomp all over you, (ie: EA, most game software houses). They don't own you, just your time from 9-5.
3. Consider getting an engineering degree, in software. It's all the fun of programming, but you get to tell programmers what to do.
Young programmers, here is how to be better than 99% of your competition: buy and read "Code Complete" http://www.amazon.com/Code-Complete-Second-Steve-M cConnell/dp/0735619670/ref=pd_bbs_sr_1/103-2943223 -4107013?ie=UTF8&s=books&qid=1176100440&sr=8-1.
Sure, it's great to love what you do, regardless of money. Yet does that really compensate for having to go to a place every weekday at a certain time, spend 8+ hours doing that activity, follow orders, ask permission to take time off, and be unable to live in material comfort if you decide to stop doing it?
The scariest part of that article is not what coding we will be doing in ten years, it's the comment from the high-level executives from the corporation. They essentially wanted to get rid of the democratically elected government:
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".
Lift your eyes from your monitor and WAKE UP!!