Back On the Market

“The greatest thing in this world is not so much where we stand,
as in what direction we are moving.” — Oliver Wendall Holmes

For the past five years and seven months, I worked at Crowd Favorite. However, I left the organization effectively last Friday, September 2nd, 2016, as a full-time employee. I move forward into new opportunities and possibilities, leaving behind a job I loved at a company that, for many years, felt like my home, and I do so with no specific destination in mind, ready to begin a journey into the unknown. To understand why I made this decision, I’d like to share my history at the company and my thoughts on my departure.

The Early Days

I interviewed at Crowd Favorite in March, 2011 at their Denver office. At the time, the company was a small development firm managed and handled primarily by its sole owner and founder, Alex King. When I interviewed with the staff, they impressed me with the culture they built within the company. The questions I received regarding development challenged me, we discussed the nature of our positions, and Shawn Parker, a senior developer at the company, even made me laugh when he asked me the most important question of the interview process, “Who shot first, Han Solo or Greedo?”

After the interview, as I waited for the bus, I wrote an email to Alex again. I thanked him for the interview, and told him that his team impressed me enough that I wanted to lower my requested salary. I did not believe, after my interview, that the skills I brought to the table were worth the amount I initially believed, and I wanted to impress upon him that the team mattered more to me than a meager difference in my asking rate. I heard back from him quickly, the same month, with an offer of employment that I accepted.

On my first day, Alex told me he wanted unit tests written in PHP Unit for a project the team wrote from the ground up. He could not get PHP Unit to work, nor could the other developers, and he needed to leave for a conference that week, so I had to do it all on my own. That set the tone for how Crowd Favorite positioned itself as an employer. They threw developers into the deep end, and the developers either sank or swam, but did so on their own skills and merits. We had support from the rest of the team when we needed it, but trying and failing until we succeeded taught us the most.

Over the next few years, I learned very quickly what I needed to succeed in my position. I dug deep into WordPress core code, learning where to replace and where to enhance its functionality for our clients. While working on foodgawker, I even discovered some of the limitations that arise with WordPress in large data sets, and constructed a Sphinx Search integration that allowed us to power almost all queries, even simple ones, in a more performant way than MySQL alone provided. I also refined my JavaScript skills significantly through supporting foodgawker, including detailed performance analysis and improvement of the ad management scripts and site behaviors.

When Things Change

Around 2014, Alex informed the team of his diagnosis of stage four colon cancer. In order to ensure the company could survive as his health deteriorated, he decided to sell the company to Karim Marucchi, then-CEO of VeloMedia. Much of our team had difficulty accepting the decision, and felt conflicted regarding the new owners and the management team they brought in, and many team members left immediately or shortly after Alex announced the change. We appreciated the effort to ensure the survival of the company, and our positions within it, but did not trust the changes we foresaw. Under Alex, the company was very developer-focused, working on interesting projects more than worrying about the income, while the new management team brought a lot more focus on traditional business models and practices.

As we transitioned to the new corporate identity, merging VeloMedia and Crowd Favorite, the culture of the company shifted. Much of the quirkier, unique nature of the organization disappeared with the Star Wars decorations and references as they left the office. The company became, over time, a more distributed and remote company. While we positioned ourselves as a technical solutions company more than a WordPress development company, most hiring came from WordPress conferences and individuals known within that ecosystem. Under Alex, we received very few hires in that manner, as he preferred people who did not identify as WordPress developers, but rather developers with a background in a variety of technologies. I found myself feeling a bit adrift and isolated as my friends and coworkers moved on to other opportunities where they felt they fit in better than they would now.

During the transition, we received some work outside the WordPress ecosystem. I refined my JavaScript skills tremendously, and worked on a couple of sites using a newer framework in JavaScript, AngularJS. I enjoyed working on the projects utilizing it, and on creating APIs and custom code with Laravel behind it. Ultimately, I felt a pull in this direction that, unfortunately, we could not sustain as our other developers preferred to stay within the WordPress culture and ecosystem where they felt more comfortable and familiar.

