What I learned from walking away from a project
A while back, I started working on a web project with a new contact that I had met through a friend. Before I got started, I knew I was familiar with the platform having worked with it regularly years before, though it had been quite some time. As it turned out, certain things had changed enough for that experience to not be meaningful anymore. At least, my deep knowledge of the required workflow had since faded somewhat.
A few days into starting the work, I realized I was in over my head. As a front-end developer, the designs were straightforward enough to implement fairly easily. In this case, it was highly customized and pre-configured, and it took time to figure out what I expected to be simple things. I realized quickly just how little I knew about their customized system, and how ineffectual I would be in getting things done.
I was banging my head on the keyboard in frustration. Why did I say yes to this job? I thought to myself. It would be terribly inefficient for me to keep working on this, and the chances of successfully completing it in time were shrinking by the hour.
For the sake of the success of the project, both for my new collaborator and for their client, I made the decision to step back from the project, and offered their money back. We had a positive discussion about it, and agreed to part ways for this project on good terms, both of us knowing that something had to change.
Did I give up too soon?
I’m an experienced and capable developer, so I know I can work with confidence with most things that I set my mind to, even in new platforms in which I might have little to no experience or knowledge. Upon reflection, I don’t think I was premature in throwing in the towel in this case, despite only working in the project for a short period of time - this time felt different.
The constraints that I was was working in were (from my perspective) too limiting and time consuming, to the point where I wasn’t able to do my best work without investing a substantial amount of time to drastically change how I work. This isn’t a commentary on whether or not the system was a good one, but it was one that, ultimately, I wasn’t going to be effective working with.
The Lesson Learned
As an independent contractor, it’s important for me to be able to deliver solid work for my clients, in a timely fashion, both for the sake of their project’s success, and for the success of my own business. I realized that in this case, I wasn’t working in my sweet spot. Not even close.
It doesn’t work to try to be all things to all clients, just because I’m a developer who can build websites. At this juncture, I may not know 100% yet what that sweet spot is, but I knew this wasn’t it.
In reality, while I haven’t specifically narrowed down into a particular niche, there are certain areas of expertise that I have developed over the years. I’m great in WordPress, CSS and JavaScript, I know Vue and React, I have good knowledge of Accessibility standards, and have delivered a high number of quality web software projects over the years. In order for me to be able to deliver the kinds of work that I know I am capable of with a high level of quality, I realized that I need to stick to these areas of expertise. Anything else would be a waste of everybody’s time.