philosophy


18
Dec 09

flexibility

fish and grains - vital to our national prosperity

fish and grains - vital to our national prosperity

We all want things, things that we don’t have (if we had them we wouldn’t want them anymore, because we would have them). To get these things we have to exchange goods and service (this is known as the economy).

To obtain the things we want we have a few choices that we can make in life.

  1. Be born into wealth and luxury, like Paris Hilton
  2. Have your rich uncle die and write a clause in his will that you have to either take $3mil or spend $30mil to get $300mil, just like in that documentary, Brewster’s Millions
  3. Through savings, wise investments, and hard work

The way that most of us people bots make our way in the world is by entering into a contract that more or less boils down to this.

I will sell you some of my time for some of your money.

Its a rather simple system, I need some money and have some sort of skill, boss man has some money and needs some sort of skill, match made in paradise. The problem is that no matter how the economy is shaped (and right now its fuck all for the employee end) the power all seems to end up in the boss man’s hands, which is why he is called the boss man.

We find ourselves in this situation, called employment, and are required to do certain task, program this, sweep up that, eat this barrel of industrial sludge. As an employee it is important that we have flexibility. It’s not always called flexibility, sometimes its called “being a team player,” sometimes its called “taking one for the team,” sometimes its called “teaming the team’s teaminess” (lots of teams in this one). The idea though is the same, you are really good at X, Y is somehow (no matter how tangentially) associated with X, would you please do Y for a while? I have quoted Mitch Hedberg before and I will again, because he so eloquently makes the point.

When you’re in Hollywood and you’re a comedian, everybody wants you to do other things that are related to comedy, but are not stand-up comedy. ‘All right, you’re a stand-up comedian, can you write us a script?’ That’s not fair. That’s like if I worked hard all my life to become a really good chef, they’d say, ‘OK, you’re a chef. Can you farm?’

he's mocking angels now

he's mocking angels now

Flexibility is generally a good thing to have, it helps you get along with your coworkers, it keeps you employed, and it let’s you grow as a person. The problem comes when professional flexibility bumps up against personal belief. The “would you program software that kills people” question. Would you program software that helps others kill people, would you program software that helps others disenfranchise people, would you program something you consider harmful, or wrong? Its a good question, one that most of us, myself included, have never had to ask themselves, but its one worth thinking about.

Your livelihood is wrapped up outside of your control, what is the line that you would not cross? Is there a line, do you consider yourself personally responsible for something someone else did with your creation. When does being too flexible, bending too much, become breaking yourself. I wish I could provide you some hard and fast answer, if they want to kill people with your software don’t code it. What people, innocent people, death row inmates, enemy soldiers, context here is key, even then, even if it were a time machine that would go back and punch Hitler’s face off (ignore the many time-space paradoxes this would lead to and the unknowable effects on the time-space continuum) could you create something for the sole purpose of destroying life. It is a question you must grapple with and come to terms, and I would suggest you find your boundary before you are forced to because you might step right by it.

I’m using extremes to make a point, but we are confronted with less extreme examples of this everyday. I run a website, should I put tracking cookies on visitors, should I contact the russian mob and let them put some insidious spywear on my site for a couple of rubles, should I go from tech blog to spam site? Luckily for you I’ve thought long and hard about these things before the russian mob comes to the door, horsehead in hand, threatening my kneecaps. Is it ok to sell user data, which data, when, to whom? Should I take work doing design for an adult website, or a payment gateway that processes it, or an advertising network that supports Glenn Beck? These are personal decisions we must make, and I would urge you to think about it now, know your boundaries, so that when the time comes you don’t make major decisions with the glare of a big payday blinding you to your values


16
Dec 09

making a sandwich

sam waterston is getting ready to rip your still beating heart from your chest, then he's going to go do some lawyer stuff

sam waterston is getting ready to rip your still beating heart from your chest, then he's going to go do some lawyer stuff

Disclaimer: I am not a lawyer, I don’t even pretend to be one, except after watching law & order marathons where I shout “I object!!” at people and that one time I asked my girlfriend if I could treat my dog Harvey as a hostile witness in the case of me vs. whoever pooped on the floor.

I want you to close your eyes (but don’t actually because then you can’t read this). Imagine a world, a terrible world much like the one we live in, but lacking a certain invention, the sandwich. A time-traveling goat went back in time to the 18th Century and decided to kick John Montagu straight in the temple before he could ever ask for “meat tucked between two pieces of bread.” The world never got the grand invention of the sandwich, humanity’s suffering was unbearable.

