There Exists No Masters
Facing problems as a web developer, alone
A year ago, I left the relative comfort of a salary job to pursue a career as a freelance web developer.
Leaving the “who’s” and “why’s” for another time, the reality of my situation shifted drastically. My previous job, working in marketing at a software company, presented a pool of hundreds of mentors that could help solve the many technical problems I would run into. Now, that number was zero.
As a developer, I was quite suddenly alone.
I struggled at first. The web is not an agreement among professionals. It’s a wild frontier of trends, opinions and ideas that continually evolve. It’s fluid, and that makes it both exciting and infuriating. Knowledge of it can never be complete. There exists no masters.
This presented a problem. I was expected to be a master of my trade. To speak authoritatively on all matters of the web. But the knowledge I possessed was far from complete. I had worked in the industry for years, and felt comfortable with certain problems, but the collective weight of my unknowns created a serious restraint on my confidence.
As more projects came to completion, however, I soon identified a pattern. It went something like this:
- A problem appears and I’m stumped.
- It sounds insurmountable. I have no experience with this sort of thing. It’s a mystery. There is no hope of success.
- I get ahold of myself and begin to research the problem.
- I solve it.
At first, this pattern infuriated me. But over the last year, I’ve learned to identify it early and deal with it more effectively.
Let’s look at those steps with a little more detail:
1. There’s A Problem
A problem is anything I don’t know how to solve. It usually comes from the client’s desire for a certain functionality. The rest of the team has agreed that it should be there, it’s been designed, now it’s time to build it. Quite often, the complexity of this last step is vastly underestimated. It’s my job as a developer to swallow any lamentations on that fact, and state whether it can be delivered. The answer is yes, it can. They don’t need to know the details until I figure out exactly what they are.
2. The Problem Is Insurmountable
This is the fear that comes from a problem which is my responsibility to overcome. No work gets done on this step. It can involve irrational feelings of resentment toward the project manager or client for not understanding what the request involves. I’ll try to come up with reasons the request is a bad idea. Occasionally I’ll just be indiscriminately upset and not really know why.
It’s worth having a discussion with the key players here. Understanding why the problem needs to be solved is a good first step to overcoming this irrational dread. Communication helps everyone feel better. Like a big cozy blanket.
The other day, a designer I work closely with commented that one of the benefits of separating design and development roles is that the designer has no idea how difficult a feature is to implement. If it’s the right move for user experience, the designer just adds it; they have no trepidations about including a feature that will be a massive headache for the developer. This creates stressed out developers, but it also creates a better end product. So everyone wins?
3. Let’s See If The Problem Is Actually Insurmountable
Once I’ve pulled myself from the aforementioned pit of despair, I turn to Google. I was coming-of-age (whatever that means) before the Google era, but I’ve repressed those memories. Future generations will be ignorant of what life was like B.S.E. (Before Search Engines). I’m at least young enough to maintain a feeble grasp on the massive effect search engines have had on knowledge and problem solving. And I’m forever grateful.
The research phase starts slow and stupid. Over the course of trying to solve one problem, I’ll generally make between 30 and 50 queries, gradually pinpointing the correct terms, solving one chunk of the problem, and unearthing new ones.
About 75% of the research/solving phase is Google searches and stackoverflow articles. The artistry of a great developer is their ability to perfectly word a search, so that the desired article tops the list, and then scan it in less than a couple seconds to determine whether the correct answer is in there. You lose points every time you touch the mouse.
The reality is that someone has had your problem already and solved it. You can argue the integrity of copying and pasting other people’s code, but in the meantime, I’ve just solved the problem.
Search, copy, paste, tweak, test, repeat. Until…
4. The Problem Was Not Insurmountable
Rejoice! I’m a legend. I’m a god. No one cares.
I try to act cool. Those closest to me are occasionally forced to suffer an enthusiastic demonstration, where I click a button and what they thought would happen, happens. I look expectantly into their eyes for the praise they’re no doubt about to lavish upon me, and am always disappointed by their feigned excitement. The rational part of me understands that I should not expect a parade for something that just works properly, but I’m not quite there yet.
The feature is delivered, the team is happy, and the project moves on. No parade, but good teammates will always find a way to appreciate the work that’s been done, and I’ve been lucky enough to have plenty of those.
What This All Means
I’ve learned that I don’t need to draw my confidence solely from some static reserve of knowledge. I have faith in my process, in my ability to solve any problem I come up against, regardless of the daunting exoticness of its first impression. This allows me to be flexible and agile. The knowledge that I gain is by necessity. No superfluities exist.
This process of problem solving has also taught me that the frustration and stress that stems from encountering a new problem is fleeting. Understanding that has helped me in situations far beyond the keyboard. Looking at all the steps at once will always be frightening. Taking the first one rarely is.
Bryce
brycekirk.com
