Where can we find top-notch python developers?

[Nicholas Reville]

Hi, I hope this is an OK spot for this question:

I'm a co-founder of the Participatory Culture Foundation
(pculture.org), we're a non-profit that develops Democracy Player and
some related internet TV tools (see getdemocracy.com). Democracy
Player has a Python backend with native front-ends for Mac, Windows,
and Linux.

We're looking to expand our development team, but we haven't been
getting enough top-quality applicants. I was wondering if anyone
here has suggestions for where we can post or list these job
openings. This is the job description:

Software Developer - We're looking for a solid programmer who can
work independently, communicate well, and occasionally step back from
the code to contemplate improvements to program architecture or our
development process. Most of our code is in dynamic languages like
Python and Ruby, so a clear understanding of language concepts is
important. Email: jobs[at]pculture.org

Here it is online: http://www.getdemocracy.com/jobs/

Any suggestions would be really appreciated and sorry if this is off-
topic!

Thanks,

nicholas

 

[Roy Smith]

Hi, I hope this is an OK spot for this question:

An even better place would be to post your position on the Python Jobs
Board, http://www.python.org/community/jobs/

 

[Alex Martelli]

Hi, I hope this is an OK spot for this question: ...
We're looking to expand our development team, but we haven't been
getting enough top-quality applicants. I was wondering if anyone
here has suggestions for where we can post or list these job
openings. This is the job description:

Yes, this is OK, as is http://www.python.org/community/jobs/ as Roy
suggested, most mailing lists of local Python interest groups (I'm not
sure they ALL welcome Python-related job offers, but I do know that
applies to the ones I read, both Italian and US ones), and so on.

The real problem, though, is that the job market for really top-notch
Python developers is getting really squeezed these days -- around here,
for example, "big-name" firms such as Google, BitTorrent, Pixar and
Industrial Lights and Magic suddenly find themselves in pretty hot
competition for a pool of talent that can't grow fast enough to
accomodate the demand.

You appear to be ready to hire people anywhere in the world, which puts
you in a much stronger competitive position. I know quite a few people
I'd just *LOVE* to hire... save for the fact that I just can't convince
them to move (in fact, in some cases, thanks to the delightful situation
with H1B visas, even if I _could_ convince them, it would still be WAY
uphill from there, darn).

Unfortunately, I entirely understand _why_ most software development
firms prefer face-to-face employees: when I found myself, back when I
was a freelance consultant, alternatively working remotely for some
time, and at the client's office for another part of the time, I saw my
productivity soar by 3-4 times when I was working locally, physically
right next to the rest of the team, rather than remotely -- nowadays,
open-source projects have discovered the same issue, which is why they
have "sprints" with everybody gathering in the same place, where SO much
more good work gets done than when everybody's connected to each other
only via the net... Alistair Cockburn makes similar observations in his
book "Agile Software Development", how it seems projects can be truly
agile only if the team is co-located... ah well:-(. It would be SO much
more convenient, for workers and firms both, if reality would be so kind
to us as to be different!-)


Anyway, best of luck!


Alex

 

[Roy Smith]

Unfortunately, I entirely understand _why_ most software development
firms prefer face-to-face employees: when I found myself, back when I
was a freelance consultant, alternatively working remotely for some
time, and at the client's office for another part of the time, I saw my
productivity soar by 3-4 times when I was working locally, physically
right next to the rest of the team, rather than remotely

Actually, it's a quadratic problem. If your productivity goes up N-fold by
having face time with your co-workers, consider also that your co-workers'
productivity also goes up N-fold by having face time with you.

