Re: [boost] Boost Incubator Status Report

Subject: Re: [boost] Boost Incubator Status Report
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-11-10 15:09:48

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/