mjhjmtu

As a software developer, I've been in both your position and Dave's. In software development teams that have worked together for a long time, each colleague starts to develop an idea of who is the 'go-to' for knowledge on a particular project or system (especially if it's something to esoteric that StackOverflow can't help!). It's great that Dave is well-qualified and picking up things quickly, but in cases where time might be against them, a colleague may simply seek out the one they know for certain has experience with the bit they were stuck on. This does not just apply to apprentices or junior developers. In one job, despite having two senior developers above me, my colleagues would ask me questions about C# problems just because I was the 'C# guy'. I had to make it clear to them over time that others knew enough about it too.

One solution could be to make your team more aware of what Dave has been working on (not simply just the achievements). It sounds as if your colleague did not know or had to be reminded that Dave took a relevant course in something. It may also be worthwhile asking to Dave to, for example, shadow a colleague on a JavaScript task after he completed a JavaScript course. This will help Dave make more of a name for himself among the team and it will also make your colleagues more confident that he is more than merely book-smart, and therefore more likely to ask for his help when the time comes. This can even be demonstrated by giving Dave the chance to work on a high-profile or important task (if you feel he is ready).

The more Dave integrates with the team, the more they will come to acknowledge and depend on his knowledge. As Dave is given more chances to demonstrate knowledge that can only come from working with your development team, the more likely it is he will be sought out for advice.

Quite simply, they either see Dave as a threat to their position, or they are too egotistical to accept help from someone "below" them on the corporate ladder, most likely both.

I've seen this occur too many times where people let their ego get in the way of development and in their heads simply cannot fathom someone who's on a lower pay-grade than them can write solutions to their problems and reason better than they can. I have no doubt that if they treat Dave this way then they will definitely be scheming behind his back, and yours, on how to deal with this "problem" that has arisen; an apprentice outclassing all the "senior members" already there.

This is what may happen; if you keep on defending Dave (which is a good thing, and highly commendable), these staff which are scornful of Dave will start to turn on you, and before you know it, and you'll be ostracised along with Dave. The fact that you don't understand that these staff members are not recognising his achievements, then you are not in their "circle" and don't understand their scheming ways.

Edit; what can be done: best thing for Dave to do right now is just keep his head down and focus on only his tasks and not try to help anyone there unless they explicitly ask him for help (which most likely will not happen, no one there's going to go ask the "apprentice" for help, because of their ego). Do this for as long as he needs to to acquire enough skills (qualifications perhaps?) in order to apply for a new role at a different company as a developer. At least from this situation I hope you'll let Dave know that unless he is of a certain "rank" in a companies' "circle", his help is practically meaningless and will fall on deaf ears. Hopefully Dave never actually becomes a part of this "circle".

It would be worth speaking to Dave's manager and/or the Development Team Manager (if they're different people) specifically on this subject, and not just in casual conversation.

With the Dev Team Manager you should highlight this issue that you've seen and suggest that they look for opportunities not just for him to grow and contribute, but for him to take actual named responsibility for something. He'll be much harder to inadvertently sideline of he's the go-to on a particular technology or has a position of responsibility in a project. This also has the benefit of being very good next-step learning for him.

With his own manager it can be in the form of feedback for his next appraisal and perhaps even a recommendation of promotion / title bump / pay rise / bonus / re-thinking his career development opportunities in light of his exceptional progress.

You should also offer to mentor him if nobody else is.

If appropriate you could also offer / request for him to join you with some of your work as a way for him to cross-train, gain broader experience, contribute where he's appreciated, and get wider exposure.

Maybe some people in the team don't want a bright apprentice.
What should the boss think if the apprentice does some things better than the so called experienced team members? And probably the apprentice is paid a fraction of what the experts get.

It seems the apprentice is too good for that team. They want someone who is not good and does not learn fast. They want someone who asks the experts and who does not have good ideas which the experts don't have.

I guess you have the choice to be on the side of the team or on the side of the apprentice and against the team...

Give it time

Though there are plenty programmers who try to stay ahead of the game by adopting new techniques, in my experience I've concluded that, in general:
Programmers who've never/not for a while experienced new input like status quo.

They're not fond of new techniques/programs/methods/... they know how the current ones behave and what quircks they have. Switching to, say, a new programming style could take quite some effort and IMO even more effort from the older people. And now imagine some random new guy saying it. And he's getting all this praise for it too, where they maintain a balance which never gets complimentented¹!

