[python-uk] The London Python Dojo is this Thursday

Stestagg stestagg at gmail.com
Fri Jul 12 13:29:40 CEST 2013


The only obvious thing I can think of here would be to have a speed-dating
style bell/noise that rings periodically, prompting people to swap over on
the keyboard.

I think this could be quite fun, maybe slightly annoying(?) but worth it,
IMO.

Teams who decide to use multiple laptops should still adopt this, but with
people rotating between the laptops.



On Fri, Jul 12, 2013 at 12:18 PM, a.grandi at gmail.com <a.grandi at gmail.com>wrote:

> Hi,
>
> On 12 July 2013 12:00, Tim Golden <mail at timgolden.me.uk> wrote:
> > While I'm definitely sympathetic, making sure to involve newbies is not
> > that easy a problem to solve. (Though that's not to say we can't try).
> > It pretty much comes down to who's in your team. Sometimes you get a
> > team which wholeheartedly embraces egalitarianism and passes the
> > keyboard round like a conch shell; other times, you've got someone
> > desperately keen who just grasps the challenge du jour by the keyboard
> > and will hardly let go.
>
> I was offered to take the keyboard (we were in the same team if I'm
> not wrong) and do some coding but I refused because I was both too
> tired and because I felt I was not at the proper level to code that
> problem.
>
> > Which brings me to your suggestion of... well, I'm not sure whether
> > you're suggesting "team streaming", ie a team of newbies, a team of
> > pros; or whether you're advocating specifically mixing the teams up.
> > I'll assume the latter as it seems to make more sense in the context.
>
> wrong assumpion :P
>
> If I'm in a team where other people are way more expert than me, I
> will never want to take the keyboard and start coding something.
> I think they would be bored by my slowness and by my level. My slow
> speed in coding could affect also the whole result (considering also
> that we have a stric time to respect)
>
> > We've tried to make this happen maybe once or twice in the past. It's
> > actually very difficult in practice, because you need people to identify
> > their level of profiency and then divide up on that basis. Actually,
> > maybe it's not that hard: we could just ask people to put, say, 0, 1 or
> > 2 on their name badge at the beginning to indicate perceived expertise,
> > and then somehow use that in the grouping. I don't know: something like
> > that could work.
>
> I would put a 1 in my case, hoping to get a easier (and doable)
> problem to solve.
> If it's still to hard I will try with 0. Better coding something easy
> than just watch other people coding.
>
> > I think people are likely to be self-deprecating when identifying their
> > level. I liked a question that Bruce Durling used a few years back: "Are
> > you more likely to be asking or to be answering questions about Python?".
>
> I won't self depreate ;) if I see that the problem is too easy for me,
> I will go to the more difficoult group the next time, no problem at
> all.
>
> > re bringing easy / intermediate problems along: well, anyone can propose
> > a problem. I think you're suggesting that *different* problems be solved
> > during the one evening, some easier, some harder. I don't say we'd never
> > do it, but in general we like to have everyone working on the same thing
> > so that, when it comes to the show-and-tell at the end, you're seeing
> > how another team solved the same problem you solved.
>
> I understand your point, but.....you really risk that people stop
> coming to the Python Dojo just because they don't feel to be at the
> proper level.
>
> I will probably keep coming anyway, because I really like the "social"
> part of the event (beer, meeting people, making new friends, talking
> about our jobs etc....), but I will keep watching other people coding.
>
> Another person could simply say: mmm... interesting but... not for my
> level. And stop coming. Do you really want this?
>
> > All that said, I'm up for trying anything. I have no issue with having a
> > specifically newbie-friendly session; or with having a problem which
> > specifically splits into an easier and a harder component; or with
> > making teams deliberately mixed ability. But that's just my take.
>
> of course if it's just me wanting this.... no problem, I will adapt
> someway, but let's see what the other people think about.
>
> Regards.
>
> --
> Andrea Grandi -  Software Engineer / Qt Ambassador / Nokia Developer
> Champion
> Ubuntu Member: https://launchpad.net/~andreagrandi
> website: http://www.andreagrandi.it
> _______________________________________________
> python-uk mailing list
> python-uk at python.org
> http://mail.python.org/mailman/listinfo/python-uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-uk/attachments/20130712/10206360/attachment.html>


More information about the python-uk mailing list