
How We Grow Junior Developers at the BBC - chaghalibaghali
https://medium.com/bbc-design-engineering/how-we-grow-junior-developers-at-the-bbc-dc3054f7e390
======
sdrothrock
I work at a small Japanese company with only two developers; myself and a
junior developer (also American) we brought on as my assistant a year ago. He
came on with little to no development and technological experience but an
incredible work/study ethic and a willingness to learn, which are both MUCH
more important to me.

The skills can be learned and refined over time, but the fundamentals need to
be there; if a developer doesn't have the right mindset or ability to learn,
then they're never going to grow, no matter how much you poke at them.

One issue I've been fighting (with myself) is knowing when to criticize and
knowing when to let him go; I err toward the latter a lot, especially
technically, but lean toward giving advice sessions or examples when it comes
to communication/professional growth skills. The reason I do this is because
it's much, much easier to refine technical skills than it is to refine
personal skills... and the personal skills are equally as important at a small
company when time is precious and you're working directly with other people
who are also under heavy loads and pressure.

I bring this up because I was surprised to see zero mention of independence as
a prized quality after the author commented that he did NOT feel like a cog in
the machine at the BBC. There is, I feel, a fine line between needing to be
told what to do every time and being able to make the right decisions on your
own.

The latter quality -- reasoned independence -- is something I think every work
environment should foster in its team members in order to have a team that
respects and can support each other. Teams fall apart if members need to be
told each and every thing they're supposed to do: members will either grow to
hate that or will become mindless minions; the team falls apart when the
order-giver is no longer there; over-communication becomes an issue and more
time is spent in meetings or replying to 100+ e-mail chains instead of
developing things for customers.

I rarely see much talk about this kind of growth in developers here though...
and it makes me wonder if I'm misguided in placing so much importance on this
concept.

~~~
skyisblue
Currently have a junior dev on the team that asks way too many questions, most
that can be easily googled. How do we push him in the right direction to
become more independant.

~~~
sdrothrock
Your particular handling of him will depend on his personality and relation to
the team, but one way I've found to handle this is to sit with him on a few
questions and walk him through the most basic levels of your thought process
as you think of queries and Google them, select results, etc. This way you're
"teaching him to fish" so that he can use that methodology in the future.

While it may often seem simple to "just Google it," it can be difficult for
people to come up with appropriate queries and weigh results, especially in
new/unknown contexts.

A lot of the time we have ready answers if other people ask us questions
because we're actively ready to attack and criticize to get an answer, but
we're more reluctant to do that with ourselves. So if the teaching approach
doesn't work, then another way is to ask him to list up the questions he has,
give it 10-15 minutes, then review them himself to see how he would answer
them -- the idea is to give him some time to "reset" and get a fresh
perspective.

------
lordnacho
One thing about junior devs is the level of skill varies greatly. Where I work
there's a guy who is nominally a junior dev, but he already knows everything
the senior devs are expected to do. If he was an average guy there'd be a lot
more handholding, but somehow with barely any hiring process (he was a friend
of a friend) we lucked out. I'm wondering whether management will be smart and
pay him like a senior dev so he doesn't leave as soon as he finds out he could
be making a few hundred grand instead of a few tens.

One major downside of this kind of variation is managers think they can
somehow repeat the trick. If we just make the hiring process hard enough and
shove enough candidates through, we can pan for those elusive 10x guys. It
also makes people think that 10x guys are a thing like a gold nugget in the
river, rather than the outcome of a long process of maturation in an
appropriate environment.

~~~
therealdrag0
Yeah I've kinda been that guy. Went from university straight into a green
field project that allowed me to grow very fast and I was smart and competent
enough to handle it. I knew the project inside and out and everyone liked me.
They billed me out at $250 and paid me $40. So I switched jobs after 1.5yrs
for a 40% raise. Then the same thing happened, so after 1yr I got another job,
also through a guy I had worked with who had seen I was good, for another 15%
raise. It's funny how a company can get hung up on relative pay-raises instead
of considering actual value added.

~~~
jomkr
I'm that guy but instead of leaving I hung around, god knows why.

After three years, I'm interviewing and getting offers of about 60% salary
increase.

