On 10 Nov 2014 at 14:02, Edward Diener wrote:
When interviewing C++ developers, I find those using Boost libraries, at least beyond shared_ptr, are rare. The brand is known by relatively few, and it is used, to any significant extent, by fewer still. That implies the need to grow our ranks through some form of advertising.
Did anyone ever get promoted for jumping onto new language features before they are commonplace? I'd doubt it.
1) I did not write what you are responding to. Please quote correctly. 2) Many ( most ? ) Boost libraries are not about new language features.
A fair point. You did not say language features.
3) I never realized that using a software library is all about getting promoted in some programming job.
I think my point was the opposite: using a software library probably doesn't improve the conditions for you keeping your job if your it makes your role look superfluous to requirements. In many roles, you don't want to make yourself look unuseful.
Using Boost will substantially raise your recruitment costs. Right now my current client who uses Boost and the C++ 11 STL extensively is trying to hire more engineers willing to relocate to their HQ and we've already dumbed down the job description once, and we'll probably have to drop any mention of the STL or Boost and any mention of unit testing or multithreading next because we are seeing *zero* applications.
I get it. Your view is the mercenary one where no one in corporate programming cares about anything but making money, job security, and getting ahead in whatever way possible. Bravo ! But in that view also Boost has no business trying to appeal to programmers in the corporate world by dumbing down its software.
My view is exactly the *opposite* of this assessment. Most engineers I have ever met want to do good engineering, and *will* do as good engineering as they know how if so enabled. It's just that their chances to do so are extremely limited in the typical corporate engineering environment. Most engineers I have ever met also are nice people who don't rock boats like the majority on this list, incidentally. They don't display strong opinions on C++ minutae or philosophy. They just get on with things as best they can with what they have. They also tend to avoid promotion, as that often leads into management and with management comes not being able to ignore org politics, dealing with which is always very tedious indeed. However, a large majority of corporate environments create individual behaviours which are highly counterproductive to good engineering. And, in a sense, that's because good engineering is dangerous to the health of the org - it can tear it apart through rivalries, threats, politics, etc. all of which become a vital threat to your future as soon as some team starts showing up all the others. So everyone has a strong incentive to not perform *too* well, it creates fraught politics. Better to take superior productivity as ice cream day, or spicy wings day. The irony of this of course is that the big multinationals typically pay the most salary on average, and yet the average worker there is working far more below capacity than the average worker in a small company. That counterintuitive outcome is the subject of many a book on how to do tech startups, or Economics books on Silicon Valley.
I do agree with Robert Ramey that better documentation is always an admirable goal for library developers, since understanding what a library offers is necessary for deciding if it is of any use.
I'm betting the ability to very quickly prototype a test solution for a problem is an even bigger draw. A web page which spits out a ready to go single header file of your choice of Boost libraries - complete with a unit testing package bundled BTW - might just be the ticket. Not that I'm arguing about the better docs of course. It's just there are more key barriers to entry than docs. Typing and clicking more than a few keys or clicks is a big one. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/