New hire cannon fodder

I recently read Some French Guy’s lamblast of YCombinator, the start-up-firm firm that doles out angel investing to young kids out of college hoping to be the next Google.  Unfortunately, I can’t say I’m surprised at the state of the ‘ideal’ career in software, but I can again reiterate how appalled I am at this frat boy mentality that has infected our culture.

It probably began with Microsoft, but you can see its effect at Apple (notably Steve Jobs’ notorious temper) and I’m sure it’s at Google too (except it’s far more sinister there.)  If you have recently graduated from college with a CS degree, congratulations, your stock options are just behind that Machine Gun nest.

Why these large firms, and now even places like YCombinator continually think the best way to move forward in software is to hire as many gullible young naive programmers as possible and work them to death is beyond me.  It’s pretty well known that 80 hour work weeks and inexperience is a guarantee to continually make the same damn mistakes over and over again.  It’s also an open question as to why new hires let these companies take advantage of them so badly.  Paul Graham had a start up, he begged for angel investing, and his life should show you – what does he do now?  Well he learned from his experience that designing and building is for chumps, to make the big bucks and sit on your ass you become an angel investor.

Kids will work for pennies.  You can continue to fill their heads with dreams of having the next big idea, even though they are carrying all the risk for you.  Junior developers, whether entrepreneurs or otherwise, are being asked to give up their 20’s, probably the best, most energetic years of their lives, to have a chance at making a dent in someone else’s bottom line.  (Make note, the one exception here I’ve seen is 37 Signals )

Is it our culture?  A friend told me after visiting Japan that it was a workaholic culture.  It was considered rude to leave the office before your boss did, and the only way your boss got to be the boss is because he stayed the longest.  So they go in at six in the mornings, leave at twelve at night, get drunk at the bar (because you’re expected to go hang out with your friends after work to network) and do it all over again the next day.  The culture sounded familiar.

Junior designers see lack of sleep as a ‘badge of honor’, they see long hours as proof of their worth.  If another developer stays later than you, drinks those extra cans of redbull developing, well then, by God, he’s the best coder alive.  Only that he isn’t.  But he is spreading a lifestyle, through adopting it himself, that is counteractive to real progress at the company and lets face it, quality of life.  If Steve works harder than you, then your PHB(Pointy Haired Boss) is going to expect his influence to make you work longer and longer hours.  This looks good on paper despite the psychologists all telling us that we get no more work done.

We nerds didn’t really grow up playing sports, but we shouldn’t be surprised to find out we’re probably the most competitive people alive.  We’ll constantly try and outdo each other in our quantity of hours put in in an effort to truly see who is the best hacker.  But have we never stopped to think who truly is benefiting from all these hours?  Do we get paid more?  No.  In fact, because many of us are salaried, we’re effectively paid less.  Are we compensated with faster promotions?  Possibly – but don’t forget about that silicon ceiling.  The only person who knows how many hours you’re putting in is probably just the guy above you – but he makes sure to show just how productive his department is (via your hard work) to everyone.  He will always get the spoils.  Who will end up really getting the spoils out of any of YCombinator’s work?  Paul Graham.

We’re the infantry and this is World War I.  The officers, the generals, are actually less knowledgeable of modern warfare than we are because they haven’t seen it.  We see it every day.  We know that hours don’t turn into value, and we know that faster means slower.  Yet, if we’re lucky, they might afford us a moments rest before they order us to charge, bayonets mounted, towards that next machine gun nest.  Our wiser calls to bombard it with artillery, or charge it with tanks, go unheeded.  Those are untested technologies, after all, and anyone who doesn’t charge a Machine gun nest is a coward and doesn’t deserve to be called a hacker.

It’s a class war between the people who know how to get something done and the people who are slowly realizing they play no more role in modern development.   And I really, honestly, want no part of it.

We mere coders are artists, dreamers, idealists.  But we must face facts – we are unnaturally naive, we believe that one day, somehow, our talent will be recognized and rewarded by some benevolent, all powerful manager.  We refuse to work together because we refuse to acknowledge just how bad it’s got.  We refuse to ask for more because we refuse to acknowledge how little we’re getting.  We refuse to stand up for ourselves because we refuse to acknowledge how screwed over we are.  We are the talent, the knowledge workers in today’s economy, and many of us are fearful of our livelihoods being lost to some cheaper person over seas.

