tutorial 5 : how to become a Better, Faster Front-End Developer

So you're a pretty great web developer already.

You've got some killer CSS chops (cross browser even), perhaps you've been a Photoshop expert for years, and you've got enough jQuery knowledge to make almost any chained animation go smoothly.

But certainly you ask yourself, what's next?

In fact, one of the most asked questions about web development is, "how do I stay on the leading edge?" Chris Coyier recently presented a fantastic talk on the subject, and there are sites fully dedicated to staying up to date on the latest web design news. Addy Osmani's roundup on becoming a better front-end engineer sets some great content out on the board for you to consider on the subject; needless to say, a lot of smart people are thinking about this very subject, so you're headed in the right direction.

In this article, we will talk about a very important way to set yourself apart and become a better developer: becoming an effective rapid interaction developer.

What is "Rapid Interaction Development?"

Rapid interaction development is a term we're using today to describe the practice of rapidly creating something for the web that a user can interact with, specifically with an intention to quickly iterate and polish the interaction. This is not the same thing as designing flat documents; instead, this includes building something that has one or more storylines of interaction.

This may include, for instance, a widget that the user can type into and search, or a dropdown menu that allows a user to select a sub-menu item. These interactive pieces are the building blocks of a larger storyline of the user's full experience of using a website, and thus they are incredibly important to be able to iterate through and "feel". When designing a website, these interactions can make or break the user's experience, and thus could make or break the effectiveness of the site as a whole.

Interactions don't always have "moving" pieces; in fact, rapid interaction development often relies on content hierarchies and hyperlinks as much as anything else. Interaction development takes into account the full interaction of the human with the computer, incorporating intuitions about the userbase, basic understanding of human factors, and a knowledge of the message and image of the organization or individual represented by the interaction.

Understanding the Value of Rapid Interaction Development

If I am hiring a front-end web developer (or anyone for that matter), I will be thinking about five primary things.

1. Does their personality fit my team?
2. Are they talented?
3. Are they efficient?
4. Are they consistent?
5. Can I pay them properly?

These questions are extremely important to any part of the hiring process. The first question is usually decided based off of interaction chemistry - not something we are going to cover in this article. The fifth is usually decided on a case-by-case basis, and is also something that is outside the scope of this article. However, when answering the other three questions, two primary factors play into the judgement:speed and accuracy. In the case of the web developer, rapid interaction development is a way of proving that you have take the craft of interaction development very seriously.

Rapid interaction development isn't accidentally fallen upon when a muse strikes (as may be the case with a more art-driven degree). Instead, rapid interaction development is a skill that is honed by the developer. This skill proves efficiency and talent, and gives more confidence in the developers ability to achieve consistency. To be able to rapidly develop interactions, the developer must have the two magic ingredients: speed and accuracy.

A disclaimer: It may be that someone gets hired because, though they aren't as talented as another individual, they are extremely consistent and have a great personality. This by no means is a "how to get a job as a developer" guide.

Let's Get On With It, Shall We?

With the understanding of the importance of rapid interaction development, we now can understand how you can immediately begin to hone this skill. Some of these tips take a simple change in mindset, while others take an investment of learning or pattern change. All of these, however, can help you become a better, faster, more valuable web developer.

Optimize Your Patterns

Have you adopted a CSS framework? If so, then you understand the value of reusable code. You have most likely adopted patterns without realizing it. In order to prove this, ask yourself, "when I start to build a website, what is my first step?" If your answer is "I don't know", then it's time to figure it out. If your answer is "first I open my text editor", then you've adopted at least one step in a pattern.

So, how do you optimize a pattern? These are often called workflows, but that's not an adequate description, as workflow doesn't include everything we want to talk about here. Some common tools to help you structure your pattern are CSS and JS "frameworks" like Twitter Bootstrap, Foundation, or Topcoat..

..preprocessing tools like SASS or LESS..

..perhaps full optimization and processor tools like CodeKit..