From £32,200 -> £55,000.

------
k__
It somehow always saddens me to read that.

Most devs I know started at a small company who didn't "grew" them at all.

I worked 7 years at a small company and never got any mentoring or external
education etc. while the "good" ppl I knew from university got jobs at big
corps and got even better because they got "grown" right.

Who already has is given.

~~~
m_st
Same here. Started as junior (with 7 years programming experience from school)
with a few other juniors at a company working on a new product without any
senior developers anymore. It sure was a little rough sometimes and we sure
made our fair share of errors and technical debt, but it was an amazing
experience. And the product still works fine today.

So with a motivated team and some autodidactic learning you can still get very
far! Especially since Google and Stackoverflow.com are at your disposal.

~~~
k__
It didn't even occur to me that I could educate myself in that time.

I started doing it after I was 9 years in.

~~~
dozzie
So you basically sat on your ass and said "somebody teach me"? No wonder that
your colleagues from university got so much better.

I never got much help from other people. In the beginning, I didn't have
_anybody_ interested in computers around me at all, yet I managed to learn
programming. Then, when I started studying IT and switched to Linux, and I
didn't have anybody to systematically learn working with unix from. This
happened when I didn't have an access to the internet, and we had very little
learning material published (first half of '00 decade), so it wasn't even
possible for me to ask a question on StackOverflow or something.

And then the pattern repeats a number of times.

It's not _mentoring_ that helps people grow. It's _learning_. It can be done
with a teacher/mentor (and in fact it's easier in a number of fields), but it
doesn't _require_ one. Don't blame others for your own idleness.

~~~
k__
Point wasn't that I was lazy, point was that I had the impression after
university I'm a dev and get a job and work.

~~~
isostatic
That's a great admission, to admit that to yourself let alone in a pseudo-
public environment shows growth and maturity so many tech people often lack

~~~
k__
I want to be good in what I do, not just think I am good.

Many people can take enough from simply feeling better than everyone around
them.

On the other hand I often feel bad about myself, which isn't good either.

------
eosrei
> I worked in an all-senior team once. Nobody admitted not understanding
> something. Everyone wrote overly-complex code just to 1-up each other

Sorry to hear about that experience. Those aren't senior developers. There's
no room for learning when you think you know everything. Senior developers
mentor, simplify, document, and admit when they don't know the answers.

~~~
spaceseaman
> Senior developers mentor, simplify, document, and admit when they don't know
> the answers.

Sadly this is far from my experience as well. It's likely a few toxic work
environments.

Not to hijack your comment but I would like to offer a specific example I've
seen of toxic behavior from senior developers. Many don't actually read the
questions you ask of them or trust your knowledge. It's very similar to
attitudes I see on Reddit, HackerNews, or StackOverflow:

"Hey I'm having a bit of trouble getting this to compile / run / there's this
weird error I'm encountering. I read the documentation and based on that tried
X, Y, and Z, but none of those solved my problem / my problem appears somewhat
different." (Where each of X, Y, and Z are somewhat long explanations of what
was tried).

"Did you try X?"

"Uh yes I did" (then to be polite I repeat my explanation of doing X)

"What about Y?"

You see what I mean. Especially in text, I find that some senior developers
can't be bothered to _actually read what someone else said_. So if you're
worried that you're a poor senior developer, I recommend you actually try and
read what your younger colleagues say and ask of you. And especially trust
that they are being honest with you. Don't assume that someone is lying or
that they're wrong on the first pass - it's condescending, frustrating, and
usually a waste of time. If you hired someone in the first place, you should
be allowed to assume a bare minimum of competency and if for some reason that
fails, you can always question them after the fact. I think it's a result of
our engineering mindset to assume absolute idiocy in every case and then work
our way up, but I think it's more productive (and especially better
leadership) to assume that your subordinates know what they are doing.

In the context of an online forum like this, I think it's best to do the
opposite: assume idiocy and work your way to competency - simply because we
are all anonymous and don't know each other. The actual workplace should be
treated differently though. People always perform better when you put your
trust in them.

~~~
IncRnd
Maybe I read your post wrong, but your post seems to complain that Senior
Developers don't believe some Junior hires have minimum competency if they are
unable to compile a file.

