11 ms·

At work we have a consultant in at the moment doing technical mentoring. He's gone right back to basics on a lot of stuff, unit testing, TDD, refactoring, pair

by cmdkeen 13y ago

At work we have a consultant in at the moment doing technical mentoring. He's gone right back to basics on a lot of stuff, unit testing, TDD, refactoring, pair programming etc. For a while it felt like a waste of time, I didn't need to be doing this etc. But a realisation is growing on me. Shared understanding is vital, even more so in a team of "left brain" introverts. Whether it is establishing what everyone thinks TDD to be and the metrics to be extracted. Or whether it is making sure that at least one other person knows what your code does, that it is the best way of doing it, that you're not taking shortcuts or making "clever solutions" that aren't needed and sacrifice maintainability. Being a professional isn't about being dismissive of 9 to 5 paycheck developers and their skills whilst slamming out loads of code. If your experience is all of introverts who want to be left alone I dread to think what your code review practices are like...

masklinn 13y ago
> At work we have a consultant in at the moment doing technical mentoring. He's gone right back to basics on a lot of stuff How did you go around to finding him? I feel we really need that where I work, go back to basics and take up some "good habits"[0], but without a consultant/trainer to suggest it feels like whining without contributing. Attempting cultural changes internally on a suggestion basis doesn't really work, people (me included) just go back to their previous stable state. [0] both small scale, the testing and refactoring stuff, and larger-scale with system architecture.
- Morendil 13y ago
  > How did you go around to finding him? If you're going to shop around for a change agent, I recommend reading Jerry Weinberg's "Secrets of Consulting"; although this is targeted at consultants rather than their clients, it can provide useful insight into how to create an effective working partnership with one. Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact. But someone with a solid grasp of the fundamentals AND a productive attitude to coaching/mentoring/consulting can be a great asset. One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him).
  - masklinn 13y ago
    > Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact. Yeah I'm well-aware of that. > One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him). Thanks for the suggestion.
- squid_ca 13y ago
  I understand your frustration with trying to do this "internally", but stay positive and keep with it. If you (and like minded supporters) keep talking about "best practices", your peers _will_ notice and _will_ start playing with them in their work. At our workplace, we have a monthly hour-long "Lunch and Learn" where we all meet to do three things: listen to someone share some interesting code they worked on that month (which helps to generate some enthusiasm and spread some knowledge around); talk together about a specific best-practice; collectively review some code with a focus on using that best-practice to improve the code. It is a very simple, low-cost, low-time-cost way to formalize the fact that you want everyone to pay attention to these things, and (in our case) has really stimulated a desire among the developers to improve their code practice. To implement this, put someone in charge (or take charge yourself :) and just start asking people to contribute. You will probably find there is a lot more interest in this than you think. Also, be sure to go easy on yourself and your peers as you try to change habits. If you look back at code you wrote, say, three years ago, you will probably say to yourself, "What was I thinking? I could write that so much better now." In the same way, three years from now you will be able to say, "What was I thinking? I could [test|commit|organize|pair-program|etc] that so much better now."
  - cmdkeen 13y ago
    Cheers - I actually had a really good conversation in the pub on Friday with some other relatively junior staff, and we all came to a much better understanding of our goals and motivations, and how closely aligned they are. It really drives the point - the social connections are what makes or breaks you in an organisation. Any meaningful change needs allies, needs to persuade people, and needs to deal with ego and politics. The people responsible for what you want to change are probably those currently in management roles! It's probably one of the harder transitions from academic/training when there are absolute truths, to business where things become much more complex.
- cmdkeen 13y ago
  Sadly it's a bit of a crapshoot. The two consultants we have in at the moment are both brilliant, but we've had a shocking one from the same firm previously, who is probably responsible for a lot of our previous problems. The best advice I can give is to find someone/a firm who hires people who switch between doing and consulting. It's a bit like the old "those who can do, those who can't, teach". Having someone with loads of current practical experience convinces the tech types to go along with their proposal. Having someone with "expert" consultant credentials persuades management to go with something. Which is frustrating when an employee has been suggesting the same thing for ages, but a massive bill is convincing... The other top tip - especially if they are from out of town and thus staying over - invite them to the pub at the end of day one. They want to hear the gripes of those at the coal face.

by cmdkeen 13y ago

masklinn 13y ago

> At work we have a consultant in at the moment doing technical mentoring. He's gone right back to basics on a lot of stuff How did you go around to finding him? I feel we really need that where I work, go back to basics and take up some "good habits"[0], but without a consultant/trainer to suggest it feels like whining without contributing. Attempting cultural changes internally on a suggestion basis doesn't really work, people (me included) just go back to their previous stable state. [0] both small scale, the testing and refactoring stuff, and larger-scale with system architecture.

Morendil 13y ago
> How did you go around to finding him? If you're going to shop around for a change agent, I recommend reading Jerry Weinberg's "Secrets of Consulting"; although this is targeted at consultants rather than their clients, it can provide useful insight into how to create an effective working partnership with one. Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact. But someone with a solid grasp of the fundamentals AND a productive attitude to coaching/mentoring/consulting can be a great asset. One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him).
- masklinn 13y ago
  > Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact. Yeah I'm well-aware of that. > One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him). Thanks for the suggestion.
squid_ca 13y ago
I understand your frustration with trying to do this "internally", but stay positive and keep with it. If you (and like minded supporters) keep talking about "best practices", your peers _will_ notice and _will_ start playing with them in their work. At our workplace, we have a monthly hour-long "Lunch and Learn" where we all meet to do three things: listen to someone share some interesting code they worked on that month (which helps to generate some enthusiasm and spread some knowledge around); talk together about a specific best-practice; collectively review some code with a focus on using that best-practice to improve the code. It is a very simple, low-cost, low-time-cost way to formalize the fact that you want everyone to pay attention to these things, and (in our case) has really stimulated a desire among the developers to improve their code practice. To implement this, put someone in charge (or take charge yourself :) and just start asking people to contribute. You will probably find there is a lot more interest in this than you think. Also, be sure to go easy on yourself and your peers as you try to change habits. If you look back at code you wrote, say, three years ago, you will probably say to yourself, "What was I thinking? I could write that so much better now." In the same way, three years from now you will be able to say, "What was I thinking? I could [test|commit|organize|pair-program|etc] that so much better now."
- cmdkeen 13y ago
  Cheers - I actually had a really good conversation in the pub on Friday with some other relatively junior staff, and we all came to a much better understanding of our goals and motivations, and how closely aligned they are. It really drives the point - the social connections are what makes or breaks you in an organisation. Any meaningful change needs allies, needs to persuade people, and needs to deal with ego and politics. The people responsible for what you want to change are probably those currently in management roles! It's probably one of the harder transitions from academic/training when there are absolute truths, to business where things become much more complex.
cmdkeen 13y ago
Sadly it's a bit of a crapshoot. The two consultants we have in at the moment are both brilliant, but we've had a shocking one from the same firm previously, who is probably responsible for a lot of our previous problems. The best advice I can give is to find someone/a firm who hires people who switch between doing and consulting. It's a bit like the old "those who can do, those who can't, teach". Having someone with loads of current practical experience convinces the tech types to go along with their proposal. Having someone with "expert" consultant credentials persuades management to go with something. Which is frustrating when an employee has been suggesting the same thing for ages, but a massive bill is convincing... The other top tip - especially if they are from out of town and thus staying over - invite them to the pub at the end of day one. They want to hear the gripes of those at the coal face.