The Final Months

Shortly after Alex passed away in September 2015, Crowd Favorite ran into some difficult times, and it added a lot of stress to the entire team. More benefits had to be shifted, the office in Denver closed, and we moved to a fully-remote team. I found working remote full-time very difficult for me, I would get lonely and demotivated more easily. I did not expect the company to go back to the old structure, but believed that I could at least stick around enough to allow other developers a chance for a graceful exit, and knew that, if there were any chance that things could turn around, they would need me there to help.

Luckily, Crowd Favorite made it through that tough time. However, the stress and isolation had taken their toll on me. I realized that I had not really grown much in the past year, and that the situation still left me stagnant in my salary and my career path. My motivation decreased, and I seldom had the energy to focus on my work to be nearly as productive as they needed. Making matters worse, the lack of energy carried over into other efforts, and even the act of seeking other work fatigued me enough that it would not happen if I didn’t make an active change. I needed to leave.

I met with Jason Rosenbaum, the COO of the company, and told him about my motivation issues. I knew that the company hadn’t seen it, but I did, and I knew they needed their team to be operating at 100% to continue their success and desired growth. We agreed that it may be best for both parties if I seek out new challenges elsewhere. I agreed to stay on a bit longer than two weeks in order to assist with the transition, since I had a long legacy at Crowd Favorite, and a large amount of institutional knowledge to pass on to their team. We decided that my final day should be Friday, September 2nd, 2016.

I sit here now, in my living room, on Tuesday, September 6th, 2016, newly-unemployed. I agreed to a contract with Crowd Favorite to work part-time through the end of the month, and I sent my updated resume out to several recruiters. I’ve heard a couple responses, and interviews and discussions are coming together rapidly. I don’t know where I’m going yet, but I do know my path. It’s time to start this journey again.

Designed to Fail

“Success is not final, failure is not fatal: it is the courage to continue that counts.” — Winston Churchill

One of the most common phrases we hear and use within the software development community is “No program survives contact with the user.” Brief research shows that this is an rephrasing of a similar statement attributed to Field Marshall Helmuth Karl Bernhard Graf von Moltke, in which he stated “No battle plan ever survives contact with the enemy.”

While we certainly prefer not to view our users as the enemy, it is often the case that releasing software, art, or other resources to broader use can reveal flaws inherent to the project itself. In software we call these “bugs”, or if we’re feeling kind perhaps “emergent features.” In art and architecture, they’re often instead called “flaws,” or “imperfections.”

In any case, and by any terminology, failure states will occur. The key is to design both for success, and for failure.

Making Exceptions the Rule

In software development, an “exception” is an unanticipated error state in which the program hit a condition that cannot be fulfilled within its constraints. There are many causes for exceptions. In an ideal case, these will truly come from unanticipated conditions. Perhaps a file we were relying on has gone missing. Perhaps a remote server is no longer responding, or the database has shut off unexpectedly. It’s even possible that, despite our best efforts, a user has found a way to get the program into a state we didn’t plan for which it cannot handle on its own.

When we’re designing a building, a car, a rocket, or a website, it’s very easy to focus on how things should look when everything is working properly. This is the state we’re most concerned about, because we want this to be the state that the most people will see and interact with. As an artist, it is very easy to get focused on all the ways you want something to work without delving further into all the ways it should behave when it doesn’t work.

However, it is naïve to operate on the assumption that exceptions will not occur, or even that they will not be reasonably common. Treat exceptions as the norm. Assume that something can go wrong in any case and condition where it is possible to do so. Write code that allows the software to degrade gracefully. Give the building redundant supports so that a structural failure of one does not bring it down.

Failure By Design

If we operate on the assumption that our project will reach a failure state, we quickly identify that there must be some way to allow the project to continue as best it can while informing the relevant parties that a failure occurred. Total shutdown should be a final resort, not the first line of defense.

