FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 05-29-2012, 05:51 PM
Grant
 
Default {OT} hire a programmer or company?

> Everything I know about dealing with technical people is from the
> school of hard knocks :-)

And class is definitely in session! Thanks to all for your guidance with this.

> I don't think it's something that can be taught or
> properly described adequately. But there are some obvious concepts:
>
> Programmers are essentially not too different from any other type of
> technical people, and you are already very familiar with those just by
> reading gentoo-user. All that stuff we do here wrt top-posting, html
> mail, udev and pulseaudio developers having strange ideas and
> (being perceived to be) ramming it down people's throats - all that
> stuff applies.
>
> I don't know how you personally deal with such things but whatever you
> find works is probably good enough.
>
> Techies don't like being second-guessed and told what to do when they
> are perfectly capable of doing the job properly. This is just a normal
> human reaction really and is always solved by simple communication. You
> always have to get to know people first, to get a grip on their
> personality, and then find out how to successfully interact with them.
> If you are married, consider what it took to learn how to interact with
> your wife smoothly :-)
>
>> Could you tell me really briefly what a manager *should* do?
>
> Ouch. That's another encyclopedia-length answer :-)
>
> I'll give you a short oblique answer that seems to work for me:
>
> Managers do not lead, they serve. They are not there to call the shots, get covered in glory,
> be seen as the best of the best or issue decrees. I've been fortunate to
> have had a few good managers in my working life and they all seemed to
> instinctively do the same very important thing: make it possible for me
> to do my job.
>
> They would deal with finance issues, they would help find out where new
> hardware was in the shipping process, they would be a buffer between me
> and the customer (or between me and the annoying executive). They would
> publicly cover me in glory when things worked out well and cover my ass
> when they didn't. And all too often they would clam me down when I went
> off on one of my rants. The point is, the manager took care of
> everything on the project except the part about being a programmer :-)
>
> Good managers are very good at observing. They don't impose themselves
> on the job at hand, they watch it and see where things are going great
> and where things can be improved. They are also patient and only
> try to improve one thing at a time, getting that thing right then move
> onto the next thing.
>
> My current manager is great, we're both a similar
> age (mid 40s), and we have an understanding - I'm good at my job and
> he's good at his. It took a while for both of us to recognize this and
> build that trust but I think we got it right eventually. The key thing
> was to communicate to the other guy and be honest and listen. In the
> beginning there was some "alpha-male" posturing going on and we had to
> drop that somewhat quickly :-)
>
> He's also particular in finding out what the whole team thinks about
> things, so really listens to our input.
>
> That's what I find works for me, but unlike computers I can't put it
> down in step-by-step fashion that will give a certain result.
>
>>
>> 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.
>
> Sounds to me like you already grasp the essentials :-)
>
> Good luck with the project.
>
> Oh , one last thing: despite all appearances to the contrary, most
> people out there can be trusted to do the right thing as far as they
> are able, and do want to do a good job. Don't let occasional lapses
> cloud your view of this. Everyone makes mistakes sometimes, we all must
> learn to be tolerant when it happens.

Sorry for the scrolling but that stuff just can't be snipped.

Regarding proposals, schedules, roadmaps, milestones.... I've got a
list of a million changes to make to my website's front-end and
back-end. There is a very specific way I want things to work, so
everything is broken down to a granular "task" level. In the old days
I would just dig in and start grinding away on things, but I'm ready
to pass that duty on to a real programmer and I can't imagine that
it's productive to have him submit a proposal, set up a schedule,
generate a roadmap, and create milestones for every little thing that
needs to be done. Can I hire one guy and give him one task at a time
and see how it goes without any of that stuff?

- Grant
 
Old 05-29-2012, 08:10 PM
Alan McKinnon
 
Default {OT} hire a programmer or company?

On Tue, 29 May 2012 10:51:13 -0700
Grant <emailgrant@gmail.com> wrote:

> > Oh , one last thing: despite all appearances to the contrary, most
> > people out there can be trusted to do the right thing as far as they
> > are able, and do want to do a good job. Don't let occasional lapses
> > cloud your view of this. Everyone makes mistakes sometimes, we all
> > must learn to be tolerant when it happens.
>
> Sorry for the scrolling but that stuff just can't be snipped.
>
> Regarding proposals, schedules, roadmaps, milestones.... I've got a
> list of a million changes to make to my website's front-end and
> back-end. There is a very specific way I want things to work, so
> everything is broken down to a granular "task" level. In the old days
> I would just dig in and start grinding away on things, but I'm ready
> to pass that duty on to a real programmer and I can't imagine that
> it's productive to have him submit a proposal, set up a schedule,
> generate a roadmap, and create milestones for every little thing that
> needs to be done. Can I hire one guy and give him one task at a time
> and see how it goes without any of that stuff?

