Why the Perfectible Job Beats the Perfect Job

I’ve changed jobs a lot over the past few years. I knew it would raise eyebrows each time I applied for a new position – they’d ask themselves how long I’d stay with them – but I told myself it was because I was looking for the perfect job, so it was ok.

I’ve realized the perfect job just isn’t out there.

There’s something wrong with every job. The dress code is too formal. The boss won’t let me work from home. They’re not using my favorite language. They’re not promoting me. They don’t give enough vacation hours. The codebase is old and crufty. Etc.

The trick is to find a perfectible job, not a perfect one. A job with a boss and a team that’s flexible enough so that you can improve the job over time.

After all, my interests will shift over time. Even if I found the perfect job for what I want to do now, I’ll grow out of it in a few years. And then where would I be? Leaving the perfect job, and torturing myself over it.

Better to find a job with a few rough edges that I can smooth out over time. As long as I go in with my eyes open, I won’t be disappointed.

Because perfecting your job is just a different type of engineering.

How I Failed to Get Clojure Adopted at my Workplace

I’m a little obsessive about the tools I and my co-workers use. If I come into a company and they’re still on svn, I push to get us switched to git. If people have to login to a remote server to develop on via a slow internet connection, I figure out how to get a local VM install to do everything we need, and share it with everyone.

So when my current company started experiencing pains with PHP, and the other devs talked about switching languages, I immediately thought of persuading them to switch to Clojure.

Why Clojure? It’s fast. It’s code is compact but still readable. And it’s got the power of Lisp.

I got permission to build some internal tools in Clojure, and set to work. I thought it was just a matter of time before the other devs would “see the light” and start switching over to Clojure.

Nine months later, we’re still building everything in PHP. No one’s even looked at my Clojure code. Beyond some jokes about Python, there’s been no further movement toward switching languages.

I’ve failed.

But why? In order to document my mistakes, so I and others can learn from them, here’s what I did wrong:

No Expertise

I’d only been using Clojure for a little over a year when I started building those internal tools. I’d never deployed a Clojure application, didn’t know too much about how to write tests in Clojure, and had only done hobby projects using it.

As a result, those internal tools I built were full of bugs when they launched. When I got pulled off of working on those tools and back to working on the core company applications, those bugs stayed – for months – without being fixed.

My co-workers’ first experience with Clojure was of a buggy, slow application that didn’t do too much. That first impression was hard to shake, even after I went back and fixed bugs and improved the apps.

No Designer

Not only were the web apps slow and buggy when they first launched, they looked terrible. I got so focused on using Clojure that I ignored the user interface, and didn’t get a front-end developer to help me with it.

No Maintenance

Some of the my co-workers were brave enough to use the applications I’d built, despite the bugs and horrible user interface. They all had good feedback, and gave it freely.

I documented everything they told me, capturing it in Jira tickets, and then sat on them for months.

Why? I’d been pulled off of internal tools to doing other application development. So instead of being able to iterate with my users, constantly improving the application, they had to wait a long time before they saw any changes. I lost what goodwill I’d had to start with, because I didn’t respond to their needs.

No Training

None of the other developers had any experience with Lisp. But instead of hosting a training session, or calling for a special code review session with Clojure as the topic, I waited for them to “come to me.”

I was certain that some of them would peek at the Clojure code, just to see what it was like, and then start asking questions. I told myself this was the natural, organic way to start spreading Clojure knowledge around the organization.

I was dead wrong. The other developers had a hard enough time deciphering PHP code from 2 years ago; they weren’t going to spend time trying to read my stuff too. Especially since it was buggy. And slow. And hard to use.

Conclusion

In the end, I should have been much more proactive if I wanted to see Clojure adopted at my company. I should have given them some training, carved out some time every week to maintain the applications, and gotten some design input from the very beginning so the tools would be easier to use. Even then, we might not have decided to switch to Clojure, but at least then it would have been an informed decision, based on well-working example applications that everyone was using.