Back in December I was approached about contributing to the Pragmatic Magazine. I was told the theme of the issue was Swift and I was asked if I had any good Swift posts that I would be willing to share.

I had a number of Swift posts that I was very proud of and I sent the links to the editor. Then I had a sinking realization that these posts were all from 2015.

Last year was a difficult year. I made a lot of mistakes and had a number of mental health issues. On paper my year seemed like it was incredibly successful, but I felt at the end of 2016 that I had not grown as I would have liked and I was not in a place I wanted to be.

One of my resolutions toward the end of last year was to have more technical content on my blog. I am in the process of writing a book. I intended to have companion blog posts where I share a number of things that I learned while I was writing the book. I have one post that has been partially written since November. It’s nowhere close to being done.

I keep wondering what’s the matter with me. I would like to produce more technical content. I keep meaning to, but things keep coming up. I know if I don’t make time to produce technical materials for blog posts or conference talks or to post on GitHub that I will be left behind. People always want examples of your work and you can’t keep pointing to work you did three years ago.

This morning I found a link to this article. The author talks about a lot of strategies about how to have a long and successful career in tech. This article helped to crystalize in my mind about why I am not producing more technical content.

Those blog posts that I submitted to the magazine were based on problems that took me months to solve. Each one of those posts and every project that I have written about that I am proud of all started the same way. I took something that was hopelessly unfamiliar and tried to force myself to learn it. These were all projects I did for Brad Larson when we were rewriting our code base in Swift.

One of these projects was wrapping libxml2 in Swift. The sample code was all written in Pascal. There was only one post written by anyone for this topic for the iPhone. That person was Jeff LaMarche. I was going to link to his blog post about it in this blog post, but it’s been taken down. So I had an incredibly undocumented technology that no one was using that it was my job to figure out.

I had about a week of complete and total panic and despair. I felt that I had been hired by mistake and that Brad would find out I was an inexperienced idiot and I would be fired in disgrace and I would never work again. I wondered about how hard it would be to find a nice easy call center job where I could cross stitch while talking on the phone all day answering the same questions over and over again. I thought this was hopeless, but it was my job to figure it out, so I had to try.

I spent a lot of time walking. I couldn’t look at my computer without getting a complete headache. I spent some time building robots. I would look at the docs periodically, but not for too long because doing so would cause a migraine.

After several weeks of doing this, suddenly things started to become clear. Instead of looking at a bunch of gibberish and having no idea about how to approach it, I finally had questions. I wondered what this one thing did. I wondered what the difference was between one object and another. I started to understand how to approach the problem.

I completed my task by learning all of this stuff over the course of about two months and I wrote my post. I was incredibly proud of the work that I did on that project and for finally figuring out how to solve it.

I never would have done that project if I wasn’t working for Brad.

First off, I never would have known what libxml2 even was. I would have just used the built in Cocoa framework and fought with it, but found plenty of sample code that I could copy and paste and go about my merry way. More importantly, if I had been doing this for myself, I would have taken one look at the lack of support, said fuck this, and done something else.

Forcing myself to confront something that seemed impossible and pushed me close to my breaking point mentally and emotionally. I have a faulty, tin-plated emotional system. If I get pushed too far I can’t function or learn. My brain shuts down. I had to confront my panic and my fear and force myself to approach this logically. At the beginning of Dune the main character has to take a Human Test. He is forced to put his hand in a box of pain and not remove it. Having mental health issues is like taking a Human Test. You have to think your way through your emotional issues and find some way of logically dealing with them so you don’t remove your hand and get scratched by the Gom Jabbar.

By being placed in a position where I could not simply give up, I was able to push through the initial phase of not knowing what the fuck I was doing to be able to see that there was an end to the Desert of Despair. I understand now that a lot of things I want to learn that seem difficult or impossible are not. I have been trying to teach myself Metal and 3D graphics math for the last two years. I know that even though the symbols seem incomprehensible and there are not a lot of approachable resources out there, I can bash my head against it enough to figure out a starting point. I can look at those symbols long enough over a long enough period of time that I can grasp some kernel of what I don’t understand that I can figure out.

I feel like our community doesn’t reward people for solving hard problems.

It pisses me off every year when Tim Cook announces some amazing new thing at WWDC and some jack ass in the audience gets some version of “Hello World!” working on it because everyone wants to be first. Everyone tries to cherry pick some easy problem that they can solve and post about so that they can show they’re keeping up with the Lattners. I have seen so much pressure in this community to pretend like you know everything. Companies place a lot of emphasis on what do you “know” not “how do you learn.” I admit that it’s a lot easier to test knowledge as opposed to problem solving and learning. I know that we’ve generally used knowledge of data structures and sorting algorithms as a proxy for how we learn. But memorizing some tips and rules doesn’t prepare you for the complete and total helplessness you feel when you confront something you must figure out that you don’t know how to do. You either rise to the occasion or you flee and become a Scrum Master.

I am realizing that most of the things I find interesting are difficult. I am in the process of learning some things that are complicated and poorly explained. I am hoping that after I push through everything I will have a wealth of material to write about on this blog. But I have to accept that what I want to do is hard. There is going to be a lot of invisible work that I do that isn’t being seen. There will be a lot of time spent thinking and processing and waiting for things to click.

Dan Barber is a prominent farm-to-table chef focused on sustainable food production. He wrote an article a while ago that really stuck with me. The gist of his article is that farmers are stripping their soil by only growing the most high profit crops. The soil gets progressively poorer and the food grown on it grows more and more tasteless because it’s nutritionally vacant. He found a farmer who grew an heirloom variety of wheat for bread flour. He thought the reason the flour was so delicious was because it was some heirloom variety, but it was because the farmer rotated his crops. He grew some less lucrative crops on his land that enriched the soil and only grew this wheat on the soil every three years.

I think one reason we have such a high burnout rate in tech is that we’re approaching development like we do farming. We will keep stripping our mental soil because it’s more lucrative to do so than it is to have furlough periods where we push ourselves to achieve truly difficult things. Start ups want to churn and burn developers because they don’t care about a person’s long term viability as an asset. It’s our responsibility as developers to take control of our careers.

Right now I am taking some time off to write a book. Even if the book is wildly successful I won’t make nearly as much money off of it as I would if I had worked somewhere during that amount of time. But taking this time to learn these things that I have wanted to learn for so long has been an extraordinary experience. The process of taking something that seems impossible and being able to make some traction with it makes me feel like I can conquer the world and anything is possible. Compared to a year ago, where I felt like I had to pretend I knew everything and I worked myself into a nervous breakdown.

Last year was a furlough year. I needed it to recover from some bad professional decisions. This year is a soil enriching year. I have so many projects I want to do and write about, but they’re going to take some time to figure out.

I would like to write more about tech on this blog, but I have to accept that I want to learn some difficult things that take a lot of time to figure out. I am not going to have a new post here every week that I am proud of. But if I can get four difficult technical posts on here this year, that’s not so bad.