Live data from Hacker News

How We Grow Junior Developers at the BBC

medium.com

51–60 of 166 posts

Re: How We Grow Junior Developers at the BBC

#51

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

Agile, like waterfall, is only as good as it’s implementers. At my workplace we had lots of lingering bugs because the entire project had been poorly architected. We pushed to refactor and our scrum masters looked at us like we were crazy. Putting patches in bugs fits in a 2 week cycle, taking months to do something right, does not.

Programmers having to beg glorified administrative assistants for permission to refactor code is why I’m inches from quitting this agile coaching bit to do a startup or something.

I can teach people XP, Kanban, or scrum but I can’t teach them common sense.

Re: How We Grow Junior Developers at the BBC

#52
post #45
post #15

Earlier quoted context omitted.

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.

> Literally anything is better than that. Amen to that. :'(

I’ll take your waterfall agency and raise you a government IT shop pretending to be agile.

Re: How We Grow Junior Developers at the BBC

#53
post #18
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?

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.

Re: How We Grow Junior Developers at the BBC

#54
post #47

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…

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

Re: How We Grow Junior Developers at the BBC

#55
post #43

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…

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

Re: How We Grow Junior Developers at the BBC

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

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.

Re: How We Grow Junior Developers at the BBC

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

They also lose all ego and eventually become beings of pure energy.

People are competitive and do foolish things because of it.

Re: How We Grow Junior Developers at the BBC

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

Yeah I often try to double check things like that before asking for help. Other wise there are too often silly things wrong like config settings not pointing to the db I think they are. But still end up with egg on my face far to often.

Re: How We Grow Junior Developers at the BBC

#60

Earlier quoted context omitted.

Agile, like waterfall, is only as good as it’s implementers. At my workplace we had lots of lingering bugs because the entire project had been poorly architected. We pushed to refactor and our scrum masters looked at us like we were crazy. Putting patches in bugs fits in a 2 week cycle, taking months to do something right, does not.

Programmers having to beg glorified administrative assistants for permission to refactor code is why I’m inches from quitting this agile coaching bit to do a startup or something. I can teach people XP, Kanban, or scrum but I can’t teach them common sense.

If you want to start a startup so you can have clean code constantly refactored, you will join many others shocked that customers don’t care (not directly, and pretty much never at startup stage). In the mean time, someone else with the idea moves quicker and has all your customers.

The end (literally).

At a (much) later stage, there will be times to refactor. Carefully, and with limited scope that shows real value.

Post reply on HN