Then one day as I’m eating a large pile of cold cuts while blogging and I notice that my fingers, slick with deli meat residue, keep slipping off the keys and the hilarious and witty things I wish to share are being turned into unreadable drivel. Spying the bread I keep handy to fend off attack from a flock of pigeons, the feathered rats of the sky, I have a sudden moment of inspiration. I place some bologna between two pieces of white bread and invent, the sandwich!

Being an enterprising young man I decide that this “sandwich” I’ve invented is quite the big deal, I decide that I should patent it and live the rest of my days fat and happy off the profit. I write up the vaguely named “Methodology for encasement of edible substances within grain derived substrate” and submit it to the US Patent Office. Then I show family and friends alike the delicious culinary brilliance that is me and my new “sandwich” to hearty congratulations and spontaneous ticker tape parades.

Then the darkness comes, swift in the night like a badger attempting to steal your young. An evil so despised that merely typing his name brings a cold sweat to my brow and a burning desire to my punch-him-in-the-face-center of my brain. Jared Fogle.

his evil can not be contained

his evil can not be contained

Mr. Fogle decides that this sandwich is big money and so takes my idea and open up a sandwich shop where people can buy a foot long sub sandwhich for $5. He begins pulling in big bucks, soon others join in on the fun and profit, Wendy’s starts putting their signature square patties between buns, McDonald’s hamburg style hand-steaks become “hamburgers” with the addition of a bun, even chipotle starts packing their rice and meat piles in a wrap they call a tortilla. The last straw though is one day, walking down the street, I encounter a young child skipping off to school, after roughing him up and taking his lunch, what do I find?!? A Peanut Butter & Jelly sandwich!?!?! Where is my royalty check you freckled bastard?!

“I invented the sandwich!!” I scream in my head, and then out-loud to the young lad’s startled mother. With a “harumph” I head back to my home, stewing with anger. When I arrive I find a letter from the US Patent Office, after 4 long years of waiting, my patent, “Methodology for encasement of edible substances within grain derived substrate” has been approved. A low rumble of laughter begins deep in my belly and it becomes a diabolical cackle emanating with an other-worldly resonance from my maniacal grin, as I pull out my cell phone and begin to dial my lawyer.

PB & Patent Infrigement

PB & Patent Infrigement

The lawsuit with Mr. Fogle’s Subway sandwich shop is long and arduous, but thanks to East Texas’ interesting take on justice and patents, I’m awarded a $500 million settlement. Arguments abound about how there is prior work and talk of inevitable discovery. These are swept aside in a tidal wave of lawsuits, Wendy’s, McDonald’s, Chipotle, even that freckled young lad. I begin handing out subpoenas like Tiger Woods picks up women, anytime, anyplace (zing!). My team of high powered lawyers are figuring out ways to sue people I hadn’t even dreamed of, I guess a pizza is just an open faced sandwich, sue away my pretties!

My madness grows as I become obsessed with everyone that has ever eaten a sandwich, couldn’t they see my brilliance, where are my residuals!? The populace rightly decides that I am a douche bag and I’m roundly mocked on the late night circuit. This darkens my cold heart into a black pit of vengeance, sandwich vengeance. People are wary of making sandwiches at home, what liability have they opened themselves up to? No one can rightly answer, “experts” abound on the internets claiming this or that, but the murky waters are indecipherable. The Patent Office is challenged, people roundly criticize them for allowing someone to patent such a vague and wide reaching concept. They review the patent and decide that it is in fact a fine and upstanding patent, one worthy of their seal of approval.

The nightmare of a world without sandwiches has been replaced by the new nightmare of a world where I control sandwiches.


Thank goodness though that this is not the world we live in, that such insanity would never happen in this day. Oh, fuck


8
Dec 09

murdering your baby

don't worry, no babies were harmed

don't worry, no babies were harmed

Yesterday my friend Ian sent me a tweet about prosper

@ihumanable I’d be more interested in using Prosper if it provided support for true prepared statements instead of concatenating strings.
6:29 AM Dec 7thpian0

With that my baby was born, the baby was a version of prosper that utilized prepared statements where appropriate. Prosper’s main functionality has been coded for a while and the bulk of the work I’ve been doing as of late has been testing, improving backend support, and adding new functionality. The nice thing about this kind of work is that you don’t have to go mucking around in working code, you are just fixing broken stuff and adding new functionality. The idea of adding prepared statements made me a little queasy, I had briefly looked at it when I was starting prosper but decided that they were so varied that for the first attempt I would just avoid the headache. What’s the problem you ask, let’s take a look at this feature table real quick.

