Need some advice - wet skills.

[Kilgore_Trout_Redux]

The story so far:

So I have been paired up with a junior/intermediate web front end developer to extend a product. (The product was written very badly by a third party.) They are doing any css and html and I am doing the javascript/backend development.

I knocked up the skeleton (Basic css/html) of the feature and gave it to him to flesh out and then fill in the contentm I am not a designer and my .css is pretty rusty so I was fully prepared for him to redo it. We are developing the new feature to be isolated so rverything is being written from scratch to prevent pollution from the old code base.

I proceeded to get along with getting the mechanics working and left junior to his own devices.

I was prett annoyed to find that when I came to plug in the back end stuff the html/css was completely unmaintainable. Most of what I had done was thrown out and replaced with stuff copy/pasted from the rest of the project which is sub par and we are trying to get away from. Class names are non descriptive or misleading because they are copied from elsewhere.

New stuff doesn't make logical sense. It is very much all just thrown together and shaken until it provides something that kind of works.

I am frustrated. This it the first time I have been given the mandate to manage another developer. I am trying to be supportive and mentoring but I can't find a nice way to tell them to throw it away and start again. They know that we are trying to do things neatly and well but they knowingly copy pasted from the rest of the project.

Also how can you teach neat and ordered thought process?

This stuff is hard.

 

[zippy]

Mentoring means you need to do more than just give him something. You have to teach him. Not tell him. Explain why what he did is incorrect. Dont get annoyed. Thats a sure way of failing. Remember, its not just your junior that is being sussed out. You are too. Obviously they want to see if you can manage/mentor someone. The whole point of them asking you to manage/mentor him is for you to show him/her the way. Letting them get on with their own devices is not mentoring/managing.

You cant teach thought process. Thats something the junior has to develop. Its called experience

There isnt really a nice way of telling someone that something they did is crap. But there is a nasty way. Don't be nasty. Don't be condescending. Don't talk down down to him. Just be straight and explain that the code need to be structured and they need to adhere to standards(did you tell him what the standards where ?).

 

[Cam]

I feel your pain. Also note though, with legacy code.. you should be just trying to make the **** work with the minimum amount of time. Any new stuff though, apply the current standards.

 

[rward]

You could try find a css methodology and use that as a guideline, something like the BEM perhaps?
http://bem.info (althought you probably want to scale it down a little )

 

[Hamster]

I have "senior devs" getting close to 40 still not grasping the concept of WTF a rollback script is important for a release. So I feels you man, I feels you.

 

[DominionZA]

Mentoring means you need to do more than just give him something. You have to teach him. Not tell him. Explain why what he did is incorrect. Dont get annoyed. Thats a sure way of failing. Remember, its not just your junior that is being sussed out. You are too. Obviously they want to see if you can manage/mentor someone. The whole point of them asking you to manage/mentor him is for you to show him/her the way. Letting them get on with their own devices is not mentoring/managing.

You cant teach thought process. Thats something the junior has to develop. Its called experience

There isnt really a nice way of telling someone that something they did is crap. But there is a nasty way. Don't be nasty. Don't be condescending. Don't talk down down to him. Just be straight and explain that the code need to be structured and they need to adhere to standards(did you tell him what the standards where ?).

This^^

I have space reserved at my desk for my guys. Before they merge into the develop branch, they put their branch into review. I check out the code, and if good they get a green light to merge.
Otherwise they come sit at my desk and I explain where they went wrong - even if it works. They all know I will only explain once though. I get annoyed with repeated offences - and then I show it. First time is completely forgivable though - as long as they learn from it.
Thankfully, it is rare that we have to go through the same explanation more than once. Got a great team.

 

[scudsucker]

and left junior to his own devices.

1st mistake.

You should have been reviewing everything he did, preferably with him, but in any case, scrutinising his commits (you do use some form of source control, I hope)

That way you catch his mistakes early and you get a chance to get him to fix them early.

 

[Kilgore_Trout_Redux]

1st mistake.

You should have been reviewing everything he did, preferably with him, but in any case, scrutinising his commits (you do use some form of source control, I hope)

That way you catch his mistakes early and you get a chance to get him to fix them early.

This was pretty much the first code review.

What frustrates me most is that he is the first person to complain about how hard the old codebase is to maintain and when given the mandate to make a clean break and do it right copy pastes the old code. Then tells me that he didn't despite all evidence to the contrary. It is just shoddy.

Anyway. A new week I will try to be more patient.

 

[me_]

Welcome to the world of a senior dev. When you get a new junior, you need to realistically allow an hour per day to sit with the dev, check what they've done and give them guidance. Don't let them go a whole week and only review what they've done then.
It gets a lot more stressful when you have multiple juniors assigned to you and you realise that it would be quicker to just do everything yourself, but that's the whole point of being a senior dev - to train juniors so that eventually they can add more value than what they take away, but it takes time.

 

[_kabal_]

Yah, letting this go a week is unforgivable.

 

[Kilgore_Trout_Redux]

Thank you for all the advice and constructive criticism. I will definitely make a few changes to the way I do thing to make sure I don't make another pigs ear of it in future.

 

[Beachless]

I have "senior devs" getting close to 40 still not grasping the concept of WTF a rollback script is important for a release. So I feels you man, I feels you.

Rollback is for hamsters who like running in circles.

But I have seen some cool stuffs like devs working straight on prod in huge systems its crazy out there.

 

[Beachless]

If you are tasked with mentoring then you need to spend some time each day reviewing the juniors code. I like just asking questions like why did you name it that so as to avoid criticism as they normally start looking for excuses then you can just say thats OK just improve it for the next review. Also remember to work the mentoring into the project schedule otherwise you will be spending your own time trying to catch up on work.

 

[Hamster]

Rollback is for hamsters who like to keep PROD from going down.

FTFY