The general gist is that programming, as a respected engineering discipline, is in jeopardy today due to the attitude claiming good programmers eschew rigorous planning and development.
In his opinion, the open source movement has further improvished the engineering aspect of programming with its "release early, release often" motto, as too the ad hoc nature of extreme programming. Additionally, the lack of process in programming also means there is a lack of apprenticeship, which is integral to the other areas of engineering.
Finally, he pulls out the standard complaint that the newer programming language abstract away alot of important detail, and programmers are now less effective due to their ignorance.
In turn, the author recommends a set of standard practices he feels will improve the lazy programmer, of which I've listed the items that seem to summarize the others:
1. Know what you are doing all the time
This consists of keeping track of goals and milestones and intentionally working towards them at all times
2. Write an example and design the whole solution upfront
This helps clarify the final goal in the programmers mind.
3. Test your own code, and test what you already know works
This ensures the programmer has a solid understanding of their work, and that they have a baseline to test against.
4. Be methodical
Keep notes, and use the scientific method to make predictions about program behavior that is not understood.
The author seems to be arguing that programming 1. is boring and 2. should be made even more so. I couldn't get past page 3, and my attention span is much longer than this for worthwhile papers.
I hope no one gave him this cliche as literal advice as he mentions in the first section. The first time I heard this cliche the first thought that popped into my head was, "That's a fun way to describe why programmers are always 'thinking out' ways to make tasks more 'efficient and maintainable.'"
I'm curious to know how other people understood this cliche when they first heard it.
I my self can be exceptionally lazy when I'm not doing something that involves creative thinking.
I tell you though, lately iv'e been feeling a little down due to pressure at work and iv'e just read pg's new essay and this one. Just reading the first words of pg's essay cheered me up. when pg talks about programmers, there's no worldly spirit in what he writes. You don't see words like professional, certification etc. He writes like a kid writing about his favorite hobby. This article actually saddened me. Like its been pointed out, you really feel the author squeezing the fun out of programming. It reminded be of the stories in the Bible with the Pharasees and Scribes. They put on the outer mask of religion but rejected it's inner power: The Holy Spirit. Similarly, there has to be that inner love for programming to make good stuff.
I'm not trying to say I think the guys wrong or a "Scribe". I just think that its sad that he talks about it in such procedural way. I would hate programming if I thought like that!
they are lazy, and that is why they work hard to engineer the best solution so that in the future they won't have to do so much maintenance to the system and scope changes and future additions will be easier.
might give one a better idea of where he is coming from.
I have a hard time believing that Mr. Dougan has ever written any end-user business software. He also shows his ignorance when he claims that certifications such as the MCSE are "good beginnings". These certifications often prove little beyond one's test-taking ability.
I do not dismiss his views in whole. There is certainly a lot of incompetence in the industry. Many CS programs have been dumbed down to increase admissions. These topics deserve consideration and discussion.
He does appear to completely lose the plot in several instances, eg. Extreme Programming is all about drinking Jolt, snowboarding and all night hacking sessions, now can we all get on with some more testing please.
It would also be easier to take him seriously if his paper wasn't riddled with grammatical errors. Holding up programmers as lazy when you haven't proof read your publication properly does seem a little odd. (I notice that it's marked as an "unpublished draft" on his site, but if you're going to put it up on the web I figure it's fair game).
I also particularly like the way that he advocates planning in advance, doing things right, etc. but then can't get the budget for a decent test environment (for their real time OS no less) in http://www2.fsmlabs.com/~cort/publications/sparky/sparky.pdf and has to cobble together a PC from spare parts.
Considering that the paper is posted as an unpublished draft on his documents listing, isn't it a bit silly to criticize this paper because it has typos and spelling errors?
hehe, certifications thingie and bs about firing QA folks freaked me out. Also the statement that OS lacks innovation - yeah, right. Its just so ignorant...
13 comments
[ 3.2 ms ] story [ 42.9 ms ] threadhttp://news.ycombinator.com/item?id=380333
I'll provide a little commentary:
The general gist is that programming, as a respected engineering discipline, is in jeopardy today due to the attitude claiming good programmers eschew rigorous planning and development.
In his opinion, the open source movement has further improvished the engineering aspect of programming with its "release early, release often" motto, as too the ad hoc nature of extreme programming. Additionally, the lack of process in programming also means there is a lack of apprenticeship, which is integral to the other areas of engineering.
Finally, he pulls out the standard complaint that the newer programming language abstract away alot of important detail, and programmers are now less effective due to their ignorance.
In turn, the author recommends a set of standard practices he feels will improve the lazy programmer, of which I've listed the items that seem to summarize the others:
1. Know what you are doing all the time
This consists of keeping track of goals and milestones and intentionally working towards them at all times
2. Write an example and design the whole solution upfront
This helps clarify the final goal in the programmers mind.
3. Test your own code, and test what you already know works
This ensures the programmer has a solid understanding of their work, and that they have a baseline to test against.
4. Be methodical
Keep notes, and use the scientific method to make predictions about program behavior that is not understood.
I'm curious to know how other people understood this cliche when they first heard it.
I tell you though, lately iv'e been feeling a little down due to pressure at work and iv'e just read pg's new essay and this one. Just reading the first words of pg's essay cheered me up. when pg talks about programmers, there's no worldly spirit in what he writes. You don't see words like professional, certification etc. He writes like a kid writing about his favorite hobby. This article actually saddened me. Like its been pointed out, you really feel the author squeezing the fun out of programming. It reminded be of the stories in the Bible with the Pharasees and Scribes. They put on the outer mask of religion but rejected it's inner power: The Holy Spirit. Similarly, there has to be that inner love for programming to make good stuff.
I'm not trying to say I think the guys wrong or a "Scribe". I just think that its sad that he talks about it in such procedural way. I would hate programming if I thought like that!
But a Great Hacker is a really really creative lazy creature
http://www.fsmlabs.com/
and his publications and talks:
http://www2.fsmlabs.com/~cort/publications/
might give one a better idea of where he is coming from.
I have a hard time believing that Mr. Dougan has ever written any end-user business software. He also shows his ignorance when he claims that certifications such as the MCSE are "good beginnings". These certifications often prove little beyond one's test-taking ability.
I do not dismiss his views in whole. There is certainly a lot of incompetence in the industry. Many CS programs have been dumbed down to increase admissions. These topics deserve consideration and discussion.
It would also be easier to take him seriously if his paper wasn't riddled with grammatical errors. Holding up programmers as lazy when you haven't proof read your publication properly does seem a little odd. (I notice that it's marked as an "unpublished draft" on his site, but if you're going to put it up on the web I figure it's fair game).
I also particularly like the way that he advocates planning in advance, doing things right, etc. but then can't get the budget for a decent test environment (for their real time OS no less) in http://www2.fsmlabs.com/~cort/publications/sparky/sparky.pdf and has to cobble together a PC from spare parts.