Database Supported by Prosper Can Support Prepared Statements
dBase YES NO
DB++ NO NO
FrontBase YES NO
filePro NO NO
Firebird / Interbase YES YES
Informix YES YES
IBM DB2 YES YES
Ingres YES YES
MaxDB YES YES
Mongo NO NO
mSQL YES NO
MS-SQL YES YES
MySQL YES YES
OCI8 (Oracle) YES YES
Ovrimos YES YES
Paradox YES NO
PostgreSQL YES YES
SQLite YES NO
Sybase YES NO
Tokyo Tyrant NO NO

As you can see the support for prepared statements varies in the Vendor Specific Database Extensions of php. There is also the fact that prepared statement support is poorly implemented in several extensions, they can be coded around but it adds a good deal of complexity. Despite all the reasons not to implement prepared statements, safety, speed, and correctness dictate that I should at least give it a go.

Yesterday and today were my go, and I met with some success. Prepared statements are not all that difficult to implement for a given backend, throw in some question marks, call the correct bind function, and you’re off and running. The real difficulty is the cross-platform nature of prosper. I wanted prepared statements to be a first class citizen, I didn’t want to decrease any existing functionality, I wanted to not overly complicate the way prosper works, and because there are 11 adapters that need to be upgraded, I wanted it to be simple to add this functionality to a given adapter.

I worked and toiled and toiled and worked, I tried hacking something up to make the MySQL adapter work, ran into the bind_results function and screamed at it for a while. Then I got out some paper and drew out some diagrams, thought about sample code. Then I went to sleep. Then I woke up and in the shower pondered the proper syntax for passing around typing information and the division of labor for transformation. Then I hacked on it some more and wrote a quick test. Then and this is the most important part I realized I had done it absolutely backwards.

I had some clues that stuff wasn’t working out right, I hit a point where I would either need to embed an if statement in every function of an adapter or have a duplicate function. I thought that with some clever coding I could shove this down into the base class, it wasn’t great but it was working. Then I saw another red flag when I realized that the processing in the where clause was identical to the processing in the values clause, and I applied some refactoring. This is when I realized that there was a single function that I could have modified and had the whole thing work much more elegantly.

That is when I had to come to the decision to murder my baby. I had painstakingly worked out the kinks for two days, traveling far down this road, touching a bunch of code, and now I realize the best way forward is back. The best thing I can do right now is to revert my changes to Monday morning and lose 2 days of work, and that is great!

It’s not the best outcome, in an ideal world I would have seen this solution before and applied it and not wasted 2 days. The thing is that I’ve learned a great deal, I’ve come up with a much better implementation, and I’ve been reminded of an important lesson, never be afraid to throw away code. The code I wrote is adequate, it works well enough, but it is far from optimal. I could keep going, head down, plowing away making as many problems as I solve trying to build a house on an unsound foundation. The point here is to pay attention to those red flags.

The other important point is that sometimes you have to actually try something to find the thing that will work. You may lose some time, but even after sitting down with pencil and paper, thinking long and hard, the optimal path didn’t come to me until I walked down the wrong road. That’s just life sometimes as a software developer, you have to learn to live with it.

I will continue working on prepared statements for prosper, and I hope that by 0.7 or 0.8 they will be implemented and in there. I still question the syntax and think that I can clean it up, right now the plan is for prosper to support unnamed parameters (?), named parameters (:name), unnamed typed parameters (%i), and named typed parameters (:name%s), but all this seems like a little much. Good thing prosper hasn’t had a 1.0 release yet ;-)


7
Dec 09

php pain

he never forgets, even the stupid decisions

he never forgets, even the stupid decisions

I am a fan of php, ever since my first software development job where I was thrown in the deep end and had to sink or swim. I swam in the sea of php and actually think it is a very nice language (begin receiving hate mail…. now!). You see, I never knew the non-OOP php, I was brought into a well managed project with Classes and Interfaces, it was basically Java with dollar-sigils thrown in. I never suffered through the spaghetti nightmare that so much php is, so I’m admittedly wearing some rose-colored glasses.

There is one feature that I love about php, it is the height of elegance, the associative array. The associative array can do anything, need a stack just use array_push and array_pop, need to do some functional programming array_map, array_filter, and array_walk are your friends. The beauty of the associative array in php is that it is ubiquitous, its a hash map, array, stack, object, all rolled into one.

The problem with the associative array though is that its create syntax is ugly. Here is how you create an array in php

$example = array(1, 2, 3);

That doesn’t seem so bad, what am I complaining about, well the problem comes when you have nested arrays (which is somewhat common).

