121–130 of 166 posts
Kinda ironic that BBC Desing and Engineering team would publish their blog on Medium!
Sorry to stray offtopic, but are remote junior dev jobs feasible?
Didn't the BBC outsource all of their programming jobs to Siemens? I had a few friends there who were TUPEd.
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 nev…
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.
Earlier quoted context omitted.
> "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…
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.
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
Earlier quoted context omitted.
> 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.…
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 blo…
contentsPerfect 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.
Lots of good stuff in this, but i have a couple of significant nits. First, paired programming is a great way to help a junior learn. But it’s dependent upon their desire, i do it frequently with one whose eyes glaze over when i explain what i’m doing and i know when they start surfing the web while i’m implementing. But otherwise paired programming is just a great way to slow me down. Secondly, the open floor plan t…
Why would you physically do the typing if you're a senior engineer pairing with a more junior developer?
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.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
Yes, I work with people who do this sort of thing to me a lot. They are younger than me, though.
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).
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.
Earlier quoted context omitted.
> Senior developers mentor, simplify, document, and admit when they don't know the answers. Sadly this is far from my experience as well. It's likely a few toxic work environments. Not to hijack your comment but I would like to offer a specific example I've seen of toxic behavior from senior developers. Many don't actually read the questions you ask of them or trust your knowledge. It's very similar to attitudes I se…
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 ask…
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).
Kinda ironic that BBC Desing and Engineering team would publish their blog on Medium!
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.
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.