
Hordes Of Novices - krisvage
http://blog.8thlight.com/uncle-bob/2013/11/19/HoardsOfNovices.html
======
mathattack
IMHO... You can't get a crew of experienced software engineers without
starting with hordes of novices. It's just not a field where you can say,
"Pass the entrance exam, get some mentoring, and come back in 6 years with
experience." It's a field that you need to explore and find if you have the
passion. (And I hate the word passion)

So it might take 20 novices coming out of these feeders to find 10 who become
decent junior programmers, to get 5 who stick it out to become decent
intermediate programmers, to get 1 who becomes a rock star.

But is this so bad? What's the downside? Everyone who falls off along the way
becomes someone with tools to make themselves more productive in whatever they
do in life.

And what's the alternative?

~~~
Cthulhu_
> And what's the alternative?

I think the author gives an alternative in the form of his pilot training;
intense training before being allowed to write code (= a proper and full
education, instead of a course), and pair programming (= co-pilot) with an
experienced or non-novice pilot (developer).

The big corporate world doesn't tend to agree with this though, two people
doing one job seems like a waste of money and time to a lot of managers that
don't know any better.

~~~
mathattack
Do you think this is the solution? Would it work in any environment? Start-up
for instance?

One could argue that training a programmer should be like training a doctor -
once you get over the initial hurdle of getting into Medical school, it's all
about a long period of learning and mentorship.

My impression is that great programmers can come from unlikely sources. It's
ok to cast a wider net for people, when the worst thing that happens is that
they're more skilled for their efforts.

------
noonespecial
_If one doctor can transplant a heart in ten hours, can ten nurses transplant
that heart in one hour? Can a hundred nursing assistants transplant that heart
in six minutes? Can six hundred hospital receptionists transplant that heart
in one minute?_

The real question is: Could the doctor do the transplant _without_ any nurses?
Could the nurses help the doctor without the receptionists?

~~~
robin2
If I wanted to be pedantic I'd say that you'd really want a heart transplant
done by a surgeon, not a doctor...

That said, I think the real questions is: who is Robert Martin, self-described
uber-hacker, that his opinions should be taken so seriously? What has he
written?

~~~
robin2
To expand on that a bit, I should mention that this question came up at a
software craftsmanship meetup, after Martin had given a talk in Cambridge.
(Incidentally, people who had seen him speak had been very disappointed.) The
only answers to "Who is Uncle Bob?" seemed to be "He's very old" and "He wrote
a book". Given his schtick is to be a sage figure of comparable stature to,
say, Don Knuth or Brian Kernighan, I don't think that's good enough.

