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/