For the most part I find coding to be a solitary activity (unless I'm doing
pair programming, but that's another post). Face time is good for design,
code review, and solving problems. It's also good for catching snippets of
conversations which aren't directly related to what you're doing but keep
you in the big-picture loop anyway. Most of the really good design work
I've been involved in has happened during random spontaneous hallway
discussions. You start with, "Hey, Joe, what do you think about ...?",
then you go find an empty room with a whiteboard, and a couple of hours
later, you've both earned your salaries for the month. Sometimes, somebody
who you didn't even think knew anything about the topic of discussion will
notice what you're drawing on the board and contribute what turns out to be
the winning idea. That's really hard to do when working remotely (even if
you're both in the same time zone, let alone 5, or 8, or 12 hours apart).

I find my most productive way of working is to come into the office every
day and appear to get nothing useful done. I go to meetings, schmooze,
argue, eat lunch with co-workers, try to sell my ideas to anybody who I can
get to listen, and deal with bureaucratic stupidity. Then I got home and
get in a good 3 or 4 solid hours of coding where there's nobody to bother
me.

 

[Cameron Laird]

.
.
.

Unfortunately, I entirely understand _why_ most software development
firms prefer face-to-face employees: when I found myself, back when I
was a freelance consultant, alternatively working remotely for some
time, and at the client's office for another part of the time, I saw my
productivity soar by 3-4 times when I was working locally, physically
right next to the rest of the team, rather than remotely -- nowadays,
open-source projects have discovered the same issue, which is why they
have "sprints" with everybody gathering in the same place, where SO much
more good work gets done than when everybody's connected to each other
only via the net... Alistair Cockburn makes similar observations in his
book "Agile Software Development", how it seems projects can be truly
agile only if the team is co-located... ah well:-(. It would be SO much
more convenient, for workers and firms both, if reality would be so kind
to us as to be different!-)

.
.
.
Now I'm uneasy.

Alex, you're describing something that's different from
my experience, and I'm alert enough to suspect my own
judgment when it differs so sharply from yours.

Briefly, remote collaboration works for me. I work on
customer premises part of the year, and, while there are
multipliers, my estimate is that they're far closer to
one than four. Sometimes they're less than one--I get
rather impatient with a lot of small talk, and locating
the approved meeting room, and waiting for approved
equipment, and ...

I like working with others, and sometimes indeed it's a
huge gain. Sometimes it's just noise.

 

[Dan Sommers]

On Tue, 21 Mar 2006 00:08:02 GMT,

Briefly, remote collaboration works for me. I work on
customer premises part of the year, and, while there are
multipliers, my estimate is that they're far closer to
one than four. Sometimes they're less than one--I get
rather impatient with a lot of small talk, and locating
the approved meeting room, and waiting for approved
equipment, and ...

I like working with others, and sometimes indeed it's a
huge gain. Sometimes it's just noise.

"We" (myself and at least one former coworker at a huge,
multi-national, telecom company) noted that most software
developers need both:

Design meetings and similar almost have to be face to face.
I can't draw and explain something on a white board *and*
watch your reactions to it and to me over a telephone[1].
We also experienced failure modes during testing for which
logs and bug reports and whatnot just aren't sufficient,
but being in the same room as the person carrying out the
test and pointing things out as the test fails can identify
what's going on in seconds.

OTOH, once the design is set, leave me alone and let me
simulate it or code it, and maybe even get it past the first
round of testing and tweaking/fixing. The last thing I want
now is someone micro-managing and/or interrupting my every
rinse, lather, repeat cycle.

Regards,
Dan

[1] Last time I had the opportunity, which was back in 2001
or so, video conferences and "smart boards" didn't function
as advertised. Color me skeptical.

 

[Alex Martelli]

Design meetings and similar almost have to be face to face.
Agreed.

OTOH, once the design is set, leave me alone and let me
simulate it or code it, and maybe even get it past the first
round of testing and tweaking/fixing. The last thing I want
now is someone micro-managing and/or interrupting my every
rinse, lather, repeat cycle.

While what *I* want, ideally, is pair programming -- somebody sitting
right at my side, alternating with me in controlling keyboard and mouse,
and in verbalizing what he or she is coding -- that's part of the huge
productivity boost I observe in a co-located team... that pair
programming works SO much better that way, that even with the best
remote cooperation tools (subethaedit onwards).

If I can't have pair programming, second-best is extremely frequent code
reviews and submits into the working branch, again facilitated by
proximity -- any question is best asked and answered f2f, often with
whiteboard &c. Phone (VOIP or not), teleconferencing, IRC or other
chats, &c, are pale substitutes, just as you find they are at design
meeting. Maybe another way to put it is: in test-driven development (or
its close equivalent, behavior-driven development, which I haven't tried
IRL yet but sounds interesting) a LOT of design is happening in ways
that intermix at EXTREMELY fine grain with coding and testing. No "big
design up front", no trace of "waterfall", but rather, very iterative
and dynamic processes (including planning and estimating -- they don't
happen quite as continuously, but can't wait for "occasional" meetings
either).

Wanna talk debugging? I think solo debugging is even worse than solo
programming -- when I just CAN'T have a debugging partner for a
sufficiently nasty bug (race conditions are the worst, but there are
many other categories vying for that title;-), I'll turn to one of my
beloved plushies (I'm firmly convinced the baby tiger is by far the most
effective debugging partner for most bugs, though Tux the Penguin has a
knack for helping spot bugs that aren't MY fault but rather the
compiler's &c -- since I've been using Python for most of my coding for
years, poor Tux hasn't seen much action recently) -- I talk out loud to
the plushy-partner to make narratives out of expected and observed
occurrences. But a *LIVE* partner, actively checking out the coherence
of my narratives and challenging them and proposing alternatives, is 10
times more effective... the plushies don't even talk back (except in
debugging sessions that have gone on for *FAR* too long;-).

Yes, there IS a place for long solo rides -- but in my experience that's
normally one, maybe two days a week; that may vary by team, by project,
and by person (I deal with interrupts better than most people, and I'm
keener on all sorts of social interaction, bonding and networking,
_including_ small chat, than 99% of the top techies I've met and worked
with), but I doubt the effective range is any wider than 0 to 2.5
days/week. And even if I'm wrong, and a Joe Supercoder I've never met
works best with 3 days a week of solo effort, 3 days of solo coding plus
2 of strong in-person interaction is NOT the same thing as, say, 3
_weeks_ of solo coding plus 2 of close in-person presence.

Essentially, to support "non colocated" team, you can't really have the
team meet in-person for more than about one week every month -- in my
experience, that just isn't anywhere like enough to get top productivity
(in projects conducted by agile methods -- if you're NOT using agile
methods, but either "seat of the pants" or "waterfall", you have far
worse problems to deal with than where people are located;-).


Alex

 

[Roy Smith]

And even if I'm wrong, and a Joe Supercoder I've never met
works best with 3 days a week of solo effort, 3 days of solo coding plus
2 of strong in-person interaction is NOT the same thing as, say, 3
_weeks_ of solo coding plus 2 of close in-person presence.

It's not hard to imagine somebody locking themselves in a cave, coding like
mad for a week, and producing reams of working code. What *is* hard to
imagine is that somewhere along the line they didn't get off on some
bizarre design tangent and what they produced is reams of code that works,
but does the wrong thing, or in the wrong way, or just plain isn't what we
needed.

I think the real advantage to pair programming is that it gives you lots of
small course corrections, before you're emotionally invested in The Wrong
Thing. We sit down together, I come up with a brilliant idea, and you
shoot it down. We argue about it for a while, and 10 minutes later I
(hopefully) see the error of my ways and we set off again in the right
direction. Contrast that with me showing up with a week's worth of code
and you pointing out a fundamental design flaw I made four and a half days
ago. By this point, I've got so much invested in the code, I'm more likely
to just dig my heels in. It's just too painful to admit at this point that
everything I did last week is garbage.

Pair programming is not easy. One of the hard things is to learn to let
go. I can't tell you how many times I've been sure I'm right, but decided
to let my partner have his way because otherwise we'd make no progress,
only to have him volunteer 15 minutes later, "Hmmm, maybe you were right
after all". Actually, I can tell you. It's about the same amount of times
it's happened in the other direction. Sometimes the best way to win an
argument is to take a dive and give the other guy enough rope to hang
himself with

 

[Ed Leafe]

While what *I* want, ideally, is pair programming -- somebody sitting
right at my side, alternating with me in controlling keyboard and
mouse,
and in verbalizing what he or she is coding -- that's part of the huge
productivity boost I observe in a co-located team... that pair
programming works SO much better that way, that even with the best
remote cooperation tools (subethaedit onwards).

I've often noticed that programming for me is akin to composing
music. Now let me start by saying that while I can hum pretty well,
I'm not a musician of any sort, so this is based upon the experiences
related to me by others who are (btw, there seems to be a very large
overlap between programmers and musicians...).

I can be mulling over a particular problem for hours, sometimes
days, and do nothing but write some pseudo-code or a couple of trial
programs that don't really do what is needed. Then, at some
unpredictable point, clarity sets in and I see the solution. After
that, it's just a matter of transferring that into code (for which
Python is by far the best language, as it doesn't get in my way).

The people I know who write music tell me of a similar process: they
play a few bars or write a few words, but it doesn't feel quite
right. Then either a particular musical hook comes to mind, or a set
of words that solidifies the image of what they were feeling, and
after that the song is written in their head and just needs to be
transferred to tape (or bits, as is more common these days).

I can't wake up one day and plan my day like this: 9-12, write some
killer algorithm; 12-1, run errands and eat lunch; 1-3, add algorithm
to existing code and refactor; etc. Nor can the musicians I know plan
of writing the first stanza of a song in the morning, the second
after lunch, and the chorus in the evening.

The other similarity is that some musicians tend to be more creative
when off by themselves, while the rest seem to feed off of jamming
together with others. Most of them strongly prefer one or the other;
rarely do they employ both. The comparison to programmers would be
that I seem to resemble the former type, while you seem to resemble
the latter.

I strongly agree on the benefit of code review, though, especially
in my case where things tend to get written more or less
unconsciously. While the main problem may be addressed well, there
are either side/end cases that still need to be addressed, or there
is an opportunity to refactor to make it fit in much better with the
project as a whole. A partner who is not emotionally immersed in the
code can usually see these things better than the person who created
the code.

Wanna talk debugging? I think solo debugging is even worse than solo
programming -- when I just CAN'T have a debugging partner for a
sufficiently nasty bug (race conditions are the worst, but there are
many other categories vying for that title;-), I'll turn to one of my
beloved plushies (I'm firmly convinced the baby tiger is by far the
most
effective debugging partner for most bugs, though Tux the Penguin
has a
knack for helping spot bugs that aren't MY fault but rather the
compiler's &c -- since I've been using Python for most of my coding
for
years, poor Tux hasn't seen much action recently) -- I talk out
loud to
the plushy-partner to make narratives out of expected and observed
occurrences. But a *LIVE* partner, actively checking out the
coherence
of my narratives and challenging them and proposing alternatives,
is 10
times more effective... the plushies don't even talk back (except in
debugging sessions that have gone on for *FAR* too long;-).

OK, we part ways on the plushie thing, but here I have to agree with
you: a second set of eyes (and brain patterns) helps immeasurably
when debugging. I think the key here is having to explain what you
did and what you thought the code should have done to someone else
clarifies the problem, whether it's explaining it to someone else in
the room, or trying to explain it in an email to a list like this. I
can't even begin to count the number of times that I've been stuck,
and decided to post the problem to a list for help, and in the
process of composing the email, figured out what my mistake was!
Those netiquette guidelines for posting intelligently aren't to help
the readers of the post; they're to help you form your scattered
thoughts into a coherent picture, and more often than not, if it's a
bug that I've created rather than a gap in my understanding, the
process of writing the email is all I need.

I guess if there's a point to all of this, it's that good
programming is a creative process, and that you need to identify what
works and doesn't work for you. There is no one-size-fits-all
approach that is the "best".

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com