I don't like using clichés, but this is a situation where 'respect' has to be earned. First show he's a team playing, a bit more passive aproach. After a while he will appear competent, even without showing code. After a bit, if he has his own tasks, he could throw in a "hey, I've written this snippet, I'd like your thoughs about it". That way he can show his level and at the same time learn how the rest of the company works (all new ideas sound great, but are they a fit?).

After some time, the status quo will include him. In my experience the more you push change, the more you get pushback. Find the flow, join it, influence it.

¹ Might be incorrect, but it explains the emotion a bit.

This answer is based on my experience as an apprentice.

Fresh out of school with A-Levels I got a position as an apprentice in a multinational consulting company, we went through an initial training period most of which did not expand significantly upon my already existing self-taught knowledge. But what this did provide was access to mentors whose role it was to provide guidance, answer technical and conceptual questions, and whose influence provided major benefit to my growth.

Upon being launched into the main company I was put in the 'innovation' team, there were lots of exciting things being developed which we could only have cursory participation in due to our needing to progress through the 'training program' & apprenticeship coursework.

Whilst there I entered into discussions with the head of a department about onboarding, and was assigned by them the task of developing an onboarding app prototype. I found a few apprentices to run this with on the side and everything was going well.

After a period of developing this during my evenings I realised that I was likely missing certain knowledge which would improve the development process, technical information regarding technologies of the time such as Angular, which the innovation team were making use of on a daily basis. I approached the lead engineer on the team for advice, was told he would not put aside any time for me as I had yet to finish the coursework (which I had no interest in, I would rather be coding), and was subsequently interviewed by him about how I was assigned this project rather than the team as a whole, he did not understand why a head of a department would choose me to run this and wanted to claim ownership of it.

This significantly demoralised me, I continued without guidance on the development but did not know how to process this situation or to seek help from elsewhere. Around this time I was going through a breakup with a longtime partner, this combined with being away from home and having little emotional support meant I started arriving late to work (despite always leaving last). A week or two of this, a missed medical appointment (I started using my existing condition as a crutch to explain away my late arrivals), I was pulled into a HR meeting by myself and given the option of being fired on the spot or signing my resignation letter, I wrote my resignation email in the interview room as I felt I had no other choice and was gone before lunch.

My manager, the team, the head of the other department, no-one know this HR action was being taken against me, the HR figure that did this to me was let go shortly afterwards.

In short, if possible try to protect him, bring his situation to the awareness of the higher ups and shine a light on his potential within the organisation in a role outside of the apprenticeship itself, explain to him the bureaucracy and how to exist within it, whilst guiding him towards mentors and being mindful of his situation, he is likely full of optimism and courage, but there is a fine line being tread between thrilling challenge and being left to wither within a corporation without support or nurturing of his talents.

You and Dave should be more direct in your offering of help.

