In 1978 I had a liberal arts degree and no job. I borrowed $2000 and went to a trade school to learn computer programming. That $2000 has paid off big time of the last 26 years and continues to do so. The course started with a simulated, 1000-memory-cell decimal "computer"; we programmed it in assembler. We then went to IBM 360-style assembler (all this was on punched cards), followed by Fortran, RPG, and COBOL.
I got a job right away for a company that made data comm hardware and, naturally, used assembler. I didn't touch a high-level language till 1984 (and that was C).
As the years have gone by, the trade (NOT profession!) has become more and more the domain of the "computer scientist". These are the guys who learned how to write compilers in school. Often, they're disappointed when the job involves something more mundane. These are also the guys who have trouble with pointers and other basic concepts because they don't really know what's going on on the machines they program.
German machinists used to spend a year doing nothing but filing as part of their training. Nothing but filing. These were people who honored their craft. Assembler is the computer equivalent. Without it, you might be a "scientist", but you'll be a lousy craftsman.
I once worked for a guy who learned programming in the Air Force in the 60's. His motto: "It's all just loads and stores and branches."
My employer has a product that includes an embedded Linux system. Some of the product code runs in user space, some is implemented as loadable modules. I can find no clear guideline anywhere that tells me whether the product can remain proprietary (i.e., closed source).
First problem: Nobody's *opinion* (not even Linux or Stallman) counts - only a legal interpretation of the GPL has any weight in the real world (i.e, with my employer). Such a legal opinion does not yet exist (though it probably will post-SCO).
Second problem: Does the fact that some code is a module mean it has to be GPL'd? (These aren't device drivers, BTW).
Third problem: How much does the use of header files "infect" the code with GPLness?
As much as I love Linux, using it in a litigation-shy big company is more complicated that most people realize.
I did about 6 months of XP (all day team programming included). Some comments:
"Test First" helps more than you can imagine without trying it. Our rule was "no code is written unless it's a fix for a broken test". This saves all kinds of time wasted on grand schemes, frameworks, APIs, etc. - you're forced to write what you need, *just* what you need.
By the time you've written the tests, you understand the problem a lot better than you did when you started.
Having the tests gives you the connfidence to refactor. When you can test *all* your code by running the hundreds of tests you've built up over the course of the project, you'll never again hear (or say!), "I'd like to imprive module X, but I'm afraid I might break the system."
I'd encourage anybody to give "test first" a try, even if you don't combine it with other XP practices.
Slashdot Mirror
Great plan if you can "find a secure profession". Do you have a crystal ball?
In 1978 I had a liberal arts degree and no job. I borrowed $2000 and went to a trade school to learn computer programming. That $2000 has paid off big time of the last 26 years and continues to do so. The course started with a simulated, 1000-memory-cell decimal "computer"; we programmed it in assembler. We then went to IBM 360-style assembler (all this was on punched cards), followed by Fortran, RPG, and COBOL.
I got a job right away for a company that made data comm hardware and, naturally, used assembler. I didn't touch a high-level language till 1984 (and that was C).
As the years have gone by, the trade (NOT profession!) has become more and more the domain of the "computer scientist". These are the guys who learned how to write compilers in school. Often, they're disappointed when the job involves something more mundane. These are also the guys who have trouble with pointers and other basic concepts because they don't really know what's going on on the machines they program.
German machinists used to spend a year doing nothing but filing as part of their training. Nothing but filing. These were people who honored their craft. Assembler is the computer equivalent. Without it, you might be a "scientist", but you'll be a lousy craftsman.
I once worked for a guy who learned programming in the Air Force in the 60's. His motto: "It's all just loads and stores and branches."
My employer has a product that includes an embedded Linux system. Some of the product code runs in user space, some is implemented as loadable modules. I can find no clear guideline anywhere that tells me whether the product can remain proprietary (i.e., closed source).
First problem: Nobody's *opinion* (not even Linux or Stallman) counts - only a legal interpretation of the GPL has any weight in the real world (i.e, with my employer). Such a legal opinion does not yet exist (though it probably will post-SCO).
Second problem: Does the fact that some code is a module mean it has to be GPL'd? (These aren't device drivers, BTW).
Third problem: How much does the use of header files "infect" the code with GPLness?
As much as I love Linux, using it in a litigation-shy big company is more complicated that most people realize.
I did about 6 months of XP (all day team programming included). Some comments:
"Test First" helps more than you can imagine without trying it. Our rule was "no code is written unless it's a fix for a broken test". This saves all kinds of time wasted on grand schemes, frameworks, APIs, etc. - you're forced to write what you need, *just* what you need.
By the time you've written the tests, you understand the problem a lot better than you did when you started.
Having the tests gives you the connfidence to refactor. When you can test *all* your code by running the hundreds of tests you've built up over the course of the project, you'll never again hear (or say!), "I'd like to imprive module X, but I'm afraid I might break the system."
I'd encourage anybody to give "test first" a try, even if you don't combine it with other XP practices.