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