..startup Wordpress themes like Bones, and even the option of building customized scripts powered by a command line. If you're a more advanced JavaScript developer and are looking to move into a new space, you should consider looking at Backbone,Ember, and other (MVC-oriented JavaScript frameworks)[http://todomvc.com/]; it would also be advised to look into Node, which empowers server-side JavaScript. It may take you some time, but picking up and learning some of these tools certainly increases productivity in the long run.

Recommendation: decide on some kind of HTML boilerplate/reusable "index.html" document and associated file structure that follows commonly accepted conventions, is built with semantic markup, and gives a "blank slate" to work from (think: HTML5 Boilerplate). Perhaps if you work primarily with Wordpress or another tool, you'd want to find a similar boilerplate with base-level functionality for that tool.

If you're a bit more advanced, pick up some Yeoman skills for fast project scaffolding and wizard-based boilerplate generation. Decide on a CSS and/or JS framework (Bootstrap, Foundation, Topcoat), and start using a preprocessor for CSS sooner rather than later. Learning a preprocessor is well worth the time investment, and won't reduce productivity as LESS and SASS can both handle vanilla CSS. Try building a full wireframe of a basic layout completely with a framework's built-in classes. You'll likely be surprised how little code you need to write to make a functional layout happen very quickly. This reduces the overhead of writing repetitive code and also has the added benefit of pulling from much more extensive testing and cross-browser considerations than one person can do on their own.

Work With What you Know; Intentionally Learn What you Don't.

It's absolutely important to adopt a lifestyle of learning as a developer. Adopting new tools and skills like those discussed above is a part of the lifeblood of any successful developer. The technology we are using every day is changing faster than anything else; in order to stay at or above our current place in the industry, it is imperative that we learn continuously.

But - it is also as important to understand that learning new technology will slow you down - at first. For this reason, when you are practicing rapid interaction iteration, you shouldn't also be learning a new framework. Instead, intentionally take some time out of your week and dedicate it to learning that framework through a pet project, weekend hack night, or by implementing pieces of the new tool in a project that absolutely needs the new functionalities provided by that solution. This will allow you to maintain your momentum, and solve problems fluently rather than in a stop-go Google and StackOverflow binge. Most importantly, this intentional segregation allows you to focus on what matters: solving design problems instead of code bugs.

As a secondary note, when you are intentionally learning, it also helps to solve problems that already have well-known and well-documented solutions; of course, the world doesn't need another simple to-do application. But creating a to-do application may help you understand JavaScript much more, and may help you in the future when you are synthesizing information in order to solve new problems. Building solutions for problems that already have well documented solutions helps you compare and contrast your solution, and makes it easier to search for help when you get stuck. If you are in uncharted territory and trying to learn at the same time, getting lost is much more likely, and will detract from the goal of the learning process.

Adopt Hyperfocused Mini-Sprints

If you've heard the term "agile", you might have some idea of what a sprint is. Sprints are short, pre-defined work periods where developers decide on a set of goals, and "sprint" to finish those goals within the alotted amount of time. Because we are talking about rapid interaction development, a sprint is well suited to this discussion. Here are the basics.

1. Define
   
   Prioritize tasks/goals, define the length of the sprint, remove or add tasks until the estimated amount of time to complete the tasks matches the predefined length of the sprint
2. Sprint
   
   This is time where you are "in the zone" - zero distractions, etc.
3. Reflect
   
   Once the sprint is complete, check your progress. Did you meet or exceed your goals? What caused the most hangup?
4. Adapt
   
   Learn from what you reflected on, and put systems into place to help avoid the hangups.

