Slashdot Mirror

Someone posted on the accu-general@accu.org list a few weeks ago (the Association of C and C++ Users) that he'd been studying the demand for various job skills at employment websites in the U.K.

Suprisingly he found that the demand for C++ programmers was dramatically higher than that for Java programmers, and further that the pay scales offerred for Java programmers were very low.

This is in sharp contrast to the situation at the height of Tulipomania. Sometime in 2000 someone lamented on a post to a C++ newsgroup or list or something that it appeared that the hourly rates available to Java consultants was twice as much as those available to C++ consultants - as much as $250/hour. This despite the fact that C++ is a much more difficult language to master.

I think one thing this indicates is that the market for web server programming has fallen off the edge of the earth. But I'm not sure what all those C++ programmers are being hired for.

News of this study came as a relief to me because I've been doing mostly C++ the last few years, and although I know Java I haven't really put much effort into it. At some points I wondered if I had made a big mistake. But I've gotten very good at programming in C++, and enjoy it a great deal now, and in fact I'm finding demand for my consulting work is starting to pick up noticably.

I don't know how the U.K. results could apply to other countries, but you could check it for the U.S. by searching for various job skills at DICE and counting the number of hits you get for each.

You could do this more systematically by having a robot browse each of the job descriptions on DICE and scraping keywords and payrates out of each of them.

I can't post a link to the ACCU archive because the archives are only available to ACCU members and I'm afraid I let my membership lapse. :-/

You might try the Association of C and C++ Users web site.

My second largest worry is that the attourneys general of the states will not be able to find the right people to give the code a good going over. HHopefully, someone on the caliber of Andrew Schulman who gave Microsoft an incredible amount of grief with Undocumented Windows 95 will agree to help out.

Ya see, thats funny, if ya woulda read the parent you would have seen what I was trying to prove.

I appreciate what you were trying to prove, I just disagree with it. It's possible to write bad, buggy and/or dangerous code in pretty much any language. But using a language reasonably well often avoids the pitfalls. In this example, C++ doesn't leave you open to buffer overruns if you choose to use the tools it provides appropriately.

Just out of curiosity, why use "string" over char*?

You might like to read this article on why container classes are usually a better choice than arrays in C++, and the most likely times you'd still want to use a raw array. Much the same arguments could be made for using raw pointers (usually bad) vs. using smart pointers, references or some other mechanism altogether (usually resulting in safer and cleaner code).

BTW, friendly tip: just because a college course tells you something is C++, don't believe it on pure faith. Many college instructors and many books on C++ are very bad and really don't know their subject. Somehow, people wouldn't accept a physics teacher who didn't know about F=ma, but they do accept a C++ teacher who doesn't know that main always returns an int. <sigh> If you want to find genuinely good books on C++ (or C, Java, and various related topics), you might try visiting the Association of C and C++ Users' web site, and looking through their book reviews.

"There can't be a better place on the Web to have this conversation than here."

For those of us who were using computers before there were PC's, much less an Internet, the irony in this statement is just too rich to pass up...

And yet, that one line captures so much of the point it's incredible.

Sure, you could get in touch with people on the old bulletin boards, but the average Joe, and certainly the average kid, didn't have the means or the knowledge to do it. The internet, and in particular the WWW, is the first time that anyone could say anything to a wide audience (more-or-less). Just look at the amount of information on /. -- you count the numbers of posts on a single thread in the 100s. Never before the 'net had things been done on this scale, either in terms of contributors or in terms of audience, and that's the key difference.

An inevitable result of that, combined with the anonymity the 'net currently provides, is shattered illusions. Those who have charged big amounts of money for services with little real value are in for a rude awakening. Perhaps just as importantly, kids who have genuine talent can get on the ladder based on merit, and not some title and suit. I am rather older than teens these days, but still young enough to feel undervalued. Modesty aside, I know, and management at the office privately acknowledge, that I can do as much as many of the more senior guys. I'm sure many here can empathise with that claim.

However, the other natural effect of this proliferation of "average" work is that truly good work now stands out. While I'm all for kids knowing their stuff, and getting credit for it, let's not pretend that a 15 year old with a couple of years playing with coding can do the same as a good 25 year old with an extra ten years. I'm not going to catch the good senior guys at the office for a while yet. (That's "good" as in, "that same enthusiastic and talented person, but ten years later".)

And this is the key point that's being missed by many replies here on this thread. Take some of the common examples. Amazon book reviews were mentioned. Let's see, suppose I want to buy a book on C++. Shall I go visit the ACCU, where they have a comprehensive range of reviews written by experienced pros? Or shall I visit Amazon, and read reviews of beginners books by beginners who, by definition, aren't qualified to review them on technical merits?

