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.
Agreed. It is more about personality than anything else. If you want to learn and solve problems you will simply work at it until you figure it out.
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.
> 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.
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.
Exactly. I would rather take a first-semester web development student who shows those foundational bright spots than a 20-year developer who does this as a 9-to-5 job.
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.
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.
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.
Well, my mentor used to yell "RTFM, doood!". Which I did. And got the answer more than once.
I would like to agree that(as a sibling comment points out) this depends on his personality and relation to the team.
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.
One approach some people take is asking "how much time did you spend on this?", where if time is less than 15 minutes you can usually reject the question outright.
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.
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.
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.
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.
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.
Are you saying it took you 9 years of seeing other people know and learn things you weren't taught at the Uni before you realized you could look things up with Google?
No, I looked many things up and I learned, but it wasn't much and really unstructured.
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.
> 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 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.
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."
> "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.
Completely agree. On a side note, the one answer that I always get from management when I suggest that we should write more documentation is: "Well, writing documentation could be useful but maintaining it is hard. So I don't think it's a good idea".
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.
> "Well, writing documentation could be useful but maintaining it is hard. So I don't think it's a good idea"
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
Explaining Bus Factor can be helpful in getting their attention. "Sure, documentation is a cost center. You know what's a bigger cost center? Not having it."
Why, look at the senior developer's brilliant, perfectly intuitive code, and know everything about the system instantly, of course!
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's not an age or experience thing. People can be jerks at any age or level. Good engineers do not equate illiteracy of the codebase (unfamiliarity) with ineptitude. Good engineers educate without contempt. On the flip side, many people come into an organization questioning why or how things are done. Often, the current product is a ball of inperfection and compromises. Spend 2x more time reading the code than asking questions. Understand why a fence was put there before you tear it down.
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.
> Understand why a fence was put there before you tear it down.
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).
> 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. 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)
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 <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.
> The results are often surprising. For example, they've copied code from a blog which auto-formats <pre> contents
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.
That is not a senior developer, developer or even technology specific issue. You can experience immature egotistical indifference in any job. "Senior" developers who act like that are "senior" in title only.
>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.
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.
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.
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.
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.
> complain that Senior Developers don't believe some Junior hires have minimum competency if they are unable to compile a file.
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 misunderstand. It is not that I have never had issues with compilation or linkage, but that a Junior Dev should be able to learn how to perform the compilation, learning the vagaries of the architecture and build system.
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.
Wow, I’m considered a Senior Developer (only 30 years experience), and I’d say one if the biggest problems I deal with is getting code to compile. Large code base, “clever” code constructs left by long gone devs, and a language, that while usually great to work with, sometimes gives inscrutable compile error messages (Swift)
As other posters have said I recommend talking to them in person if possible. It's worked for me to just get in front of them because they're a lot less likely to think you're lying, and you can more quickly shut down the paths you've already went down if you do know your stuff about that method (and if you don't, it'll be clear to them and they can alleviate the issue).
Sure, probably good advice. I work remotely though, and more importantly I no longer feel I need to prove anything about what I know or what I'm capable of. I've pulled off a lot of shit. But I also don't have an attitude about it or think that makes me special, I just know what I can do.
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.
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.
> 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'.
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.
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.
> but there are quiet working areas that you can go to to work
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.
For a great self-deprecating parody of BBC Values, and modern office culture generally, I highly recommend the BBC series, W1A. It should be available on Netflix.
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:
The new BBC headquarter's officeless workspaces are a running gag throughout the series. (Unfortunately, this video is evade-copyright-detection quality.)
> 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
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.
Another angle we take to help limit lost interest is the pilot (user on keyboard) doesn't write code without the co-pilot (person sitting near by) audibly directing the flow/logic of code. Good learning/teaching while on both sides.
Because i’m really senior, which means i have trouble seeing what’s on their tiny, dirty laptop screen. But mostly i’m in a hurry to get back to actually doing stuff.
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.
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.
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.)
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. ^^
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.
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.
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.
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.
Well many parts of the BBC (tech wise) got outsourced/tuped circa 2003, saw lots of good people go and the whole of new media (web aspect) got decimated back then with cuts.
>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?
Digital do seem to have sorted this out, with clear job titles and stuff, at least for programmers, and tech jobs upto band 10. Elsewhere it's not so clear cut. Support have no way to progress past band 8 without going into a terrible management structure. Good engineers are rarely good managers.
"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.
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.
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.
agile only pisses me off when I see 'experience working in an agile environment' as a desired skill in a job posting. More of a buzzword than a principle.
Because its the common mistake large companies make when implementing agile.
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.
This isn't true in my experience. Each team I've come across has their own variant of Kanban that works for them that has evolved over time.
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.
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.
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.
> 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.
> 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.
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.
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.
I could, but W1A, a BBC sitcom does a much better job. Beyond that, we’re talking about criminally overpaid management which until relatively recently spent a few decades covering for the likes of Jimmy Saville. It’s the same management which still can’t quite figure how to deal with the realities of content delivery in 2017, because it might mean real change.
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.
> "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:
What your talking about matches my complaints exactly. I dont understand.
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
> "Developers are almost never included in those stages."
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.
I'm a relatively junior developer, and I work on a team that I would characterize as agile (though we don't use that word). I have broad latitude to write what I want to (with peer review of code, and peer + stakeholder review of RFCs), at whatever pace my manager and I agree is reasonable, to fulfill broad business goals.
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.
Agile or RAD done well can be very good but it does require more experience developers than say waterfall and the PM scrum leaders really need to know there stuff not just done a weeks course.
Not sure that throwing a junior developer in the deep end with agile is always good idea
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.
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 ...
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 :)
Yes, especially given there's a proper BBC blog system (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.
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.
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.
I have mixed feelings on this, it seems to me it is doable, but it requires 2 important things:
1. The Junior has worked remote before. If you get someone where this is their first remote job, unless they're incredibly organized and have a remote strategy they will lose socialization and much more.
2. A ton of work on the manager's part. Mentoring sessions, checkins, very active communication channels etc.
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?
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".
I was at the BBC for a few years. I can't talk for much other than Children's BBC, but there many of the people involved in that area of production had also worked in a range of roles in the BBC and migrated over to that position. Alternatively they had worked writing and creating outside of the BBC, possibly in passion projects but likely on other paying gigs - possibly with agencies. But generally they were people who were able to point to a large body of previous work.
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.
First, I have no idea how to answer your question. I did do some writing, but nothing famous and not scripts. I was a journalist to earn money while I was went to the university.
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:
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,
I disagree. I would struggle to get many senior dev roles in companies due to gaps in my knowledge (e.g. TDD, Agile or whatever PM style they use). As a freelancer/contractor however I can pick roles that only require skills I'm very good at and can therefore charge senior rates.
NB: This is if you were defining junior/senior based on pay. Hard to tell from your comment if you were.
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.
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.
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.
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
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.
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.