

Unlearn, young programmer - mountaineer
http://blogs.tedneward.com/2012/03/21/Unlearn+Young+Programmer.aspx

======
dkarl
Supervising junior staff is not where this battle is won or lost. Your
development culture is going to have the biggest impact on how those young
programmers go about their tasks. If you want junior programmers to develop
well (software and themselves) you need to attend to the culture they take
their cues from.

I worked in a near-ideal development culture once. Twice, I suppose. Everybody
was humble. Everybody documented their code. Everybody bounced their ideas off
someone; even the smartest guy in the office humbly asked for advice and meant
it. Everyone was quick to assume that if other people thought their code was
confusing, then it probably was. Everyone assumed they should be able to
explain their brilliant idea to anyone else on the team and convince them of
its value. Most of what I knew about the codebase at those jobs I learned from
guys who knew ten times as much as me drawing diagrams on the whiteboard and
asking, "Do you think this will work? Or am I being stupid here?"

A junior programmer would naturally succeed at the picture-hanging problem in
that environment because they'd approach it the same way the star programmers
approached their work: tell other people what they're working on and what
they're thinking, and make sure they can articulate and justify an idea before
they commit themselves to it.

That's the ideal. Most cultures fall short of that in one way or another. In a
completely opposite situation, if the star programmers work in isolation,
disdain to discuss their work with lesser programmers, neglect to document
their code, and aspire to write code that no one else understands, junior
programmers will learn some very unhelpful lessons. This is true even if the
star programmers are getting shit done and writing efficient, correctly
functioning code, because they're basically (and I shudder to use this word
because I don't want to start the wrong kind of conversation) peacocking.
They're getting stuff done the hard way and proving they can thrive in a
completely unsupportive environment. There's unspoken machismo, which put into
words would sound like this: "Nasty opaque codebase? What's wrong, can't take
the complexity, little man?" "Gosh, I would have _written_ some comments if I
knew _some_ people _needed_ them." That's the kind of environment where a
programmer is going to either wilt and do something really stupid because
they've already given up or "rise to the challenge" and try to make a drywall
saw using a 3D printer.

Take care of the culture: set a good example, promote respect and humility
among your developers, and don't exempt anyone from good practices. Then
junior programmers will find their way even if you don't have time to guide
them yourself.

~~~
stcredzero
_I worked in a near-ideal development culture once._

Thank you very much for this description. I find it gratifying and inspiring.

 _Everyone was quick to assume that if other people thought their code was
confusing, then it probably was...There's unspoken machismo, which put into
words would sound like this: "Nasty opaque codebase? What's wrong, can't take
the complexity, little man?"_

Also, I find this to be key. There is room for raw talent and huge, inspiring
amounts of clever -- but it needs to be focused exactly where it does the most
good. Let's just assume that one's competitors are in the same league when it
comes to intellectual horsepower. Then it behooves one to make sure one's
resources are focused where they do the most good. Let the competition
dissipate their intellectual powers in developer pissing matches while you
quietly outperform them.

Of late, I've come around to a radical stance on this. Modulo DRY, one should
almost always target one's code to the lowest common denominator programmer on
the team -- the newbie. This should probably follow an 80/20 or 90/10 rule. If
a bog-standard well informed and competent programmer can't come in and start
fixing 80% of your code within an hour, and it's not due to lack of non-
programming specialized domain knowledge, then you're doing it wrong. There's
room for elegant abstractions and the odd clever hack -- but you only get to
have at most 7 of these in any given subsystem, and the code involved should
be the minority of your codebase.

Clever is a valuable resource. Use it wisely.

------
pilif
Then again, by being experienced, you know that certain things just don't work
and never will. Until you see a newbie do them because he didn't know it was
"impossible".

Like the guy presenting his NES emulator at jsconf.eu in 2010 which was
practically a line-by-line port of a Java emulator. If you'd have ask me
whether it was possible to line-by-line port a Java application (and a
complicated one at that) to JS, I would have told you that, of course, this
was entirely impossible.

Until that guy, totally new to JS and emulation -heck - even programming in
general - just did it because he didn't know better.

Sometimes, having a new perspective is very helpful and we must be careful not
to lose that. Sure. The solution might not be perfect, but one can always
refine it.

------
ilaksh
He implies that googling a problem will generally lead inexperienced
developers to incorrect solutions. I think this is false.

He also assumes that Googling won't be the first thing junior developers do
when they are given an unfamiliar task. Unfortunately, for too many, this is
the case. The solution to that problem is to train junior developers to
google. It sounds like the author of this article also has yet to learn the
importance of googling first.