$configuration =
array(
  'name' => 'My Configuration',
  'server' => array (
    'name' => 'localhost',
    'port' => '8080',
    'users' => array (
      array (
        'username' => 'example',
        'password' => 'example'
      ),
      array (
        'username' => 'user01',
        'password' => 'pass01'
      )
    ),
    'overrides' => array (
      'https' => false )
  )
);

The biggest problem is not that I have to keep writing the word array its that arrays don’t look like arrays. They look like function calls, with other nested function calls, of course the newlines and tabs help out, but they don’t solve the problem. Let’s look at how this would appear in JavaScript using super-awesome JSON.

var configuration = {
  name: 'My Configuration',
  server: {
    name: 'localhost',
    port: '8080',
    users: [ {username: 'example', password: 'example'},
             {username: 'user01', password: 'pass01'} ],
    overrides: {https: false}
  }
};

That’s much nicer and the more important part is that hashes look like hashes and arrays look like arrays. There was a proposed php syntax change that was discussed to death and an analysis here which would have made the following legal php

$configuration = [
  'name' => 'My Configuration',
  'server' => [
    'name' => 'localhost',
    'port' => '8080',
    'users' => [ ['username' => 'example', 'password' => 'example'],
               ['username' => 'user01', 'password' => 'pass01'] ],
    'overrides' => ['https' => false]
  ]
];

But this is not the case, and more importantly, may never be the case. The issue has been brought up and rejected several times, with the following reasoning

I see no advantages here, only another way to do already possible thing and yet another way to confuse people.

- Anthony Dovgal

For the record: I’m -1. array() is enough. Ridiculous idea to begin with.

- Jani Taskinen

There is no reason to add another syntax for *exactly* the same thing, especially because it’s ungoogable

- Derick Rethans

Then there is this

I’m ok with it as well. Like I said over a year ago (*), it is a syntax very familiar to web developers and it feels natural to most people.

(*) http://marc.info/?l=php-internals&m=117060700805108&w=2
- Rasmus Lerdorf (the guy who created PHP)

The problem I see here is that the vote finally breaks down to 1 / 3 contributors in favor and 17 / 20 users in favor, it was then rejected. There is no recourse and as long as the people maintaining php see this as a useless feature, as a “backward incompatible syntax that duplicates already existing one, but 5 characters shorter” change request, it will never move forward.

This is a shame and it is myopic and dishonest. To trivialize this change supported by the vast majority of the php users voting as some sort of luxury people want so that they can avoid typing 5 characters is intellectually dishonest. The major point is that square brackets mean arrays in php, unless you are creating one, then it looks like a function.

$array = array(0, 1, 2, 3, 4, 5, 6); //Create the array
$element = $array[5]; //Get the element at index 5
$array[3] = "hello"; //Set the element at index 3
$array[]  = "example"; //Push an element onto the array

The dishonest part about the argument against the change is that it would be some sort of crazy zany backwards incompatible change and we would never break backwards compatibility. First off, if you are going to classify any addition to the language as backwards incompatible, then stop having a core development team, you are done, close up shop you can’t add anything to the language anymore. Secondly, php has a history of removing and adding things that break older code, anyone remember the first stab at classes, or ever written $stringvar{4} to access a character, that is going away and you should write $stringvar[4] from now on. It’s deprecated as of php 5.3.0 and will most likely be removed as of php 6.

But we are left as a community without recourse, the array function to create an array exists and by that fact alone it will remain forever. The most disheartening thing about the whole misadventure is that because this has been brought up and rejected so many times any time it is brought up now it is automatically rejected as being rejected before. Discussion has attached to this idea a Scarlett Letter, most undeservedly.

At the end of the day I won’t jump ship, but it’s one of those things that makes you stop and scratch your head. Why be so against it? I don’t buy the arguments against it, I don’t understand the fervor that the devs fight against it with, and I don’t see the harm.

As people push the boundaries of what the language can do and the concept of the DSL (pushed by those ruby people) becomes more and more prominent, language cruft will have to fall by the wayside. Not improving array literal syntax is not the end of the world, but the attitudes and egos on display fighting a harmless change that the user base wants could be.


Edit: My arrays were using non-literal keys, which is incorrect as pointed out by Mewp in the comments, they have been corrected. Sorry about that, thanks for the correction Mewp.


4
Dec 09

state of the blog

danger danger will robinson

danger danger will robinson

I was having a discussion the other day with my pal Jeremiah about blogging, on-line presence, and other nerdly things (nerdly clearly a portmanteau of nerd and worldly). We talked about how one drives traffic to a site, maintains quality, and he pointed me to a smart bear. As you can imagine this only spurred more discussion about blog-promotion and self-promotion.