There are numerous other examples. Look at programming. Many people here write the most amazing advocacies of new buzzwordisms in the programming threads. And yet, it's clear to the pro's that most of them have never programmed a serious, large scale, professional system in their lives, because they overlook the basic (to a pro) issues that they've never encountered.

Look at web pages for another example that's close to home. The ease with which a keen 15 year old can produce a decent homepage really shows up the con artists. However, no 15 year old has the knowledge of all the deeper issues, from graphic design through usability to effectively managing a site with literally 100,000s of pages on it. These things are the difference between a page good enough for a keen amateur (created by the 15 year old) and a page good enough for a business to bet its existence on (created by the experienced professional web design outfit).

And that, really, is the crux of it. In any activity, keen amateurs can get pretty good if they put enough into it. Those amateurs can be 15 or 50, and often, it doesn't much matter. Eitehr way, it's right and proper to give credit where it's due. But they'll never catch the pros, and no 15 year old has all of the knowledge, experience, maturity and ability to do a job in the same league. If you don't believe me, take a look at how many dot-bomb stories we've seen lately, and then count how many of the failures were wholly run by inexperienced management who assumed they could do it, and learned the hard way that they were wrong.

Don't touch Schildt if you want to learn decent C++. His books have many well-known problems. A couple of the earlier C ones were so bad that people wrote lengthy pages about them to make the point. There was a running joke that his The Annotated ANSI C Standard contained the complete text from the C standard, but was published at a fraction of the cost. This was said to represent the value added by his comments.

If you really want to know what his books are like, you could visit Amazon and read their reviews, which are written by people who purchased the beginners' books, and are therefore by definition not qualified to review them for technical merit. Or, you could do the smart thing and visit the Association of C and C++ Users web site, and check out their book reviews. These are generally regarded as being fair and accurate, and there are an awful lot of bad reviews of an awful lot of Schildt books.

</rant>

try this book :
The Microsoft File by Wendy Goldman Rohm
or this one
Undocumented Windows by A Schulman
or this one
Unauthorized Windows 95 by Andrew Schulman

or this one :

Undocumented Windows NT, by Prasad Dabak, Sandeep Phadke, and Milind Borate
example chapter

Here's a whole bookstore making money from undocumented Windows API calls :
http://www.sonic.net/~undoc/bookstore.html

what something online?

try here http://www.vbworld.com/api/shelldoc/

a password cracking utility that uses Win32 undocumented api calls to display the currently logged user's password

API: Access/Office and AddressOf Operator

some more software

is that enough yet ?


.oO0Oo.

try this book :
The Microsoft File by Wendy Goldman Rohm
or this one
Undocumented Windows by A Schulman
or this one
Unauthorized Windows 95 by Andrew Schulman

or this one :

Undocumented Windows NT, by Prasad Dabak, Sandeep Phadke, and Milind Borate
example chapter

Here's a whole bookstore making money from undocumented Windows API calls :
http://www.sonic.net/~undoc/bookstore.html

what something online?

try here http://www.vbworld.com/api/shelldoc/

a password cracking utility that uses Win32 undocumented api calls to display the currently logged user's password

API: Access/Office and AddressOf Operator

some more software

is that enough yet ?


.oO0Oo.

You Said:
Like it or not, Mickeysoft has some good programmers. I don't like Microsoft, but even I can admit the programmers there are pretty damn smart. Ever read any of their books? Writing Solid Code has many good ideas on writing bug free and easily debugged code.

Reply:
And at least as may horrible ones. As a fellow developer, I beg of you to be very careful of adopting the views of that book. A detailed review of why it can be harmful is available at accu. Code Complete, on the other hand, is a very good book. Not really by a microsoft guy, but the author spent alot of time there as a consultant. Plus he draws all of his advice from case studies, so there is research to back up what he says.

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

I have a question:

Watt Humphrey of Carnegie Mellon's Software Engineering Institute pushes the Capability Maturity Model, which he claims marries Total Quality Management (made famous by the Japanese) with software engineering. It's sounds a bit like Scientology to me, with PSP/TSP, reviews, and lot of acronyms, but I have seen rave reviews around the web.

Could some please let me know if the CMM and the "Best Practices" being discussed have anything to do with each other?

Thanks.

Moderators: this isn't intended to be offtopic - I am trying to get at what "best practices" are driving the discussion

I don't think she would have understood if I told her I'd been featured on Slashdot and had to take breaks from her to go post...

