Slashdot Mirror
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!"
In strict fairness I have to agree with your Microsoft comment; however, I come down on the side of not chasing the money but chasing, instead, the love of programming and the heady pleasure of making something really complex and significant work.
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.
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.