I got to thinking about how I promote ihumanable.com and I want to share with you my method of promoting and how its all working out.

First off I think it’s important to understand my goals with ihumanable.com. You may have noticed that this site has no advertisement, in fact the pixels your eyes are gobbling up cost me money to send to you. I don’t write this blog to make money off of it, so that capitalist drive to push ad-views and click-throughs doesn’t exist. It’s not all kumbaya and hippies though, the general idea is that this blog will help me create an identity for myself which makes me more marketable as a programmer (someone has to pay for these delicious pixels). The main reason I write this blog though is that I love to program and when I’m not doing that I love to talk about programming, this blog gives me a nice outlet for both.

Here is my formula for success

  • Read a lotHacker News, Coding Horror, Stack Overflow, these sites are well worn in my browser. So are Practical Common Lisp, Learn You a Haskell for Great Good!, and Learn You Some Erlang for Great Good!. Read everything you can, read voraciously all the tech, if you love to do it like I do then all the better.
  • Remember things – This goes along with the point #1, if you are reading and reading but not recalling anything, then its no help at all. I have a pretty good memory, but I’ve found that Delicious Bookmarks and Firefox’s Awesome Bar are the most helpful additions my memory could ever use. Example: I remembered the article Jeremiah sent me but had no idea what it was, typed ‘bear’ into the Awesome Bar and bam, there it was, thank you Firefox.
  • Write what you know – Write about the stuff you know, take the time to learn something before posting. Post about things you’ve actually done, that’s how this blog started wanting to share my experiences doing ruby koans.
  • Links are your friends – You might lucky enough to be interesting, but you don’t have to be. Include plenty of links to the interesting things that you’ve read from the point #1.
  • breaking up the wall of words

    breaking up the wall of words

  • Wall of words – People get intimidated by a wall of words, break it up with video embeds, pictures, and blockquotes
  • Promote Appropriately – Every time I post I tweet about it, I’ve posted a few posts on Hacker News and met with some pretty good success. I don’t spam Hacker News though, I like the community and when there is something of interest, I submit it.
  • Make sharing easy – See those things at the bottom of the post, they let you submit my article to social networks, tweet about them (that one’s new).
  • Make it easy to follow – See those icons at the top of the page, one let’s you follow me on Twitter, one let’s you subscribe to the rss feed.
  • Make it memorable – I like to try and find an image to start an article that either captures the article’s content or is just memorable. I also tried to pick a domain name that would be memorable and easy to type, ihumanable.com.
  • Track readership – My hosting company keeps statistics and I use Google Analytics to track readership, this let’s me know what is working and what isn’t.

Those are the basic guidelines I try to follow and the results have been pretty good. I’ve had a general increasing trend in daily readers, and I’ve had a few big blockbuster days. Monday’s article was on the front page of Hacker News for around 8 hours and had 1,806 pageviews. That was astonishing to me. I’ve had some other big jumps in the graph, but the general slope is what is even more exciting, people are starting to read regularly.

I’ve been posting every weekday (missed Thanksgiving and Black Friday) since October 2nd, 2009 when the blog started. I like to think that the consistent posting let’s people know that they can check in everyday and get something new and fresh. This frequency is not required, but a consistent posting schedule is nice because it let’s people know when more is coming and hopefully makes them look forward to the next post.

Here are the things that I’ve discovered that I didn’t realize I would when I started.

  • Relationships – Through this blog I’ve met some cool new people, like Mark Essel, and improved my relationships with existing friends, Jeremiah Peschka and Rick Kierner.
  • Great Discourse – It may be the subject matter or the promotion avenues, but so far the discourse generated by my blog posts have been more than I could ever ask for. Comments are insightful and well-thought.
  • Passion – I never really wrote before and now I love it. I look forward to writing a post everyday.

That’s the state of the blog right now, I’m delighted with where it is. Growth is never easy, there is so much content and so little time. If you refuse to pander, write what you know and love, promote consistently and honestly, you will find people to read your words. That’s why I write, and I would have never guessed what it would mean to me.


2
Dec 09

fortune cookie wisdom

makes delicious chicken

makes delicious chicken

I’m back at my company’s main office today tying up a loose end for a previous client. This means that it’s all the free Diet Dr. Pepper I can drink, a trip down memory lane to the land of .Net, and lunch at Saigon Palace. Saigon Palace is a wonderful little restaurant in the heart of Columbus that serves up a fantastic General Tso’s lunch special. The best part of any meal is the desert, and at Saigon Palace the sweet treat to cap off the meal is the humble fortune cookie. The fortune cookies at Saigon Palace are infamous at work for containing a piece of paper with something written on it that is almost never a fortune, and frequently not even understandable.

