Slashdot Log In
Jeremy Allison's Advice to Young Programmers
Posted by
CowboyNeal
on Fri Apr 06, 2007 04:22 AM
from the take-heart dept.
from the take-heart dept.
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!"
Related Stories
[+]
Linux: Jeremy Allison Resigns From Novell In Protest 344 comments
walterbyrd writes to alert us to word from groklaw.net that Jeremy Allison has turned in his resignation at Novell. "The legendary Jeremy Allison (of Samba fame) has resigned from Novell in protest over the Microsoft-Novell patent agreement, which he calls 'a mistake' that will be 'damaging to Novell's success in the future.' His main issue with the deal, though, is 'that even if it does not violate the letter of the license, it violates the intent of the GPL license the Samba code is released under, which is to treat all recipients of the code equally.' He leaves the company at the end of this month. He explained why in a message sent to several Novell email lists, and the message included his letter to management."
[+]
Linux: Post-Novell Interview With Jeremy Allison 65 comments
schestowitz notes an
interview with Jeremy Allison, of Samba fame, after he had left Novell in protest
over the company's deal with Microsoft. From the interview: "My guess is that the negotiations for the useful parts of the agreement (the virtualization part and the federated directory interoperability part) had, as Ron [Hovsepian] says, been going on for months and just before Novell wanted to seal the deal Microsoft turned up with 'there's just this one more thing we want you to sign...' and in desperation to get the other parts of the deal done they rushed it through."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
It's not what you know ... (Score:5, Insightful)
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.
Re:It's not what you know ... (Score:5, Insightful)
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.
Open Source will not change this. Despite what seems to be common belief among some people, a program being open source does not make it a commodity. Non-trivial environments do not change software platforms on a whim, be they proprietry or open source.
Parent
Re: (Score:3, Insightful)
Re:It's not what you know ... (Score:4, Insightful)
I'm sorry, but I think you're overestimating the relevance of the OSS community.
To give an obvious example, my employer is currently recruiting. The senior technical guys doing the interviews/selection know plenty about Linux and GCC, since we use them all the time. However, I doubt they've heard of anyone in the OSS community apart from maybe Linus and RMS. IME software development is a small world, and unless you're looking for your first or second job, it's far more likely that someone at a prospective employer will have worked with you before or know someone who did than that they will have read the credits of some piece of OSS you contributed to, remembered that your name was 17th on the list, and actively pursued you.
This isn't to knock the value of contributing to OSS. Doing so can help you learn a lot, demonstrates a willingness to volunteer your time to something you think is worthwhile, and often shows that you can get things done as part of a large, distributed team. These are all good news for a prospective employer, so go ahead and put the work on your CV. Just don't have any illusions about headhunters coming knocking at your door because you once fixed a bug in $OBSCURE_OSS_TOOL. It just isn't going to happen, except for a very lucky few.
Parent
Re:It's not what you know ... (Score:4, Informative)
Parent
The first advice is also the most important one (Score:5, Insightful)
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.
Re:The first advice is also the most important one (Score:5, Funny)
Also, it's very easy to make a mistake which you don't discover until several months later, but which you end up having to support for the next two decades.
Parent
Re:The first advice is also the most important one (Score:4, Funny)
Parent
Re:The first advice is also the most important one (Score:4, Funny)
a missing period can mean big trouble.
Parent
Re: (Score:3, Funny)
Re:The first advice is also the most important one (Score:4, Insightful)
Parent
Reinventing the wheel == learning (Score:3, Insightful)
And of course, (Score:4, Funny)
Wear Sunscreen.
Re: (Score:3, Informative)
For those a little too young to get that, here's the original [chicagotribune.com]. And yes, it's definitely worth reading. :-)
Excellent Advice (Score:4, Insightful)
Re: (Score:3, Insightful)
Don't tell me that POSIX is a more valuable (speaking in terms of money) thing for a programmer to know than the latest thing out of Microsoft. If you call things that change a "trap" then POSIX is one of the very few things which hasn't been a trap (including Java, which Allison praises).
He talks about machine code still being very relevant, and that you can't write code for thousands of machines working i
Re:Excellent Advice (Score:5, Interesting)
In more than 16 years of doing MS programming and chasing the latest thing to keep ahead, I look back and wonder how many projects might still be in use if they were in Linux/Unix. Instead, the products died with their native OS. Further, once on the MS money train, the only alternative is to chase the newest thing to keep in place or move slightly ahead. In addition, I have seen many other proprietary toolsets come and go. In fact, some of the toolsets were simply created, it would seem, to capture customers who would need programmers for those toolsets in order to maintain the code. Then, finally, when the product is stable, it is time to migrate it to the new version at even greater cost. Lock-in is great, and only now do businesses recognize the risks it brings.
As for machine code, I agree that not too many need to master it. I have done my share of assembler in lots of environments and believe strongly in the importance of wrapping one's head around what is really happening. If you notice, buffer overflows are the most exploited weakness of modern applications. Once you debug a buffer overflow in assembler code, you remember full well how important it is to avoid them. On the other hand, if somebody really understands what is happening in the machine and OS then C and C++ are very efficient ways to program. And, Java, which keeps the executing machine relatively constant, is maybe the grail of programming. Even then, understanding what the virtual machine is doing with that Java statement is important in making efficient code.
I also agree he is somewhat removed from the majority of developers. But, the majority of developers are probably focused on the other aspects of development. That topic is best handled by this excerpt from "The Zen of Programming"
-----
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief.
"Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer. "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to tax laws. By contrast, an operating system is not limited by outward appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. That is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well," he said, "but which is easier to debug?"
The programmer made no reply.
-----
So, there you have it. The majority of developers create applications that require focus on the externals and present their own difficulties and challenges. Those challenges are not so much technical as people and business. The two challenges meet, though when the accounting package is killed by a proprietary product migration, and has to be redone (if there is money to redo it).
In truth, I find it hard to counsel new programmers because the world is changing so quickly. Having been burned repeatedly with proprietary lock-in and migrations, businesses now buy their applications from major vendors and change their processes and practicies to comply with the constraints of the software. I personally think that the resulting uniformity in methods will eventually stagnate the companies who do this. But, when you consider that corporations can only see a quarterly horizon, maybe that is the best that can be expected.
Parent
Re:Excellent Advice (Score:5, Interesting)
The Unix standards are just better than many others. They are simpler and more elegant, and they last a long time. On a cross-platform project I was working on recently some windows developer changed "uint32_t" to a "typedef DWORD UINT32_T" and "typedef uint32_t UINT32_T". Wtf is a DWORD and why not typedef it to uint32_t. I believe doing too much Windows programming warps even the best programmers; you either move on to something else or you lose the ability to write good code.
Parent
Here's the best piece of advice I could give (Score:5, Insightful)
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.
"Do what you love" is overrated (Score:4, Insightful)
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.
Re:"Do what you love" is overrated (Score:4, Insightful)
Chances are one day you're going look over at your wife and realize she's old, fat and crabby. Maybe if you're rich you'll buy yourself a new, young, pretty wife who is docile as a lamb. But in the end you still won't be happy. And the people around you will justly despise you and your new wife. If you look in the mirror you'll see you're no prize yourself.
The state of being in love, either with your spouse or with your job, is necessary to the continuance of civilization, but it is not sustainable.
It would be better to say this: "love what you do." This better captures the effort and imagination needed to live a life of what the Greek philosophers called "Eudaimonia": a kind of sustainable well-being.
Then in choosing a job, you should not choose that which you simply have a passive attraction to. You should choose something believe you have the capacity to generate new love for that will carry you through the hard times.
Parent
Comments from an old programmer (Score:5, Insightful)
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.
Re:A hard reality... (Score:5, Informative)
I agree completely since it is a fact that has been established over the years, [...]
I have to argue there are still a lot of computing applications where the network is of only tangential interest. Word processing, desktop publishing, video editing, [single player] games, etc. There's no shortage of work where the network is really just a a process for getting an initial set of data onto the machine to be manipulated (if it even does that - eg: photo editing with photos coming straight off the camera).
Mr Allison's advice (and commentary) seems to be very much centred around writing high-performance server applications. Which is hardly surprising, given his background, but may not be equally applicable to all forms of coding (eg: writing GUI apps for GNOME or KDE today is probably quite different to writing X apps twenty+ years ago, and an intimate knowledge of the underlying hardware/OS is only really necessary if your code is performance-sensitive).
[...] i still wonder if iTunes(one of the best examples i could remember) would have been so widely used today if not for the music sharing feature!
Of course it would. The iPod is the main reason iTunes is popular (( don't think I've _ever_ used iTunes music sharing features - or the iTunes Store, for that matter).
Parent
Re: (Score:3, Informative)
Re:Bullshit (Score:4, Insightful)
You just listed a bunch of applications that are very CPU-intensive and "extremely parallelizeable". That is, every single one of those applications would be great to distribute. All modern production-level renderers operate on clusters (renderfarms). Apple's Logic software (similar to Pro Tools) supports distributed processing.
Any digital artist would *love* to have even a small cluster available to do previews... while Maya et al have very good OpenGL previews, there's never enough CPU power for computer graphics (and I believe there never will be).
You don't see any benefit of networking these applications? Maybe for a person's own finance management software a network would be overkill, but any company with more than 1 person handling finance management benefits from a remote data store and thick clients. Maybe you always play single player games, but I occasionally play StarCraft with a friend. Across a network.
Network != World Wide Web
Parent