Learn this--hacker culture is not optional

Categories: imported

In the past couple of weeks, I've become increasingly aware of how much conflict younger open source projects I'm involved in have compared to more mature projects and projects run by folks with an extreme number of years in open source.

Then I had to explain to my housemate who Donald Knuth is... ...and tell a fellow Drupalista what the Jargon File is... ...and define "grok" for a colleague from the XMPP community... ...and stifle a laugh while my 7-year-old tried to describe the wumpus to someone who should know better... ...after which I read Eric Raymond's recent post on the social utility of hacker humor.

Then I grokked.

In the projects that have been around for a dozen or more years, or those run by hackers who have been, there is a common culture and identity shared by all: we're hackers. Whatever else we are -- country bumpkins, urbanites, gay, straight, bi, male, female, transgender, a particular religion or nationality, old or young, single or married, parent or not, rich or poor -- we are hackers, and all we need to know to work together is that we share that cultural bond of hackerdom.

In the younger open source projects, people are expected to recognize that we all come from different cultures. Not only are we to recognize it, but we are supposed to keep track of these cultural differences and be sensitive to them, which of course means being constantly aware of them. It's all about differences, and "what do people think because I'm a $whatever?"

Meanwhile, I've worked with old-school hackers who were evangelical Christians -- the kind that are as certain of the corruptive nature and future damnation of pagans as they are of the sun rising -- and never had an issue. To those of us immersed in hacker culture, a hacker is a hacker; hackerdom provides enough common ground for us to work together and enjoy it. Without that, people end up bailing out of development discussion because of cultural claptrap.

Successful open source draws on talented people regardless of their religions, sexual identities and preferences, nationalities, disabilities, ages, and other differences. A couple of decades have shown that an extremely successful way to do that is to have -- regardless of whatever else we are part of -- a common hacker culture.

So for the sake of harmony and productivity, PLEASE:

  • Grok some Heinlein.
  • Hunt a Wumpus or two.
  • Remember to bring your towel.
  • If you have trouble remembering your towel, consider investing in sapient pearwood luggage.
  • Read The Art of Computer Programming (yes, the entire series).
  • Read RFC 1149
  • Play Adventure and/or Nethack.
  • Try to "man woman"
  • Keep in mind that Tux is not randy (that would be impolitic!) he's full of fish.
  • And see what Alice and Bob are up to now. ...because failure to look up any of the above via the Jargon File or a search engine kills kittens.

Also, to those of you already indoctrinated in the ways of the hacker, help the newbies around you get some culture. Trust me, it makes us all less isolated from one another, less at odds with one another, and more able to focus on the code.

Posted on September 11, 2010 View Comments

I usually don't write about feminism, but...

Categories: imported

I rarely write about feminism. When I have, it has to point out the foolishness of pushing non-tech women into technology in the name of gender equality, and trying to obscure the ability gap by pressuring competent women to spend too much of their time with the incompetent ones.

This time I'm writing about a brilliant article I came across on twitter (thanks @crell).

The tech industry isn't closed to women, or girls for that matter. I was welcomed from the first day I wandered into the open source world, a self-conscious twelve-year-old farm girl with no feel for tech culture. The problem is that most 12yo girls don't feel like spending their nights in front of a computer screen and line after line of code.

Jolie's article talks about what should be obvious, but no one talks about -- you can't raise a little girl with nail polish and baby dolls then expect her to magically become obsessed with tech at university. I'm sure my chemical sensitivities (which caused extreme illness when I was exposed to clothing stores, new clothes, make-up, etc) had something to do with my becoming a geek.

Will all girls raised in a more varied existence go into STEM fields? Of course not. But those with the talent will discover it early enough to have it inform their goals and personalities.

Please read the article I linked above -- it's really worth the read. I'm going to stop in the office of my son's elementary school this afternoon and offer to resurrect the junior high school computer club I used to run in an elementary version, so that more kids (boys and girls alike) can get into tech. :)

Posted on September 08, 2010 View Comments

On Speculative Web Development Work

Categories: imported

Many web developers, especially Drupal developers (who are in particularly high demand these days), won't touch speculative work, period. With so many options available to us, we can choose work that will pay now over work that might pay some day. Still, not everyone who has an idea has the front money to build it. I have had some luck with speculative web development work over the years, and I thought I'd talk about why I do it and how I choose which projects are worth speculating on.

Not long after I diverted from my former career path to pursue life as a Drupal consultant, I received the following advice from a trusted friend: "Every good independent web developer has a project or two that is their own, besides what they do for their clients." It's turned out that he is right. Good speculative work gives me a chance to build a product I'm really happy with, free of portfolio-harming client compromises and NDAs. It also provides me with important experience following a project through its entire life cycle, so that I can jump into my consulting projects and easily answer "where do we go from here?" no matter what state the site is in. Finally, good speculative work gives me something potentially profitable to do when my consulting business slows down. Instead of having tons of work or no work, I have tons of paying work and a little speculative work to fill in the gaps, which is better than no work!