Dave is surrounded by senior software engineers. Telling them "I know something" is easily ignored (maybe out of pride, maybe because they honestly don't see how Dave might help them). Telling them "You need to use X in this way and Y in another way to accomplish Z" is very concrete, proves his knowledge and makes it hard to dismiss.

The same applies to you. Asking a senior engineer "have you asked Dave" can be understood as

• "Take Dave under your wing and try solving the problem together" - which may not seem very reasonable


• "Have you tried randomly asking your colleagues for help?" - which he did, he just randomly asked another colleague


• "I know that Dave knows how to help you"

Instead tell them "Dave mentioned that he knows a solution to your problem."

Why is Dave still a junior if he can outdo Senior staff and pick up on things quickly? The only way I see to force this is to make Dave a Senior or Mid-level dev and assign bug tickets - assuming you're using scrum or kanban - to him.

Other than that, you just need to improve his reputation with things that actually matter; achievements, not standard grades in standard courses.

While I agree with pretty much all answers already here with the following pieces of advice:

• Give it time


• 'Respect' is earned over time


• Make him medior/senior


• Assign bigger/more complex tasks


• Get Dave to do pair-programming with the others/seniors

I think something is missing. In your question you mention that you've already been trying this and that:

I've already tried explaining to everyone how good he is and the achievements he has made in such a short space of time, to no avail. He really wants to make a good impression to help kick-start his career but finds it hard that he has not been listened to.

There's 2 things that stand out, 1 of which becomes a question:

1. "[...] kick-start his career but finds it hard that he has not been listened to"


2. You've been trying to explain - How long has this been going on?

If this is "pretty long" (fill that amount in yourself, you're the best judge in the situation), I come to this advice:

Tell him to find a job elsewhere.

I mean this in the best-case for Dave. If you've been trying the above and have probably tried most of the advice/answers to your question here, tell him to just leave. Software developers are in short supply, being somewhere where you're not listened to sucks. Ok ok, you listen, but "the rest" doesn't, that sucks.

Anyway, that's what I'd do if I had an intern become a not-so-much-intern anymore and have this happen. I would also tell him to put me down as a reference and to no longer apply for intern jobs; junior minimum (based on amount of time in jobs, managers tend to get their knickers in a twist over "too" young mediors/seniors).

Dave could use the Ben Franklin effect...it sounds like he is kind of on the bad side of it right now.

The idea is that we like to believe that we are fair, so if we do someone a favor we subconsciously rationalize that they must be a good person who deserved a favor, and conversely if we do someone harm (even by accident) we try to rationalize that they somehow deserved to be harmed.

Pitfalls to watch out for: If you ask for too many favors, or too large of favors, that doesn't work. If you preemptively do things in return, it doesn't work. And if a neutral third party asks for favors on your behalf, it doesn't work (and may be detrimental).

It seems like you and Dave have been falling into categories two and three. Dave's large backlog of favors that he has done for others leave them feeling like they owe him, which actually makes him less popular. And your cheering him on as a third party makes him less popular.

If Dave, on the other hand, asks to be shown or taught something, the person showing/teaching will 1) feel good about Dave because they did him a favor, 2) feel good about themselves because they had knowledge that was useful, and 3) maybe think Dave is smart, if he asks good questions and learns quickly.

Unfortunately Dave isn't here, but my advice to you is to stop cheerleading Dave quite so loudly--that is, stop bringing Dave up any time someone needs help. If Dave does help you, then that's OK to mention, or if Dave does really good on a solo project--but at roughly the same level you would mention any other teammate.

Instead, try to get Dave to talk to other team mates as an apprentice, instead of as a teacher. For example, there's always domain specific knowledge that isn't available in written resources. If Dave runs into any problems like that, you can point him to a colleague who is both knowledgeable and likely to be flattered by him asking questions. ("You should ask Sally and Bob--they worked on this originally and know all of the picky details about why certain things are the way they are.")

https://en.wikipedia.org/wiki/Ben_Franklin_effect#Uses

There's more to being a senior developer or a team leader than programming skill, there's communication, accountability, and responsibility for starters as a senior dev you're responsible for more and are more of a go to person(s) for... everything, you don't get to pick and choose usually.

Then there's architecture / design patterns, I've had folks on some of my teams who can solve most technical problems (some I've failed at), but the moment you ask them to design something is a WTF moment to put it nicely.

So what should Dave do? Make a big deal of the problems he solves, demonstrate an understanding, rather than stating "it's done" ( which is synonymous with "it was simple"), show an understanding of the system, and produce code with minimal bugs.

What should you do? Encourage Dave to explain his problem solving to the rest of the team. Also, if he's picked up the skills he feels he needs, you should encourage him to apply for a non-apprentice position there or elsewhere.

It's always been the plan that I should just convince the top people in the industry -- CEOs, CTOs, academics, top-level consultants, heads of government sectors needing advanced techn, and more or less let the know-nothings say what they wanna say. Then I'd have a startup and when I start earning money (a lot of it), that should speak loudly for itself.

But things have changed from then. Excessive ridicule had worn away my and my product's credibility. At first, I was very, very opposed to having my work be shown in public, but I eased up a when I found it countered those false rumors of what my work is about. With how quickly I eased up, I didn't even realized that it bothered me that much that my capability was questioned.

Right now, there's even a good chance that I will lose and that will take out the deterrent. The people I've angered would then do everything in their power to stop me from launching my startup.

About those programs "David" wrote. If those programs are no more than many hundreds to thousands LOC, then I doubt what he's solved a commendable problem. And to disappoint you, it's either I write sizable software (ENR still being the biggest) as products or small wrappers for Unix tools and such. I don't bother with small program prompting you to enter values through the CLI, doing minor things.

I have a folder of my solutions to combinatronic problems -- permutation, combinations, solved with small functions. The functions' corresponding test C files are the only small programs that I have. At the very start of this journey, I thought I was gonna need those functions. Didn't turn out to be that way. Well, it had to be written down anyways.