Imagine my surprise as I got a fortune today that was a full sentence and it made sense.

Impatience may be appropriate at this time.

That made me sit up and take a second look. I might also be buying a lottery ticket with 20-5-15-51-27-13 on it. Back on track though, it made me think about where I am in life and where I want to go and what I’ve subconsciously been telling myself for my whole life, “Be patient, work hard, bit by bit you will reach your dreams.” It’s the kind of thing that works really well to achieve standard goals, to accomplish lots of things in life it’s not a bad idea. The problem is that its effectiveness can blind you to any other way forward. Then yesterday I read Derek Siver’s There’s no speed limit (The lessons that changed my life.) and this fortune cookie brought the whole story rushing back into my mind. Patience can be a virtue, but it can also be a hindrance. To quote Monty Burns

If you can take advantage of a situation in some way, it’s your duty as an American to do it. Why should the race always be to the swift or the jumble to the quick-witted? Should they be allowed to win merely because of the gifts God gave them? Well, I say cheating is the gift man gives himself!

Now I don’t want to promote any cheating, but sometimes the impulsive, dangerous, caution-to-the-wind approach to life feels like cheating. There is no structure, there are few guidelines, its up to you and your guile to make it. Patience ensures you a slow steady build up, impatience can be dirty and dangerous, it can pay off big or blow up in your face. The cookie brings up a good point though, impatience is sometimes appropriate.

That’s the idea I want to impart today, not that patience is bad or that impatience is good, but that sometimes impatience is appropriate. Gunshot wound, don’t patiently wait for a taxi, demand an ambulance. Production server on fire, don’t patiently wait for the Triage Committee to assemble, put it out. Bored at work, don’t patiently wait for someone to walk by and hand you something interesting to do, go poke around for the good problems, become the person that solves them.

Patience is a virtue, but impatience is appropriate, sometimes. It’s up to you to determine when it’s appropriate, and you will have to pay the piper if it blows up. Learning when its right to leap without looking and speak up when others are quiet is the way that you take control over your own destiny.


30
Nov 09

spinning wheels

keep pushing that boulder

keep pushing that boulder

Back from Thanksgiving, nice break, hope everyone had a good holiday. With the long weekend came some time to eat turkey, spend time with my family, and reflect on life. I’ve been thinking about what I want to ultimately accomplish in life and how to get there. The end goal is to work on complex technical problems and produce something useful for humanity.

I spend a good amount of time on Hacker News which is a great place to find out about new technology. It’s a fantastic community where entrepreneurs and programming geeks get together and talk about technology and startups. It’s the kind of place that incubates ideas that become the next twitter or youtube. Spending time there has made me think that I can do more, do better, it was part of the drive to make prosper.

The problem is that life doesn’t happen in a bubble. You have to buy groceries, pay the rent, and keep the lights on. So I’ve found myself at an odd cross road, I’d rather not continue doing business programming, but I can’t stop. What is a person to do? How does one pursue their dreams while maintaining financial security, is it even possible?

For a long while I’ve believed that you can work a 9-5 to keep the lights on and then work on a side project in the evening. The problem that I’m now finding is that any project that you can hang your hat on and make a living with is going to require more work than what you can give it in the 4 or 5 hours after you get home from work and before you go to sleep to get up for work the next day. Once you throw in trying to have some semblance of a life, it becomes nearly impossible to give a side project enough love and attention to make it work.

I’ve still been working full bore on prosper and its sister project that has yet to be released. The problem that I face now is this ever creeping feeling that I am merely spinning my wheels, and the encroaching danger of professional burnout. Prosper has yet to see any real adoption, which is not surprising its not ready for anything concrete yet, it is unproven, and it is still in a huge state of flux. The 0.5 release and the current bleeding edge on GitHub are fairly different, with the bleeding edge being a fair bit better.

There is no use moping about all this, so I need a plan to move forward with. Can I quit my day job to focus on the side projects, no. Should I give up on my dreams, no. What is the way forward then? Normally I would double down, work harder and push through. The problem is that I think I slipped from the first stage of professional burnout (Physical, Mental and Emotional Exhaustion) to the second stage (Shame and Doubt), and pushing harder, doubling down, may only accelerate this process.

