We had an apprentice join our team in late 2017, this is the first time an apprentice has been given a rotation in the Software Development Team so it's a new concept to everyone. For the purposes of the question I’ll call him Dave.

Despite being fresh out of A-Levels and having no previous experience in Software Development, he has picked things up so quickly and rarely asks for help from anyone.

The issue is that my other colleagues don't seem to see what I am seeing, Dave is doing things that even some of the Senior members of staff can't do. There's been occasions where someone has struggled with a problem and he's offered to assist and is never taken up on the offer. He's came to me and explained and the solution he had to the problem was pretty good.

On occasion I've even said, "Have you asked Dave, as he's just completed a course in that?" and it'll be blatantly ignored, and they'll proceed to ask another team member who equally has no clue in the subject. On the rare occasion he's able to interject into the conversation, he fixes the problem and often does it very quickly.

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.

How do I get this across to the team? Dave has developed multiple programs that are being used in live since starting but people don't seem to take him seriously.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – user44108
    Commented Aug 16, 2018 at 6:12

12 Answers 12


When I started my apprenticeship as a software developer, I was in a similar situation. Although I had no qualifications "on paper", I had a lot of private experience with software development. Just nobody believed me. So what I did was ask the most respected senior developer on the team what he was working on and if I could take a look. I then spent the next day analyzing the sourcecode looking for the worst part I could find. Then I approached him and asked:

Hey [senior developer]. I've looked at your sourcecode and there is one thing I don't understand. What's the reason why you didn't use [more efficient solution] here? I am sure there is a good reason why you used [inefficient solution]. But I don't know this technology as well as you do. So I would really like to know why you did that.

Now, he did of course not have a reason to do it the inefficient way. The efficient way simply didn't occur to him. That moment he understood that I am far more capable than my job title would say, but the way I showed him was submissive and unconfrontational, so he did not perceive me as an obnoxious know-it-all either.

Five years later, I got his position.*

*no, don't worry. I did not bully him away. He got an even better paying job offer somewhere else.

One thing you should teach Dave about is the importance of visibility in the workplace. People might underestimate him because they are not aware of his talents and just judge him by his job title.