I did read through some of the comments here earlier this evening and I must say that this has been an excellent discussion. The sheer number of comments posted shows I must have struck a chord with the community - and my experience with other programmers shows that this is a common problem with others.

I'll post tomorrow what the folks on comp.lang.c++ and comp.sys.mac.programmer.misc had to say but they were in general along the same lines as what was posted here:

• Take a break
• Get a life
• Do something fun that doesn't involve computers
• Engage in vigorous physical exercise
• associate with the attractive sex
• Step back from low-level coding and do other software-oriented things like design, discussions with a coworker or documentation

I did in particular step back to think about software from a different level than coding, but I didn't actually do design work. Instead, I just cracked open some good programming texts. If you haven't read much lately there's probably a lot of good stuff that will stimulate you and improve the effectiveness of your work - check the book reviews online at The Association of C and C++ Users (and consider joining it - I did, a couple months ago).

One thing I consider important in the reading I did was that I wasn't looking for solutions to the problem at hand. Rather, I was trying to get back to something I'd been missing for a long time and wanted to indulge in - the sheer joy of learning for its own sake.

It was the case that the books I was reading were pertinent to my work but I wasn't searching them for solutions. I was just reading and flipping through them as my curiousity led me. And when solutions to my problem would occur to me, I'd put them out of my mind until the time I'd decided ahead of time would be my time to resume work.

What actually got me going again was that I had such a flood of ideas and they had crystallized so clearly I was able to sit down and implement my solution in a day and it worked just fine - still does.

Something else that helped stimulate me was the website on Extreme Programming.

A lot of the approaches there really appeal to me. Particularly I like the ideas they have that could be generally expressed as "design by coding" and are mentioned I think by Stroustrup in the intro to More C++ Gems as "expressing designs in the code".

That is, rather than doing a bunch of up-front modeling using diagrams like OMT or UML or what have you, you just write code - but you are designing in the code, so they emphasize in extreme programming that you constantly rewrite the code as designs gel.

One thing that saddnes me though is that Extreme Programming also suggests programming in pairs. This is something I used to do with Dave Johnson when we were at Working Software together. We'd help each other through hard spots and just rap about politics and stuff and go have coffee or a beer and get a lot of work done.

Now I live at the End of the Internet and I'm working for myself as a one-man consultant shop. It has its advantages (I can work at home and set my own hours) but one big disadvantage is that I work very much alone and there's no one around to bounce ideas off of.

I have other programmer friends and I do call them up but they all have their own gigs - it's not the same.

On another important note, several people both here, privately via email and in the newsgroups raised the possibility of this being clinical depression.

Well that is something I was well aware of and had been considering. Depression is something I have been dealing with all my life, as you will see in another slashdot article I posted:

Manic Depressive Geeks

I didn't used to be (woefully so) but now I'm very introspective about my mental and emotional state. I have to be. I didn't used to be but now I just won't tolerate the depths of misery that I just thought were part of the normal human condition.

But I don't think that what was happening to me was the sort of depression that I usually consider. There are "endogenous" and "reactive" depressions. Endogenous depression just happens to you and is usually caused by chemical imbalances in the brain (shortages of serotonin or norepinephrine) and is what's usually experienced with Manic Depression, while reactive depression is (naturally) a reaction to external events, like a personal tragedy.

Life has been really hectic for me for a long time, with the turbulence of my consulting business, falling in love with a woman from another country, planning a wedding, moving to Canada, and just trying to keep it all together. Maybe if all that hadn't been going on, I wouldn't have gotten stuck. But basically, I just got stuck.

Robert Pirsig talks about stuckness and ways to overcome it extensively in Zen and the Art of Motorcycle Maintenance, which I recommend highly (and probably ought to reread). And I really was suffering the kind of stuckness he described, the stuckness that occurs when you just want to get your bike fixed and you break the head off a crucial screw...

(Robert Pirsig went nuts while a grad student in philosophy at the University of Chicago. He had shock treatment back when it wasn't very carefully administered and lost nearly all his memories. The book is about his motorcycle trip across to some of the places he used to live to visit old friends he hardly remembered, along with an amazingly enlightening discussion of what he'd been so obsessed about that it drove him crazy - what is Quality?)

Someone mentioned meditation in the discussion. I had found reading about Zen and doing meditation on my own was of profound help in overcoming my mental illness back in the really dark days. But as things got better and my career got in shape and I stopped seeking so much and concentrated on learning to program and making a place in the world for myself I drifted away from that, something that I think is really wrong.