A lot of these problems are actually not new and are like the example of the
picture. If you google 'how to hang a picture' you will find good
explanations. You are unlikely to find a lot of people at the top of the
search results who are telling you to cut the drywall.

When it comes down to SAX versus DOM, that's not really quite comparable to
hanging a picture. In those types of cases, what you say to the junior
developer is 'Google it and come back to me when you've found some example
code that you are going to start with'. That way you can guide them if
necessary before they get too far in. Or give them a starting direction, being
as explicit as possible (point to code example).

If they are googling and coming back with really strange solutions (which,
again, you tell them to go over the outline of the solution with you before
they start implementing it), then maybe they don't have the intellectual
capacity or experience for the tasks you are giving them.

On the second half of this post, he is also wrong. The timid and tentative
developers will probably often get along fine with the more senior developers,
because they are going to be happy to do things exactly the way they tell them
and won't talk back. Part of the time they will be so clueless that they can't
get anything done, and since they don't use Google they won't get anywhere but
the others will be careful to follow the lead of the senior developers. So the
traditional approaches will be passed on and everyone will be happy.

Anyway in the end he more or less gets to his conclusion which is reasonable
enough, although stated in a way which I find to be somewhat arrogant. I think
the entire basis for this was a fair amount of wasted time which was at least
partly the fault of the more senior developer not providing initial guidance
or checking in on the junior developer.

It IS definitely helpful when developers, whatever their experience level, are
secure and modest enough to ask for other people's knowledge, opinions and
help freely. I have found this to be rare. Too often asking questions is
simply interpreted quite stupidly to mean that the other developer is
ignorant. And also quite stupidly, not know literally everything is
interpreted as ignorance.

To boil it down, the author sounds like a dick, should take some
responsibility for the wasted development effort that he is trying to put all
on the junior developer, should learn to Google himself, read my post, learn
to ask questions himself, and work very hard at cloaking his arrogance when he
speaks to the junior developer. And no I do not know who this person is and am
not actually related to the situation. Article just pushes some of my buttons.

