I like the self-linking too. Since I haven’t read all your old posts, it gives me some more interesting reading without having to dig through the archives myself.
If peeple write code as well as they write blog posts then indeed outsourcing is around for a long time.
I’ve been accused of gratuitous self-linking in the past
And I nearly posted a comment asking you to link to your earlier posts.
Spoon-feeding, anyone?
And you said you wouldn’t become a full-time blogger.
Oh My, How do you people ever get anything done!
Hey Judy, that’s what I’m asking myself every time I scroll through this blog. Yes I know, why then read the blog I can hear them ask? Well once in a while there is an interesting link to another site. That’s it all worth.
Great post !!!
On reuse, I would add:
“re-use is just a nice side-effect”
Thanks for the recommendation. Another good book to improve my witchcraft… er, I mean software craftmanship (my background is mechanical engineering).
BTW, what’s wrong with self-link? I like links! As long as it’s useful, why not? It’s not like there’s an obligation to click or anything. Keep it coming Jeff.
I second (third?) the self-linking. The comment before about reading other relevant content is absolutely precise. I think the “gratuitous self-linking” comment came from the post on Paul Graham which invoked a little anger in a few people. But really, what is the point in writing a blog if you don’t promote your own writing?
As for the discipline of Software Engineering - I think it’s something which will need to grow a great deal in the coming years, and education of it for students as an extension of that. The entire content of my single “Software Engineering” module during university (3 yrs ago) was the Rational Unified Process - we spent so long drawing use-cases and sequence diagrams, I don’t think anybody understood what Software Engineering was actually supposed to be.
Wow, it was weird seeing a picture on here of the one computer science book I felt was good enough to keep around after college. The only things I can really criticize are minor. Here’s one thing to nitpick:
Placing a number like “28 times better” on programming skills assumes that everyone is capable of coding anything given to them and that the best programmers are simply much faster at doing so. However, I think we can all agree that the ability to figure out how to design something in the first place is a gift in and of itself, and it shouldn’t be taken for granted. Some people are simply much, much better problem solvers than others.
I think I’ll grow a beard.
Some additional thoughts I had based on my experience in certain segments of the industry:
-
Smaller teams are more productive teams. Larger teams result in layers of virtual paper pushers and “managers” who generally get in the way and waste resources (time, office space, computer pool dollars).
-
Meetings are seldom as useful as people think they’ll be. Most communication can be done more effectively in an asynchronous fashion using e-mail, wikis and issue trackers.
-
Teams that don’t insist that they have final decision on additions to the development team are asking to be stuck with someone who is underskilled or able to snowball the interviewer/manager. Senior developers ought to be very interested in the hiring process because they’re likely to be the ones who have to deal with the boat anchors they’ll get otherwise.
-
Communication is a key ingredient in software development. Teams need easy, quick ways to communicate that don’t become a distraction to progress. Good communications between the end-users, the testers, the developers and all other stake holders helps to minimize misunderstandings. This is one area where smaller teams can excel, specifically because there are less folks to keep in the loop.
Just one Smurf’s opinion.
Q. How many Open Source developers does it take to screw in a lightbulb?
A. One to screw it in. One to write the FAQ. Ten to test it. One to respond to forum posts about how to screw in a lightbulb. Two to decide they would do it differently, so leave to create a fork. A thousand to debate whether anyone should be using a proprietary light bulb. Four to develop a free lighbulb. Ten to test it. One to write the FAQ.
I also like the self linking, mainly because I’ve only been reading your blog for 6 months.
Also, do please write a revises must-read list, and don’t be afraid to make it too long.
Excellent post again.
I also recommend Robert’s latest book: Software Creativity 2.0.
It is really a good book that makes you think about the nature of software engineering based on past studies and historical data from real-life example. In his book, Robert always presents pros and cons for every topic he talks about: for instance theory vs practice, or discipline vs flexibility or process vs product. This allows us to create our own judgment and vision of why creativity is required in the software engineering field.
I also agree with a lot of readers: Jeff, updating your must-read/all-time-favorite book list would be great ! 
Thanks !
#30. COBOL is a very bad language, but all the others are so much worse.
Practical Programmer
Robert L. Glass
Cobol—A Contradiction and an Enigma
So it’s not just McConnell who is picking up on these mistakes. Heh…now we just need to actually get people to heed these problems and actively DO something about them.
As a side-note, does your host have a tagging feature? It seems easier to just tag posts and have a related posts panel on the side/at the bottom. I don’t mind self-linking at all, but why put all the effort into it when you can have the work done for you? After all, that’s what computers are for, no?
In Soviet Russia, software engineers you!
What a superb list. It really does explain everything that’s wrong with the management of this industry. Too bad it doesn’t bring solutions. It can’t bring solutions because the only people who will read it are the people who don’t need it.
Well, that’s where I come in. Software engineering manager extraordinaire. If your company displays all the problems cited in that list, just contract me for one day. My crack team of professionals will take care of any overly competent informed expert engineer who revealed those problems in your organization. Yes that’s right, there’s no silver bullet, we use:
It’s frustrating to see all of us bitching about the same things we were bitching about 25 years ago. If we were so smart we might have gotten a lot of this figured out by now. My observation: there are no “stupid” people or “idiots” in this industry. There are, however, egos, egos and more egos. But don’t ask the one developer who is “28 times better” than another developer.