During my time off my then-fiance lent me her copy of Chogram Trungpa's The Path is the Goal, A basic handbook of buddhist meditation. It is published by Shambhala Publications

I'm afraid I read a little bit of it then when my time off came to an end I set it aside and started thinking again.

One of the little traps our mind has for us is thinking. I like to think, and I'm particularly well-developed at it. But my wife tell me that we are not our thoughts, and actually our thoughts can lead us astray. And when I was getting so stuck on my programming problem I was thinking really hard and trying to solve my problem by thinking harder.

One thing you do in meditation is to stop thinking. Hardened programmers might find that a frightening concept. And you can't really try to stop thinking - you just sit, and look, but not too hard, and experience

You cannot experience your world as it really is and be thinking.

One thing that Pirsig discusses in his book is how to bring the wisdom attained at the rarified mountain peaks of meditation down to practical value in everyday experience. He uses fixing a motorcycle as an illustrative example but when I read the book I found that I was able to program better because I could "become one with the machine".

My wife doesn't really believe this is possible but I think it is, that one can meditate while carrying out an intellectual activity like computer programming. That's something that I seem to have lost long ago, that I had years ago when I was not nearly so knowledgeable but I did have the ability to really lose myself in the machine all day long without distraction - and without getting tired or worn out.

Don't forget:

Tilting at Windmills for a Better Tomorrow

• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00201 1a
• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00136 5a

Heller is a prolific author, but the ACCU only recomend his book on Motif.

Thad

• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00201 1a
• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00136 5a

Heller is a prolific author, but the ACCU only recomend his book on Motif.

Thad

• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00201 1a
• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00136 5a

Heller is a prolific author, but the ACCU only recomend his book on Motif.

Thad

• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00201 1a
• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00136 5a

Heller is a prolific author, but the ACCU only recomend his book on Motif.

Thad

Slashdot readers after book reviews may also be interested in the Association of C and C++ Users. There are currently 2,100 books in the book review section and a variety of mailing lists concerning the contents of the reviews and books available for review. All reviews are submitted by members and if my memory serves me, then you get to keep the book after you have reviewed it. Not only this but you also get a small magazine which called "C Vu containing general articles on C, C++, Java, embedded systems, hardware and software reviews, Windows and X-Windows programming, games programming and tutorial-style articles for newcomers".

Slashdot readers after book reviews may also be interested in the Association of C and C++ Users. There are currently 2,100 books in the book review section and a variety of mailing lists concerning the contents of the reviews and books available for review. All reviews are submitted by members and if my memory serves me, then you get to keep the book after you have reviewed it. Not only this but you also get a small magazine which called "C Vu containing general articles on C, C++, Java, embedded systems, hardware and software reviews, Windows and X-Windows programming, games programming and tutorial-style articles for newcomers".

Slashdot readers after book reviews may also be interested in the Association of C and C++ Users. There are currently 2,100 books in the book review section and a variety of mailing lists concerning the contents of the reviews and books available for review. All reviews are submitted by members and if my memory serves me, then you get to keep the book after you have reviewed it. Not only this but you also get a small magazine which called "C Vu containing general articles on C, C++, Java, embedded systems, hardware and software reviews, Windows and X-Windows programming, games programming and tutorial-style articles for newcomers".

Have a look at the ACCU (The Association of C and C++ Users) site. This is one of the best sites for book recommendations by experienced programmers who are not afraid to speak their mind (booksellers tend to give rosy reviews, and reviews of the form "This book is perfect, I love it, I have read almost three chapters, and can't wait to read more" are worse than useless - why anyone would take advice on how to learn C++ from someone who completely lacks C++ experience beats me). The ACCU rates books for level of experience required and overall quality.

Once you have read an 'introductory' C++ book (try ACCU for some good reviews). I would recommend that you join ACCU. Their publications are excellent and their subscriptions are very cheap (approx GBP 15.00 per year).

Then read "The C++ Programming Language 3rd Edition" by Bjarne Stroustrup. (ISBN 0-201-88954-4) It's quite challenging and is absolutely essential for professional C++ programmers. I can quote the ISBN because I'm meant to be working on a C++ program at the moment, so the book is on my desk.

Don't underestimate the length of time it takes to become a C++ programmer. It is a huge, rich, sophisticated language, and well worth the effort of learning.

You should in general avoid any programming book which includes the phrase "in 21 days" in the title. The Association of C and C++ Users provides a book review section, it should be able to help you find a good C++ book.

You should in general avoid any programming book which includes the phrase "in 21 days" in the title. The Association of C and C++ Users provides a book review section, it should be able to help you find a good C++ book.