That seems like something a Junior Dev should have mastered during their
educational period.

~~~
rxhernandez
Then you're not senior enough to know enough of the unique problems that come
from trying to compile things, especially for embedded devices.

One of the non-embedded cases is compiling boost on a visual studio machine
for wrapping python which can be its own special kind of hell. I've seen at
least one very respected principal developer wholly screw this up. I can write
for hours on those kinds of problems and how to solve them.

------
valuearb
Lots of good stuff in this, but i have a couple of significant nits.

First, paired programming is a great way to help a junior learn. But it’s
dependent upon their desire, i do it frequently with one whose eyes glaze over
when i explain what i’m doing and i know when they start surfing the web while
i’m implementing.

But otherwise paired programming is just a great way to slow me down.

Secondly, the open floor plan they described is a clear disregard for the
productivity of individual software engineers. Maybe the author never
experienced the difference, but it’s significant.

~~~
josh602
> Secondly, the open floor plan they described is a clear disregard for the
> productivity of individual software engineers. Maybe the author never
> experienced the difference, but it’s significant.

Actually, I have. I've worked in two small digital agencies where the devs
were in their own office. I didn't like it. It was too quiet for me and I felt
like I wasn't allowed to talk to anyone. I concentrate better when I have
background noise. Some of my colleagues have headphones, but I don't like to
use them because I don't want to give the impression that I don't want anyone
to interrupt me. I prefer people coming up to me to speak to me rather than
sending me a message.

There's a very good historical reason why the BBC is committed to open plan
offices and hot desking. Back in BBC Television Centre days (if I'm
remembering correctly), it used to be that managers would have their own
offices and the teams they line managed would be based in a completely
different part of the building. Eventually, someone realised this is silly.
There was a huge transformation of the corporation's culture, which brought
about the existence of the BBC Values, and no one was allowed to have their
own private office any more. Managers would sit with their teams, and people
were able to just go up to other teams and chat with them, collaborate, etc.

It would go against the BBC Values if someone senior gave themselves a sense
of greater self-importance just because they were a higher grade. No one
should be told, 'You can't talk to me because your grade is too low'.

~~~
valuearb
It's fine to put managers in the same area as their teams.

It's fine if you prefer to work in an open area.

But studies are pretty consistent that developers are more productive with
fewer distractions. Not giving developers the option of private offices is
underutilizing some of your most expensive resources.

~~~
josh602
True! I think a lot of modern workplaces are good at compromising on this. In
our case, we don't have private offices, but there are quiet working areas
that you can go to to work. Although these are sparse in our Salford campus,
unfortunately; there's a lot more in the London buildings.

~~~
valuearb
I actually work in an open floor plan. I have a great boss, coworkers,
interesting work, the only thing I hate are the distractions.

In our case we have “breakout rooms”, nominally for impromptu meetings but
it’s acceptable to camp out in them for a while if you need privacy/focus. But
I can’t drag my big screen monitor in them, or use them every day, so they are
a very imperfect solution. If we added large screen monitors to them, and
allowed engineers to camp in them most of the day every day, they’d be
perfect. But then they’d be, private offices.

The last time I managed people, I had the company build small single person
offices for them. If they needed to pairs or a bit, they had just enough room
for that. If they needed a meeting with more than 2 people, there were rooms
for that.

We never had problems with collaboration or communication, and this was before
slack. Team members would email non urgent information to their team. Product
managers would sit in your office to work out details of a new feature or bug
to be solved. But if it wasn’t urgent, they’d respect your need for focus.

------
dopeboy
I train new technical hires at Fortune 500 financial institutions so this
article struck a chord with me.

One of the key points that I leave my cohort with overlaps with the OP's point
about fresh perspectives. The hires I'm with are up to speed with the newest
languages, newest frameworks, and newest tools. I encourage them over and over
to try to bring that knowledge into their roles.

------
vegancap
This is an exciting read for me as I start as a Software Engineer at the BBC
on Monday!

~~~
ArbitraryString
Good luck with your job! What sort of languages/technologies will you be
working with?