Things you might want to encourage him to do:

  • Hold presentations in front of the team. Conceal it as an exercise to test presentation skills.
  • Look for internal projects which are of interest for management.
  • Solve long-standing problems everyone is afraid of tackling.
  • 66
    I see this is the accepted answer, but I would like to highlight that this approach is very risky, imho: I am an intermediate-level developer, and if a person who is fresh out of A-Levels and having no previous experience in Software Development comes to my source code and says "why didn't you think of this?" with an obvious, more efficient solution, I would feel like he is amazingly condescendant. And I would feel stupid, of course. Maybe I am oversensitive, but OP's colleagues could be as well. Commented Aug 14, 2018 at 8:14
  • 4
    @SimoneChelo I tried to make it clear in my answer, but maybe I didn't bring it across as well as I could. The idea is to phrase the improvement suggestion as a question with the assumption that the senior is smarter than oneself and that one wants to learn from them. When this is brought across well, it should not feel condescending for the receiver.
    – Philipp
    Commented Aug 14, 2018 at 9:15
  • 6
    It is clear as you state that a smart senior should recognise when someone wants to prove himself (your aim) and when someone is an insufferable know-it-all. I just want to address that not everyone is a smart senior, and could take this approach the bad way. Commented Aug 14, 2018 at 10:12
  • 5
    @SimoneChelo The approach also runs the risk of the developer having a reason it's done that way and you may undermine your current position. Heck, they could even cop-out and say it's under-engineered because it was done under a deadline when they didn't have time to just pour over source code looking for a better way.
    – Centimane
    Commented Aug 14, 2018 at 11:00
  • 14
    This solution is pretty much the logic, "go beat up the toughest looking guy in the prison yard". The dev could be really understanding, but it'll likely comes across as sarcastic and very know-it-all.
    – Tom
    Commented Aug 14, 2018 at 12:31

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 so 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.

  • 6
    On the "making your team aware" front, my team has this pattern of having members who have just spent time learning something new (maybe over a formal course, maybe not) give a short presentation of what they learned. This helps the team to as a whole to be aware of new tech as well as gauge how much the learner knows about that tech.
    – muru
    Commented Aug 14, 2018 at 2:09

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...

  • I work on completely different stuff hence why I try and help how I can but I’m pretty limited, but I really don’t think they expected he would be as good as he is.
    – andtodd
    Commented Aug 13, 2018 at 7:36
  • 3
    I like this, maybe you could mention the Ego/reputation of the senior members being affected. They don't want to be demoralised by an apprentice
    – Twyxz
    Commented Aug 13, 2018 at 7:37
  • 1
    That would be my first intuition as well. Look for instances where they hide information to keep it as competitive advantage.
    – Puzzled
    Commented Aug 13, 2018 at 15:51

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 complimentented1!

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.

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

  • Speak for yourself. My method is working hard to stay ahead of the kids, and freely sharing my knowledge. And when they come up with something improved, I congratulate them and gained some more knowledge myself.
    – gnasher729
    Commented Aug 13, 2018 at 22:22
  • 1
    Haha I did speak for myself, I've encountered this a few times now :) And I'm not saying all programmers are like this, but "In general" i find this to be true
    – Martijn
    Commented Aug 14, 2018 at 6:59
  • I agree with @gnasher729 I have over 10 years industry experience and although the type of programmer you describe most certainly does exist from my experience they are in the minority. To me and my team if we do not stay ahead of the curve we risk becoming obsolete. It also makes it more difficult to get a new job if you have no experience of newer technologies. As a team we push change when we can to better ourselves so that we do not become stagnant. I am all for knowledge sharing even if someone is in their first week. I will sanity check it before allowing it to be shared with the team.
    – kenjara
    Commented Aug 14, 2018 at 12:09
  • I must say, I'm glad I'm getting oppossed with this answer. It's better for everyone to switch routine every once in a while: "that's how we always work" is the enemy of innovation. I've tried to update my answer accoridingly :)
    – Martijn
    Commented Aug 14, 2018 at 12:32

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."

  • The thing is, as a junior dev, we may think we are right, we may even know we are right, but it's difficult to assert to someone more senior that they need to do "X in this way and Y in another way to accomplish Z" - if the junior is incorrect in this instance it will not look good on them. It's wise to assume you may be wrong, even if you know you're not, especially when talking to a senior.
    – ESR
    Commented Aug 14, 2018 at 4:47
  • I've been Dave. The thing which really helped me was someone who also knew the job, to say "I haven't got time [to help you] right now, but I know Dave can do this; you should ask him. Dave, can you foo a bar with Gertrude for a minute?". Eventually Gertrude learned to bring her bars to me. Commented Aug 14, 2018 at 6:23

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).

  • "Oh, hey Dave. You're really great at your job and we really love having you around... I think you should work somewhere else."
    – dvniel
    Commented Aug 15, 2018 at 9:12
  • 1
    When you listen to Dave but the rest doesn't, for whatever reason, then yes. I would be enough of an adult to tell someone, that I like working with, that the rest of the office is being childish and he (Dave) should probably find a place where he fits in. I, personally, would also take offense at what the rest was doing and find myself another place to do my thing, as such an "exclusive" and "I'm better than you because <reason>" environment doesn't sound like the place I would stick around.
    – rkeet
    Commented Aug 15, 2018 at 9:57
  • 1
    I think you could be even more explicit in this answer: that the best result for Dave is a position with a firm whose culture can make use of his talents, and that facilitating him staying here is actually doing him a disservice. It's possible he can eventually win these people over, but this kind of strictly hierarchical and close-minded environment is very toxic (the skills fossilization if nothing else), and all that energy he'd spend just trying to get listened to is energy better spent doing valuable work in an environment that supports his development.
    – Tiercelet
    Commented Aug 15, 2018 at 18:43

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.

  • He is on a temporary contract due to his apprenticeship. If a vacancy becomes available, I have no doubt that he would get the post.
    – andtodd
    Commented Aug 13, 2018 at 15:32
  • 1
    @andtodd so he's an intern. Basically, if he's contributing regularly he's already over performing. Talk to your boss about promoting him because of that.
    – user53651
    Commented Aug 13, 2018 at 15:36
  • 1
    The company wont work like that, he must complete his apprenticeship and can only apply for a role if one becomes available. There are a number of reasons, including budgetary as an apprentice wage is less than 1/3 of the developer role, never mind the senior. They’ll want him to finish the apprenticeship as he’s also cheaper labour.
    – andtodd
    Commented Aug 13, 2018 at 15:42
  • 1
    @andtodd Make a case anyway, or write a strong letter of recommendation for him. Outside of that you can only really assign him more important tickets.
    – user53651
    Commented Aug 13, 2018 at 15:43
  • 2
    @andtodd maybe you can help push to make it easier/faster for him to get a real position? We don't know how much patience he has, but also quite approachable and un-arrogant peoples' patience can run out. Especially if he is a silent kind of person his frustrations maybe don't show so easily. Commented Aug 13, 2018 at 15:53

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.


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.")



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.

  • I'm not sure what you're trying to say - "don't overrestimate the new guy"? Whereas your own tale is about people underestimating you?
    – Rup
    Commented Aug 15, 2018 at 11:11
  • And there is some truth to the old "knowing where to put it" fable: you can fix software performance, correctness, reliability etc. problems with the right small change.
    – Rup
    Commented Aug 15, 2018 at 11:12
  • 2
    This anecdotal answer doesn't seem to address the question at hand. Can you please edit it so that it does?
    – user44108
    Commented Aug 15, 2018 at 13:15
  • @Rup I don't know how technical you are (I won't bother to check your profile page), but if you're a good engineer, to be able to improve performance, correctness, reliability, etc of a solution, you have to have the base. In most software, that means the codebase. When talking about software packages, the tools included. Exactly where did I improve from? ENR was started from scratch, just C & no other library. ENR uses no external support programs either. If you're talking about improving methodology, well, I'm fine not having improved them much.
    – Dehbop
    Commented Aug 15, 2018 at 14:17
  • 1
    "If those programs are no more than many hundreds to thousands LOC, then I doubt what he's solved is a commendable problem." The heck? What kind of software environment do you live in where all your "commendable problems" require 10,000 lines of code to solve?!
    – Kevin
    Commented Jan 3, 2019 at 21:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .