[Phpwm] Job for web programmer

[Phil Beynon]

> >> We don't actually ever just jump into code.  That's another reason for
> >> us to all work in the same place.  We spend time at the beginning of
> >> each project and when we come to new/potentially difficult things
> >> discussing how we're going to implement it.  We'll either discuss as a
> >> whole team (all 4 of us) or in smaller groups.  We make
> extensive use of
> >> our whiteboards to describe ideas, and come up with an approach before
> >> we sit down to work.  Then, once we're coding - especially when pair
> >> programming, we discuss issues as we're going along.  Pair programming
> >> is supposed to include a fairly constant dialog about what is happening
> >> - the navigator should be asking the driver why they're doing certain
> >> things or doing something a certain way, and making suggestions about
> >> how else they might do it while keeping in mind how the code fits into
> >> the larger scheme of things.
> >> The idea is that the navigator keeps a more high level view while the
> >> driver concentrates more closely on the details.
> >>
> >> Even when we're not pair programming, we interrupt each other to ask
> >> questions.  It may disturb one of us, but in the long run, we work more
> >> efficiently.
> >>
> >>
> >> Kat
> >>
> >
> > Doesn't this result in a very linear approach though, as
> against working on
> > different aspects and everyone ending up at the finish point based upon
> > their set of tasks at roughly the same time?
> I'm not sure what you mean by that.
> To explain a bit more how we work:
>
> We have a planning board, with cards on indicating tasks(which refer to
> tickets in trac).  They're grouped into weeks, and within that week is
> the work I estimate we can get done within the time.  Most tasks can be
> done by any of us, so when someone needs more work they either pick up
> the next card, or ask me what I want them to do next.
> Anything that we think will require a design session is planned in,
> normally with an indication of time (e.g. "Wednesday morning") and we'll
> normally all pitch in with that.
>
> Most of the time, David and I are working on separate things (as David
> does a fair bit of sysadmin, and I do all the management/admin stuff)
> and Sam and Paul are either working on their own tasks or pair
> programming.  We're all contributing to different bits of different
> projects, but the tasks are set out in such a way that each one is a
> feature or small set of features that fit together.  We don't have one
> shared "finish point" and sometimes we'll put a task to one side to work
> together on something, but because of our tracking it won't get forgotten.

OK, the way it was coming over before that was a lot more of an enforced
structure, which would be hard to work within unless everyone was about
equal.

> Because we work in a very defined way (using our framework and a certain
> set of tools) and because we all work on all projects, we can easily
> help each other out when required.
>
> When we're actually getting stuck into some code on our own, we all wear
> headphones, hence the stories of flying rubber penguins to get each
> other's attention.

A pro listening to decent music whilst working company - you have gone up in
my estimation immensely! :-)

> Does that explain it or am I not following your thought?

Yup!

Phil