Consider Amazon as an example. This is a very complicated eCommerce site, and one of the strongest digital marketplaces in the world. They operate with millions of users, some as strict consumers and others as businesses, pushing transactions of many kinds in great volume throughout the day. The extreme majority of transactions will have no issues. However, in a complex system there are multiple points of failure.

It is possible that they will get enough traffic or orders to shut down their orders database. Even though that database is down, they do their best to never prevent the user from interacting with the site as much as possible. So, even when orders are offline a user may be able to go through the store, read reviews, explore products, search, and add items to their cart or wishlist. It is only when the user reaches the failure point that they are stopped, and when that occurs the user is notified that their desired interaction cannot be completed, but that they can continue to interact with other portions of the site while the system administrators address the issue.

In architecture, this can include stress fracture planning. When you look at a sidewalk or driveway, there are lines through the cement called “contraction joints”. They aren’t structurally necessary and they aren’t particularly appealing visually. In an ideal world and ideal design, they probably wouldn’t be there, so why do those lines exist? They exist for failure, for that undesired state. Due to natural processes, the land under and around a driveway or sidewalk will shift over time, adding stress to the cement. The contraction joints are intentional, structured weaknesses designed to be a controlled point of failure. By having them, the majority of fractures will occur along and down those lines, in relatively straight lines that can be easily patched and filled.

Redefining Success

In many cases, success can be defined as “working exactly as intended.” An application is successful if the user can do everything they’re supposed to do, and if it looks and acts the way it is intended to.

Such a definition of success is insufficient, though, because it only tells half the story. Success does not exist in a vacuum, and is not an absolute state. If everything is working properly, we’re certainly doing well, but we haven’t reached success just yet.

Success needs to be a broader term. Rather than considering success to be everything working as intended, we need to redefine it. Success is not the absolute inability to fail, but the ability to continue when failure occurs. Only the simplest projects can even be presumed to exist in a state where no error is possible, and even then it is still naïve to assume none could occur. When there is no possibility of existence without failure, we must consider success to mean the ability to fail in a controlled fashion and get back into a functional state to continue operating.

Making Better Mistakes

“Let’s make better mistakes tomorrow.” — Alex King

For over 4 years, I’ve worked at Crowd Favorite. When I began working here, the company was solely-owned by Alex King. Though he is no longer with us, he serves as a role-model and an inspiration for much of my approach to my career, and I would feel remiss not expressing my thoughts on how he has influenced me.

About Alex

Alex was one of the best developers I’ve had the privilege to work with. He worked through the .com bubble in Silicon Valley, invented the share icon, helped develop the core blogging framework that would become WordPress, and built a reputation for excellence and pride both in his own work and in the work that was done within his company.

As a developer, and as an employer, Alex had high expectations on himself and his employees. He pushed everyone he worked with to do their best, almost always beyond their comfort and sometimes even beyond their limits. Very little that was less than perfect was good enough. More than once, I witnessed products we branded get delayed due to perfection paralysis. If it didn’t meet his vision, it wasn’t yet ready for it to be seen by others. Alex built his reputation on his excellence, on his demands, and that he would go to the same lengths for a client project that he would go to for his own. Nothing less than the best was good enough.

Despite that demand for excellence, Alex was more understanding than it may sound. He pushed for perfection, and he demanded excellence, but recognized that you cannot have such success without failures. He knew that failure can be a success, because we can learn from it, and accepted that those he hired may do things in ways that didn’t work out. This was especially true as he pushed us to expand our horizons, to go beyond the way things are done into the way things could be done better. Sometimes, we would iterate for significant time trying to figure something out, and still settle on doing it the way it’s been done before. This was valuable time, because we explored other options, we tested our assumptions, and we grew in our knowledge of our applications and our limitations.

Unfortunately, in 2013 Alex was diagnosed with cancer, and had to step away from the business, and from development as a whole. He fought a long battle, and ultimately passed away in September of this year. He left behind a wonderful family, and the remembrances and his ongoing influence among those who were fortunate enough to have worked with him.