I still believe that I can change the face of PHP database access, that my library can provide a hugely needed service to hundreds or thousands of PHP developers. I still believe in my ability to create useful technologies and solve difficult problems. So I’m creating a list of things to accomplish in the hopes of defeating my professional burnout.

  • Re-institute a workout and diet regimen – Long hours at work and on projects have caused me to spend too many hours sitting around and running to McDonald’s or Wendy’s for a quick bite to eat.
  • Create concrete project goals for prosper – So far development on prosper has been haphazard, I’ll get some idea and then work implementing it. The problem being that this leads to an almost manic-depressive like development schedule. When there is a new feature to implement I could spend 6 hours working on it, then have days and days of nothing until a new idea springs up.
  • Make time to relax – I find that I spend most of my off-time working on prosper or its sister project. The other “down-time” that I have is spent reading technical articles and ebooks about programming. This stems from my deep love of programming, I do enjoy reading about lisp for hours, but I need to rekindle some of my love for other subject matters, too much of anything is a bad thing.
  • Reflect on the good – Too often I spend time thinking about the negative. There are many great things that I take for granted.

Like GI Joe said, knowing is half the battle. This post is more about coming to terms with the difficulty that I’m currently facing, but I hope that it can help others in a similar position. No one is going to hand you your dreams, you have to fight and scrape and kick and scream to make it. It is difficult grueling often thankless work. It’s not easy, but if you want more out of life than a paycheck and a cold grave you must fight for it. The struggle takes it toll on everyone, but by being cognizant of the dangers, and recognizing that you are not impervious to the grind, you can make it through, and hopefully make something unique and beautiful.


9
Nov 09

api design

blinkenlight interface

blinkenlight interface

I’m still working on my skunkworks side project, over the weekend I had the joy of integrating several third party php libraries. I got to spend a good amount of time on php.net reading over APIs and figuring out how to fit them into my project. Some of them were sublime, as though the author had read my mind and knew my exact mental model. Some of them were abominations, fighting me all the way. This got me to thinking about the design of a good API

What makes an API good? There are a few things that make an API really nice to work with.

  1. Similarity of behavior – Writing an API that does searching through a b-tree? Look at how searching is implemented for arrays or strings, and then copy the crap out of that API. This allows the developer to use all that knowledge they’ve built up about searching, so if I know
    array_first($needle, $haystack)

    returns the first instance of $needle in $haystack or FALSE on failure to find $needle, then

    btree_first($needle, $haystack)

    should work the same way.

  2. Readability – Your API should make code that is readable, the function names should be descriptive (without being overly verbose), and code written with it should flow nicely. Avoid using difficult to pronounce function names like strcspn.
  3. Minimalism – You’re writing an API because you are doing something non-trivial, something complex enough that you want a simple looking API to interact with, so do exactly that, make it simple. I’m sure that reflangulating the zyffer is a complex process that involves juxtaposing the allibaster and repeppering the kilgore while making sure not to narfle the garthok, but the reason you are writing an API is to hide that complexity away, don’t write a Leaky Abstraction. Allow me to write code like this
    $zyffer = new Zyffer();
    $zyffer->reflangulate();
    

    Not like this

    $zyffer = new Zyffer();
    $zyffer->juxtapose(Zyffer::allibaster);
    $zyffer->denarfle(Zyffer::garthok);
    $zyffer->repepper(Zyffer::kilgore);
    $zyffer->reflangulate();
    

In the course of writing the API for my side project I’ve found it useful to put myself in the shoes of a new programmer trying to use my API. How long would it take them to figure out X? How often would they curse my name? What is the WTFs/min ratio looking like? It has been a helpful tool to adopt that mindset and ask myself, why am I requiring this parameter, why do they have to call this function before that function, and would that be apparent, why am I making their life so difficult. It has helped my slim down my API considerably, this combined with Convention over Configuration has led to an API approaching “not terrible.”

Then it hit me, I have stumbled upon a big important rule, that I’ve implicitly been following for years, but now my brain is aware of it.

You should write everything like it will one day be a public API

Of course, like any rule that is written in absolutes, there are sure to be exceptions. But I think on the whole, it will serve you well for a few reasons. Public APIs are written to be simple to work with, which means that after you’ve encapsulated all the hard complicated stuff you can interact with a nice clean API. This will make your life nice when working with your API, but the best part is maintenance. Remember that new programmer we imagined to help write the API, that will be you, intrepid API writer, just a few short months after moving on from the API. You will inevitably be called back to add a feature or fix a bug, and if your API is simple to pick up, then you will remember more of it, and relearn the parts you forgot that much quicker.

Another advantage is that a well-written API is much more likely to encapsulate well-written code. When your API is separated nicely and parsed up cleanly between well defined units of work, the code powering them will probably have well defined separation of labor and understandable flow. The API itself becomes the documentation for how a process is accomplished, the various actors nicely laid out as well defined classes and the behaviors as fancy-pants interfaces. I’m certain you can create a clean API over a horrible pile of spaghetti code, just as surely as you can create a crap API over a beautiful collection of clean OOP, but a good API encourages good code.