------
lc94
What they don't mention is the abysmal salary (£23,000~) they start you on. No
idea why anyone would choose to work there.

~~~
josh602
I turned down a graduate contract in London for £30k, going up to £40k after
two years, to be at the BBC. If you want to work at BBC D&E, you accept that
you're not going to get a competitive salary. But in return, you get very
relaxed and laid back working conditions. (Or so people tell me. I haven't
worked at any other large software org to compare.)

Someone I know, who is now a principal dev, was previously a contractor for
the BBC. He decided to leave contracting and join the corporation permanently.
He's one of the most amazingly clever developers I have ever met.

(But yes, we'd all still appreciate it if we could be paid more.)

------
user5994461
Isn't the BBC a company where the only senior positions are as a contractor,
charging 3 times the amount of their permanent counterpart for much less
hassle?

I am not sure if the author is trying to write a nice PR piece or is so
inexperienced that he believes in all this corporate bullshit he's repeating.
^^

~~~
DRW_
I'm not the author, but I recently joined the BBC as a software engineer and
haven't found all that many contractors at all, the ones I have are in regular
non-senior positions.

It may be the case for 'talent' and management of TV projects (for example),
but in the tech departments - your assertion, in my experience seems to be far
from true.

~~~
isostatic
I've been here 14 years which is just about long enough to not be a newbie any
more. I now plenty of contractors, most are useless. After 5 years one of the
few good ones has taken a staff job.

We do seem to be getting better, the recent IR35 rules helped, but we still
have contractors employing contractors. At a high level they're typically
there to implement some bad idea and the fuck off so everyone can blame them
afterwards.

~~~
PoachedSausage
One of your major contractors are the organisation that runs the TV and radio
transmitters, Arqiva. An organisation absolutely bloated with middle
management and contractors employing subcontractors.

The BBC would have been better off keeping transmission in-house.

~~~
isostatic
Oh yes, we outsource many departments that used to be in house, from
transmitters to cleaning, I was referring to contractors working alongside
full time staff - usually because we don't pay staff enough to fill the roles
with the right people.

------
bjornlouser
"I wanted to make sure that my first job post-university would be somewhere
where I would feel happy and work not on my own, but with an agile team ..."

It's interesting that any young developer would regard the micromanagement
that comes with agile as a plus.

~~~
sudhirj
> micromanagement that comes with agile

It's a sad day when the ideas behind the agile movement have fully become the
Agile System (tm) in engineer consciousness. The word used to denote a style
of working, not characterised by micromanagement or by a Scrum Master (tm,
again) telling people what to do, but ironically by leaving behind dogma for a
loose collection of principles that worked effectively for the team and the
problem at hand. The word has been lost, though. Using the word 'agile' now
evokes more derision than enthusiasm or excitement.

~~~
ismail
Curious why would one think agile is micromanaging?

~~~
bitwize
Because Agile is seen as a set of processes, not a set of values. The new
hotness is time tracking -- making developers accountable at a micro-level for
how much time they spend at each step of developing a feature, enhancement, or
fix. All of which will have been specified in the beginning-of-sprint planning
meeting of course. Management likes this because to them it's like profiling
and optimizing a program. Developers hate it because the numbers are BS and
the planning is basically waterfall in miniature, giving them little
opportunity to explore the solution space. Plus the data collection itself is
panopticon-ish.

Agile was an attempt to sell basic (old school, think CSAIL not L0pht) hacking
strategies to stiff-necked managers and executives under the rubric of making
better software for cheaper. But managers and executives have their own set of
values: measurability and predictability, the more the better. Agile requires
you to let go of those a little, which Corporate America isn't willing to do.
So if you join a Scrum shop, you will likely see cod-Agile that goes through
the motions of Scrum while forgoing the principles of Agile -- under pressure
from the top.

~~~
ismail
Is this the case for every company doing scrum? I find some benefits in scrum:

1\. Having regular scheduled meetings reduces distractions. For example,
someone coming along to chat about something while you are in the zone.

2\. The important things get discussed with the right people in the room.
Decreasing assumptions

I think people tend to forget that the critical thing to get right with agile
or whatever methodology you are following is:

1\. It is #1 about conversations between people.

2\. The conversations between people help you explore the complexity.

3\. The conversations help you surface assumptions, get alignment on what
needs to be done

4\. It is not about 'tracking', but rather encouraging effective communication
to converge on the best path forward.

So question:

If you had to design a better agile process, what would that look like?

~~~
bitwize
> Is this the case for every company doing scrum? I find some benefits in
> scrum:

I find a lot of benefit in many agile methodologies _on paper_.

But where the rubber meets the road, the principal decision makers have a
vested interest in _not_ holding up the principles of agile.

> It is not about 'tracking', but rather encouraging effective communication
> to converge on the best path forward.

For any path forward, managers need to answer these questions:

* What needs to be done?

* How long will it take?

* Are we on track, behind or ahead of schedule? (This needs to be answered at least once a day.)

* What, exactly, are the pain points? (Again, once a day at least.)

These can be summarized in a Scrum standup, but what managers really want to
see is a detailed analysis. Hence the need for:

* Detailed task breakdown of each story/ticket

* Detailed time estimates on each task

* Detailed daily-at-least time logging on each task

So yes, it absolutely is about tracking. Tracking is _the_ central component
of any corporate software process. Tracking is what enables your manager to
get a picture of what currently needs to be done and how far along the team is
in getting it done. Inasmuch as agile processes can exist in this environment,
they must be reshaped to accommodate the tracking requirements. Which means
they won't be agile anymore.

Tracking also provides the benefit of an auditable paper trail, so that when
government regulators come sniffing around they have a nice log of who did
what when on the software.

In short, Agile has by and large failed. It does not adequately meet the needs
of upper and middle management of a corporate shop, for whom time is money and
there are strict accountability requirements.

------
rntksi
I was once a Jr Dev for the BBC too (back in the days). It was exactly as you
described. Extremely beneficial in terms of personal development due to the
culture it offered.

------
throwaway7645
Slightly off topic, but does anyone know if they still use Perl? I think the
BBC iPlayer used it.

~~~
rntksi
I do remember they used Perl for backend, and there was a resident Perl-guru.
I'm not sure with all the new Zend engine refactoring whether Perl still lives
inside the BBC ...

~~~
isostatic
The BBC is bigger than just the online devs. In news we still have a fair
amount of perl, mainly in Nagios checks and other bits of monitoring, but
pretty much any news package you see coming in from abroad, and many in the
UK, passes through a system with critical perl elements (JFE and davina). PHP
is more prevalent for more recent developments - Raven is PHp for example -
anything you see edited for the party conferences is recorded and edited on
Ravens, whenever you watch Asia Business Report every clip you see is played
out of Raven, as are the graphics running on the screens in the studios. The
lower third graphics on ABR are casparcg loading templates that are
ttraditional perl cgi (mainly just to insert various variables). The news
archiving system in bureaus has a perl front end, as does the web part of the
video production system. Our offline captioning system (webcap) is perl, and
the standard ubuntu build we use on c. 1200 machines has a lot of perl tweaks
to configure and monitor.

These are critical systems, but we don't have the resources of
online/fmt/digital/whatever, of all those systems only Raven gets any active
development (about 2 man months a year), we just don't have the manpower or
the time, so don't expect to find a job wanting perl though :)

~~~
throwaway7645
Thanks for the explanation!

------
nnain
Kinda ironic that BBC Desing and Engineering team would publish their blog on
Medium!

~~~
isostatic
Yes, especially given there's a proper BBC blog system
([http://www.bbc.co.uk/blogs/internet](http://www.bbc.co.uk/blogs/internet)).
I wonder if the poster had permission to post this, or if it's just a personal
blog. Hopefully he won't get in too much trouble if the latter.

~~~
josh602
We're trying out Medium as a blogging platform because it was seeming like the
BBC Internet Blog wasn't reaching our intended target audience any more.
Better to go where your readers are than expect them to come to you.

------
lostPoncho
Sorry to stray offtopic, but are remote junior dev jobs feasible?

~~~
p4lindromica
you need to be in the office as a junior dev because you don't know what you
don't know and you can learn a lot through osmosis

~~~
andkenneth
Learning by osmosis is just not a thing. You can't just smack a junior in the
middle of a team that doesn't effectively do remote, but a team with a good
remote culture should certainly have no issues with a junior being remote as
well.

~~~
p4lindromica
how does a junior dev know the difference when accepting a job offer? (aka you
don't know what you don't know)

------
dom96
Thanks for sharing.

In regards to the BBC however, and on behalf of my SO, I am curious how to get
your foot in the door as a script writer (or as something related to this).
Does anyone have any insights/tips/contacts that they would give to someone
interested in becoming a script writer for the BBC?

~~~
DanBC
[http://www.bbc.co.uk/writersroom/](http://www.bbc.co.uk/writersroom/)

~~~
dom96
I was hoping for something other than this. This is something that I am
already aware of.

~~~
jdietrich
Write, pitch, repeat. Working as a runner might help you network and
understand the industry, there are various mentorship schemes, but ultimately
nobody gives a shit unless you've got a great script. You don't need
permission from anyone to write a script and send it to a commissioner.

There's a mile-long queue of people who want to be a script writer, but a much
more exclusive club of people who actually write and pitch scripts regularly.
As the great Ronnie Coleman said, "everybody wants to be a body builder, but
ain't nobody wanna lift no heavy-ass weight".

------
jlebrech
I hope they fill their diversity quota and don't just hire people from the
huge white pool. because I want them to fail.

------
rokhayakebe
Going from Jr to Sr in an organization is "easy/ier." Making the same progress
as a freelancer/contractor is more difficult.

~~~
richardknop
Most contractors are senior devs from my experience. One reason to go
contracting is if you're a senior dev already and your career progression
seems stuck because you're at the top of salaried positions in your company
already. Going contracting is a way to get a pay rise for people like that.

~~~
nvarsj
Going contracting in IT in London is a way to get a pay rise for anyone. A
senior dev contractor will likely make more than a director or architect at
the same company. The whole situation is wacky.

~~~
richardknop
Yeah that's true. But to get really high daily rates you need to be senior dev
with decent amount of experience from my experience.

I agree the whole situation is a bit ridiculous. But when in majority of
companies salaries for developers are limited to something like 60-70k.

This has been slowly changing and there are more companies willing to pay up
to 90k but even then as contractor you can make equivalent of 120k or more
even after still taking 25 days off per year.

------
gaius
Didn't the BBC outsource all of their programming jobs to Siemens? I had a few
friends there who were TUPEd.

~~~
isostatic
No, they tried doing that - first into an external company (BBC Technology),
then in 2006ish they sold that off for something like £500m. Some programming
jobs went (Coledia, which was attempts to commercialise things like BNCS and
Jupiter), but the software jobs that were really close to the business like
the news website stayed in house. Since then things like iplayer were built in
house, and obviously R&D were never moved out.

Other technology that moved included areas like networks, most commodity IT
(domain controllers, file servers etc), and for some reason the main area that
looked after satellite bookings, routings etc (analog video distribution and
audio tag frames are fairly core broadcast technology). However the news area
that did this stayed in house, as did most of the desktop support in news (but
not elsewhere), and most of the broadcast support. Except in Glasgow where
pretty much everything was moved to Siemens.

It was a total mess, and it still is a bit of a mess. Many of the people who
were outsourced are still working for ATOS (who took over Siemens/SBS/SIS), in
fact I think they even kept the final salary pension which everyone else lost
a few years later. A few who had been moved out were moved back in too.

However that all seems to be changing again - I believe most of the Atos jobs
are moving from Bracknell to Eastern Europe as part of the new contract, and
the WAN connectivity which Atos held (through vodafone) has recently moved to
BT

~~~
gaius
_However that all seems to be changing again - I believe most of the Atos jobs
are moving from Bracknell to Eastern Europe as part of the new contract_

Yes, it was reported in El Reg that the BBC claim they have to lay off all
their UK tech people in order to afford to close the salary gap between their
already incredibly well paid on-air performers. Funny how _commercial_ they
can be when it suits them.

------
yeukhon
Curious any companies in the Us can self-proclaim having similar environments?
BBC only hires engineering in the UK

------
tweedledee
By grooming them?