In the traditional agile approach, sprints are based on helping with team collaboration and generally last multiple days or even weeks. Here, we are talking about self-management and hyperfocused mini-sprints. These mini-sprints might even simply focus on a single task or interaction, and its associated goals. The process of defining and prioritizing the task or its subtasks before diving into the work, and subsequently taking time to reflect on the process and adapt your workflow or patterns (remember, it's important to optimize your patterns) will help you become more objectively aware of your speed and productivity, and will allow you to be more conscious of what could use improvement at a micro-level.

Recommendation: define two 3 hour sprints for one day, each with a primary task. The purpose of the sprint (as with a physical sprint) is to drive your brain as hard as you can for those 3 hours. After those 3 hours, you will need a brain break; perhaps this is your lunch break, or maybe you've chosen to adopt an alternative schedule to allow for an uninterrupted hyper-focused block of time (more on that later). Whatever the case, planning these sprints apart from each other will help you recharge your brain. It's worth trying completely opposite types of activity (like taking a walk or reading fiction) or even a nap - more on that here. If you work for an agency, perhaps the break in between is the time you set aside for meetings, administrative tasks, or less taxing development tasks. Some people consider this the best way to work every day, and some may choose to do this kind of "sprint interval training" sporadically; choose what ends up making you the most productive, and increases your interaction development speed.

Temporarily Block Go-To Websites

If you are like most people, your fingers have muscle memory; when you open a browser, is it instinct to immediately type in Hacker News, Tuts+, or Twitter? What are the sites that cause you to procrastinate?

Hacker News has attacked this problem in a specific way, offering signed-up users the ability to set up a "noprocrastinate" restriction. There are some interesting tools that also offer these kinds of restrictions, but why not do it yourself? On a Mac, run the following commands from terminal:

1 2 3 4 5 6 7 8 9

sudo nano /etc/hosts # enter your password when it asks for it. # This will open a file in a terminal-based code editor; # Don't worry! You won't be doing much in here. Type the following lines. 0.0.0.0 twitter.com  0.0.0.0 facebook.com  # press Ctrl+C (exit), Y (yes I'd like to save), and enter (save as the existing filename)

You can edit the same file on Windows (see this explanation).

This will block you from using Twitter or Facebook, and will instead redirect you to your localhost (0.0.0.0 is a shortcut to your machine). To get back to social-network-land, just follow the same steps, but remove the lines you added.

Recommendation: Should you block Facebook and Twitter all the time while you are working? We say no. It makes sense to be able to take small breaks between tasks to keep from burning out. However, during a sprint, if these sites are seemingly causing you to waste time, it's important (at least until you break the muscle-memory driven habit) to put them on pause. The important note here is, control your procrastination, even if that means scheduling time to waste. Being aware of the time you are putting into a given activity will help you be more conscious of whether or not that time is slipping away from your control.

Minimize Interruption

Interruptions have long been known to decrease productivity of knowledge workers. (See here, here, here, here - and there is much more available through a quick Google search.) Programmers (and, therefore, web designers) are susceptible to potentially only getting one uninterrupted 2-hour session in a day. In agile methodology, there is the concept of core hours that holds that strong focus should be maintained for 5 total hours per day. This is a far jump from the two hours programmers can expect to achieve in a normal office.

The Anatomy of an Interruption

There are many kinds of interruptions, but we will look at two specific aspects of interruption today. The first are welcomed or "self-inflicted" interruptions, the second are external or "intrusive" interruptions. Both types are detrimental to productivity, and both types can be somewhat managed in different ways.

Self inflicted interruptions occur because you have in some way created space for them to occur. These usually come in the form of programmable notifications (phone, computer, etc).

Intrusive interruptions occur because other humans need you to pay attention to them. The disconnect is the timing and sense of urgency. You must manage your own time, and you must put into place ways of doing so that circumvent the negative effects of interruption as much as possible.

So what do you do to alleviate interruptions? How do you achieve Zen Zone Time? Here are a few of our recommendations.

1. Minimize or completely disable notifications
   
   This includes phone notifications like texts, email, Twitter, and even "chat". Hide your chat windows, and attend to them as a part of your workflow, instead of on a response "demand" basis. This may seem like it will hurt your productivity at first, but you might be surprised how willing people are to wait if it is actually important, and how likely they are to problem solve for themselves if you are too busy to break from what you are doing.
2. Have your management read this: adopt an organizational respect for The Zone.
   
   Create rules in the organization about "zone time" or "maker time". This means there are specific boundaries for when, where, and how you can interrupt someone when they are in the zone. Have specific ways of signifying you are "under", like putting your headphones in or working in a specific part of your office. This is the purpose of "away" messages on chat, as well. Management must set aside time for the cultivation of rapid interaction development!
   Managers - this may seem like a potential threat to the office, but like anything, you can try this for a bit to see what pieces fail and what pieces succeed. You will likely see productivity increases immediately.
3. Isolate yourself
   
   Perhaps the most effective solution, isolating yourself makes you the controller of your space. This can happen in many different formats; for instance, many web designers and developers work from coffee shops to dive into isolation. This will prevent interruptions that happen as a result of physical proximity. Isolation doesn't always mean location, however; if most of the office works from 9-5, perhaps you work from 6AM to 2PM or 12PM to 8PM. This will give you space and time to think and work without interruption. Perhaps you can work remotely one or two days per week? Maybe it's much simpler than that for you, particularly if you are a freelancer.
4. Be diligent with scheduled communication
   
   If you are going to put barriers up around you, you must also be willing to stick to your word and respond to messages when you come out from under the Zone. Don't let this slip, or else the productive aspects of your Zone time will be reduced by the negative aspects of your communication habits. Oh, and don't forget to call your mother!

Game On: Competition and Reward

What makes "hackathon" events so productive? How do people turn out viable products in 48 hours? Perhaps it is a mixture of characteristics.
1. Anticipated, protected, planned time for focused rapid development

2. Competition with others

3. Cash rewards

Hackathons break from the "normal flow" of every day work. Certainly, we wouldn't want to work 48 hours in a row all the time. But the productivity mindsets that arise from this are extremely important. We've alluded already to how important focus and uninterrupted time is. However, it's a worthy effort to consider how creating some personal competition and reward systems may help increase your efficiency in development. This helps set benchmarks and naturally trains your brain to adapt to the behaviors that are rewarding.

Recommendation: if you work with another developer, decide on a competition with clear goals, and make it time oriented. Doesn't really matter what those goals are. Take some time to work through them. Perhaps you can compete against yourself; practice by using the sprints as your competition, and set your goals to increase your efficiency by some amount of time. Set rewards up both for when you are in a competitive mode, as well as for when you complete any focused sprint of work. This will help keep you focused during the sprint itself. A reward may be a physical thing (like a cup of coffee) or something less concrete (like a VIP parking spot for a week or "free time").Dive into the Open Source Community

We will keep this tip short, because the benefits here will be obvious. The Open Source World is full of amazing and talented people building things that help others do their jobs better every day. Examples like the frameworks we mentioned above just barely scratch the surface. Here are some of the benefits to working and communicating with the open source community.

1. Exposure to new tools
2. Free solutions to common problems
3. New solutions to emergent problems
4. A better understanding of problems you may not know exist
5. Opportunity to contribute and become a part of the giving/receiving cycle
6. Thought Osmosis: learning by repetition and exposure

Diving into the open source community and learning to use tools that are offered can immediately increase productivity, but also makes it much more likely that another person could pick up your project and continue developing on that project. Open source allows for people to collaborate around a decided standard and pre-existing documentation. This reduces cognitive overhead for transfer of projects, and makes you a much more literate developer; this immediately translates into higher efficiency.

Recommendation: Get a GitHub account, and start building things with tools available on GitHub.

This is somewhat of a reiteration of what we said earlier - use open source frameworks to solve problems in predictable, patterned ways, and participate in the community of other people who are doing so. Collaboration and discussion are very important keys to learning.

Conclusion

This by no means is a complete list of things you can do to become a rapid interaction developer. Leave some notes in the comments of things you've tried that have worked, failed, or have had little to no effect!