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