Live data from Hacker News

How We Grow Junior Developers at the BBC

medium.com

91–100 of 166 posts

Re: How We Grow Junior Developers at the BBC

#91
post #88

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.

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.

Re: How We Grow Junior Developers at the BBC

#92
post #54
post #47

Earlier quoted context omitted.

>Many don't actually read the questions you ask of them or trust your knowledge I think the issue could be that you're using written communication. It can be a difficult way to get help. Can you sit down and talk with these seniors?

Also, not implying this is the case but often I see junior developers saying they've done X but have to double check if they overlooked something or mangled with something from Y and Z after repeated attemps.

I have had a junior dev claim that someone must have changed their code overnight. I decided that there were a couple more possibilities before going down that route of inquiry.

Re: How We Grow Junior Developers at the BBC

#93
post #91
post #88

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.

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 st…

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.

Re: How We Grow Junior Developers at the BBC

#94

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. ^^

> charging 3 times the amount of their permanent counterpart

As one of these people (but not at BBC), I would rephrase this. BBC offers contractors 3 times the amount, and contractors graciously accept it.

Re: How We Grow Junior Developers at the BBC

#95
post #53
post #18

Earlier quoted context omitted.

Curious why would one think agile is micromanaging?

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. Develo…

Well said. The panopticon is spot on. Worked at places like that where each JIRA ticket feels like a timed coding exercise with a negative immediate consequence if it takes too muvh time. Result: most tasks are completed on time, stats look brilliant, hacks upon hacks, burnout, no cohesive design.

Re: How We Grow Junior Developers at the BBC

#96
post #32

> 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.

> 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 se…

Yes, I work with people who do this sort of thing to me a lot. They are younger than me, though.

Re: How We Grow Junior Developers at the BBC

#98
post #10

"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.

> 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…

Mmm, this line of thinking makes it impossible to critique though. Anything you don't like is just the official, bad system. Real agile is just the good parts!! You see what I mean.

Re: How We Grow Junior Developers at the BBC

#99
post #43

Earlier quoted context omitted.

> 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 h…

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.

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.

Re: How We Grow Junior Developers at the BBC

#100
post #76

Earlier quoted context omitted.

> 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 se…

> Did you try X?" > "Uh yes I did" (then to be polite I repeat my explanation of doing X) As somebody who often does this, it’s because 8 times out of 10 it works. Magically when you try again and go meticulously through the steps with someone watching, they work even though they didn’t before. I don’t know why but it works on me too. I’m not being condescending, I’m trying to be your rubber ducky. Because it works.…

It's still frustrating to be at the receiving end of this. It's infuriating when this is the response after spending hours or days researching, then trying and retrying various things, being meticulous in recording every step involved.

I've been on Stack* for a while now, and generally take people at their word when they say they've done X. The results are often surprising. For example, they've copied code from a blog which auto-formats

 contents, replacing hyphens with en dashes. You'd only notice if your font makes this noticeable or by running the actual code.

One reason it would be OK to ask someone to try X again is if they haven't included enough information for anyone to replicate the issue. However, the better response in these cases is usually to ask for supplementary information until it can be reproduced.

Post reply on HN