The Day the Meetup Died (and the Triumph of Evil)

I just got an email from meetup.com today that was supposed to be an “apology” for the way they recently announced their change to being a for-pay service. They weren’t actually changing anything, mind you, but they wanted to apologize for how they said it. I’m not sure what was wrong with what they said before, other than the part where they wanted to charge $9/month. $9/year, maybe even $19 per year, I might’ve paid. $9/month is a ridiculous amount for the West Palm Python meetup, which has 8 members, only 3 of whom have ever even RSVP’d “yes” for a given meetup. More often than not, the meetup simply consists of me and Ty having dinner and talking about a wide variety of stuff, most of which only tangentially relates to Python anyway.

Take our last meetup, for example, which was last week. We did get one other RSVP, and waited around outside the restaurant for about half an hour before giving up and going in. At one point we saw a guy who was reading a book on cryptography, which made me think he might be the guy who RSVP’d, but I turned my head for a few seconds and he was gone. Obviously I’m not too good at this whole “meetup organizer” thing. Of course, the only reason I signed up to be the organizer in the first place was so I could change the venue. The original venue set by meetup.com was a TGI Friday’s in western Boca Raton, which was really out of the way for both Ty and I, and indeed would’ve been out of the way for anybody living or working near I-95. So, I clicked on one of meetup.com’s spams asking for someone to volunteer as organizer, and the rest is – or was – history.

So now, meetup.com wants to charge $9 a month for what Ty called “a mailing list and a couple of cron jobs”. To be fair, meetup.com offers more services than just that, but that’s really all that’s relevant to what the West Palm Python Meetup – such as it is – actually uses. Or used, I should say, because I don’t really see the point in continuing it. Ty and I will still get together, of course, but the truth is that we’ve always been talking much more about “getting things done” in our personal lives and business ventures than we have about Python. Ty doesn’t get to use Python much in his “day job” these days, and most of the things I’d tell him about my Python work go in this blog anyway, so there’s really not much for us to talk about on that front.

And as if those weren’t enough reasons to drop the meetup’s “official” status, our last meetup ended up with us concluding that we really shouldn’t be polishing our skills so much, because it’s counterproductive to our financial goals. We concluded that the difficulties we’ve experienced in moving towards financial independence are in fact caused by our skills, which are all “cap ex”. That is, capital expenditures. Software development – or any product development – is cap ex, business process improvements are cap ex, and so on. But if all you have is cap ex skills, you don’t really have a business, you just have a consultancy that can improve on a business.

So, our skills are sort of an attractive nuisance. It’s altogether too easy to start talking about creating a company around some software concept or product, and then drift into thinking about the product and how to produce it, instead of the important part for a business: selling it! What’s really weird about this is that we tell people this stuff all the time when we consult on their businesses. But somehow when we look at our own ventures the consulting part of our brains switch off and we end up employing our skills as ends in themselves, rather than as a means to an end. Ordinarily, we extract the customer’s requirements and design from there, but we never seem to ask what our requirements are.

Having established that fact at one meetup several months ago, we endeavored last week to actually state our requirements with respect to financial independence: levels of risk, level of time investment (e.g. not to interfere with our “day jobs”), etc. Once we did this, it was incredibly obvious why we could never decide before what sort of business would be most workable; we didn’t have any criteria by which to decide! It was also pretty obvious what sort of things we actually should do, and I’m quite excited about it, even though this sort of thing was at the bottom of our list of preferences before. Indeed, I still would rather be able to do one of the more exciting or ambitious ventures we’ve talked about in the past, but I now understand why they would never have worked, and why I always knew that in my gut but could never articulate the reasons before.

The moral of the story (as I jokingly told Ty last week) is that the true secret to success lies in lowering your expectations. Or put more seriously, determining what your real requirements are, and then subordinating everything else to those requirements. In the book, The Ultimate Secret to Getting Absolutely Everything You Want, the author describes this as “being willing to do whatever it takes”. But that means you need to know what it takes, which means you need to know what it is that you really want, including all the small but nonetheless important requirements like, “doesn’t interfere with my day job”.

It actually seems really weird that this wasn’t clear to us before, because again it’s one of those things that we’ve done with software development for a very long time. You absolutely have to have clear priorities if you want to guarantee a successful software project. Indeed, you have to have an organization that is “willing to do whatever it takes” to get the project done, and a major part of that is knowing which requirements are more important than others, because sometimes “whatever it takes” is giving up on a less important requirement either temporarily or for the long-term. What absolutely kills software projects are phony priorities where item A is “more important” than item B, but you’re not allowed to actually trade off item B to get item A. When everything is important, nothing is important. But if you lower your expectations by letting go of less important things, then you are in a better position to do “whatever it takes” to get the more important things.

Or, perhaps a better way of explaining it, is that sometimes “what it takes” to get your most important requirements fulfilled, is that you be willing to give up some of your less important requirements. And often the most important requirements are “nonfunctional” ones like risk, cost, time, and quality. So, if you put lots of functional requirements on your plate, you run the risk of having “whatever it takes” be something like “take an unknown period of time to develop, without any guarantee that you’ll ever succeed”. Strangely, a lot of organizations are more than willing to take that risk, probably because so few projects succeed that nobody really thinks success is within their ability to control.

Indeed, most organizations treat project success as something like the weather: something you can gripe about but don’t really have any control over. I remember once at Verio that a director I reported to once complimented me on a successful project, but something about the way he said it disturbed me, and it took a couple of days to figure out that the reason it bothered me was that he spoke of it as if it was luck. He’d said something about, “boy, that went well, didn’t it?”, in the same way that you might say, “boy, it’s a nice day today, isn’t it?” That is, he was complimenting me on not having screwed up the project, not on making it successful, because he didn’t believe you could make projects successful. (As opposed to avoiding screwing them up.)

So I talked with him about it, and because he was really open to learning, he was able to take the analysis, prioritization, and design principles I showed him, and apply them to other projects under him, making them less like “the weather”, and more like, well, like projects really ought to be.

And so, having finally applied those principles to my own goals instead of merely to those of my clients, I’m now strangely at peace with my life in a way that I’ve never been before (except maybe when I was heavy into Zen meditation). I don’t know how long it will take, but I do know now that I am willing to do whatever it takes.

Before this, there was really only one obstacle remaining: the assumption that I should seek to employ all of my skills to the best of my ability. This concept was at the heart of my Not Evil Enough post a few months back, although most people who’d read that article didn’t seem to “get” what my angst was actually about. Which is probably because I didn’t, either. It’s just that I’ve lived under the assumption of “do your best” for so long that I didn’t even know it was there, or that it was the ultimate source of my conflict.

So, although that article was about a specific instance of the conflict, it’s something I’ve really been struggling with for years. That is, I’ve been trying to reconcile my commitment to “do my best” with a growing awareness that in business, “best” often isn’t. Mediocrity often means a lower risk or higher profit, and if your goal is to profit, then by all means be mediocre if that’s the “best” way to achieve the goal. I’ve always wanted to have my personal business ventures involve some dimension of “best”, like best product, best service, best price, and so on. Somehow, “best profit” or “best risk profile” never made it on that list, which is why I’ve never had more than modest successes.

So, “evil” (in the hacker sense of “suboptimal” or “less than the best”) has triumphed, but it’s me who has won. In a way, I feel like my life is really just beginning, as if a barrier between me and my life had just been lifted. And it has; it’s just that the only barrier was inside me all along.