“Let’s Make Better Mistakes Tomorrow.”

One of Alex’s most memorable sayings was “Let’s make better mistakes tomorrow,” and I’ve tried to keep that in mind as a I grow and develop professionally, and as a person. As demanding as Alex ever was on me, I have always had the tendency to be equally or more demanding on myself. I’ve had projects that intimidated me, where I felt myself failing before I began, and in those cases I then had to fight both my own fears and the demanded growth simultaneously. That fear only added a greater chance to fail without motivation to grow. Accepting the possibility of that failure, moving past that fear, was where I was able to grow.

I’m still not perfect, of course, nor do I want to be. Perfection has no room for growth, and represents stagnation. I don’t want to be perfect because I don’t want to stop growing, learning, adapting, and experiencing new things. Sometimes it can be difficult to push past that fear, but even that is another opportunity for growth and there is success just in getting past that point.

It can be a very big challenge to accept that things won’t always go well, or that we don’t start out fully competent at everything we do to the same level of excellence as others who have done it for years. It can be intimidating to put ourselves out there to be judged by those we consider superior within a field. It can be difficult to forgive ourselves the easy mistakes, and the missed opportunities, that come up as we develop. We can’t expect to be perfect. We can’t expect to ever know everything.

All we can demand of ourselves, all we can really push for, is to do our best and never stop trying. Let’s not stay in our comfort zone. Let’s get out there, learn, try new things, and make better mistakes tomorrow.

The Paralysis of Perfection

“Perfection is not attainable, but if we chase perfection we can catch excellence.” — Vince Lombardi

For over two years now I’ve owned the devbyday.com domain. For over two years it has sat dormant. There is so much potential, and so much available that I want to achieve, that I wanted to hold off until I got everything just right before revealing it to the world at large. And therein lies the problem. In seeking perfection, I allowed myself to slip into the comfortable view that having nothing is better than having something imperfect. That is the paralysis of perfection.

It’s easy, as a developer, designer, or client, to get into such a mindset. We want the world to see something in a very specific way, and have such expectations, that we would rather reveal only when it’s ready. I find that, too often, this leads to endless iteration, particularly when perfection is not something with clearly defined expectation and goals. Over the past two years I’ve gone through several cycles of evaluating designs, and implementing my own, but never finding the one that truly stood out to me as the perfect model of my design, and my unclear vision.

The Cost of Perfection

At a Mexican restaurant near my office, they have a saying painted on the wall: “Perfeccion tiene su precio.” (“Perfection has a price” in English). This is very true. Apart from the obvious financial components of this price, there are more intangible costs that we pay. On top of the simple costs of hours spent working on a design for this site and researching options, on top of the costs incurred by hosting and owning a domain but not providing any content, there was a price in knowledge.

Until now, I’ve not written anything on this site. However, that does not mean nothing has happened in the last two years. That does not mean there is nothing I’ve learned in the past two years. On the contrary, I’ve grown significantly, in both professional and personal capacities. I’ve had great ideas for posts and articles to write on my experiences. Those ideas are all lost now, casualties to my search for an ideal, and a more substantial cost to that quest. Perfection has cost me money, and cost me knowledge. The worst part is that paying the price for perfection does not mean perfection can be purchased. Perfection may never be achieved, but striving for it without practical concerns will ensure significant ongoing costs.

Perfection as an Ideal

Striving for perfection has a cost, and perfection may not ever be achieved, but that does not mean we should not try anyway. By reaching for the stars, we learn what our limits are. If we give ourselves measures that are impossible to match, we have a lasting gauge for our continued growth and personal improvement.

In that sense, desiring perfection is a laudable behavior. It comes down to the difference between recognizing when that perfection is being used as a measure for growth, and when it is being used instead to push us down and hold us back. For too long, perfection has become my expectation instead of my standard of measurement when it comes to this site, its contents, and its look and feel.

The price of perfection, as an expectation, has gotten too high, and it’s time to start the journey, and share that journey as it progresses, rather than only being willing to provide the results.