Programming Is Like Sex

Programming Is Like Sex

I had way too much fun writing this post, if you have even half as much fun reading you’re in for a treat. Or a tacky mess you wish you could forget. You never know until the morning after.

So, here’s why programming is like sex, totally.

You have either too much or too little of it

Either you’re starved, or stuffed. Finding the balance point is almost impossible, and never more than a fleeting moment.

One day you are swamped in work, the next three years you are thoroughly underworked. Think about quitting, both the job and programming itself, but then something always keeps you going just a little longer. A little side project, a fun task that you did not expect to land on your desk, that one project at work that keeps you occupied for a month.

You work yourself up, break a sweat, wear your chin high and do the best job you can — only to realize that once you get what you worked for, it was all just a bunch of if-statements in fancy clothes.

It feels different at work than at home

At home, on your own time and dime you can take all the time you want, try out new things, shelve projects that don’t pan out without anyone being the wiser — other than you. You can commit to version control with the comment asdf or lots of random fuckery, and god knows you acted on instinct without ever first creating a task or requesting any permissions.

At work, the same things feel strangely rushed, as if someone could suddenly waltz in and catch you, as if there are suddenly rules to the game that needed none last night.

It’s fun to talk about, but exhausting to do

How often have you heard, even said the sentence “well, that’s easy” or “that’s just a one-liner”? How often have you sat in meetings, engaged and deeply invested in a discussion about possible outcomes, when nobody thought of the first steps yet?

And how often have you sat at your desk, slowly sinking into it as you realized that you totally misjudged the requirements, that you don’t even have the tools to deal with these problems, much less know how to use them? That you over-promised, but couldn’t even tackle the project if you had under-promised and over-delivered? That this is clearly not a one-man-job, but that you can’t admit that to your boss or coworkers?

How often did you go from expecting a no, to actually getting the job, just because nobody better volunteered?

Most people can’t communicate what they want — because they don’t know

You know just fine what I am talking about, people who act like they have all the answers, but can’t even ask the right questions. Who have no clue what they want, but still send you requests that don’t even make sense. Who think you are stupid for being unable to read between the lines that were never written.

A lot of times you want to send back an email to ask for clarification, but know it is wasted effort. The best way to move forward is to just start and figure things out along the way by which direction the push-back is coming from.

Related  I Learned Coding Mostly From Porn

Eventually, you will have failed often enough to understand the lingo, the nuances, the unspoken attempts to clarify what should have been part of the very first email on the matter.

There is art to the craft

If you have ever seen skilled fingers move across a keyboard, fluently entering commands that result in exactly the expected outcome, then you’ll know how different that is from the craftsman who has to work hard, methodically every step of the way.

Some people, they just act on instinct, anticipate the reaction, implement workarounds to the problems that haven’t even arisen yet. They understand not just the function, but the system, and how it fits into the whole infrastructure. They know the source of the problem without an extensive debugging process, they can read the cryptic error messages at a glance.

They are, by all means, artists.

The best results happen at midnight and on weekends

No problem worth solving has ever seen its solution in the bright hours of the day. No good lines of code were ever written sober, or sitting at a desk at nine in the morning.

The process of programming may well start early in the morning, stretch through the day, occupy your mind even well into the evenings — but you’ll write the last line of code that gets the solution to compile in the wee hours of the night.

Or on a Saturday morning, when the blinds are still closed, and so are three of four eyes. Before you had the first coffee of the day, or after the last beer of the night. Sometimes, during lunch break, when you’re fighting various kinds of hunger.

All your efforts are just temporary

Nothing is to last, least of all the successes of yesterday. The best you can hope for is that they open the door to new challenges, that being successful once gives you the chance to being part of the team next time.

The system that you helped maintain last year long has a new developer working hard for minuscule rewards — and slowly your copyright notices are starting to disappear as the whole code is getting refactored.

And that is if things go right, if you aren’t entangled ten years later in a project you should have moved on from years ago.

And lastly: It’s a whole lot of fun

Despite all the shortcomings, all the pain, you’ll still show up for work the next time your skills are needed.

You’ll work your ass off, google all kinds of weird shit that you probably should already know, but either never learned or embarrassingly forgot. How to open a file behind a back, how to unzip a rawr archive. You will clean up in a day what you left unattended for months, just to seem like you have your act together.

You will test and tease, run probes and ping the server in hopes of getting a favourable result. You will run daily monitoring to gauge the effect of your work, and you’ll set your own personal goals to make each day as productive as possible.

And then, at some point, you’ll press F5 and the whole thing compiles.

Related

Comments

No Comments Yet!

You can be first to comment this post!

Post Reply