Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Grow Junior Developers at the BBC

medium.com

Post reply on HN
Print view View original

81–90 of 166 posts

Re: How We Grow Junior Developers at the BBC

#81

Post by ZenoArrow »

UK-AL wrote: post #15
bjornlouser wrote: post #8

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

He worked at a waterfall digital agency. Literally anything is better than that. The description of working a digital agency matches mine exactly. Your given pictures and told to make it work as fast as possible. With no input into the actual experience.

> "He worked at a waterfall digital agency."

> "Your given pictures and told to make it work as fast as possible. With no input into the actual experience."

That's not what waterfall is. That's almost the exact opposite of what waterfall is. The general idea behind waterfall is that you do most of the UX design planning before a developer gets to work on it. If you're "given pictures and told to make it work as fast as possible" that is not waterfall.

Look at the graph found in this Wikipedia page, and note how the 'Requirements' and 'Design' stages are either started or completed before 'Implementation' commences:

https://en.m.wikipedia.org/wiki/Waterfall_model

Re: How We Grow Junior Developers at the BBC

#83

Post by dasmoth »

ismail wrote: post #18
sudhirj wrote: post #10

Earlier quoted context omitted.

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

Curious why would one think agile is micromanaging?

Curious why would one think agile is micromanaging?

(At least in the case of Scrum): because some of the most vocal advocates say so[1]! The premise seems to be that fine-grained oversight is less objectionable if it comes from “the team” rather than a manager, and that model does seem to work for some. It still kills the opportunity to work autonomously for any non-trivial interval of time.

[1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...

Re: How We Grow Junior Developers at the BBC

#84

Post by dba7dba »

klenwell wrote: post #66
spaceseaman wrote: post #33

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…

Ha. I can relate. At my last gig, it wasn't the seniors developers (well, it was some of them, too). It was the principal developer. As my supervisor, he told me, a senior developer, I asked too many questions. "A senior developer shouldn't need to ask questions." My questions usually weren't even technical questions but rather questions meant to clarify business specs so that we could make better technical decisions…

> "A senior developer shouldn't need documentation. The knowledge should be in your head."

So a senior developer shouldn't document, and shouldn't answer questions (since he said one shouldn't ask questions)?

What's a junior dev to do when there is no documentation and no one to ask for help/clarification?

Re: How We Grow Junior Developers at the BBC

#85

Post by andkenneth »

p4lindromica wrote: post #82
lostPoncho wrote: post #78

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

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

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.

Re: How We Grow Junior Developers at the BBC

#87

Post by meheleventyone »

sheepmullet wrote: post #56
spaceseaman wrote: post #33

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…

Why do you think it is a trust/respect issue? The fastest way I can get up to speed is by speaking directly with you and getting you to walk me through what you have tried.

Then it's a communication issue, the hypothetical senior isn't explaining why they are trying the same thing again. Which is missing an opportunity to teach something and improve the working relationship.

Re: How We Grow Junior Developers at the BBC

#88

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

Re: How We Grow Junior Developers at the BBC

#89

Post by yxhuvud »

valuearb wrote: post #36

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

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

That is why you have them handle the keyboard while you decide what to type.

Re: How We Grow Junior Developers at the BBC

#90

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

Post reply on HN