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.<p>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.<p>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.<p>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.<p>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.<p>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.
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.<p>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.
It somehow always saddens me to read that.<p>Most devs I know started at a small company who didn't "grew" them at all.<p>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.<p>Who already has is given.
> I worked in an all-senior team once. Nobody admitted not understanding something. Everyone wrote overly-complex code just to 1-up each other<p>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.
Lots of good stuff in this, but i have a couple of significant nits.<p>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.<p>But otherwise paired programming is just a great way to slow me down.<p>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.
I train new technical hires at Fortune 500 financial institutions so this article struck a chord with me.<p>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.
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?<p>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 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 ..."<p>It's interesting that any young developer would regard the micromanagement that comes with agile as a plus.
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.
Thanks for sharing.<p>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?