April 6, 2015 at 7:09 am
xsevensinzx (4/5/2015)
It's way too expensive for most companies to do that. It has too much risks in some cases. Even if you do take it on, the team has to be fully committed to making it happen.I just so happened to respond to a stack question from a junior developer who was struggling in her environment because senior developers were not helping her or the other juniors on the team. She was only 2 years into the career and it was in the video game industry where she specifically didn't aim to join, but was recruited specifically off LinkedIn.com.
In her case, which is something I've experienced in my long history working on large-scale video game development, she would receive so much push back from the senior devs. She started out asking for help. It got her nowhere. Now she is keeping to herself trying to do the best she can. She has given up on the system and doesn't know what to do.
In cases like that, both leadership and the team have to help the juniors. If not everyone is on board, especially the team, you have cases like hers. It's bad for the team, bad for the product and bad for the business on all ends.
Which if you ask me, is a real shame, especially in her case. Seniors who choose to ignore the help of the team are pretty much just adding to the problem.
I'd argue that the it's way too expensive for a company to hire multiple (or even one) junior programmers and NOT have some sort of mentoring program in place. The only excuse for not having senior programmers mentor the juniors is a lack of senior programmers. The team mentioned above is setting itself up for failure. Leaving the juniors out to dry allows them to produce suboptimal code and will end up with the team producing a poor product that the senior devs will have to fix (and fixing stupid programming errors is not what most people enjoy about programming). There's definitely a management issue at that company and probably a lot of other issues as well.
The young lady would be well advised to start looking for a better company to work for.
April 6, 2015 at 7:34 am
Brian Hibbert (4/6/2015)
xsevensinzx (4/5/2015)
It's way too expensive for most companies to do that. It has too much risks in some cases. Even if you do take it on, the team has to be fully committed to making it happen.I just so happened to respond to a stack question from a junior developer who was struggling in her environment because senior developers were not helping her or the other juniors on the team. She was only 2 years into the career and it was in the video game industry where she specifically didn't aim to join, but was recruited specifically off LinkedIn.com.
In her case, which is something I've experienced in my long history working on large-scale video game development, she would receive so much push back from the senior devs. She started out asking for help. It got her nowhere. Now she is keeping to herself trying to do the best she can. She has given up on the system and doesn't know what to do.
In cases like that, both leadership and the team have to help the juniors. If not everyone is on board, especially the team, you have cases like hers. It's bad for the team, bad for the product and bad for the business on all ends.
Which if you ask me, is a real shame, especially in her case. Seniors who choose to ignore the help of the team are pretty much just adding to the problem.
I'd argue that the it's way too expensive for a company to hire multiple (or even one) junior programmers and NOT have some sort of mentoring program in place. The only excuse for not having senior programmers mentor the juniors is a lack of senior programmers. The team mentioned above is setting itself up for failure. Leaving the juniors out to dry allows them to produce suboptimal code and will end up with the team producing a poor product that the senior devs will have to fix (and fixing stupid programming errors is not what most people enjoy about programming). There's definitely a management issue at that company and probably a lot of other issues as well.
The young lady would be well advised to start looking for a better company to work for.
Indeed. It was surprising to me to see even a few seniors agreed with the mentality that they shouldn't be bothered as much or it's not really their problem.
For example, many of the seniors who responded said that most of the time, it's easy questions the junior should have researched more in depth before asking. They are essentially wasting the senior's time as opposed to quote-on-quote, Googling it.
Others seemed to have the mindset that it's more on the leads plate to handle. That identifying the issues is not really up to them. That's why management is there. It's their responsibility.
However, I feel that it's still their responsibility to address and help. Even if the questions are simple, someone has to raise the issue to see what's going on and address it with the juniors so they can continue their growth. Pushing back on it only drives the juniors to hit further roadblocks that only increase the risks on the project that really shouldn't be there such as sloppy code, delays in the project, low moral and more.
April 6, 2015 at 8:21 am
Brian Hibbert (4/6/2015)
The young lady would be well advised to start looking for a better company to work for.
I would love to have someone to mentor. I enjoy teaching and sharing knowledge, but in almost every job that I've had I've been the only DBA and sometimes only programmer. My boss assigned a co-worker to back me up on my current project, but he's not really interested in doing advanced database, so he'll be more my backup for the sysadmin needs for the project. That's fine, as far as it goes, and it's a role that I need. But what I love about teaching in-house is I have a person that I can bounce ideas off of in person, there are so many times that you solve your own problem by explaining it to someone that I might need a bigint to cover it. 😀
xsevensinzx, what I think is sad is that the seniors aren't just failing to mentor a junior, they're failing to mentor a woman, and we need all the women in IT that we can get. I know that game studios are a very different environment, still.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
April 6, 2015 at 8:47 am
Wayne West (4/6/2015)
xsevensinzx, what I think is sad is that the seniors aren't just failing to mentor a junior, they're failing to mentor a woman, and we need all the women in IT that we can get. I know that game studios are a very different environment, still.
Not only that, a woman programmer in the video game industry, which is even more rare. I don't think I've ever encountered a woman programmer in the video game industry.
April 7, 2015 at 3:11 am
...
Indeed. It was surprising to me to see even a few seniors agreed with the mentality that they shouldn't be bothered as much or it's not really their problem.
For example, many of the seniors who responded said that most of the time, it's easy questions the junior should have researched more in depth before asking. They are essentially wasting the senior's time as opposed to quote-on-quote, Googling it.
Others seemed to have the mindset that it's more on the leads plate to handle. That identifying the issues is not really up to them. That's why management is there. It's their responsibility.
However, I feel that it's still their responsibility to address and help. Even if the questions are simple, someone has to raise the issue to see what's going on and address it with the juniors so they can continue their growth. Pushing back on it only drives the juniors to hit further roadblocks that only increase the risks on the project that really shouldn't be there such as sloppy code, delays in the project, low moral and more.
Well, there is certainly a balance. I've been in with developers who seem to just formulate questions, disturbing the floor, that if you just type them into google you get the answer straight up. You can deal with that a bit but it soon becomes very tiresome. Developers do need independence.
However more often there is a lack of willingness to help, which reflects very badly on the unwilling. I have spent a lot of time trying to foster an atmosphere of mutual respect and learning from each other - an hour's help, a constructive review or just discussion of pros and cons of approaches here or there can really make a difference to someone trying to do the best they can. If you cannot provide that for your juniors you deserve all the failure you will inevitably get. And yes, this attitude does seem to come down from management.
April 7, 2015 at 6:21 am
call.copse (4/7/2015)
...
Indeed. It was surprising to me to see even a few seniors agreed with the mentality that they shouldn't be bothered as much or it's not really their problem.
For example, many of the seniors who responded said that most of the time, it's easy questions the junior should have researched more in depth before asking. They are essentially wasting the senior's time as opposed to quote-on-quote, Googling it.
Others seemed to have the mindset that it's more on the leads plate to handle. That identifying the issues is not really up to them. That's why management is there. It's their responsibility.
However, I feel that it's still their responsibility to address and help. Even if the questions are simple, someone has to raise the issue to see what's going on and address it with the juniors so they can continue their growth. Pushing back on it only drives the juniors to hit further roadblocks that only increase the risks on the project that really shouldn't be there such as sloppy code, delays in the project, low moral and more.
Well, there is certainly a balance. I've been in with developers who seem to just formulate questions, disturbing the floor, that if you just type them into google you get the answer straight up. You can deal with that a bit but it soon becomes very tiresome. Developers do need independence.
However more often there is a lack of willingness to help, which reflects very badly on the unwilling. I have spent a lot of time trying to foster an atmosphere of mutual respect and learning from each other - an hour's help, a constructive review or just discussion of pros and cons of approaches here or there can really make a difference to someone trying to do the best they can. If you cannot provide that for your juniors you deserve all the failure you will inevitably get. And yes, this attitude does seem to come down from management.
Years ago I found a simple solution, if a developer or junior came to with no evidence of having tried to think for themselves then my answer was blunt. They learnt that even a minimal amount of effort on their behalf they could gain my help. I treated everyone the same and made it clear what my policy was, and management knew, so any whining from the lazy didnt get anywhere. Worked in the long run:cool:
Teach a person to fish ......
April 7, 2015 at 9:29 am
Brian Hibbert (4/6/2015)
I'd argue that the it's way too expensive for a company to hire multiple (or even one) junior programmers and NOT have some sort of mentoring program in place.
I'd agree. Even if you only had one programmer/DBA, hire a consultant for an hour a month to mentor them and check their work.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
April 7, 2015 at 10:01 am
xsevensinzx (4/5/2015)
...Seniors who choose to ignore the help of the team are pretty much just adding to the problem.
...and ignoring their responsibilities. Those who don't should have it pointed out that they have to have seniority over something to be a "Senior" otherwise what is the point. With seniority comes responsibility.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 7, 2015 at 10:04 am
Yet Another DBA (4/7/2015)
...Years ago I found a simple solution, if a developer or junior came to with no evidence of having tried to think for themselves then my answer was blunt. They learnt that even a minimal amount of effort on their behalf they could gain my help...
That is how I work too. If you see my responses on the forums here (I am most active on the PowerShell forum) you will see a pattern of asking posters to supply a query or an issue not a task specification.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 31, 2018 at 2:27 am
I work in a company with over 800 employees. we have well over 50 developers.
Our company takes a slightly novel approach to apprentices.
In the UK we have a new certification called a T-level (technology level) - students from 17-18 years old have to work for us for 2 days a week for an entire year in order to gain practical enterprise level experience. They are paired with a senior developer in order to ensure that they gain strong solid practical abilities such as normalisation, OOP, etc …
we have 12 of these students (plus 2 work experience kids)
We seek to gain Zero commercial gain from this, we contribute back to the community... but we also see it as a year long interview!! - at the end of the process we know what skillsets they have and we take them on as "developer" - not as an apprentice
Each student will set up an Azure environment from scratch (so they see the operations side of things), build a prototype and each month give a 5 minute "show and tell" of a technology they think the business could use
I think it's genuinely a great approach to apprentices… even if we don't take them on we will give them a reference and they have a big name on their CV.
MVDBA
October 31, 2018 at 3:23 am
I like MVDBA's example. And although I agree with the comment above from Gary Varga about juniors thinking for themselves, the way the seniors treat them is key to either dispiriting them or encouraging them: it is a skill to balance 'I told you before' with 'Let's ensure you get this (even if it takes more than once!)'.
And this was posted 30th March 2015 not 20th - just sayin'.
October 31, 2018 at 6:32 am
Reading the editorial and the assorted comments, my thoughts are that providing some sort of mentorship or apprenticeship to new hires would be a very good thing for just about any organization (that has more than none of a given role.)
In my mind, the ideal situation would be, *every* new hire, regardless of experience in the industry, goes into the apprenticeship role, but not just as a way to ensure they know how to write good code or the like, but also for the mentor to show and explain the hows and whys of the business itself. Again, ideally, the business would also identify those employees who would make *good* mentors, rather than just tossing the role to the most senior staff or the grumpy old "didya google it before you came to bother me" type.
It would be up to the mentor and the apprentice to determine (possibly with a guideline checklist) whether the apprentice was ready to "spread their wings and fly" on their own. This way, the new hire who's been banging out code since they got their first TI99 4/A might only be an "apprentice" for a couple weeks (long enough to know where to find documentation and the coffee) while the fresh out of college hire might be an "apprentice" for a couple months. And yes, the person who's been coding forever could still be hired and have the title of "Senior Developer" with all the pay and perks, in this sort of system "apprentice" is a very flexible term. Additionally, there'd have to be some sort of "review" process, some way to get the "apprentice" to start moving out from under that tag.
Obviously, being able to do something like that would be very dependent on staffing and workload, but I honestly think in the companies that could find a way to do it, it would pay off in spades in the long-term. New hires wouldn't be getting thrown into the deep end of the pool with a 5lb weight and told "sink or swim," but instead would be handed the weight and put in the shallow-end of the pool with a trainer, and given the opportunity to move to the deep end as fast as they want.
October 31, 2018 at 7:19 am
jasona.work - Wednesday, October 31, 2018 6:32 AMSince they got their first TI99 4/A
You are showing your age... I had one of those
MVDBA
October 31, 2018 at 8:06 am
MVDBA - Wednesday, October 31, 2018 7:19 AMjasona.work - Wednesday, October 31, 2018 6:32 AMSince they got their first TI99 4/AYou are showing your age... I had one of those
Heh
First home PC for the family and the school I was going to got themselves a quartet of them and set them up in their new "computer lab" (also known as the supply closet in the front office)
October 31, 2018 at 12:56 pm
Brian Hibbert - Monday, April 6, 2015 7:09 AMI'd argue that the it's way too expensive for a company to hire multiple (or even one) junior programmers and NOT have some sort of mentoring program in place. The only excuse for not having senior programmers mentor the juniors is a lack of senior programmers. The team mentioned above is setting itself up for failure. Leaving the juniors out to dry allows them to produce suboptimal code and will end up with the team producing a poor product that the senior devs will have to fix (and fixing stupid programming errors is not what most people enjoy about programming). There's definitely a management issue at that company and probably a lot of other issues as well. The young lady would be well advised to start looking for a better company to work for.
I once worked at a company which had been doing massive hiring for quite awhile but almost everyone hired was fresh out of school. At a company meeting we were told that there was going to be another spate of hiring so I inquired about what skill/experience levels we would be hiring and was told it would be more entry level people. I said, "Don't you think we have enough of those?" He got indignant and said how he prefers hiring new people because experienced programmers always want to do things their way whereas with new people we can train them to do things our way. I replied, "That's true. But who's going to train them?"
Viewing 15 posts - 31 through 45 (of 47 total)
You must be logged in to reply to this topic. Login to reply