At then end of the day the API is the face of your code. You can write up all the pretty documentation and how-to’s and promotional websites with sweet web 2.0 reflection and fun oversized graphics, but when it gets down to brass tacks the developer is going to be instantiating your objects and calling your functions. The fact that there is a pretty floating cloud icon isn’t going to make a developer feel any better that she just spent 4 hours figuring out that she forgot to juxtapose the allibaster and that made shit hit the fan when she called the promulgate function on the zyffer’s subclown. Make sure that your code has a pretty face, even if its only you using it, the benefits will far outweigh the minor upfront costs


6
Nov 09

climbing a mountain

I’ve been done with my last big project for about a month now, waiting on the customer to make up their minds on some enhancements. It’s one of those positions that seem enviable until you’re a month deep in it, sitting around trying to find something to do. So I’ve filled my work time tackling whatever tasks have come by, writing up documentation, working on and completing two smaller projects, and reading up on technology. It passes the days but sometimes can be a bit of a bore, and the real challenge is trying to figure out how not to waste my company’s time, trying to make value without a project can be hard.

Stratego... similar to strategy

Stratego... similar to strategic

Then my boss told me that I would be working on a new project. Huzzah! I’m leaving behind .Net back to the land of Java, thus keeping my streak alive of never working in the same language 2 projects in a row. The project position has been described to me as a strategic technical challenge. Let’s break that down real quick.

Strategic – That’s a fun word, what does it mean, dictionary.com defines it (after a great deal of military definitions) as

Highly important to an intended objective

So this is an important position, one which is necessary for intended objectives. From what I’ve gathered of the work I’ll be doing, this is an apt definition

Technical – Nothing touchy feely here, no user interaction, no pretty style sheets, no fancy jQuery magic, just straight CS4xx type algorithms and number crunching. I’m have a feeling I’m going to have to dust off that Math degree sitting in the corner.

Challenge – This is the word I love, the thing I live for, a good challenge. I’ve been working on enough quick one week, one off, hit-it and quit-it projects as of late, I’ve missed the thrill of a good challenge.

I don’t know how much I’m at liberty to share about the project which is why this post so far has sounded a little bit like a riddle. The one point of information I’ll share is that the task I’m going to be taking on was sent out for quotes and the number that came back was… 10,000+ man-hours. You aren’t misreading, and I triple checked that I wasn’t mistyping. In case you aren’t familiar with what 10,000 man-hours means I’ll take a quick detour to explain it.

The Mythical Man-Month

The Mythical Man-Month

In one day, one programmer puts in 8 hours of work, that is 8 man-hours. One week is 40 man-hours. Assuming you get two weeks vacation, one year of development is 2,000 man-hours. That means that 10,000 man-hours of work is 5 straight years of development, half a decade of work. Of course, throwing some more resources at it you could hit 10000 man-hours with a 5 man team in just 1 year, more or less. The problem though is that this reduction in time is non-linear, you can’t just throw 10,000 developers at the problem for an hour, this is pretty well discussed in The Mythical Man-Month.

In less technical terms that means that there is approximately a metric shit ton of work to do. And not grunt work mind you, complex problem solving work. This is a mountain of work. There are a few things that you can do when a mountain blocks your path.

  1. You can turn around and go home
  2. You can rent a helicopter
  3. You can ready your climbing gear

Going home isn’t an option in this case, the task can’t be overlooked and other things can’t happen until we are up and over the mountain. The outside quote was a helicopter, it costs some cash but is easy and relatively painless for you. Well we can’t wait around a year to get this thing done. So that only leaves us with one option, so I’m gathering up some rope and pitons. I’m dusting off the part of my brain that remembers how Java works, remembering that strings can only be compared with .equals(), and fondly remembering the joy that is Eclipse after the ghetto of Visual Studio (holy war can begin now, be sure to insult my mother).

I’m preparing myself for what will be the biggest technical challenge of my career, and it fills me with happiness. It reminds me that I love this profession, that I’m stupid lucky to get paid to do it, and that I’m going to go in there and climb that mountain. From the little information I have, I’m sure the climb is going to be arduous, but I’m determined to plant my flag at the top, and I know that that will be amazing.

I want to challenge you to look around for your own personal mountains, its easy to avoid them, to walk away, go home, or rent a copter. You should instead commit yourself to the climb, because when you are at the top of a mountain, all the other problems are pretty small.