How We Grow Junior Developers at the BBC
medium.com
medium.com
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.
I have seen so many developers utterly fail at this. They require not just a particular language, but a particular framework and a certain specific mountain of abstractions. Any less that could remotely expose their incompetence is immediate cause for rebellion. Their strong arguments are whining and excuses instead of simply figuring it out.
I don't want to have to work at as a baby sitter if I am hired to be a senior developer. Some junior devs are a pleasure to work with and really bring appreciation to the job and others make me want to quit and go do something else.
I say junior devs, but I have also encountered some senior devs whom I would describe as junior.
I would actually rephrase this and go a step farther -- I have met many people who don't like to learn, full stop. They learn the minimal amount necessary to carve out safe, known territory, and do all the work they possibly can to NOT LEAVE THAT AREA.
This is obviously a great survival trait and may be good in some careers, but it's not a trait I'd like to see in a developer, especially one I fully intend to do my best in growing.
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.
When it was my chance to mentor, I would sit with the junior guy and just talk about the context and problem at hand. Talk about the keywords and then form a query to google. I would sometimes intentionally put in the wrong query and then refine it for better results. It worked.
But juniors are sometimes bad at retaining processes and a similar query would pop up in a few weeks again. Then I would just send them a lmgtfy link (which is a dick move. Don't do this). Have some compassion, patience and empathy. It might take longer but that guy will thank you in the long run.
I work with people who did things their own way for 10+ years, never worked as team, never kept up with a quickly changing industry, never improved their skills, that now they're opinionated, they feel that as long as something works it's good to go, etc.
Introducing them to a code review workflow exposed how truly uneducated they were. Code review turned into education sessions, explaining how fundamentally they've misunderstood or misused CSS, javascript, or the tools we use.
It's dramatic how much money and time is wasted because no one with authority to fire them wants to. Back when I ran my own studio I let people go the instant it became clear they weren't going to make it, but these people couldn't pass a simple interview with me.
My company sees it but keeps trying to find ways to solve the problem. You can't throw training at it, you can't throw more meetings.
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.
After three years, I'm interviewing and getting offers of about 60% salary increase.
From £32,200 -> £55,000.
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.
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.
I started doing it after I was 9 years in.
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.
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.
I just came to work and did what had to be done. After years I learned that there is much more and I don't have to fear things that are outside of my comfort zone.
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.
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.
Good point, I was simply saying that in my experience it's the people with "senior" in their job title who do this most often.
> many people come into an organization questioning why or how things are done.
I think Chesterton's fence is a very important concept for new engineers to learn. But sometimes it's still valuable to understand for yourself why that fence is there in the first place rather than just take someone's word for it. The best scenario is an opportunity for a senior to guide a junior in the exact why.
I'm using this line from now on. As a senior dev with a lot of experience I find myself often being the only one questioning the tear it down mentality. Everyone wants to write greenfield code, and instead of taking the time to understand why current code looks like it is a mess people just want to start over. IMO, no one sets out to make a mess. A mess occurs are compromises are made to add new functionality and catch corner cases. I'm also fine tearing down a fence only after someone can tell my why it was put there and why it can down be torn down (and also how it can be rebuilt in some improved manner).
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?
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.
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.
At my last performance review, when he dinged me for lacking knowledge expected of me in my role (one of the boxes in the evaluation form), I pointed out I was the one who had done most the documentation for our major applications.
His response:
"A senior developer shouldn't need documentation. The knowledge should be in your head."
What?! This guy isn't fit to be principal developer.
Sure, the knowledge should be in your head, but it should also be documented in case you get hit by a bus or go on vacation.
Does no one senior ever stop to think about business continuity? What happens when you onboard someone new? A senior developer is just supposed to drop all their work and get the new person up to speed for a month?
I find that companies with a bad documentation culture see it as a cost center ("this takes so much time") whereas companies with good documentation culture realize that even if it takes time, the benefits far outweigh the costs.
As you said, this should be part of the culture. Documentation should be seen as an artifact that is equally as important as the software deliverable itself.
Your management does not understand the value of good documentation.
Flip the industry:
"Well, airplanes are useful for transportation, but maintaining the documentation takes too much time. So we should skip writing the maintenance documentation and just let the mechanics figure it out themselves every time they need to replace a part" (assuming the plane doesn't fall apart mid-flight)
If you framed it as such, they would see that their counter-argument against documentation is silly. Now, they could argue that your software isn't life critical and people won't die if it fails, but personally I think that's beside the point. It's a business decision the aviation industry has made to document things thoroughly and it's paid off in spades for them.
Of course you have to invest time and effort into documentation, but you maintain it the same way you maintain your software or your tests.
It sounds like your management doesn't realize that although documentation has a visible cost (people's time) it also has many invisible savings: to quickly reference in emergency situations, employee illness/vacation/departure/onboarding, supporting legacy versions.
tl;dr - your management sees documentation as a cost center
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?
I live this life right now. No documentation, and the senior devs have left, so you just have to figure out what the hell they're thinking as best as you can with the code left behind, sometimes stepping through everything multiple times to see how the data flows through it. Thankfully one of the architects that used to work here knew how to make readable, modular code, so our newer projects aren't too bad to modify, but our legacy systems are awful nests of spaghetti.
That seems like something a Junior Dev should have mastered during their educational period.
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.
You're definitely taking the wrong impression from my post then. Do you code in C / C++?
If you've never had an issue compiling a large codebase as a new developer then I should either bow before your greatness or mock you for your inexperience because in large, complicated projects with 1000-line makefiles included from various sources, on a platform with various skews, flags and options, even the most talented developer can have issues with compilation - especially in most corporate scenarios where the exact command line you need for the internal build tool Steve wrote in 1996 is passed down through email and IM logs. OH and don't forget that some of the objects we link with are actually dummy files to be filled in by a shared library on the target that's been precompiled... OH and some of our functions are actually programmatically generated by a Perl script that runs as part of the build script. These are just some of the things I was exposed to as a junior at various companies.
Building gets messy, quick. Should it be? Probably not. Is it? Hell yes. Download boost or blender or something and try and compile for a non-standard or multiple platforms. My sibling even gives a specific open-source example (although open-source projects are typically MUCH better about getting building to be simple)
More importantly, my point is not that the junior doesn't know how to compile. Compilation is just a place where things get very messy very quickly, and a precise explanation of what was done needs to be given so that the senior can guide the junior along a proper debugging path. Your attitude is precisely the thing I'm recommending against.
> a file.
Whoever needs to only compile one file? That's not the hard part :)
You mention Enterprise development among other items. Making a shim or method for onboarding new devs is exactly a way for one to advance in Enterprise development. Therefore the Junior Dev should take this opportunity to learn the internal system and create a way to simplify its use for others. Not doing something like this is a trap that many Junior devs fall into, even when a Senior dev hangs the opportunity out in front of them.
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. Many times when you’re explaining it to me, you’ll realize the thing you thought you tried you actually didn’t.
Being your rubber ducky is more important than just telling you the answer (which I often don’t even know so I’m bringing you along to my thought process)
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 <pre> 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.
Perfect example! Often if you tell me “I tried to copy this and it didn’t work” I don’t know why. But if you show me how you copied and what exactly, things like this immediately pop up as possible clues.
I know it’s frustrating but it really does work on everyone. Half the time I show someone what I’m struggling with and I try to show them what I tried, the act of showing them reveals where I went wrong and I figure it out without them saying a word.
A lot of people don't listen to me, in a lot of different contexts in my life. I don't know whether other people experience this as much as I do or if there is something about me that informs that response in people, but it is a pattern in my life. I'm not so sure there is much to be done about it.
People are competitive and do foolish things because of it.
While I agree with you in spirit, in practice - in my experience at $BIGCORPs and $STARTUPs - this is very much standard operating procedure.
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.
This is so sad and frustrating. I get distracted easily too, but when someone is taking time to show and explain something to me, they have my full attention. Anything less is so disrespectful and just a waste of time.
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'.
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.
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.
Doesn't help if you have a desktop and no laptop. Plus there weren't many in White City last year when I was there - everything was co-opted to be a meeting room or office as they slowly closed off various sections for refittings.
Here's one of my favorite scenes, where Hugh Bonneville's character, the new Head of BBC Values, explores the BBC open floor plan for the first time:
https://www.youtube.com/watch?v=foG-O-_zbew&feature=youtu.be...
The new BBC headquarter's officeless workspaces are a running gag throughout the series. (Unfortunately, this video is evade-copyright-detection quality.)
I’m going to accept that i’m part of the problem and have them handle the keyboard from now on, as you and the others suggest. And have them airplay to a big monitor.
Thank you.
That is why you have them handle the keyboard while you decide what to type.
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.
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.)
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. ^^
Not really, no.
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.
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.
The BBC would have been better off keeping transmission in-house.
I know this as I worked for the BBC at the time.
https://www.out-law.com/en/topics/employment/business-sales-...
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.
It's interesting that any young developer would regard the micromanagement that comes with agile as a plus.
Also, for some (many) junior anythings some micromanagement is a good thing, especially for a college grad with little "real world" experience.
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.
As a C-level you want to know the roadmap for the next 12 months and waterfall gave you that. Agile can be a bit terrifying (ofc it shouldnt be), therefore certain people (SAFE, looking at you) have worked out how to make agile look like waterfall from above. Basically by building tiers of process and making the demon-scrummaster (rather than teams) all powerful.
The BBC is, as i understand it, a notorious example.
We have no scrum masters. We have a plurality of leadership in teams, comprising of a tech lead, one or more product managers, a project manager and maybe a senior UX designer. This works quite well for us. I've only been at the Beeb for a year, of course, but I wouldn't say I've generally felt micromanaged. In particular, the tech lead of my current team very clearly makes a conscious effort to ensure he takes a step back and allows the team to self-organise.
Dean Leffingwell is a charlatan and a snake oil salesman.
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.
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?
It would have a well-defined process and standards for proposing, testing, evaluating, and adopting process changes.
In fact, that's all it would have; you'd start with that and apply it to the combination of itself and your pre-existing dev process, whether or not that process claims to be “agile”.
If your process isn't centrally about continuously optimizing itself to business circumstances, tasks, and team personalities and skills, it's not agile.
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.
(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-...
There are people who suck at managing software development and people who suck less. Whether they call it agile or use some system or other has zero correlation with how toxic or effective they are.
This is heresy amongst my peers but I love to gaslight them by saying: there were plenty of high performing waterfall teams before anyone ever uttered agile.
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.
Amen to that. :'(
> "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:
Developers are almost never included in those stages. Your given designs that have already been completed. Then you "make them happen", you have no input in the designs because they have already been designed and signed off. They only care about the speed of implementation, not quality.
Agile means that requirements can be more easily changed from feedback in process.
Pictures = design and user experience documents.
Most product based companies I've worked for means, I actually have input into almost everything around the product. If I feel something is not a great design or is difficult to implement I can change that as I go along. Can't do that in waterfall
That's not been my experience. I've seen business analysts working closely with developers to scope out what's needed and find the the best way forward, before the coding is due to start. For all the the apparent negatives of waterfall, I've seen that it can work quite well, when it's used correctly.
Having approach that can tolerate that is essential.
I wouldn't last long under the micromanagement of being handed an architecture and software design by someone else, and being told to just churn it out.
Not sure that throwing a junior developer in the deep end with agile is always good idea
Putting patches in bugs fits in a 2 week cycle, taking months to do something right, does not.
I can teach people XP, Kanban, or scrum but I can’t teach them common sense.
The end (literally).
At a (much) later stage, there will be times to refactor. Carefully, and with limited scope that shows real value.
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 :)
https://medium.com/bbc-design-engineering/about
It has also been shared internally on a few slack BBC teams that I'm in, so it's all good.
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?
Except for that the only way is the "hard" way, requiring some luck, through things like writers room.
I don't think I ever saw a role like 'script writer' on the internal job sites.
Don't forget that a large amount of the production is out of house - through production companies of varying sizes.
What I loved about working there was the genuine passion for content and the audience that most people there had - good luck if they can get in.
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".
But, your question made me curious. It really does look like the link in the sibling post is as valid a link as you're going to get. I'd suggest your SO put the work in and make use of all the resources at that link.
Having said that, write and network. Certain jobs aren't acquired by the usual methods. There probably is no long interview and application process. Instead, your SO will have to do something to get noticed.
There are probably lots of ways to get noticed that involve luck. I'd not depend on luck. I'd make opportunities to get lucky, however.
I did find this link, it seems like a good link and the information passes the smell test. Here:
https://www.theguardian.com/careers/insiders-guide-to-becomi...
I think the networking idea is probably one of the biggest ways to get noticed. Join local writer's groups. Go to workshops. Get to know people. Instead of contacting them and saying, "Hey, I want a job!" Have them contact someone, probably having made some good contacts first, and say, "Hey, I really could use some advice."
I'd suspect that getting contacts is the first step. Do the research. Make use of the site they sibling post gave you. Do what they suggest, and then some. If there is an event for screenwriters, be there. If there is a pub they frequent, be there.
I'd not immediately pressure for a hire, or even to show samples. I'd listen, learn, ask as many questions as I could, and I'd make it a point to listen. People love to have an audience. So, when developing this network, be an active listener. Active listening is a very, very underrated skill to have. People love to talk, encourage them to do so. Pay attention to what they say. Ask good questions. Ask questions that invite them to share their knowledge. Most of all, truly listen and take their advice to heart.
Write... If you want to be a writer, write. Write a lot. Write all the time. Write about anything and everything. Write stuff that people will see, even if it is just forum posts. Write constantly and cover a wide variety of topics. Write about what you know, and use your writing as an excuse to learn more so that you can write about that.
Put yourself out there. Find people who will honestly give you advice. This means you're going to need people who understand both good writing and the subject matter. You can find those people online or in the real world. Friends and family shouldn't be your first choice. They aren't always able to be unbiased. Nobody likes to tell a loved one that they suck and their dream is hopeless because they have no skills.
If they do suck, that doesn't mean they can't learn - so keep at it. Keep writing, keep taking classes, keep going to creative writing groups, go to any writing group that will have you. Write ad copy for free. Find a website and edit their work and then send it to them.
Build up a portfolio. Even if it is just a blog, get your stuff out there. They want to see someone that can be prolific and good. They want to see someone who is capable of putting out consistently good work. They want to see someone who has motivation to complete projects.
So, write, write, write... Learn, learn, learn. Network until your schedule is so full that you barely have time to live a normal life.
And be ready for rejection. Be ready for a lot of rejection. Be ready to sacrifice your dream and be willing to write for a different company. When rejection happens, and it will, don't give up. When they reject one script, ask them why and then make the script into something that fixes those problems.
I'm sure scads of people also want to write for the BBC. They not only have to be better than the rest, they have to have more drive than the rest. They have to stand out and be noticed. They have to have someone who is rooting for them on the snide of the company. The BBC has to want then, make them want you. Make them aware that not taking you means that their competition will take you. Make them know that you're an asset that they don't want going to a different company. Make them know that you can solve a problem and fills niche that nobody else can fill better than you.
Some of this is covered in the link I gave you. I could go on but this is already long enough. If they want to work there, they are going to have to work at it. Use the resources available and be ready to work harder than your SObhas ever worked in their life,
NB: This is if you were defining junior/senior based on pay. Hard to tell from your comment if you were.
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.
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
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.