That will only work if you show him the big picture first so he sees
where the bits fit in. By all means contract him to focus on one aspect
at a time, but please don't disguise the overall view. It's
counter-productive and he's not doing something he has already done
many times before so he really needs to be able to see how the bit he's
working on fits into everything else.

We've discussed this project of yours more than once here over the
years, and each time the same thing gets raised - you are unwilling to
show a programmer the whole picture. Does this mean the handover
efforts have all failed before?



--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 05-29-2012, 11:52 PM
Peter Humphrey
 
Default {OT} hire a programmer or company?

On Tuesday 29 May 2012 15:37:37 Alan McKinnon wrote:

> Oh, and this one is a classic too:
>
> Q: How do you get a project to be 3 years late?
> A: One day at a time.

Or: the first 50% of the project takes the first 90% of the time, and the
other 50% of the project takes the other 90% of the time.

--
Rgds
Peter
 
Old 05-30-2012, 09:00 AM
Grant
 
Default {OT} hire a programmer or company?

>> Regarding proposals, schedules, roadmaps, milestones.... *I've got a
>> list of a million changes to make to my website's front-end and
>> back-end. *There is a very specific way I want things to work, so
>> everything is broken down to a granular "task" level. *In the old days
>> I would just dig in and start grinding away on things, but I'm ready
>> to pass that duty on to a real programmer and I can't imagine that
>> it's productive to have him submit a proposal, set up a schedule,
>> generate a roadmap, and create milestones for every little thing that
>> needs to be done. *Can I hire one guy and give him one task at a time
>> and see how it goes without any of that stuff?
>
> That will only work if you show him the big picture first so he sees
> where the bits fit in. By all means contract him to focus on one aspect
> at a time, but please don't disguise the overall view. It's
> counter-productive and he's not doing something he has already done
> many times before so he really needs to be able to see how the bit he's
> working on fits into everything else.

In the past I did plan to disguise the overall view, but I've gotten
over that thanks to folks like yourself.

> We've discussed this project of yours more than once here over the
> years, and each time the same thing gets raised - you are unwilling to
> show a programmer the whole picture. Does this mean the handover
> efforts have all failed before?

Previous handover efforts have failed, and precisely for that reason.
I didn't bring up obscuring the big picture this time, but re-reading
my top paragraph in this message I can see that it sounds like that's
what I'm getting at. It's not at all. I'm just trying to preload
some management knowledge and fit it into my context (which does not
include obscuring the big picture from developers).

- Grant
 
Old 05-30-2012, 09:11 AM
Grant
 
Default {OT} hire a programmer or company?

>> > 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.

- Grant
 
Old 05-30-2012, 12:57 PM
Nicolas Sebrecht
 
Default {OT} hire a programmer or company?

The 30/05/12, Grant wrote:

> So if I see a way that their coding could be improved (faster
> execution, greater legibility, etc) I just keep quiet about it?

Improvements is only one aspect of where to focus the efforts.

> How often should I read their code? I was planning on reading it a lot.

In small teams, these tasks (including making releases) are usually done
by the software maintainer. To know what to do, you should be clear
about who will be in charge of releasing the software. A SVC is
*required* and the tool choice should be a team choice.

Once done and roles assigned, it will be really easy for you to know
what you can/should do or not. Anybody can act/interact as different
role as long as the role is well defined (e.g. while reviewing code, you
do reviewing code /only/ and might discuss the design choices but the
final technical decision must stay in the hands of the software
maintainer).

FMPOV the key role is the maintainer. The job requires both good
technical knowlegde and a large project view.

--
Nicolas Sebrecht
 
Old 05-30-2012, 10:58 PM
Alan McKinnon
 
Default {OT} hire a programmer or company?

On Wed, 30 May 2012 02:11:54 -0700
Grant <emailgrant@gmail.com> wrote:

> >> > 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

--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 05-31-2012, 06:44 AM
Grant
 
Default {OT} hire a programmer or company?

>> >> > 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
 

Thread Tools




All times are GMT. The time now is 09:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org