Despite the potential benefits of developing a few well-chosen speculative projects here and there, there will always be far more demand for speculative development than there are developers available to fill it. I, like every other developer who considers speculative work, must somehow separate the wheat from the chaff. There isn't a formula for a successful project (if there were, we'd all use it and be rich) but here are some key points to consider before taking (or offering) a speculative web development project:

Can I (as the developer) afford to take on this project? If it becomes worth $0, $100k, or $10m how will I feel about my share?

A typical speculative offer from an inexperienced businessperson looks something like this: Alice brings Bob idea and, if he's very lucky, some management or sales skill (none of which matters until there is a product to sell or someone to manage). Bob does all of the development and theming work, provides server resources and possibly graphics. Alice offers Dave 2%-10% interest in the venture. Any developer would have to be insane to accept such a proposal. A typical web start-up with no physical product and a moderate amount of custom development needed will cost $15-$30k in funds, labor, or some combination thereof to get off the ground. Many need more than that. Alice's offer has Bob putting in 100% of that investment (mostly in the form of his labor) for only 2-10% of the profits should the business take off. Meanwhile, Alice risks nothing (having an idea didn't cost her anything) and walks away having either broken even ( 0 investment, nothing to lose) or with 90+% of the profits!

There are some developers who will work with someone coming in with just an idea. I won't, even if I truly believe he/she has the next billion-dollar idea. I don't want to work with someone who has nothing to lose. Having nothing to lose changes the way one approaches a business venture. As the old saying goes, we should all have a little skin in the game. That said, most people with an idea don't want to give 50+% of the venture to their web developer, and few web developers can invest thousands of dollars in development time and other resources in a project from which they will at worst take a total loss, and at best receive only a tiny share of any profits that might come along some day.

What I have found works for me is to take a smaller share of a venture in exchange for a discount on any work performed on the project. This lowers my risk (I can still pay my bills while we get the site running), gets the other participant to invest something (the development money), makes start-up far more affordable for the "idea person", and has slightly better odds than a lottery ticket of getting me a pleasant bit of extra money down the road.

Is this person/group someone I want to work with?

You'll note that I haven't even gotten to evaluating the idea yet. This is on purpose. The idea matters, but it's only one part of the risk/reward equation. I take on very little speculative work -- on average less than one project per year. I'm not going to do work with no guarantee on what the return might be and deal with a giant pain in the rear doing it. I only take spec. work from people I've worked with before. I don't want to partner with someone and then find out he/she is a total crackpot, and I'm stuck with him/her! Whomever I am working with must above all be someone I know I enjoy working with. Who a developer will enjoy working with varies, but some things are (mostly) universally true: we want to work with people who value our work and expertise, and whose skills and expertise compliment our own. We don't want to have to argue with you for hours to talk you out of a flash splash screen or auto-playing audio on the web site. Remember, one of the primary benefits to speculative work (from a developer's perspective) is the chance to build a great product -- the best product we possibly can. In theory, this is exactly why the "idea person" brings in a skilled developer to begin with.

Is the "big idea" here viable?

There's no formula here (or if there is, I don't know it) -- for me, evaluating the "big idea" is tag-team between intellect and instinct. This is not to say that I have amazing business instincts -- if I did, I would have a much more expensive car and a much bigger yard -- but that I can usually tell if something's really hinky. The intellect part of the equation means asking questions like "who is the target audience?" "what is the product?" "how is this different/better than the competition?" "how does this generate income?" "what kind of overhead is involved?" "is there anything out there on which we can gauge the potential success of this project?" and "how will our target audience find out we exist?". Then I think of some other questions and ask them. Again, I must emphasize that I am not a business genius. I do, however, have years of experience watching web sites succeed and fail. If something is way outside my area of expertise, I probably know someone with the knowledge I need to guess if an idea will be worth my time. 90% of the time, when someone offers me speculative work, they either want to identically clone some existing, successful site, or they have a vague idea of making a web site about $something, but have not given any thought to how it will actually generate revenue.

Can my potential partner and I come together on a strategy?

A good idea, without execution, is just a daydream. I don't do handshake deals on speculative projects -- it's too easy to get cheated (or just recall the deal differently) two years down the road when real money starts coming in. Stratagem #1 is making sure that who is putting in what, who is doing what, and who is getting what out, are all down on paper. We also need things like a working budget, a strategy for promoting the site, etc. Hash out the basics early on, when the cost for walking away is minimal to none. Make sure everyone has realistic expectations.

What happens if it all goes south?

If I can't handle a project failing, I shouldn't be speculating on it. Of the four speculative projects I've taken on in the last few years, one was a total loss, one made me slightly more than I'd have made billing normally for the time spent on it, and two have futures yet to be seen. The one that was a total loss financially, ironically, is the one from which I've taken the biggest gain. I was very new to the business world, essentially fresh off the farm where I grew up, and what limited experience I had was working for the military and a military contractor -- which are a world all their own. Working on a venture capitalist (word I didn't know before this project) funded project with a business-savvy partner was very educational!

Posted on July 07, 2010 View Comments

« Previous Page -- Next Page »