1 |
>> >> > You can get away with almost anything except these two things: |
2 |
>> >> > |
3 |
>> >> > Do not micro-manage |
4 |
>> >> > Do not tell them how to do what they do |
5 |
>> >> |
6 |
>> >> Could you give me an example of this last one? |
7 |
>> > |
8 |
>> > - I see you are using Perl with hashrefs to do function xyz. Have |
9 |
>> > you considered (i.e. I would like you to) using |
10 |
>> > $INSERT_SOMETHING_HERE? |
11 |
>> |
12 |
>> So if I see a way that their coding could be improved (faster |
13 |
>> execution, greater legibility, etc) I just keep quiet about it? |
14 |
>> |
15 |
>> > - Wanting to personally review the code often. I've seen some |
16 |
>> > managers want to do this daily. |
17 |
>> |
18 |
>> How often should I read their code? I was planning on reading it a |
19 |
>> lot. |
20 |
> |
21 |
> |
22 |
> Perhaps I was too literal. Those examples should be read in the context |
23 |
> of obsessively fiddling with someone else's work. Alternatively, doing |
24 |
> those examples and not producing anything worthwhile from doing it. |
25 |
> |
26 |
> Code reviews and suggestions are valuable, but there's a time and a |
27 |
> place and a forum for them. All productive teams eventually reserve a |
28 |
> time slot for review and demos of running code. You and the entire team |
29 |
> can and should discuss optimizations then. |
30 |
> |
31 |
> Let me put it another way - you likely don't like it if someone else |
32 |
> fiddles with your work while you are trying to do it, or gives |
33 |
> "helpful suggestions" while you are trying to concentrate. All I'm |
34 |
> saying is to avoid doing that to others. Good old common sense will |
35 |
> tell you when this is happening - you already know how to do it, no |
36 |
> need to analyze the thing any further than that |
37 |
|
38 |
Got it, thanks Alan and thanks everyone for helping with this. |
39 |
|
40 |
- Grant |