------
MattGrommes
You also get the other end of the spectrum, the "experienced" Lead/Manager who
looks at hanging a picture and goes "These walls will never hold that" (when
they've worked for years). Then he tears out the drywall and studs, gets the
PM to read him the entire Building Code and agree to each line, puts in 4x4
posts instead of studs, all the while agreeing to re-tile the floor and paint
the room, all on the same schedule as hanging the damn picture.

Any resemblance to anyone I've worked with is coincidental.

------
mountaineer
In short, to become a good developer, ask good questions, find a mentor, find
opportunities to teach. Wise words for any profession I think.

~~~
paupino_masano
I'm pretty sure any top student coming out of their course thinks they're a
good developer already with all the right answers. To ensure they DO ask good
questions I think providing mentoring for junior developers is probably one of
the more effective investments you can make.

~~~
genbattle
Agreed. As the above type of eager young developer, I can say it has been
rather disappointing the lack of mentoring and direction at my first job.
Junior programmers are just assigned to a task and expected to complete it.
Programmers that don't ask questions and bug other more experienced developers
don't survive. Developers like myself learn the ropes after a while, but it's
frustrating to have no real direction or encouragement.

I know this probably comes off as the comments of a naive young programmer,
but I sort of expected that companies would have some level of formal or
informal training. I thought I might even be sent to attend developer events
or conferences. At the very least I expected there might be some sort of
formal internal forum for knowledge sharing, presentations, etc.

Because of (what feels like) a lack of skill advancement, I spend the majority
of my free time playing around with technologies I feel like I should be
learning at work. But at most companies there seems to be this "We're not
paying your to learn" attitude. It's very disheartening coming from a
university environment. Plus it seems kind of self-destructive in some cases;
if a company as a whole falls behind its competitors technologically, how can
it be effective as a business in the technology sector?

I suppose by posting this i'm just making an argument for why i'm a
nailgun/drywall saw type of guy. Hopefully the transition to a working
environment will only get easier.

~~~
gruseom
What you're describing is, unfortunately, standard practice in the industry -
and has been for a long time. I've been around for a while and have been as
frustrated by it as you. (Sorry for self-quoting, but I wrote about this in
the last bit of <http://news.ycombinator.com/item?id=3341058>)

This may not be what you want to hear, but in my experience, organizations
don't change much, so take your hopeful energy and channel it into finding (or
starting) something else that is better. Hacker meetups and open-source
projects are two ways to interact with other programmers. As far as work goes,
try to find (or start) a place with a culture of collaboration. They're rare
but do exist. The trouble is that absolutely everybody will say "yes" when
asked if their culture values collaboration, mentorship, etc., and you need
some way to cut through the bullshit. Best way I know is by knowing a person
who works there.

------
prophetjohn
I think it's also important to point out that young programmers often don't
know that what they don't know is reasonable to not know. As one of these
drywall saw guys, sometimes I'm cutting drywall because I feel like I should
be able to figure out a certain amount of things on my own. When I started my
first (and current) job, no one ever expressed to me that it's okay to ask
lots of questions and to not know much. Sure, it's probably the junior's
responsibility to ask questions, but the senior has been in both situations.
The junior has been in neither. The senior engineers have to have some
responsibility for letting the juniors know to ask when they're unsure of
something, etc.

Also, at risk being 'that guy' (also, proud suggester of using Rails in lieu
of the GWT that _every_ developer constantly complains about), I think it
would be helpful for junior engineers to pair with someone more senior, at
least some of the time so that they're not halfway through cutting up the wall
before it's noticed. I know I've come up with some fairly terrible solutions
now that I've learned better and I'm probably doing things now that I'll look
at in a couple months and think are terrible.

------
stevear
I strongly agree with some of the interactions in this article.

Advice to Junior Programmers: Don't be 'that guy'. Don't be that guy that
derails meeting and projects by trying to switch frameworks or languages or
whatever. Writing code in your free time is different than writing code for a
business on a team. Listen to your co-workers and go with the flow until you
have a lot of experience under your belt.

Managers and Sr. Devs have a very keen awareness of when they run into 'that
guy'. No one likes them and they are toxic to projects. Managers and Sr. Devs
want to be completing projects and not defending why they are using XYZ
technology.

'That guy' has a good technical ability but no business sense and usually ends
up being let go. This leads to 'that guy' thinking they have been let go
because no one can see their talent and adopting a victim mentality.

Be a facilitator, not an irritator.

~~~
thatguy11
That guy here who was recently let go.

Thank you sir for your kind advice.But I think I will run my own business.It
was my mistake that I thought I can co-exist with the likes of you.

~~~
jacques_chester
You'll eventually meet your very own version of "that guy". It is an
inevitable cycle of life.

------
icebraining
"In the face of ambiguity, refuse the temptation to guess."

~~~
tucif
this would be the best tl;dr for this article.

Just typed 'import this' on my python console to read the zen again.

------
jakejake
It's like the guy who wrote this article can see into my soul.

Most people on my team over the years we tend to be on the same page about
projects, timelines, etc. But I've had people where it seemed like every
minuscule detail had to be spelled out or the work wouldn't meet the
requirements. That isn't just Jr. developers though, Sr. Developers can go the
opposite way and spend months engineering and re-engineering without getting
anything accomplished.

Basically I think it's easy to manage people who think similarly to how you
think. It's a lot tricker managing people who have a totally different style
or way of thinking.

------
maccylo
I feel this resonating quite strongly with me as I'm that young programmer
that needs mentoring. Occasionally I get stuck with questions which I can't
google answers for (for they result in the drywood type of solutions) and I
don't have anyone to ask. Sure, there are many, many people around me
(professors, older students) who do know the answers to those questions, but
but one question always paves way for another and asking them to make a
commitment for longer than half an hour seems like asking too much.

~~~
gcp
An active open source project with an IRC channel might come a long way.

------
kinleyd
A very useful article. While the experience is drawn from the tech world, I
think this is true for most professions. The bottom line is everyone starting
out needs some guidance, and most of the time you are left to sink or swim.
However, I think over time many, if not most (among those do make the effort
to level up, not those who don't even try), eventually learn and get wise.

------
pjmlp
Right on target.

I see lots of these young programmers in every single project I work with.

Usually they tend to be hired by Fortune 500 companies (the customers my
employer works for), as they are on salary level quite cheap.

But in the end their googling for solutions usually do more harm than good to
the projects.

------
stray
Ah, yes.

And of course, the young padawan who has built a rube-goldberg monstrosity
that kinda works will be furious when you suggest simplifying.

~~~
evincarofautumn
“But it would be such a waste to throw away all this code!”

Working on my own, it took me a long time to overcome this feeling. When
you’re too stubborn or embarrassed or mad that you didn’t think of a better
solution in the first place, it can be really hard to let it go. But nowadays,
I feel better the more code I can remove.

------
derleth
So... how often will following this advice get you labelled as an 'idiot' who
'doesn't know how things are done' and really should be pawned off on some
other company so we don't have to train this loser on company time?

