The Workplace Asked by JimmyTheOne on September 9, 2020
For the last ten years, I have worked as the only senior developer in a team of 4-5 developers within a larger organisation, supporting a range of corporate systems.
Within the first couple of years, the other developers all moved on, but I stayed as I enjoy the work, the systems, and the customers. Since then however, our team has experienced significant turnover, partly because of the use of contractors, but mostly because none of the developers hired to permanent positions stay more than 6-12 months.
Many of these developers have exhibited poor coding and/or language skills, an inability to solve problems independently (despite our extensive technical documentation, which has been praised by several of the better contractors), and an inability or unwilligness to engage with the business domain of the applications we support. We have no business analysts or QA staff, so it is up to developers to engage with all facets of the software lifecycle from requirements to implementation, which seems to be a major stumbling block for many developers.
As the only senior developer and system expert, I have attempted to mentor them all and to work with them on project work (under excessively-strict deadlines). More often than not, they have left the team and I have ended up being told by management to fix or rewrite their code (always under pressure because their bad code has been released to production against my objections and broken our systems).
Despite being always polite (if sometimes overly direct), helpful, and as friendly as possible given how much pressure I am under in my role, I am starting to get a reputation as a grumpy senior developer that is constantly picking on other people’s work. I do my best not to nitpick, but I also cannot afford to let incorrect code slip through code reviews. My team leader, although verbally supportive of my approach, rubber-stamps everything that is presented to them, which makes me look even more critical of other people’s work.
Now I have a new manager who really wants me to emphasise the mentoring aspects of my role. They have just hired an allegedly experienced developer, who so far has struggled to complete the most basic tasks in a timely fashion or with any degree of correctness or attention to detail. For example, on a simple bug fix, they produced code that did not meet requirements, did not actually work, was in the wrong layer of the application, had typos, ignored the recommendations or suggestions I made in code reviews, and required six code reviews to get to a finished state.
I am expected to mentor this developer and work with them on a project over the next few months. How can I work productively with this developer and show myself to be a good mentor?
I am a senior developer and train graduates and apprentices as developers, so I am familiar with people not knowing much.
You say your new manager has asked you to emphasise the mentoring aspect of the role. You can only do that if you have an understanding of who they hire, both in a technical as well as a personality sense.
My suggestion is to express a far greater interest into the hiring process. Talk to your new manager and tell them that you'd like to be included in interviews. Look at your company's job listings and make sure that the skills listed there are relevant to the position and that they make sense. Feed this back to your manager, who is likely going to be the hiring manager here (but be careful, they might have written it).
If that doesn't work, you will have to figure out first what the people you're given already know. This is always tricky. Keep in mind that most of them will be well-meaning and might not know that they're not very good (if they are not). And it might not be their fault that they're there now, and are not meeting your expectations. If your organisation does not pay market value for example, they will not hire top talent, so you will have to work with what you get.
You should be open and approachable to new hires, make them feel welcome, safe, and encourage them to seek your help. Take some time (yes, I know, deadlines, but this has an ROI) and pair-program with them through their first ticket. Chose a small task that does not require much business knowledge for that. Let them fix a bug that's already diagnosed, for example. Let them drive, sit back and explain proprietary things and business logic on the way, but observe their approach, their technical savvy and how they solve problems.
Keep in mind that different people work in different ways. It can look like someone is slow if they don't use keyboard shortcuts, or if you are used to doing everything in the terminal and they like an IDE. But at the end of the day these things don't matter.
You want to see if they understand what's going on, and if they can figure out how to solve a problem. Don't make up your mind too early, and don't judge. They are at a new job, working with a product they have never seen before, in a new code base that is scary and full of intimidating things that will make them feel like an impostor and they have an experienced person sitting next to them. They will want to impress, and it's naturally that they're stressed. Give them time, and be supportive.
About Pair Programming
In order to facilitate pair programming, you have different options. Remember that you are onboarding someone new, so they will expect that you know the ropes, and they'll be glad about any help they can get. On average a senior developer takes about 3 to 6 months to be fully productive, so it's OK to want to look for guidance in the beginning.
The easiest way is to just offer it to them.
Hey, you got your first ticket assigned. I've got some time this afternoon, so if you want we can sit down together and I can walk you through our ticket workflow and help you get started.
Always try to make it sound like an offer, but not like they will owe you after. You're there to help, and it's safe to ask you things.
You can also check in regularly. Again, try to sound friendly and like you're just trying to help.
How is that ticket going? I know our codebase can be a bit overwhelming at the start. Let me know if you need any help. I'm happy to pair up with you as well.
Alternatively, you can just go and do it. Even if that's not the current company culture, they don't know that yet, because they're new. This is your chance to shape a new culture. If you push this onto new hires, and they enjoy it, they'll embrace it and carry it forward, and the next hire will experience it as normal.
During your pair programming sessions, try and be a passive source of feedback. These people are supposedly experienced, so don't tell them what to do. Instead, your presence should be reassuring. You're there to help, but not to judge. Point out oddities in the repository structure or give anecdotes about why stuff is the way it is as they move along the code, but don't take over the keyboard or mouse. That's probably the most important lesson for mentoring there is. Never take over the keyboard or mouse. That's intimidating and makes them feel inferior or not good enough.
When they are making a mistake, wait for a bit before you point it out. Let them compile and see what's going on. Give them a chance to catch the problem themselves before you intervene (unless maybe it's a missing semicolon).
Watch your language. Don't use expressions like "just do this" or "you could have simply done this instead". That trivialises the problem, although it was probably hard for them to solve. Instead say things like "oh by the way, there is an easier way to do x. Do you want me to show you?".
Finally, don't make the sessions too long. It's hard to concentrate for a long period of time, but it's even harder to do that when someone is watching you. I notice myself getting bored when I'm watching someone for more than an hour, and I lose interest, especially if it's slow going. Allow for breaks, and see how the other person is feeling. If you think concentration is going down, suggest a coffee break. In fact, I often offer to go and get beverages when I'm the one watching.
While we're all working from home during Corona (in the UK in my case), I run a one hour session twice a week with them sharing their screens and video turned on both ways with each of my trainees. They're beginners, and we never did working from home before, so initially I focused a lot on explaining that this is not so I can control that they're working, but that it's so they have a chance to get direct, live feedback. They've all embraced it and are looking forward to the sessions. Sometimes they ask for more of them, too.
Pairing is a powerful mentoring tool, even if all you're doing is helping another senior person out. We can all learn from each other, and we never stop learning.
Correct answer by simbabque on September 9, 2020
My team leader, although verbally supportive of my approach, rubber-stamps everything that is presented to them, which makes me look even more critical of other people's work.
More code. More defects. Regardless of how careful one is. Maybe the business leaders really want that rubber stamped stuff in production today, even if it's not perfect.
As the only senior developer and system expert, I have attempted to mentor them all and to work with them on project work (under excessively-strict deadlines). More often than not, they have left the team and I have ended up being told by management to fix or rewrite their code (always under pressure because their bad code has been released to production against my objections and broken our systems).
Kind of crazy that you are basically doing everyone's job for them without any additional compensation or promotion. Saying, 'yes' to everything without hesitation may not be in your best interest since currently the slacker/underperforming/unprofessional co-workers are being paid for the work you are doing. Let's turn your frown into a smile: I would ask about getting a bonus for rush jobs. Yes, some companies do pay you nice piles of cash for doing emergency work/maybe spending all day on a holiday weekend churning out something amazing. This is probably more likely to happen if, from their POV, you have some kind of life that doesn't normally allow you to work 18 hour days every day of the week.
How can I work productively with this developer and show myself to be a good mentor?
I think you have already shown yourself to be a good mentor by not going postal (figuratively speaking) over the ridiculous work environment and tons of time you've had to waste telling someone the same thing over and over again. And you've obviously been leading by example.
You should eliminate the emotional tude you are showing the lower level co-workers at work about this. It's not going to help anything but I do get how you feel 100%.
Answered by HenryM on September 9, 2020
I think you are in tricky situation. Having folks who are inexperienced or simply don't care about their work is a problem for sure. Getting more involved in hiring and mentoring the new hires are certainly constructive things to do. You could also get them excited about the domain itself, so they feel more motivation, and ownership. But there's only so much you can solve with these two tools. If the hiring pipeline has just so many options you'll do as good as the hiring manager themselves.
What sort of engineering practices you follow / not follow: agile (Any version), TDD, CI/CD, code reviews, etc? These tend to help, and especially teams that are struggling. If there's a strict policy of tests passing before a code review, it's hard to justify sending a PR for review which doesn't compile. As a senior engineer you can push and justify some of these changes. But you won't be able to win all fights. And 10 years is long enough so you know which fights are winnable and which are not.
OTOH, the problem might be deeper. Working in these sorts of teams, gluing one corporate system to another, adding reports for various legal requirements, adding an interface so that folks can do $thing, is not everyone's cup of tea. I'd wager the majority's. It keeps the corporation running, and can be devilishly complex, but with such a hot IT market in many cities around the globe, so many exciting startups to join before they crash and burn, I imagine it's really hard to find good folks for this team.
I'd take the whole situation as a signal to find another gig. As the saying goes, you don't want to be the best in the band. I'm not advocating excessive careerism here, just a bit of active career management. At the end of the day, there is a real risk of letting your skills become numb, and not being able to find another job when (not if) this one's gonna go away.
Answered by Horia Coman on September 9, 2020
Old Nick's comment about pair-programming is very true.
But aside from that:
Do not teach anything before you know how much of the underlying basics are missing. So whenever you want to teach a (new?) thing, ask lots of questions first. Tell them in advance that you will ask them lots of questions, some of them very silly, some difficult (so they will not feel irritated).
Then check the basics, and if necessary the basics of the basics. Do so in a good-natured way, and if they do not know an answer, do not yet invest time in explaining the right answer (but give a small indication if an answer they gave is wrong). Instead ask some question that are more basic, until you found the point they understand and are familiar with.
[Edit: Bonus points if you can ask them a question that makes them realize an answer they just gave cannot be true and lets them understand the right answer. That does give the feeling of "Oh, I understood! I enjoy this!" instead of "Oh, I was wrong again. I hate this!".]
I had used this problem a lot when giving private math-lessons. The problem at hand was something like "They want to understand derivations", but the underlying lack of understanding was often down to the basics of multiplication. Students will not tell you that this is a problem (out of shame, or because they do not realize, or, in your case, because they fear losing their job). But there is no point in spending an hour teaching how to derive a function when the student is spending this hour trying to hide the fact that they do not even understand what you are doing when multiplying an "x".
So: first step: do regular fun-little-quizzes to find out what your developers do understand. Let them explain those things. Take their knowledge up a step, and give them exercises to make sure they internalized that new knowledge. Give them (and yourself) regular breaks - even if that means they are doing some unnecessary manual work in between.
You mentioned that you are under tight deadlines. But be happy when you can leave at the end of the day having taught something that they now understand, instead of having spend hours trying to teach a thing they "must" know.
Answered by JW at Flavia on September 9, 2020
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP