TCLP 2008-06-18 Inner Chapter: Hacker Work Ethic (Comment Line 240-949-2638)

This is a feature cast.

The hacker word of the week this week is deep magic.

The feature is an Inner Chapter on the hacker work ethic, drawing heavily from my own experience on what motivates me to hack.

[display_podcast]

Grab the detailed show notes with time offsets and additional links either as PDF or OPML.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

3 Replies to “TCLP 2008-06-18 Inner Chapter: Hacker Work Ethic (Comment Line 240-949-2638)”

  1. I’m not sure I agree with you about the valuation of ancillary functions in open source projects. Documenting is certainly seen as less prestigious than coding, but it’s certainly appreciated, especially by the people who read it.

    Project management gets shrugged off not so much because it’s seen as unnecessary, but rather because unlike documentation or artwork it’s pretty easy to pretend to do the job when you’re really not qualified. Further, unless you’re contributing on your employers time, you’re really only going to be interested in scratching your own itches. If a community project manager tells you to work on x instead of y, you really have no reason to listen to them. Even on the planning side, you can only wield the carrot or stick of getting into a particular release.

    The successful community project managers aren’t just that, they’re also lead developers who have the justification to say “This is where we’re going, this is what needs to be done, and this is when it needs to be done by. Feel free to pitch in.”

  2. User appreciation doesn’t directly effect or inform the hackers who may not value those functions as directly, though. My point wasn’t about overall appreciation, but specifically the views that touch on the hacker work ethic.

    I do wonder how projects of scale address the necessary evils of project management. Mozilla has been in the press for their bug triage and is clearly able to speak as an organization to what will and will not make it into a release. For that project, at least, that implies there is someone, somewhere saying exactly, “You will work on x instead of y.” Given Mozilla’s origins and operations, they may be more exceptional, but I doubt they are entirely unique.

    I will grant the blending of roles that more often works. And I think having a project manager also be of strong repute as a developer resonates well with the core hacker ethic itself. Sadly, not all lead developers are equally well equipped to make a respected code contribution and make good decisions on the non-coding priorities.

  3. I’m not entirely clear on how Mozilla is organized now, but it the past it was an exception. It’s a lot easier to say “you will work on x instead of y” when you’re signing the pay cheques. If you’re not, you have to draw on the goodwill bank, which is a lot harder to measure and you risk driving people away from the project.

    I agree that not all lead (or just strong) developers are necessarily the best choice for project management, that’s just the easiest way to fund the goodwill bank.

    I find this issue quite interesting, because it seems to me that the most successful free software projects are those that have found a way to address it.

Leave a Reply

Your email address will not be published. Required fields are marked *