Some escape, some make it.  Make no mistake – a coder CAN change the world.  But I have yet to see a coder escape and not turn around and punish the next generation.  It seems that once a person realizes just how screwed over they’ve been, they can’t wait to screw over the next guy.  Like hazing in college.

There’s little I can do to convince you.  Little I can do to change the culture, really, because we are that competitive, and we are that arrogant to believe that we would never be screwed over like this.  We’ll never admit that working long hours has sacrificed relationships, family, entertainment, career development, education.  It’s just ‘a part of the job’.  I can, however, make fun of you for it.  And I think you should do.

So if you take anything else from this, junior developer, it’s that you don’t have to put in that extra 10%.  You don’t have to stay the extra hours to get ahead.  But you can make a snide comment while walking past the cube of the guy who refuses to leave work.  Maybe one day he’ll get it, but until then, he’s machine gun fodder.

[edit: Fixed typos.  Keep my feet to the fire or I'll never learn.  Thanks MichealMichael and Joe.]

Unit Tests as a Negative

There’s a constant debate between hacker types and PHB(Pointy Haired Bosses) types over what exatly it means to ‘design’ software.  While many things in software that we consider ‘design’ are helpful in one way or another, they don’t suffice for a design like you might find in other engineering disciplines.

For example, if I gave you a ‘design’ for a bridge, a blue-print for a bridge, it would then be a completely mechanical effort after that to build the bridge.  The design is a peice of knowledge that captures all the decisions that must be made to build a bridge, leaving only the physical work to be done.  (I realize here I’m simplifying bridge work but stay with me…)

In software there’s no such thing, and we can prove it by contradiction.  If you were to give me something that could be turned into ’software’ with only mechanical effort, i.e., some sort of ‘design’, similar to designs in other fields, what would you have actually given me?  You would have given me the CODE for that software.  Compiling IS the mechanical work of software, as our field is entirely knoweldge based.  There are no materials to put together once the ‘design’ is complete, and the idea of removing all decisions means you’ve specified your software so much you might as well have coded it.

Programming languages are, after all, our best attempt at describing a language that allows non-ambiguous description and determination of a system.

In other words, as the hackers have always said, “The Design is the Code”.  This point of view is very attractive, but I want to add a nuance to it that might show room for comprimise between hackers and PHBs.  Software starts out at a high level – if you’re doing waterfall, you start out by building requirements.  If you are doing agile, you start out by gathering user stories/cases.  Most of us probably start out doing a little bit of both – we need to start at a very high level description of the system we’d like to build.

This would be like being asked by a city to build a bridge over some river.  You still need to scout for a location, secure funding, go through designs given to you by architects, etc.  The use case phase is similar.  As we drill down, we can turn use cases into smaller and smaller sequences of behavior the customer wants, or more and more detailed requirements on different parts of the system.  We do this, ideally, until we get to the point that it’s more effective to use code to describe what the system should do than to use high level abstractions like sequences and stories.

But our requirements, our user stories, they are not just providing a means to drill down into what our system is supposed to do – they are levying TESTS on our system.  The highest level we can call verification testing, but ultimately, for every use case, one should imagine that there ought to be an automated way to test that use case to ensure the system we are building fulfills that case.

Like plaster being poured into a mould,  our software is ‘poured in’ to these implicit tests.  The mould defines where our system stops.  Similar to photography – when we create a photograph, we not only have the picture, but the negative.  The negative defines the complete opposite of the picture, and if combined with the picture would simply look like a meaningless gray.  It is through the difference between the negative and the picture that form takes place.  Likewise, it is not just in code, but also in our means of testing that code, that our true design forms.

Specifications, requirements and use cases all are simply high level views of ‘test-driven-development’.  A test is just the negative of the software that fulfills it, and together, the test and the software, do you have a true design.  If we focused more on continually refining our requirements and use cases into actual test automated test cases, at the lowest level, then we can take advantage of TDD from the begining in.

After all, for anyone who’s done TDD, what’s the first thing you do when you start out with a blank slate?  You decide what it is you want your new object to do, and then you write a test for it.  A specification can be seen as a test (unfortunately they do not exist in that form very much today).  A specification can be seen as a negative of the software that it produces.

For every object in your software, there should be a negative, a thing that describes the exact opposite, partnered to that object.  If your software provides a function which you plug in 3 and get out 6, then you should have a negative that plugs in a 3 to some nameless thing and expects out a 6.   These are two ways of describing the same thing, but as art like photography and sculpture shows, you need both to move forward.