Mixing
As the new guy, how do I get people to act on all their big talk? [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
I'm "the new guy" at a small manufacturing company's IT department. We've a small team of 3 application devs + 1 database dev/dba-ish role. I've been here for a few months, so I'm hitting the point where I've started to gain the trust and recognition of my colleagues.
During my interview, there was a lot of talk about wanting to be more Agile. There is still a lot of talk about it, but no action on it. To be honest, I don't care if we're "Agile" or not, but we really do need to start doing some things that are just best practice, Agile or not. Things like Unit Testing and Code Reviews. Yes, let's go with those two first, as they're the biggest bang for the buck.
Now, I've been putting code I touch under test before modifying it. Partly because I've seen the benefits, and partly because I'm afraid of breaking anything in a legacy code base. My manager is very happy with this. He's told me so himself. The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things. I think it might be because they simply don't know how, but it's possible that they think "they don't have time". (The not having time part is totally untrue by the way. Management knows it's an investment up front that pays dividends back and is completely supportive of the effort.)
It's honestly becoming a bit frustrating for me to hear so much talk, but to see no action from my teammates. As the new guy, how can I push them into action without ruffling feathers? I don't want to be that guy.
This is not a duplicate of the suggested question because that guy was asking if/how he should push his ideas. These aren't my ideas (although I agree with them, obviously). My question revolves around how to get my colleagues to take action on their words.
professionalism software-industry new-job company-culture motivation
asked Sep 12 '15 at 12:33
ThatGuy
477311
marked as duplicate by gnat, scaaahu, mcknz, Lilienthal♦, IDrinkandIKnowThings Sep 17 '15 at 19:50
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
 |Â
show 1 more comment
up vote
4
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
I'm "the new guy" at a small manufacturing company's IT department. We've a small team of 3 application devs + 1 database dev/dba-ish role. I've been here for a few months, so I'm hitting the point where I've started to gain the trust and recognition of my colleagues.
During my interview, there was a lot of talk about wanting to be more Agile. There is still a lot of talk about it, but no action on it. To be honest, I don't care if we're "Agile" or not, but we really do need to start doing some things that are just best practice, Agile or not. Things like Unit Testing and Code Reviews. Yes, let's go with those two first, as they're the biggest bang for the buck.
Now, I've been putting code I touch under test before modifying it. Partly because I've seen the benefits, and partly because I'm afraid of breaking anything in a legacy code base. My manager is very happy with this. He's told me so himself. The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things. I think it might be because they simply don't know how, but it's possible that they think "they don't have time". (The not having time part is totally untrue by the way. Management knows it's an investment up front that pays dividends back and is completely supportive of the effort.)
It's honestly becoming a bit frustrating for me to hear so much talk, but to see no action from my teammates. As the new guy, how can I push them into action without ruffling feathers? I don't want to be that guy.
This is not a duplicate of the suggested question because that guy was asking if/how he should push his ideas. These aren't my ideas (although I agree with them, obviously). My question revolves around how to get my colleagues to take action on their words.
professionalism software-industry new-job company-culture motivation
asked Sep 12 '15 at 12:33
ThatGuy
477311
marked as duplicate by gnat, scaaahu, mcknz, Lilienthal♦, IDrinkandIKnowThings Sep 17 '15 at 19:50
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
2
They may just appear to like the "idea of testing and gated check-ins" because they don't want to argue about it.
– Mark Rogers
Sep 12 '15 at 13:35
What do you mean @MarkRogers?
– ThatGuy
Sep 12 '15 at 13:36
2
They may not be in the mood or have the energy to change how they work so they just give lip-service to the idea while they continue doing what they were already doing. Hoping that eventually someone else will figure it out for them or the issue otherwise goes away. Classic dodge.
– Mark Rogers
Sep 12 '15 at 13:37
I don't know @MarkRogers. You might be right, but they seem genuinely interested in making things better. Or, at least they're interested in talking about making things better. Hmm
– ThatGuy
Sep 12 '15 at 13:43
2
If they are genuinely interested but nothing is happening, it may be because nobody feels comfortable in taking the lead on getting it going. Are you that guy? If so, put together a plan and pitch it. They'll support you and maybe be grateful for your leadership. If you aren't willing to take the lead, then it's a bit hypocritical to criticize them for not doing so either, regardless of how long the situation has been going on for. Look on this as an opportunity, not a problem.
– Francine DeGrood Taylor
Sep 14 '15 at 17:29
 |Â
show 1 more comment
up vote
4
down vote
favorite
up vote
4
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
I'm "the new guy" at a small manufacturing company's IT department. We've a small team of 3 application devs + 1 database dev/dba-ish role. I've been here for a few months, so I'm hitting the point where I've started to gain the trust and recognition of my colleagues.
During my interview, there was a lot of talk about wanting to be more Agile. There is still a lot of talk about it, but no action on it. To be honest, I don't care if we're "Agile" or not, but we really do need to start doing some things that are just best practice, Agile or not. Things like Unit Testing and Code Reviews. Yes, let's go with those two first, as they're the biggest bang for the buck.
Now, I've been putting code I touch under test before modifying it. Partly because I've seen the benefits, and partly because I'm afraid of breaking anything in a legacy code base. My manager is very happy with this. He's told me so himself. The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things. I think it might be because they simply don't know how, but it's possible that they think "they don't have time". (The not having time part is totally untrue by the way. Management knows it's an investment up front that pays dividends back and is completely supportive of the effort.)
It's honestly becoming a bit frustrating for me to hear so much talk, but to see no action from my teammates. As the new guy, how can I push them into action without ruffling feathers? I don't want to be that guy.
This is not a duplicate of the suggested question because that guy was asking if/how he should push his ideas. These aren't my ideas (although I agree with them, obviously). My question revolves around how to get my colleagues to take action on their words.
professionalism software-industry new-job company-culture motivation
asked Sep 12 '15 at 12:33
ThatGuy
477311
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
I'm "the new guy" at a small manufacturing company's IT department. We've a small team of 3 application devs + 1 database dev/dba-ish role. I've been here for a few months, so I'm hitting the point where I've started to gain the trust and recognition of my colleagues.
During my interview, there was a lot of talk about wanting to be more Agile. There is still a lot of talk about it, but no action on it. To be honest, I don't care if we're "Agile" or not, but we really do need to start doing some things that are just best practice, Agile or not. Things like Unit Testing and Code Reviews. Yes, let's go with those two first, as they're the biggest bang for the buck.
Now, I've been putting code I touch under test before modifying it. Partly because I've seen the benefits, and partly because I'm afraid of breaking anything in a legacy code base. My manager is very happy with this. He's told me so himself. The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things. I think it might be because they simply don't know how, but it's possible that they think "they don't have time". (The not having time part is totally untrue by the way. Management knows it's an investment up front that pays dividends back and is completely supportive of the effort.)
It's honestly becoming a bit frustrating for me to hear so much talk, but to see no action from my teammates. As the new guy, how can I push them into action without ruffling feathers? I don't want to be that guy.
This is not a duplicate of the suggested question because that guy was asking if/how he should push his ideas. These aren't my ideas (although I agree with them, obviously). My question revolves around how to get my colleagues to take action on their words.
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
professionalism software-industry new-job company-culture motivation
asked Sep 12 '15 at 12:33
ThatGuy
477311
edited Sep 13 '15 at 16:14
asked Sep 12 '15 at 12:33
ThatGuy
477311
asked Sep 12 '15 at 12:33
ThatGuy
477311
asked Sep 12 '15 at 12:33
ThatGuy
477311
477311
marked as duplicate by gnat, scaaahu, mcknz, Lilienthal♦, IDrinkandIKnowThings Sep 17 '15 at 19:50
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by gnat, scaaahu, mcknz, Lilienthal♦, IDrinkandIKnowThings Sep 17 '15 at 19:50
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
2
They may just appear to like the "idea of testing and gated check-ins" because they don't want to argue about it.
– Mark Rogers
Sep 12 '15 at 13:35
What do you mean @MarkRogers?
– ThatGuy
Sep 12 '15 at 13:36
2
They may not be in the mood or have the energy to change how they work so they just give lip-service to the idea while they continue doing what they were already doing. Hoping that eventually someone else will figure it out for them or the issue otherwise goes away. Classic dodge.
– Mark Rogers
Sep 12 '15 at 13:37
I don't know @MarkRogers. You might be right, but they seem genuinely interested in making things better. Or, at least they're interested in talking about making things better. Hmm
– ThatGuy
Sep 12 '15 at 13:43
2
If they are genuinely interested but nothing is happening, it may be because nobody feels comfortable in taking the lead on getting it going. Are you that guy? If so, put together a plan and pitch it. They'll support you and maybe be grateful for your leadership. If you aren't willing to take the lead, then it's a bit hypocritical to criticize them for not doing so either, regardless of how long the situation has been going on for. Look on this as an opportunity, not a problem.
– Francine DeGrood Taylor
Sep 14 '15 at 17:29
 |Â
show 1 more comment
2
They may just appear to like the "idea of testing and gated check-ins" because they don't want to argue about it.
– Mark Rogers
Sep 12 '15 at 13:35
What do you mean @MarkRogers?
– ThatGuy
Sep 12 '15 at 13:36
2
They may not be in the mood or have the energy to change how they work so they just give lip-service to the idea while they continue doing what they were already doing. Hoping that eventually someone else will figure it out for them or the issue otherwise goes away. Classic dodge.
– Mark Rogers
Sep 12 '15 at 13:37
I don't know @MarkRogers. You might be right, but they seem genuinely interested in making things better. Or, at least they're interested in talking about making things better. Hmm
– ThatGuy
Sep 12 '15 at 13:43
2
If they are genuinely interested but nothing is happening, it may be because nobody feels comfortable in taking the lead on getting it going. Are you that guy? If so, put together a plan and pitch it. They'll support you and maybe be grateful for your leadership. If you aren't willing to take the lead, then it's a bit hypocritical to criticize them for not doing so either, regardless of how long the situation has been going on for. Look on this as an opportunity, not a problem.
– Francine DeGrood Taylor
Sep 14 '15 at 17:29
2
2
They may just appear to like the "idea of testing and gated check-ins" because they don't want to argue about it.
– Mark Rogers
Sep 12 '15 at 13:35
They may just appear to like the "idea of testing and gated check-ins" because they don't want to argue about it.
– Mark Rogers
Sep 12 '15 at 13:35
What do you mean @MarkRogers?
– ThatGuy
Sep 12 '15 at 13:36
What do you mean @MarkRogers?
– ThatGuy
Sep 12 '15 at 13:36
2
2
They may not be in the mood or have the energy to change how they work so they just give lip-service to the idea while they continue doing what they were already doing. Hoping that eventually someone else will figure it out for them or the issue otherwise goes away. Classic dodge.
– Mark Rogers
Sep 12 '15 at 13:37
They may not be in the mood or have the energy to change how they work so they just give lip-service to the idea while they continue doing what they were already doing. Hoping that eventually someone else will figure it out for them or the issue otherwise goes away. Classic dodge.
– Mark Rogers
Sep 12 '15 at 13:37
I don't know @MarkRogers. You might be right, but they seem genuinely interested in making things better. Or, at least they're interested in talking about making things better. Hmm
– ThatGuy
Sep 12 '15 at 13:43
I don't know @MarkRogers. You might be right, but they seem genuinely interested in making things better. Or, at least they're interested in talking about making things better. Hmm
– ThatGuy
Sep 12 '15 at 13:43
2
2
If they are genuinely interested but nothing is happening, it may be because nobody feels comfortable in taking the lead on getting it going. Are you that guy? If so, put together a plan and pitch it. They'll support you and maybe be grateful for your leadership. If you aren't willing to take the lead, then it's a bit hypocritical to criticize them for not doing so either, regardless of how long the situation has been going on for. Look on this as an opportunity, not a problem.
– Francine DeGrood Taylor
Sep 14 '15 at 17:29
If they are genuinely interested but nothing is happening, it may be because nobody feels comfortable in taking the lead on getting it going. Are you that guy? If so, put together a plan and pitch it. They'll support you and maybe be grateful for your leadership. If you aren't willing to take the lead, then it's a bit hypocritical to criticize them for not doing so either, regardless of how long the situation has been going on for. Look on this as an opportunity, not a problem.
– Francine DeGrood Taylor
Sep 14 '15 at 17:29
 |Â
show 1 more comment
3 Answers
3
active
oldest
votes
up vote
11
down vote
It's honestly becoming a bit frustrating for me to hear so much talk,
but to see no action from my teammates. As the new guy, how can I push
them into action without ruffling feathers? I don't want to be that
guy.
Using phrases like "big talk" and "push them" can indeed make you that guy, so you don't want to go there.
Consider asking your manager if it would be okay for you to create a presentation on some of the practices you consider important. Some companies have "brown bag talks" during lunch where such topics are common.
If accepted, you can talk about what you are proposing, why you consider it important (hopefully not just because you feel it's a "best practice", but more about why it will benefit the team/company in their particular context), and how you all can go about implementing these ideas.
Try to get the manager's explicit buy-in ahead of time, then use your powers of persuasion to convince others to get on the bandwagon. Sometimes suggesting a pilot project starts things off well - often starting small is the simplest way toward improvements.
answered Sep 12 '15 at 12:42
Joe Strazzere
223k105653921
5
That's the thing. They know the benefits, otherwise there wouldn't be so much talk about it... The pilot project is a good idea though. I like that. I might be able to make that happen.
– ThatGuy
Sep 12 '15 at 12:53
1
Knowing something would be an improvement and wanting to take advantage of if, and bring able to find the resources needed to adopt it, are often very different matters. In theory practice should be identical to theory; in practice that isn't always possible and when it is you usually have to get there incrementally.
– keshlam
Sep 13 '15 at 2:17
suggest improvements |Â
up vote
4
down vote
The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things
Do they actually know how to do unit testing?
If you've never done this before, this may not be straightforward to just start doing. Especially if you have years of experience doing no testing.
It sounds like your entire team at least is open to the idea of changing their processes. I'd focus on making sure you know why they are not doing things. I suspect it's either a general resistance to change or lack of understanding for how to do things.
If it's a lack of knowledge, you can consider ways to help with this. One good way might be asking someone for help and sort of doing a pair programming thing, when working with code you don't understand (as fully). You can talk through what you are doing, and see if you can write tests with the other person there, explaining what you are doing.
Note that seeing a test written (code review) and knowing how to approach writing a test aren't necessarily the same thing.
If it's just a "we like talking about it and sounding hip without doing anything" problem, you might try when that conversation happens, to be suggesting or asking about very specific, practical things (rather than just lamenting lack of code review or unit testing, too):
- "man I wish we were more agile."
- "well, do you want to review each other's code? I'm free this afternoon and have a commit I am making"
answered Sep 12 '15 at 13:42
Elysian Fields♦
96.8k46292449
They legitimately might not know. Some pair programming might be a great course of action. I'm not sure I'd do that for getting legacy code under test, but maybe with a bit of greenfield code. Thanks. Solid advice.
– ThatGuy
Sep 12 '15 at 14:07
2
@ThatGuy people will most likely not come out and say that, either. Telling the new guy, "hey us more senior people don't know how to do something you think is basic and management wants" is not likely. Legacy code you are unfamiliar with is perfect for this, you can say something like, "I'm hoping to write some tests on legacy code and you are more familiar with that codebase - can you help me?" and again, just talk through the process as you do it. People generally like flattery and asking for help is a great way to build support in the future.
– Elysian Fields♦
Sep 12 '15 at 14:10
That's a pretty good argument. Point taken.
– ThatGuy
Sep 12 '15 at 14:14
suggest improvements |Â
up vote
3
down vote
To make code reviews practical,
you need a system that facilitates them.
For example, as GitHub does with Pull Requests or as GitLab with Merge Requests.
I heard great things about Gerrit, but I haven't used it.
Get one of these or similar installed (even just on your own PC, at first),
otherwise it just won't be practical.
Here's an example of introducing code reviews to a colleague using GitHub.
Implement a reasonably interesting change on a branch,
and intentionally leave in some mistakes.
Create a Pull Request,
and ask a teammate to kindly review it.
Sit with him,
show him your mistake,
and how he can enter a comment on the relevant line.
Walk him through the rest of your changes,
if he makes any remarks,
ask him to enter a comment right there and then.
After you reviewed all the changes together,
return to your desk,
commit and push the corrections.
The earlier comments will be gone from the Pull Request,
ask him to make another pass in case he finds anything else.
Repeat until he finds nothing,
and the Pull Request can be accepted.
Show to other teammates too, keep assigning to them Pull Requests,
and encourage them to do the same to you.
Hopefully the practice will catch on.
The process is exactly the same with GitLab (free clone of GitHub),
but they call Pull Requests as Merge Requests.
I don't know with Gerrit and others,
I'd imagine similar functionality exists.
We implemented this idea in two teams so far,
over the past 3 years.
It's the single most popular practice we implemented.
The guys doing it love doing it,
and occasionally send me Merge Requests even after I moved to another team.
In my new teams I'm trying to spread the practice precisely the way I described above.
As for unit testing:
- Get a continuous build system working that executes unit tests as part of the build.
- Propose a brown bag lunch talk demonstrating examples of good unit tests and bad unit tests. Put the content you used in a public repository.
- Write good unit tests and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Lobby for a practice of everybody implementing (at least) one unit test per week. Make sure to measure and track progress (I use a simple Excel sheet).
As for code quality improvements:
- Get a static analysis tool integrated into the continuous build system. For example SonarQube.
- Implement corrections to problems raised by the static analysis tool, and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Propose buying books that are well-known to be good resources in your domain, have them lying around your desk, and encourage others to pick up and borrow anytime.
- Lobby for a practice of everybody implementing (at least) one correction to problems raised by the static analysis tool per week. Make sure to measure and track progress (I use a simple Excel sheet).
Notice the common pattern in both of the above examples:
- Get a tool setup that will help achieving your goals efficiently
- Use code reviews as a way to lead by example
- Get additional supporting materials lined up
- Lobby to implement improvements in small, manageable steps
All these ideas are so small and simple incremental changes that they are really easy to sell.
Customize, and use a variation adapted to your environment.
answered Sep 12 '15 at 20:58
janos
1615
Thanks for this. I'm more convinced that if this is going to happen, I'm going to have to teach it. This will definitely help.
– ThatGuy
Sep 12 '15 at 22:19
suggest improvements |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
It's honestly becoming a bit frustrating for me to hear so much talk,
but to see no action from my teammates. As the new guy, how can I push
them into action without ruffling feathers? I don't want to be that
guy.
Using phrases like "big talk" and "push them" can indeed make you that guy, so you don't want to go there.
Consider asking your manager if it would be okay for you to create a presentation on some of the practices you consider important. Some companies have "brown bag talks" during lunch where such topics are common.
If accepted, you can talk about what you are proposing, why you consider it important (hopefully not just because you feel it's a "best practice", but more about why it will benefit the team/company in their particular context), and how you all can go about implementing these ideas.
Try to get the manager's explicit buy-in ahead of time, then use your powers of persuasion to convince others to get on the bandwagon. Sometimes suggesting a pilot project starts things off well - often starting small is the simplest way toward improvements.
answered Sep 12 '15 at 12:42
Joe Strazzere
223k105653921
5
That's the thing. They know the benefits, otherwise there wouldn't be so much talk about it... The pilot project is a good idea though. I like that. I might be able to make that happen.
– ThatGuy
Sep 12 '15 at 12:53
1
Knowing something would be an improvement and wanting to take advantage of if, and bring able to find the resources needed to adopt it, are often very different matters. In theory practice should be identical to theory; in practice that isn't always possible and when it is you usually have to get there incrementally.
– keshlam
Sep 13 '15 at 2:17
suggest improvements |Â
up vote
11
down vote
It's honestly becoming a bit frustrating for me to hear so much talk,
but to see no action from my teammates. As the new guy, how can I push
them into action without ruffling feathers? I don't want to be that
guy.
Using phrases like "big talk" and "push them" can indeed make you that guy, so you don't want to go there.
Consider asking your manager if it would be okay for you to create a presentation on some of the practices you consider important. Some companies have "brown bag talks" during lunch where such topics are common.
If accepted, you can talk about what you are proposing, why you consider it important (hopefully not just because you feel it's a "best practice", but more about why it will benefit the team/company in their particular context), and how you all can go about implementing these ideas.
Try to get the manager's explicit buy-in ahead of time, then use your powers of persuasion to convince others to get on the bandwagon. Sometimes suggesting a pilot project starts things off well - often starting small is the simplest way toward improvements.
answered Sep 12 '15 at 12:42
Joe Strazzere
223k105653921
5
That's the thing. They know the benefits, otherwise there wouldn't be so much talk about it... The pilot project is a good idea though. I like that. I might be able to make that happen.
– ThatGuy
Sep 12 '15 at 12:53
1
Knowing something would be an improvement and wanting to take advantage of if, and bring able to find the resources needed to adopt it, are often very different matters. In theory practice should be identical to theory; in practice that isn't always possible and when it is you usually have to get there incrementally.
– keshlam
Sep 13 '15 at 2:17
suggest improvements |Â
up vote
11
down vote
up vote
11
down vote
It's honestly becoming a bit frustrating for me to hear so much talk,
but to see no action from my teammates. As the new guy, how can I push
them into action without ruffling feathers? I don't want to be that
guy.
Using phrases like "big talk" and "push them" can indeed make you that guy, so you don't want to go there.
Consider asking your manager if it would be okay for you to create a presentation on some of the practices you consider important. Some companies have "brown bag talks" during lunch where such topics are common.
If accepted, you can talk about what you are proposing, why you consider it important (hopefully not just because you feel it's a "best practice", but more about why it will benefit the team/company in their particular context), and how you all can go about implementing these ideas.
Try to get the manager's explicit buy-in ahead of time, then use your powers of persuasion to convince others to get on the bandwagon. Sometimes suggesting a pilot project starts things off well - often starting small is the simplest way toward improvements.
answered Sep 12 '15 at 12:42
Joe Strazzere
223k105653921
It's honestly becoming a bit frustrating for me to hear so much talk,
but to see no action from my teammates. As the new guy, how can I push
them into action without ruffling feathers? I don't want to be that
guy.
Using phrases like "big talk" and "push them" can indeed make you that guy, so you don't want to go there.
Consider asking your manager if it would be okay for you to create a presentation on some of the practices you consider important. Some companies have "brown bag talks" during lunch where such topics are common.
If accepted, you can talk about what you are proposing, why you consider it important (hopefully not just because you feel it's a "best practice", but more about why it will benefit the team/company in their particular context), and how you all can go about implementing these ideas.
Try to get the manager's explicit buy-in ahead of time, then use your powers of persuasion to convince others to get on the bandwagon. Sometimes suggesting a pilot project starts things off well - often starting small is the simplest way toward improvements.
answered Sep 12 '15 at 12:42
Joe Strazzere
223k105653921
answered Sep 12 '15 at 12:42
Joe Strazzere
223k105653921
answered Sep 12 '15 at 12:42
Joe Strazzere
223k105653921
answered Sep 12 '15 at 12:42
Joe Strazzere
223k105653921
223k105653921
5
That's the thing. They know the benefits, otherwise there wouldn't be so much talk about it... The pilot project is a good idea though. I like that. I might be able to make that happen.
– ThatGuy
Sep 12 '15 at 12:53
1
Knowing something would be an improvement and wanting to take advantage of if, and bring able to find the resources needed to adopt it, are often very different matters. In theory practice should be identical to theory; in practice that isn't always possible and when it is you usually have to get there incrementally.
– keshlam
Sep 13 '15 at 2:17
suggest improvements |Â
5
That's the thing. They know the benefits, otherwise there wouldn't be so much talk about it... The pilot project is a good idea though. I like that. I might be able to make that happen.
– ThatGuy
Sep 12 '15 at 12:53
1
Knowing something would be an improvement and wanting to take advantage of if, and bring able to find the resources needed to adopt it, are often very different matters. In theory practice should be identical to theory; in practice that isn't always possible and when it is you usually have to get there incrementally.
– keshlam
Sep 13 '15 at 2:17
5
5
That's the thing. They know the benefits, otherwise there wouldn't be so much talk about it... The pilot project is a good idea though. I like that. I might be able to make that happen.
– ThatGuy
Sep 12 '15 at 12:53
That's the thing. They know the benefits, otherwise there wouldn't be so much talk about it... The pilot project is a good idea though. I like that. I might be able to make that happen.
– ThatGuy
Sep 12 '15 at 12:53
1
1
Knowing something would be an improvement and wanting to take advantage of if, and bring able to find the resources needed to adopt it, are often very different matters. In theory practice should be identical to theory; in practice that isn't always possible and when it is you usually have to get there incrementally.
– keshlam
Sep 13 '15 at 2:17
Knowing something would be an improvement and wanting to take advantage of if, and bring able to find the resources needed to adopt it, are often very different matters. In theory practice should be identical to theory; in practice that isn't always possible and when it is you usually have to get there incrementally.
– keshlam
Sep 13 '15 at 2:17
suggest improvements |Â
up vote
4
down vote
The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things
Do they actually know how to do unit testing?
If you've never done this before, this may not be straightforward to just start doing. Especially if you have years of experience doing no testing.
It sounds like your entire team at least is open to the idea of changing their processes. I'd focus on making sure you know why they are not doing things. I suspect it's either a general resistance to change or lack of understanding for how to do things.
If it's a lack of knowledge, you can consider ways to help with this. One good way might be asking someone for help and sort of doing a pair programming thing, when working with code you don't understand (as fully). You can talk through what you are doing, and see if you can write tests with the other person there, explaining what you are doing.
Note that seeing a test written (code review) and knowing how to approach writing a test aren't necessarily the same thing.
If it's just a "we like talking about it and sounding hip without doing anything" problem, you might try when that conversation happens, to be suggesting or asking about very specific, practical things (rather than just lamenting lack of code review or unit testing, too):
- "man I wish we were more agile."
- "well, do you want to review each other's code? I'm free this afternoon and have a commit I am making"
answered Sep 12 '15 at 13:42
Elysian Fields♦
96.8k46292449
They legitimately might not know. Some pair programming might be a great course of action. I'm not sure I'd do that for getting legacy code under test, but maybe with a bit of greenfield code. Thanks. Solid advice.
– ThatGuy
Sep 12 '15 at 14:07
2
@ThatGuy people will most likely not come out and say that, either. Telling the new guy, "hey us more senior people don't know how to do something you think is basic and management wants" is not likely. Legacy code you are unfamiliar with is perfect for this, you can say something like, "I'm hoping to write some tests on legacy code and you are more familiar with that codebase - can you help me?" and again, just talk through the process as you do it. People generally like flattery and asking for help is a great way to build support in the future.
– Elysian Fields♦
Sep 12 '15 at 14:10
That's a pretty good argument. Point taken.
– ThatGuy
Sep 12 '15 at 14:14
suggest improvements |Â
up vote
4
down vote
The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things
Do they actually know how to do unit testing?
If you've never done this before, this may not be straightforward to just start doing. Especially if you have years of experience doing no testing.
It sounds like your entire team at least is open to the idea of changing their processes. I'd focus on making sure you know why they are not doing things. I suspect it's either a general resistance to change or lack of understanding for how to do things.
If it's a lack of knowledge, you can consider ways to help with this. One good way might be asking someone for help and sort of doing a pair programming thing, when working with code you don't understand (as fully). You can talk through what you are doing, and see if you can write tests with the other person there, explaining what you are doing.
Note that seeing a test written (code review) and knowing how to approach writing a test aren't necessarily the same thing.
If it's just a "we like talking about it and sounding hip without doing anything" problem, you might try when that conversation happens, to be suggesting or asking about very specific, practical things (rather than just lamenting lack of code review or unit testing, too):
- "man I wish we were more agile."
- "well, do you want to review each other's code? I'm free this afternoon and have a commit I am making"
answered Sep 12 '15 at 13:42
Elysian Fields♦
96.8k46292449
They legitimately might not know. Some pair programming might be a great course of action. I'm not sure I'd do that for getting legacy code under test, but maybe with a bit of greenfield code. Thanks. Solid advice.
– ThatGuy
Sep 12 '15 at 14:07
2
@ThatGuy people will most likely not come out and say that, either. Telling the new guy, "hey us more senior people don't know how to do something you think is basic and management wants" is not likely. Legacy code you are unfamiliar with is perfect for this, you can say something like, "I'm hoping to write some tests on legacy code and you are more familiar with that codebase - can you help me?" and again, just talk through the process as you do it. People generally like flattery and asking for help is a great way to build support in the future.
– Elysian Fields♦
Sep 12 '15 at 14:10
That's a pretty good argument. Point taken.
– ThatGuy
Sep 12 '15 at 14:14
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things
Do they actually know how to do unit testing?
If you've never done this before, this may not be straightforward to just start doing. Especially if you have years of experience doing no testing.
It sounds like your entire team at least is open to the idea of changing their processes. I'd focus on making sure you know why they are not doing things. I suspect it's either a general resistance to change or lack of understanding for how to do things.
If it's a lack of knowledge, you can consider ways to help with this. One good way might be asking someone for help and sort of doing a pair programming thing, when working with code you don't understand (as fully). You can talk through what you are doing, and see if you can write tests with the other person there, explaining what you are doing.
Note that seeing a test written (code review) and knowing how to approach writing a test aren't necessarily the same thing.
If it's just a "we like talking about it and sounding hip without doing anything" problem, you might try when that conversation happens, to be suggesting or asking about very specific, practical things (rather than just lamenting lack of code review or unit testing, too):
- "man I wish we were more agile."
- "well, do you want to review each other's code? I'm free this afternoon and have a commit I am making"
answered Sep 12 '15 at 13:42
Elysian Fields♦
96.8k46292449
The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things
Do they actually know how to do unit testing?
If you've never done this before, this may not be straightforward to just start doing. Especially if you have years of experience doing no testing.
It sounds like your entire team at least is open to the idea of changing their processes. I'd focus on making sure you know why they are not doing things. I suspect it's either a general resistance to change or lack of understanding for how to do things.
If it's a lack of knowledge, you can consider ways to help with this. One good way might be asking someone for help and sort of doing a pair programming thing, when working with code you don't understand (as fully). You can talk through what you are doing, and see if you can write tests with the other person there, explaining what you are doing.
Note that seeing a test written (code review) and knowing how to approach writing a test aren't necessarily the same thing.
If it's just a "we like talking about it and sounding hip without doing anything" problem, you might try when that conversation happens, to be suggesting or asking about very specific, practical things (rather than just lamenting lack of code review or unit testing, too):
- "man I wish we were more agile."
- "well, do you want to review each other's code? I'm free this afternoon and have a commit I am making"
answered Sep 12 '15 at 13:42
Elysian Fields♦
96.8k46292449
answered Sep 12 '15 at 13:42
Elysian Fields♦
96.8k46292449
answered Sep 12 '15 at 13:42
Elysian Fields♦
96.8k46292449
answered Sep 12 '15 at 13:42
Elysian Fields♦
96.8k46292449
96.8k46292449
They legitimately might not know. Some pair programming might be a great course of action. I'm not sure I'd do that for getting legacy code under test, but maybe with a bit of greenfield code. Thanks. Solid advice.
– ThatGuy
Sep 12 '15 at 14:07
2
@ThatGuy people will most likely not come out and say that, either. Telling the new guy, "hey us more senior people don't know how to do something you think is basic and management wants" is not likely. Legacy code you are unfamiliar with is perfect for this, you can say something like, "I'm hoping to write some tests on legacy code and you are more familiar with that codebase - can you help me?" and again, just talk through the process as you do it. People generally like flattery and asking for help is a great way to build support in the future.
– Elysian Fields♦
Sep 12 '15 at 14:10
That's a pretty good argument. Point taken.
– ThatGuy
Sep 12 '15 at 14:14
suggest improvements |Â
They legitimately might not know. Some pair programming might be a great course of action. I'm not sure I'd do that for getting legacy code under test, but maybe with a bit of greenfield code. Thanks. Solid advice.
– ThatGuy
Sep 12 '15 at 14:07
2
@ThatGuy people will most likely not come out and say that, either. Telling the new guy, "hey us more senior people don't know how to do something you think is basic and management wants" is not likely. Legacy code you are unfamiliar with is perfect for this, you can say something like, "I'm hoping to write some tests on legacy code and you are more familiar with that codebase - can you help me?" and again, just talk through the process as you do it. People generally like flattery and asking for help is a great way to build support in the future.
– Elysian Fields♦
Sep 12 '15 at 14:10
That's a pretty good argument. Point taken.
– ThatGuy
Sep 12 '15 at 14:14
They legitimately might not know. Some pair programming might be a great course of action. I'm not sure I'd do that for getting legacy code under test, but maybe with a bit of greenfield code. Thanks. Solid advice.
– ThatGuy
Sep 12 '15 at 14:07
They legitimately might not know. Some pair programming might be a great course of action. I'm not sure I'd do that for getting legacy code under test, but maybe with a bit of greenfield code. Thanks. Solid advice.
– ThatGuy
Sep 12 '15 at 14:07
2
2
@ThatGuy people will most likely not come out and say that, either. Telling the new guy, "hey us more senior people don't know how to do something you think is basic and management wants" is not likely. Legacy code you are unfamiliar with is perfect for this, you can say something like, "I'm hoping to write some tests on legacy code and you are more familiar with that codebase - can you help me?" and again, just talk through the process as you do it. People generally like flattery and asking for help is a great way to build support in the future.
– Elysian Fields♦
Sep 12 '15 at 14:10
@ThatGuy people will most likely not come out and say that, either. Telling the new guy, "hey us more senior people don't know how to do something you think is basic and management wants" is not likely. Legacy code you are unfamiliar with is perfect for this, you can say something like, "I'm hoping to write some tests on legacy code and you are more familiar with that codebase - can you help me?" and again, just talk through the process as you do it. People generally like flattery and asking for help is a great way to build support in the future.
– Elysian Fields♦
Sep 12 '15 at 14:10
That's a pretty good argument. Point taken.
– ThatGuy
Sep 12 '15 at 14:14
That's a pretty good argument. Point taken.
– ThatGuy
Sep 12 '15 at 14:14
suggest improvements |Â
up vote
3
down vote
To make code reviews practical,
you need a system that facilitates them.
For example, as GitHub does with Pull Requests or as GitLab with Merge Requests.
I heard great things about Gerrit, but I haven't used it.
Get one of these or similar installed (even just on your own PC, at first),
otherwise it just won't be practical.
Here's an example of introducing code reviews to a colleague using GitHub.
Implement a reasonably interesting change on a branch,
and intentionally leave in some mistakes.
Create a Pull Request,
and ask a teammate to kindly review it.
Sit with him,
show him your mistake,
and how he can enter a comment on the relevant line.
Walk him through the rest of your changes,
if he makes any remarks,
ask him to enter a comment right there and then.
After you reviewed all the changes together,
return to your desk,
commit and push the corrections.
The earlier comments will be gone from the Pull Request,
ask him to make another pass in case he finds anything else.
Repeat until he finds nothing,
and the Pull Request can be accepted.
Show to other teammates too, keep assigning to them Pull Requests,
and encourage them to do the same to you.
Hopefully the practice will catch on.
The process is exactly the same with GitLab (free clone of GitHub),
but they call Pull Requests as Merge Requests.
I don't know with Gerrit and others,
I'd imagine similar functionality exists.
We implemented this idea in two teams so far,
over the past 3 years.
It's the single most popular practice we implemented.
The guys doing it love doing it,
and occasionally send me Merge Requests even after I moved to another team.
In my new teams I'm trying to spread the practice precisely the way I described above.
As for unit testing:
- Get a continuous build system working that executes unit tests as part of the build.
- Propose a brown bag lunch talk demonstrating examples of good unit tests and bad unit tests. Put the content you used in a public repository.
- Write good unit tests and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Lobby for a practice of everybody implementing (at least) one unit test per week. Make sure to measure and track progress (I use a simple Excel sheet).
As for code quality improvements:
- Get a static analysis tool integrated into the continuous build system. For example SonarQube.
- Implement corrections to problems raised by the static analysis tool, and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Propose buying books that are well-known to be good resources in your domain, have them lying around your desk, and encourage others to pick up and borrow anytime.
- Lobby for a practice of everybody implementing (at least) one correction to problems raised by the static analysis tool per week. Make sure to measure and track progress (I use a simple Excel sheet).
Notice the common pattern in both of the above examples:
- Get a tool setup that will help achieving your goals efficiently
- Use code reviews as a way to lead by example
- Get additional supporting materials lined up
- Lobby to implement improvements in small, manageable steps
All these ideas are so small and simple incremental changes that they are really easy to sell.
Customize, and use a variation adapted to your environment.
answered Sep 12 '15 at 20:58
janos
1615
Thanks for this. I'm more convinced that if this is going to happen, I'm going to have to teach it. This will definitely help.
– ThatGuy
Sep 12 '15 at 22:19
suggest improvements |Â
up vote
3
down vote
To make code reviews practical,
you need a system that facilitates them.
For example, as GitHub does with Pull Requests or as GitLab with Merge Requests.
I heard great things about Gerrit, but I haven't used it.
Get one of these or similar installed (even just on your own PC, at first),
otherwise it just won't be practical.
Here's an example of introducing code reviews to a colleague using GitHub.
Implement a reasonably interesting change on a branch,
and intentionally leave in some mistakes.
Create a Pull Request,
and ask a teammate to kindly review it.
Sit with him,
show him your mistake,
and how he can enter a comment on the relevant line.
Walk him through the rest of your changes,
if he makes any remarks,
ask him to enter a comment right there and then.
After you reviewed all the changes together,
return to your desk,
commit and push the corrections.
The earlier comments will be gone from the Pull Request,
ask him to make another pass in case he finds anything else.
Repeat until he finds nothing,
and the Pull Request can be accepted.
Show to other teammates too, keep assigning to them Pull Requests,
and encourage them to do the same to you.
Hopefully the practice will catch on.
The process is exactly the same with GitLab (free clone of GitHub),
but they call Pull Requests as Merge Requests.
I don't know with Gerrit and others,
I'd imagine similar functionality exists.
We implemented this idea in two teams so far,
over the past 3 years.
It's the single most popular practice we implemented.
The guys doing it love doing it,
and occasionally send me Merge Requests even after I moved to another team.
In my new teams I'm trying to spread the practice precisely the way I described above.
As for unit testing:
- Get a continuous build system working that executes unit tests as part of the build.
- Propose a brown bag lunch talk demonstrating examples of good unit tests and bad unit tests. Put the content you used in a public repository.
- Write good unit tests and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Lobby for a practice of everybody implementing (at least) one unit test per week. Make sure to measure and track progress (I use a simple Excel sheet).
As for code quality improvements:
- Get a static analysis tool integrated into the continuous build system. For example SonarQube.
- Implement corrections to problems raised by the static analysis tool, and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Propose buying books that are well-known to be good resources in your domain, have them lying around your desk, and encourage others to pick up and borrow anytime.
- Lobby for a practice of everybody implementing (at least) one correction to problems raised by the static analysis tool per week. Make sure to measure and track progress (I use a simple Excel sheet).
Notice the common pattern in both of the above examples:
- Get a tool setup that will help achieving your goals efficiently
- Use code reviews as a way to lead by example
- Get additional supporting materials lined up
- Lobby to implement improvements in small, manageable steps
All these ideas are so small and simple incremental changes that they are really easy to sell.
Customize, and use a variation adapted to your environment.
answered Sep 12 '15 at 20:58
janos
1615
Thanks for this. I'm more convinced that if this is going to happen, I'm going to have to teach it. This will definitely help.
– ThatGuy
Sep 12 '15 at 22:19
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
To make code reviews practical,
you need a system that facilitates them.
For example, as GitHub does with Pull Requests or as GitLab with Merge Requests.
I heard great things about Gerrit, but I haven't used it.
Get one of these or similar installed (even just on your own PC, at first),
otherwise it just won't be practical.
Here's an example of introducing code reviews to a colleague using GitHub.
Implement a reasonably interesting change on a branch,
and intentionally leave in some mistakes.
Create a Pull Request,
and ask a teammate to kindly review it.
Sit with him,
show him your mistake,
and how he can enter a comment on the relevant line.
Walk him through the rest of your changes,
if he makes any remarks,
ask him to enter a comment right there and then.
After you reviewed all the changes together,
return to your desk,
commit and push the corrections.
The earlier comments will be gone from the Pull Request,
ask him to make another pass in case he finds anything else.
Repeat until he finds nothing,
and the Pull Request can be accepted.
Show to other teammates too, keep assigning to them Pull Requests,
and encourage them to do the same to you.
Hopefully the practice will catch on.
The process is exactly the same with GitLab (free clone of GitHub),
but they call Pull Requests as Merge Requests.
I don't know with Gerrit and others,
I'd imagine similar functionality exists.
We implemented this idea in two teams so far,
over the past 3 years.
It's the single most popular practice we implemented.
The guys doing it love doing it,
and occasionally send me Merge Requests even after I moved to another team.
In my new teams I'm trying to spread the practice precisely the way I described above.
As for unit testing:
- Get a continuous build system working that executes unit tests as part of the build.
- Propose a brown bag lunch talk demonstrating examples of good unit tests and bad unit tests. Put the content you used in a public repository.
- Write good unit tests and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Lobby for a practice of everybody implementing (at least) one unit test per week. Make sure to measure and track progress (I use a simple Excel sheet).
As for code quality improvements:
- Get a static analysis tool integrated into the continuous build system. For example SonarQube.
- Implement corrections to problems raised by the static analysis tool, and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Propose buying books that are well-known to be good resources in your domain, have them lying around your desk, and encourage others to pick up and borrow anytime.
- Lobby for a practice of everybody implementing (at least) one correction to problems raised by the static analysis tool per week. Make sure to measure and track progress (I use a simple Excel sheet).
Notice the common pattern in both of the above examples:
- Get a tool setup that will help achieving your goals efficiently
- Use code reviews as a way to lead by example
- Get additional supporting materials lined up
- Lobby to implement improvements in small, manageable steps
All these ideas are so small and simple incremental changes that they are really easy to sell.
Customize, and use a variation adapted to your environment.
answered Sep 12 '15 at 20:58
janos
1615
To make code reviews practical,
you need a system that facilitates them.
For example, as GitHub does with Pull Requests or as GitLab with Merge Requests.
I heard great things about Gerrit, but I haven't used it.
Get one of these or similar installed (even just on your own PC, at first),
otherwise it just won't be practical.
Here's an example of introducing code reviews to a colleague using GitHub.
Implement a reasonably interesting change on a branch,
and intentionally leave in some mistakes.
Create a Pull Request,
and ask a teammate to kindly review it.
Sit with him,
show him your mistake,
and how he can enter a comment on the relevant line.
Walk him through the rest of your changes,
if he makes any remarks,
ask him to enter a comment right there and then.
After you reviewed all the changes together,
return to your desk,
commit and push the corrections.
The earlier comments will be gone from the Pull Request,
ask him to make another pass in case he finds anything else.
Repeat until he finds nothing,
and the Pull Request can be accepted.
Show to other teammates too, keep assigning to them Pull Requests,
and encourage them to do the same to you.
Hopefully the practice will catch on.
The process is exactly the same with GitLab (free clone of GitHub),
but they call Pull Requests as Merge Requests.
I don't know with Gerrit and others,
I'd imagine similar functionality exists.
We implemented this idea in two teams so far,
over the past 3 years.
It's the single most popular practice we implemented.
The guys doing it love doing it,
and occasionally send me Merge Requests even after I moved to another team.
In my new teams I'm trying to spread the practice precisely the way I described above.
As for unit testing:
- Get a continuous build system working that executes unit tests as part of the build.
- Propose a brown bag lunch talk demonstrating examples of good unit tests and bad unit tests. Put the content you used in a public repository.
- Write good unit tests and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Lobby for a practice of everybody implementing (at least) one unit test per week. Make sure to measure and track progress (I use a simple Excel sheet).
As for code quality improvements:
- Get a static analysis tool integrated into the continuous build system. For example SonarQube.
- Implement corrections to problems raised by the static analysis tool, and assign Merge Requests to a teammate who's most likely to buy into the idea.
- Propose buying books that are well-known to be good resources in your domain, have them lying around your desk, and encourage others to pick up and borrow anytime.
- Lobby for a practice of everybody implementing (at least) one correction to problems raised by the static analysis tool per week. Make sure to measure and track progress (I use a simple Excel sheet).
Notice the common pattern in both of the above examples:
- Get a tool setup that will help achieving your goals efficiently
- Use code reviews as a way to lead by example
- Get additional supporting materials lined up
- Lobby to implement improvements in small, manageable steps
All these ideas are so small and simple incremental changes that they are really easy to sell.
Customize, and use a variation adapted to your environment.
answered Sep 12 '15 at 20:58
janos
1615
edited Sep 12 '15 at 22:26
answered Sep 12 '15 at 20:58
janos
1615
answered Sep 12 '15 at 20:58
janos
1615
answered Sep 12 '15 at 20:58
janos
1615
1615
Thanks for this. I'm more convinced that if this is going to happen, I'm going to have to teach it. This will definitely help.
– ThatGuy
Sep 12 '15 at 22:19
suggest improvements |Â
Thanks for this. I'm more convinced that if this is going to happen, I'm going to have to teach it. This will definitely help.
– ThatGuy
Sep 12 '15 at 22:19
Thanks for this. I'm more convinced that if this is going to happen, I'm going to have to teach it. This will definitely help.
– ThatGuy
Sep 12 '15 at 22:19
Thanks for this. I'm more convinced that if this is going to happen, I'm going to have to teach it. This will definitely help.
– ThatGuy
Sep 12 '15 at 22:19
suggest improvements |Â
2
They may just appear to like the "idea of testing and gated check-ins" because they don't want to argue about it.
– Mark Rogers
Sep 12 '15 at 13:35
What do you mean @MarkRogers?
– ThatGuy
Sep 12 '15 at 13:36
2
They may not be in the mood or have the energy to change how they work so they just give lip-service to the idea while they continue doing what they were already doing. Hoping that eventually someone else will figure it out for them or the issue otherwise goes away. Classic dodge.
– Mark Rogers
Sep 12 '15 at 13:37
I don't know @MarkRogers. You might be right, but they seem genuinely interested in making things better. Or, at least they're interested in talking about making things better. Hmm
– ThatGuy
Sep 12 '15 at 13:43
2
If they are genuinely interested but nothing is happening, it may be because nobody feels comfortable in taking the lead on getting it going. Are you that guy? If so, put together a plan and pitch it. They'll support you and maybe be grateful for your leadership. If you aren't willing to take the lead, then it's a bit hypocritical to criticize them for not doing so either, regardless of how long the situation has been going on for. Look on this as an opportunity, not a problem.
– Francine DeGrood Taylor
Sep 14 '15 at 17:29