Re: [gentoo-user] {OT} hire a programmer or company?

[Pandu Poluan <pandu@poluan.info>]

[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

On May 29, 2012 3:39 PM, "Grant" <emailgrant@gmail.com> wrote:
>
> >> >> I'll be getting my feet wet with this shortly.  Any other tips
> >> >> regarding the management of one or more programmers working on
> >> >> various small web projects?  Maybe workflow or any key procedures
> >> >> a newbie manager should follow?
> >> >
> >> > 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?
> >
> > - Fiddling with the roadmap. Somehow, this always ends up like the
> > homeowner overriding the architect and trying to get the roof up
> > before the walls.
> >
> > - Giving "advice" on the process such as saying how awesome a concept
> > stakeholders and product owners are in Scrum. But they use
> > ExtremeProgramming.
> >
> > - Wanting to personally review the code often. I've seen some managers
> >  want to do this daily.
> >
> > - Get personally involved on their level.
> >
> >
> > All these things class as interference. Managers and owners who do this
> > have miles of justifiable reasons for doing so, but it's always hogwash
> > - they interfere, plain and simple.
>
> This is really interesting to me.  Is there a forum/website/book with
> more gritty, practical advice like this on managing programmers?
> These are the kinds of mistakes I will definitely make if someone
> doesn't tell me not to.
>
> Could you tell me really briefly what a manager *should* do?
>
> I think I'll try to manage a single programmer working few hours and
> see how it goes.  My asking stupid questions is due to my lack of
> experience and there's only one way to fix that.
>
> -  Grant
>

Off the top of my head :

* It's OK to ask the team about their roadmap and milestones schedule, and
even raise objections and/or suggest changes AT THE VERY START OF THE
PROJECT.

* When the project is under way, DO NOT EVER interfere unless asked.

* It is okay to regularly (weekly or biweekly) ask for progress report with
regards to the previously agreed milestone schedule. If delays happen, you
must also ask what the cause of the delay is, and what the team plan to
overcome and/or compensate

* Ask the team to keep a 'weather report' regarding the project, updated
continually, stored in a shared folder. This is less a report to you than
something you can present to your superiors when they start asking, "Are we
there yet?"

Rgds,

[-- Attachment #2: Type: text/html, Size: 3357 bytes --]