in reply to The path to mastery
Instead strive to understand fully and completely the tool at hand. Explore exactly how it works and what it can do. In addition constantly learn how to build on what you and others have done before. Aim for clarity and comprehension, and mastery shall surely follow.
First, let me say that exploring a langauage and it's capabilities is a Good Thing. Make no mistake about that. Any correct (i.e. non-Cargo Cult) knowledge is good knowledge. But knowledge is also knowing how, when, and where to apply it...
So, while these are noble goals, I don't place a lot of faith in them being attainable in the real world. Using the minimum code to accomplish a task is of no value if the next person to come behind you can't maintain it. When I leave my job, I don't expect the company to be able to hire a Larry Wall, a btrott, or a merlyn. Instead, I hope to have written my code where an *average* programmer can maintain it. Because companies can't afford industry stars to support upgrades, changes, and fix (Dog forbid) bugs.
I believe the code should be well structured, well documented, and well designed. But not so tight that if I need to insert a debugging line, that I have to unroll 8 loops, 2 map statements, and a sort, just to print some keys to verify data.
What are my qualifactions? I've been writing code for 20+ years. I started in BASIC, learned APL, Fortran, COBOL, Forth, 'C', C++, Pascal, Logo, Perl, 14 different assembly langauges, and Dog knows what else. I'm not saying this to brag. I've had to solve problems in all these langauges, at one time or another. I do embedded systems, Windows apps, device drivers, and web-based applications. I don't want to learn a language *so* well, that it's to the exclusion of others. I have too many environments to work in. I'll probably never write Perl as tight as a lot of the people here. I'll probably never get as good at regexps as Ovid has. I'm a generalist.
To me, good code is not code that exploits obscurities of a language, or uses methodologies so unusual, you're not even sure the language supports it. No, good code is code that uses mainstream idioms whereever possible, algorithms that are well documented, and the source can be modified without fear of breaking everything else it depends on. A good book towards this subject is The Pragmatic Programmer by Hunt and Thomas. Another is The Practice Of Programming by Kernigan and Pike.
I do believe that in an ideal world what you say is true. But the reality of marketplaces, workforces, and our generally lousy education system really don't make such an implementation practical.
As an aside, if anyone I hire writes code that only they can maintain, because it's either so good, or so bad, they're out of there. I don't have time for prima donnas, nor incompentents. I want good people, that are flexible, adaptable, and not super-stars. Because someone *else*, sooner or later, is going to be working on that code. As further proof of this theory, take a look on SlashDot, referrencing the people that write and maintain the 400,000+ lines of code for the Space Shuttle. They're 9-to-5, average, disciplined people. Not stars.
--Chris
e-mail jcwren
First, let me say that exploring a langauage and it's capabilities is a Good Thing. Make no mistake about that. Any correct (i.e. non-Cargo Cult) knowledge is good knowledge. But knowledge is also knowing how, when, and where to apply it...
So, while these are noble goals, I don't place a lot of faith in them being attainable in the real world. Using the minimum code to accomplish a task is of no value if the next person to come behind you can't maintain it. When I leave my job, I don't expect the company to be able to hire a Larry Wall, a btrott, or a merlyn. Instead, I hope to have written my code where an *average* programmer can maintain it. Because companies can't afford industry stars to support upgrades, changes, and fix (Dog forbid) bugs.
I believe the code should be well structured, well documented, and well designed. But not so tight that if I need to insert a debugging line, that I have to unroll 8 loops, 2 map statements, and a sort, just to print some keys to verify data.
What are my qualifactions? I've been writing code for 20+ years. I started in BASIC, learned APL, Fortran, COBOL, Forth, 'C', C++, Pascal, Logo, Perl, 14 different assembly langauges, and Dog knows what else. I'm not saying this to brag. I've had to solve problems in all these langauges, at one time or another. I do embedded systems, Windows apps, device drivers, and web-based applications. I don't want to learn a language *so* well, that it's to the exclusion of others. I have too many environments to work in. I'll probably never write Perl as tight as a lot of the people here. I'll probably never get as good at regexps as Ovid has. I'm a generalist.
To me, good code is not code that exploits obscurities of a language, or uses methodologies so unusual, you're not even sure the language supports it. No, good code is code that uses mainstream idioms whereever possible, algorithms that are well documented, and the source can be modified without fear of breaking everything else it depends on. A good book towards this subject is The Pragmatic Programmer by Hunt and Thomas. Another is The Practice Of Programming by Kernigan and Pike.
I do believe that in an ideal world what you say is true. But the reality of marketplaces, workforces, and our generally lousy education system really don't make such an implementation practical.
As an aside, if anyone I hire writes code that only they can maintain, because it's either so good, or so bad, they're out of there. I don't have time for prima donnas, nor incompentents. I want good people, that are flexible, adaptable, and not super-stars. Because someone *else*, sooner or later, is going to be working on that code. As further proof of this theory, take a look on SlashDot, referrencing the people that write and maintain the 400,000+ lines of code for the Space Shuttle. They're 9-to-5, average, disciplined people. Not stars.
--Chris
In Section
Meditations