Write Code Every F–king Day!
I've been planning this post for a few months now. My initial plan was to make it my 100th post, using that milestone to review the things I've done to be best web developer I can be.
But the things I've been doing have led to some very satisfying events during my first month at my new job. So I feel the need to publish this post now in the hopes it will help other web devs, especially the beginning ones.
Both Christian Heilmann and John Resig have discussed these things before, and probably more elegantly than I'm about to discuss them here. But they should transcend to all developers so one more blog post about them won't hurt.
Simply put: write code every day.
Every.
F#%king.
Day.
About the new job
As mentioned in my last post, I left Revlon and took a front end developer position at Everyday Health where I perform a variety of web stack-based tasks. By “web stack,” I mean I work primarily with HTML, CSS and JavaScript.
The first tasks I was given were JavaScript and CSS bug fixes. I also had to rewrite some HTML to make it cross-browser/device compliant, but I dealt with these bugs mostly.
Then I had to refactor functionality inside one of the company's public-facing web applications. This was a straight-up JavaScript task and was tougher than the bug fixes.
I've always been a bit insecure about my web stack skills being up to par, specifically the JavaScript one. JS goes through changes seemingly every minute and keeping up with the changes takes effort.
So I've always been a little concerned as to whether or not my JS skills are up-to-date and went into the new job with this concern. But a funny thing happened: I was able to do everything I was asked to do.
I'm not saying that the bugs were so easy to fix that a five-year old could fix them (they weren't), or that my ability to handle the refactor makes me the world's greatest web developer (it doesn't). I saying that I wasn't intimidated by these tasks because, as it turns out, my skills are better than I'm giving myself credit for.
Why are my skills better than I'm giving myself credit for?
I am 100% convinced that my ability to do the job is the direct result of a decision I made months ago to try and write at least one piece of web stack code a day. I missed some days during the weekends but I'm still writing code on a consistent basis.
Some of the code was for work, some of it was for the lynda.com courses I created. Most of it was just my trying out some new framework or tool, or just playing with a certain part of the JavaScript core API.
I ended up writing lots of code…lots and lots and lots of code. Here's a recent snapshot of my GitHub commit map that proves it:
</p> The blank days on the commit map (particularly those closest to the right) don't necessarily indicate that I didn't write code on those days. It may mean that I wrote code for my employer that shouldn't be committed to my personal GitHub repos…makes sense.
The blank weekend days mean that I took a break to have a life, which is awesome! We're still seeing that I wrote code pretty regularly and as a result of that, here's what happened when I got to Everyday Health:
- finding content inside a complex JSON API and loading it onto the page wasn't a problem for me.
- using jQuery for managing data and state instead of creating fancy fade-ins wasn't a problem for me.
- fixing cross-browser errors related to CSS transitions wasn't a problem for me.
- writing feature detection with pure JavaScript instead of Modernizr wasn't a problem for me.
- creating a responsive web site without Bootstrap or Foundation wasn't a problem for me.
You are a Web Developer Engineer
As I was coding daily, I also had to solve some of the various problems that show up in web stack development. In fact, the bugs I worked on at Everyday Health were fixed by remembering how I solved these problems.
That's important because a big part of a web developer's job is solving problems. It's easily 70% of the job and, at the same time, is the most under-spoken part of it.
It's an assumed skill-set for engineers of all types however…mechanical, electrical, etc. The railroads built across the continental United States in the 1800's wouldn't have come to be without engineers….someone had to solve the problem of laying flat tracks among the Rocky and Appalachian mountains.
Like those engineers, we web devs are also architects that build cool things with code, but our jobs require us to be engineers as we build the cool things. Like those engineers, it's our job to not only solve problems with the things we create, but we need to anticipate the problems before we start creating.
It's because of this that I'm a bit uncomfortable with the term “web developer” and think “web engineer” better describes our jobs. Writing code daily makes you a better engineers…the problem it took you eight hours solve today will teach how to solve it in 10 minutes tomorrow.
Where do you go from here?
You go and start coding. Here's how I suggest you do things:
Conclusion
Alex Sexton delivered the best statement ever for learning web development:
“The only way that I've found that I'm able to stay up to date is by creating. I follow a well-curated list of people on twitter, and read blogs and programming news sites, but when it comes down to it, the only time I'm ever really learning is when I'm doing.
When I want to learn something, I'll just start a project with it, and along the way I'll figure out the other tools I need to be successful. After a few failed attempts, normally I can create something meaningful (that I usually throw away anyways) that allows me to understand core concepts and/or make quick uninformed jabs about things that I don't like or understand.”
In the past, I spent too much time trying to learn by reading lots of books, taking classes and attending conferences when I should have learned by doing. I spent the better part of the last year “doing” and am performing well at a job that I was nervous about at the start.</p>
And it's all because I tried to write code every day.
Every.
F#%king.
Day.