(I missed Martin's talk because it clashed with one by Herman Hauser. Industry
pioneer vs methodology salesman wasn't much of a contest for me.)

I the interests of full disclosure, I should probably mention that I've had an
encounter with another Martin (Micah) from 8th Light (see
[http://forums.pragprog.com/forums/62/topics/2753](http://forums.pragprog.com/forums/62/topics/2753))
- nice kid but I wouldn't want him writing code that I needed to rely on.

~~~
Nimi
I find the described interaction problematic from an agile standpoint: "People
and interactions over processes and tools" \- and then, they agree to give a
_lecture_ on TDD? You're describing literally shoving a _process_ down the
throats of unwilling programmers.

I'm not an agile expert, but it seems to me they should have refused such an
arrangement, and plainly say: "Right now, you don't use an agile methodology.
Us giving a lecture to your guys won't change that, it will simply be a waste
of your money. You can rent from us an agile coach for minimum 6 months, and
she will try to transition you to an agile methodology. This isn't a single
decision you make and then 'bam, you're agile' \- this affects hiring, you
might even have to let go of programmers who won't play along. Don't pay us
for a lecture that will simply anger your employees and achieve nothing."

Regardless of the usual agile vs. waterfall debates, what they did sounds to
me very far from the principles of being agile.

~~~
robin2
In this case, I don't think the company can be blamed. As I recall, it hadn't
asked for TDD training, it had asked for C++ training. So if anyone should be
blamed it would be ObjectMentor for (a) hearing this as "introduction to
object orientation", and (b) sending someone with rusty C++ skills.

~~~
Nimi
That's what I meant - even if your employer asked for TDD training,
ObjectMentor should have objected on the grounds that it will achieve nothing.

~~~
robin2
Well, ObjectMentor got paid, someone at the company got to tick a box to say
that developers had been given appropriate training, and we got a break from
real work.

Corporate training is an odd business, it has to be said.

------
kadabra9
> Is our industry doing the equivalent of offering free rides to hopeful
> software developers, calling them pilots, and throwing them by the thousands
> into airplanes just to watch them crash and burn? The evidence is pretty
> compelling. There's a lot of crashing and burning out there. Is that because
> nobody is signing the log?

No, it's because some companies do a really bad job of interviewing and hiring
developers. This could be for a few reasons:

1\. Companies are so hungry to attract developers they make an offer to the
first candidate that seems remotely competent, only to see him/her struggle
when they get out of the bootcamp and into the trenches of day to day work.

2\. Companies have clueless people interviewing candidates for technical
positions, and just do a bad job evaluating them.

For all of those "novices" that these bootcamps and such produce, some will go
on to fizzle out, but my guess is some of them are actually talented/hard
working enough to stick with it and evolve into competent developers. At the
end of the day, it's still the responsibility of the company doing the hiring
to determine which is which.

The need for developers is only going to increase... so yes, we do need those
hordes of novices, but with that need comes an increased responsibility to
focus your hiring/recruiting efforts.

~~~
kasey_junk
I think people underestimate how hard it is to find good developers. I've
spent a lot of time thinking about it, experimenting with hiring processes,
and hiring yet I still wouldn't trust my success rate very much.

The issue is that we don't have any objective measures as to what makes good
software. This means that everything we do in the hiring space is subjective,
which makes it really difficult to do rigorous study/improvement on.

That said, novice programmers even excellent ones are exponentially less
valuable than experienced ones. But, the ratio of good developer to bad seems
constant across experience levels.

In my mind the 2 biggest issues in finding good developers are: 1) the cost of
novice developers. The market has driven demand so high that it is too costly
to experiment/mentor young developers knowing that they will (and probably
should) only provide 2 years of valuable work (1 year of uselessness and 2 of
value in a 3 year hire). 2) the senseless ageism in our industry. The idea
that older developers are somehow inflexible or out of touch just doesn't gel
with my personal experience. The older developers who are still out developing
are doing it because they enjoy it and keep up with new technology. If they
didn't they would have left the profession a long time ago.

Unfortunately, this has led me to a policy of hiring a few more experienced
developers instead of a more healthy mix of novice/experience. I know that
makes me part of the problem but I can't afford to be otherwise.

------
onion2k
The overwhelming majority of bespoke software is a CRUD app in disguise (to a
lesser or greater extent). You don't need to be an expert to develop things
like that - a basic knowledge data structures, connecting to a database, and
some UI and off you go. That isn't going to change. So I would argue that yes,
we need the horde. We need more of the people at the "bottom" doing the boring
stuff than we need at the top doing the hard stuff.

~~~
mildtrepidation
I don't know about "overwhelming majority," but yes, there is a very large
slice of software that is essentially CRUD.

In my recent experience, though, it's almost always attached to, part of, or
feeding into or off of something else, whether that's a CMS, API's, satellite
sites, or some sort of proprietary custom plumbing.

Many things _can_ be done by novices, and the limited supply of experts means
they _can 't_ do everything. But for many projects, that boring stuff at the
bottom handles the data that's vital to everything else, and it's vital to be
careful when using novices to work on the lifeblood of your business. Without
careful management, you'd better hope they randomly fail to introduce any
serious design flaws or security issues given only "basic knowledge data
structures, connecting to a database, and some UI."

------
dbecker
_Is our industry doing the equivalent of offering free rides to hopeful
software developers, calling them pilots, and throwing them by the thousands
into airplanes just to watch them crash and burn?_

With some exceptions, it's less dangerous when a novice programmer writes ugly
code than when a pilot crashes a plane.

So we shouldn't require as much caution around letting people program as we do
in letting them fly an airplane.

~~~
normloman
Just don't let them program air traffic control software.

~~~
herge
Or medical imaging devices.

~~~
ecopoesis
Or let them handle website security

~~~
Profpatsch
Holy crap.

Or write Sony’s user management. Or Adobe’s. Or …

------
marcus_holmes
yes, Uncle Bob, we do need hordes of novices.

Because in the days of yore only monks and priests knew how to read and write,
and that was bad. Getting everyone to read and write is good. 90% of what they
write will be crap, but that's better than not having them write at all.

Obviously they're not going to be writing commercial or critical systems.
Learning to code helps people deal with technology, but it doesn't make them
professional coders. Just like learning to write a shopping list is useful but
doesn't make me a journalist.

Opposing people learning things because what they might create with that
knowledge is just wrong.

~~~
jasonlotito
> Opposing people learning things because what they might create with that
> knowledge is just wrong

He doesn't oppose people learning things.

> Obviously they're not going to be writing commercial or critical systems.

No. That's _exactly_ what he's talking about. The trend to hire more people
rather than better people.

FTA: "Do we really need to keep on recruiting and training cannon fodder to
throw at software projects? Or should we rethink this."

Take a few minutes to read the article.

~~~
venomsnake
I had a big project failed once because at the beginning out rockstar
programmer/ninja/free electron (and he was a genuine one) threw a temper
tantrum and said - I am bored of working with Microchip Pics (don't worry if
you are young and don't know what that is) I want to use something more
powerful - so we switched vendors, the stack to keep him satisfied. It went
downhill. Sometimes you need mediocre guy for a non demanding job.

A bored talented programmer can sink a project as good as incompetent one.

~~~
GVIrish
I think what you encountered is a different type of trap, the trap of the
talented jerk. The guy/gal who is brilliant, so they're allowed to get away
with a crappy and/or irrational attitude. Sometimes this works out well, but
other times it'd be better to hire someone may not be of the same caliber
skills-wise, but has a better attitude and is more pragmatic.

Your coworker might not have been a true "jerk" per se, but he certainly
sounded irrational.

------
ds9
He makes a good point that one more competent developer is much more valuable
than multiple incompetent devs.

The first part of the piece, about how much software is needed and for how
many uses, suggests another point he does not make -- namely that there is a
lot of redundancy. In the universe of softare, how many independently
developed, duplicative solutions to essentially the same functionality, code
pattern or use case are there? Probably quite a lot, right?

The efforts of the limited number of good devs societies have on tap,
obviously would go a lot further if there were more re-use and sharing. I know
I'm an idealistic outlier in believing software should never have been deemed
copyrightable, but the more we go in the "Free" direction - with GPL/BSD type
licences and such - the better off we'll all be, in a macro view.

------
mildtrepidation
_If one doctor can transplant a heart in ten hours, can ten nurses transplant
that heart in one hour? Can a hundred nursing assistants transplant that heart
in six minutes? Can six hundred hospital receptionists transplant that heart
in one minute?_

All of the people involved have useful and important skills, but they are not
appropriate or relevant for the operation in question. My only change here
would have been to swap receptionists out for interns: The skills are still
relevant, but the experience is not there and the expectation is still
unreasonable.

No, development is not surgery (certainly not brain surgery, and usually not
heart surgery). But it is often complex work that requires not just an
understanding of what to do, but also how to do it, why to do it that way,
what alternatives are available and how they might benefit the work in the
future, how requirements tend to change, the difference between what
clients/bosses say and what clients/bosses mean...

It's vital that we have new developers. But the point of having new developers
is that they become experienced developers; a swarm of n00bs is not, in and of
itself, valuable. Treating it as such is dangerous, as many, many rescue
projects painfully illustrate.

------
ebbv
"Get off my lawn you damn kids!"

Today's novice is tomorrow's expert.

No matter how much of an expert you think you are, you are a novice to someone
else.

If we go back and look at your code from X years ago (or even last week), are
you going to be comfortable or are you going to squirm a little and want to
make excuses for certain things?

Bad code making it into production and causing problems for users is not the
fault of the novice developer, it's the fault of their team lead/manager. Who
shouldn't be a novice. If they are then that's an organizational problem, and
not one caused by the mere existence of novices.

------
henrik_w
The problem with mentoring programmers is: who is a good mentor? Looking back
at when I started coding, very few of the senior people there would not have
been good mentors. They simply weren't good enough. They would have taught me
the wrong things.

Also, of course we need more good developers. The problem is that there aren't
enough good people to be found (this is not a problem of too few places where
you learn to code). Plus, the demand for more software seems pretty limitless.

~~~
scrabble
Yes. There's also difficulty in finding mentors. There are sites that pop up
claiming to offer software mentorship, but most seem to be just people who are
willing to help you with an issue you're having with your code. That is not a
good mentor-protege relationship.

~~~
xradionut
There's also a problem finding decent students/coworkers that listen. I don't
know how many times I've made suggestions and recommendations, just to be
ignored.

I co-lead a local programming user group and we commonly help people.
Frequently we encounter people that want us to fix the bug in one line of code
and don't want help in fixing the structure, the function, the readability or
overall program.

~~~
henrik_w
Exactly. Not enough developers care enough to be either good mentors or good
mentees.

------
azurelogic
While I enjoyed and partly agreed with Uncle Bob's equivalent of "Get off my
lawn", it would be excellent if he also proposed something that resembled a
solution to the problem. I struggled at my first dev job because school only
taught me the basics, not modern full-stack agile software engineering. I
worked with a team that had everything from testing to deployment polished and
near perfect. However, some of them gave me a chance, and today, I suck a lot
less at writing good, clean, tested code. Our industry will need to continue
to do things like that if we hope to improve over time. Otherwise, history
will just repeat itself.

~~~
memracom
One of the problems with software engineering training is that few schools
take the "engineering" part seriously. Instead they train programmers or
software developers. If engineering was taken more seriously then they would
teach SWEBOK and SEMAT along with coding. Of course, many schools would argue
that software engineering is a young profession and that SWEBOK and SEMAT are
not yet fully formed. But nevertheless we do have people that are trying to
apply some engineering rigor to the process of developing software and there
is something there for all of us to learn, even if these things take another
decade or two to become fully formed.

------
lmm
Have you ever worked at a job where a guy who learned to program 20 years ago
has to sign off on everything you do? I did, and it was awful. I've also
worked at a place that hired nothing but fresh graduates, and that... actually
turned out pretty well. There were cases where they wrote more code when they
needed to, or used an unsafe construct when there was a better alternative...
but they were willing to reason about things, to experiment, rather than just
"this is how we do it". I'll take an untrained grad over someone who rigidly
follows procedures any day.

------
edw519
This discussion reminds me of Joel Spolsky's "Hitting the High Notes":

[http://www.joelonsoftware.com/articles/HighNotes.html](http://www.joelonsoftware.com/articles/HighNotes.html)

Instead of debating with every other PHB, PM/BA, or clueless customer, I have
them read this first. It's fundamental for understanding how to use high
achievers to get things done.

(Love this part: "Five Antonio Salieris won't produce Mozart's Requiem. Ever.
Not if they work for 100 years.")

------
sailfast
As a relative "novice" compared to the author, I welcome the suggestion that
more formalized mentorship and "sign-off" by someone with experience would
improve programming. Sorry I can't do your apprenticeship program. I see what
you did there. Up scope!
[http://www.8thlight.com/apprenticeship](http://www.8thlight.com/apprenticeship)

The problem is that this cannot be implemented at scale, and certainly will
not respond to demand. One may not have the opportunity to find in person
mentors, but instead have the internet and a problem to solve. You have to
navigate through on your own to find the people that do it right, and you may
latch on to the wrong people!

On the hiring side - for critical systems with a profit incentive and high
potential, (or for a company with a unique mission that entices developers)
you can afford to find and hire the bard. For other tasks, _something_ is
better than _nothing_ so you get mediocre code. (there is still a HUGE market
out there for that small something for small to medium businesses).

For outlying scenarios where markets have become imbalanced by regulation or
law (such as government contracting) you get incentives to put butts in seats
regardless of experience as long as they meet the criteria. (Java cert =
signed pilot's card right?)

Certification is hard to get right, as is mastery. I applaud you for creating
an environment to provide guidance and make mistakes and would welcome a
larger scale effort to do so.

------
asparagui
Hoard == a secret stash Horde == a large group

------
memracom
As the guy who formulated SOLID principles, co-created the Agile manifesto,
and formulated the red-green-refactor process of doing TDD, I'd say that we
should listen to what he has to say.

Why do we keep training programmers in university to bang out low-level
unstructured code? We know better and some schools like MIT with SICP have
been following a different approach, but why is this not more widespread?

Java is a horrible language to teach to new developers because it has traps
all over the place that are best avoided. If a course started with DDD for a
month before the first line of code is written, then perhaps Java would be OK.

I'd still like to see all developers learn some machine coding and assembler
but that should be something that you leave to 2nd or 3rd year after you have
a grounding in how to structure programs.

------
asgard1024
I think he is basically arguing for a professional organization of
programmers, which would give out certifications and (wink, wink) make sure
their salaries won't get too low by limiting competition. (I don't necessarily
disagree, just saying.)

------
leetreveil
Press the G key while you're on the website and you'll see their layout grid.

EDIT: it's this:
[https://github.com/dotjay/hashgrid](https://github.com/dotjay/hashgrid)

------
xacaxulu
Don't hire and mentor a newbie or a graduate of a coding school, just hire a
master coder+pilot. Perhaps the consultancy team at 8th Light could pick up
your project for thousands of dollars a day...

------
caseyamcl
There is a definite argument to made for putting in-place more rigorous
standards for developer education. My wife is a nurse, and there are very
strict standards for getting a nursing license and graduating with a BSN
degree. After all, she deals with human lives, and mistakes could be deadly. I
believe such systems help ensure consistent behavior, and I agree that such a
thing might be useful in certain areas of the developer world.

However, we have to be careful, because a big part of software development
involves inspiration and creative work. If people aren't interested and
encouraged to pursue development as a hobby or career path, where will the
masters of the future come from? Think of the amateur, but not so great,
photographer hobbyist who grows up to become a legend in their field.

I also have to disagree with Uncle Bob on the use of the term "hordes" to
describe "many people interested in a craft". The negative connotation is
indicative of the kind of snobbery that people as the top of their field may
be entitled to, but certainly doesn't win people over when trying to make a
convincing argument. It smacks of somebody looking down from the Ivory Tower
of Enlightenment and sneering at the ignorance of the perceived mobs below...

------
mattdeboard
I wonder about the thought process that spawns articles like these.

I'm a novice but I think I do pretty well for myself. I also didn't write my
first line of code when I was very young. I didn't get any thrills or anything
from programming until I started in my 30s.

Obviously you need hordes of novices. What a preposterous, pretentious thing
to say. It's the ultimate "first world problem" of career fields. "We have too
many people who want to do this job because the pay is so good, career outlook
is so bright, and job satisfaction is so high!"

Yes you'll probably have to work much harder on a good noise filter when
hiring, and you will probably have to be ok with taking a chance on hiring
"newbs", hoping to get a great one who trains up well.

This is a really geeky rant, and I don't mean that in a good way. I mean it as
in totally socially tone deaf. It's like Comic Book Guy from the Simpsons
wrote this. I know the author is a well-known guy in the software world but
that doesn't change my opinion at all.

------
programminggeek
It is probably worth noting that Uncle Bob doesn't seem to be implying that
the pilot training model is exactly the model that we should use. His point if
you read a bunch of his stuff is that as a profession, we should look beyond
our own borders to learn lessons from doctors, accountants, lawyers, pilots,
engineers, architects, etc. to advance the level of professionalism in our
profession. If software is going to make the world a better place ideas like
"move fast and break things" probably isn't going to end up being a net
benefit overall, especially for important, life or security critical software.

If we pile in a bunch of novices without proper training and hand them
projects that involve account security, personal information, etc. we are
going to keep hearing about major security breaches, password hacks, etc.

The more that the software industry has major catastrophic failures costing
millions/billions of dollars, the more likely that we get regulated.

~~~
Cthulhu_
And yet, go our own way too. Software is (or used to be built) like other
engineering professions; big design up front, then build (and often have the
actual construction done by relatively low-wage workers). Software's much more
complicated though.

------
al2o3cr
A question not asked by the piece: is what we do really "heart transplants"
and Shakespearean plays? Sure, that surgeon can do the transplant like nobody
else and ol' Bill can write a play like nobody else, but what if all the
client actually needed was a bandaid or a quip for a greeting card?

------
skaplun
I believe there will be as many commercially created sites in the not so
distant future as there will be houses.

programmers are the house builders of tomorrow, and they are needy, creating
more jobs than the average bricklayer, so they drag a few non-educated along
for the ride with them.

All in all a boon for all involved.

------
zdw
I tend to view people who know the extreme basics of programming as tinkerers
or "power users", not as miniature Fabrice Bellards.

I'd rather have a bunch of curious people who want to try their hand at some
light automation than people who freak out when anything minor changes.

------
scrabble
It should be clear that what we need is more software developers, but people
who are able to quickly rise above the level of novice.

Generally this is what the interview process is meant to weed out.

------
allworknoplay
You're completely right, it would be much better if they all went into finance
or management. There's no place for people trying to learn real skills.

------
unclebobmartin
Does anybody here think that healthcare.gov was put together by experts? Or
was it more likely a horde of novices?

------
wwkeyboard
I love the idea of starting people on the path to learning how to build
applications. However I think he brings up a good point, I can't find on the
code academy website where it says "this is a start to long process of
learning". appacademy goes as far as to say 12 weeks and you're in.

------
dsego
Should we have associations, guilds, licensing?

~~~
unclebobmartin
I would vote for associations and guilds. I'm not a fan of licensing. I don't
think we know enough to license people.

------
websitescenes
This article is ridiculous. Someone needs to program the software obviously.

