Imagine if you were a rock or hip hop musician and had to seek a green light for your art from an institution called the Ministry of Culture and Islamic…

Every developer starts about 100 projects that never end up going anywhere. So many good ideas, so few executed ideas. Just about every software developer that I know has a folder structure that resembles the one shown. More than a handful of incomplete projects that seemed like a great idea once upon a time. Like many of you, I’ve had many ideas for great products / companies and even started down the path of implementation for some of them. A bot that determines arbitrage opportunities between eBay and Amazon. A social network for referral based businesses (plumbers, electricians, software developers, etc). A bitcoin search engine. A CSS framework for the days when Bootstrap wasn’t literally everywhere. A “hot or not” that found people from Instagram. A real-time visitor analytics engine. The list goes on. I’ve started on just about every one of these projects (and more), but never saw them through to completion. In talking with my developer friends and colleagues, I find that the story is oft repeated. Some folder on their computer that lives as a graveyard to high hopes and incomplete dreams. I’ve wondered why this is. Success as an Obstacle We, as an occupation, are blessed with high employability. Currently, the national unemployment rate is around 6.7%, while the unemployment rate for web developers is closer to 1%. Our salaries are also substantially higher than the average. In 2012, the median income for software developers was more than $90,000, now of course, if you’re any good, you can far exceed that. Having taught complete n00bs before and watching them become entry-level developers has brought me a great deal of personal satisfaction. But it’s also brought them financial satisfaction, with starting salaries ranging from $45,000 to $70,000. So it’s clear that software developers are generally successful. Yes, there are thousands that completely suck. There are many that are not paid well at all and can’t hold a job for very long. But I’m making a generalization here, so allow me the liberty to be general. A halfway decent developer is a relatively (compared to the general population) successful person. This success can paralyze and inhibit the completion of goals, however. We are far from hungry and we’re too smart to think that we can ever be foolish. The impediment of Knowledge We know so much. We can talk about the shortest way to travel between multiple cities. We understand how to take large problems and break them into smaller sub problems. We can tell you the best way to “abstract” whatever your system is into discrete units. We are true polyglots as we can say “Hello World,” in any number of languages. We don’t shy away from situations that might require thousands of calculations since we understand the power of recursion. We know a lot, but is that enough? The great Einstein once quipped: A little knowledge is a dangerous thing. So is a lot. Sir Isaac Newton, one of the smartest men of his time, could accurately predict the movement of celestial bodies so many millions of miles away. He stood on the shoulders of giants to see farther than anyone else had. Physics wasn’t his only interest as he also (co)gave us calculus. Surely he could understand how money and markets work, right? Wrong. During 1720, at the peak of the South Sea Stock Bubble, he threw down a ton of cash and went broke. All of his knowledge didn’t help him one bit, because he failed to understand the dynamics of markets. His knowledge was not domain independent — he was a master of moving bodies, but that did not translate to the psychology of his fellow traders. We too are like that. While we can explain algorithms and data structures all day long, we may not inherently understand what people want. When the twitters first came about, I suspected it was just a fad that would disappear. I was wrong. We often seek sexy solutions without realizing the mundaneness of the problem. Career ADHD I’m sure the same holds true for any major city, but I am speaking of my experience and the experiences of my colleagues and friends in the New York City area. We jump around in our careers. We swing between startup, corporate, agency and “just taking time off.” I realize this doesn’t hold true for everyone, and the trolls of the internet will leave comments with how they’ve stayed at the same job for 19 years, but I have found that those with the passion / interest in having a side project, often don’t stay at one place for too long. I think that this Career ADHD leads to many abandoned side projects. Sometimes a new job starts up and the demands of getting caught up there mean putting the side project on “pause.” Sometimes we lose interest because the side project was aligned with something that we were doing at our previous job. While logistics is a reason that switching jobs every few years makes it much harder to stick to a side project, there is something to be said about the mentality of switching. If you can change your job in 3 years, why not change your side project in 3 months? You’ll have a better idea at (seemingly) the exact moment that you hit a wall in your current side project. Fixing It So I’ve identified a few reasons that I think that I have so many unfinished “great ideas.” Admitting it is the first step. Understanding the reasons why is the second step. Now, for the third step — fixing it. It won’t be an overnight solution and many of my projects will remain forever abandoned, but after thinking through it a bit more, I think I’ve come up with some steps to help this from becoming a pattern. You are Awesome First, recognize that every side project makes you a slightly — or in some cases, substantially — better developer. Your skills are the sum of the times they’ve been applied, so the more you develop, the better you become. Learning new technologies / languages / frameworks is a great reason to start a side project. Even if it never finishes, something was accomplished. So, first realize that you don’t always have to finish every project — as long as you walk away with some gain. Build parts of Projects You’ve started so many projects and, as you got wiser with each, hopefully you learned to reuse code. Building modules and libraries instead of rewriting everything each time. Assume that whatever side project you’re working on now may not be the last one, so you’re better off grabbing components from it instead of of building specific things that ONLY this project can use. Documentation matters, so leave notes for yourself that can be easily applied to the next project. Do it with Others Now that we’ve gone through successful ways to fail completing a project, let’s try to complete some! It may be your brilliant idea, your baby, your future billion dollar empire, but as of right now — it’s nothing. Share it with other people, the more the merrier. The natural excitement will continue to propel the project forward. Maybe you can even open source it, to encourage community participation? Relying on others and having them rely on you keeps you foused and accountable. Solve problems you Have Rather than making your next project an iPhone app that lets you take pictures of food while you travel by bicycle in cities that have cloud cover 43% of the time where the nightlife consists of urban zoos that hold endangered genders of overpopulated species — try to make something that you would ACTUALLY use. If you’re a developer, solve developer problems. If you work for an agency, create something that agencies would like to use (see: 37 signals). Even in your personal life, you invariably have some small problem that technology can solve, so why not create something to solve it? That way, even if it doesn’t actually go anywhere big, at least you built something useful. Size matters, so stay Small Don’t create an enterprise XYZ when the timeframe to do so would be 8 months. Focus on something you can create in 4 weeks, part time. Scale your features back to keep a monthly release cycle, no matter how simple. Having something shipped has a strong psychological component that further encourages you to work on it. Something sitting on your laptop for 8 months that has never seen the light of day is almost depressing to work on. It’s all about the little wins, since the journey is a marathon instead of a sprint. Brag until you Fail Social pressure is a real thing. It’s why skinny jeans became a thing. Instead of working in secret, tell people what you’re working on. The feedback you get might help shape the product. I can assure you, no one is out to steal your idea. It’s extremely hard to execute even a simple idea, so don’t worry too much about that aspect. Share your idea, it’ll validate (or invalidate it), shape it and most importantly, commit you to it. We don’t want to let people down and we do want to save face, so tell people what you’re working on.

You hired a new developer for a project you’re working on and she seems to have solved all of your problems. She’s been on the job for 3 days and she’s already suggested upgrades for 5 of your libraries and re-organized your JIRA issues. At every turn, she seems to validate your choice in hiring her. She’s found 8 bugs that were glaring and would have caused a critical meltdown. How terrible was your previous developer that he couldn’t have spotted any of this?? She’s baffled by his decision to use the XYZ framework and doesn’t understand why he chose to use Postgres instead of CouchDB for this particular application. She complains to you that the lack of a CDN is costing you HOURS in needless content serving. How could you have been so blind to not see any of this? Well, it wasn’t your job, right? That was your previous developers’ job and he seems to have failed miserably. Good riddance. The curse of the present Don’t worry — your situation is far from unique. I’ve seen it time and time again that a new developer comes in and seems to change everything almost overnight. She or he suggests new tools, new processes, new languages and new everything. All of this while badmouthing the previous developer or team. I’ve been on all sides of this fine play. I’ve been the “previous developer” who got badmouthed by the new guy. I’ve been the new guy that used the previous guy as my scapegoat. I’ve hired developers that have been in both positions. I’ve worked for companies that couldn’t see what was plain to me: this happens all the time. It’s what I call the “curse of the present.” When you, as a developer, look at the choices used to build a particular application, you’re blown away at the poor decisions made at every turn. “Why, oh why, is this built with Rails when Node.js would be so much better?” or “how could the previous developer not have forseen that the database would need referential integrity when they chose MongoDB?” But what you may not realize is that you are seeing the application as it exists today. When the previous developer (or team) had to develop it, they had to deal with a LOT of unknowns. They had to make many decisions under a cloak of opacity. You are cursed with the knowledge of the present, so the system seems like a hackjob of bad decisions. Pass the blame Another reason that developers tend to blame the previous developer is because it’s easy. The previous developer no longer has to justify his actions and isn’t there to defend himself. So blaming him is super easy. If a developer doesn’t want to work very hard or solve a particular problem, it’s far easier to blame something inherent in the system rather than laziness (or incomptence). When the boss asks “what’s the timeline on the [whatever],” it’s easy and convenient to say “well, normally it would only take 2 weeks, but since we’re dealing with an older version of [some library], it’ll probably take a month.” It may be true that the older version will take more time, but it also may be true that you, the developer, just don’t feel like working very hard this month. Justification You hired this new developer for a reason. After a series of interviews, some coding tests and whatnot, you finally hired this person. Now, this person has to justify that they’re worthwhile. Developers tend to think that a great way to do this is by making BIG changes early on. Implementing all sorts of processes that don’t need to be implemented and introducing all sorts of tools that no one else on the team has heard of. I’ve seen countless permutations of this behavior, where a developer will come around and say how bad using Pivotal is and that we now need to use JIRA or they can’t believe we’re still using Subversion and how we should move to Git. It justifies the knowledge that we have and hopefully impresses you, oh glorious boss. End it I think it’s a bad practice to simply blame the previous developer or team for something. Give them the benefit of the doubt and assume that they made the best decisions they could under the constraints they had. They didn’t have the knowledge of the fully baked system. In the short term, it may impress the overlords that brought you into the organization, but in the long run, it hurts us all. We’ve all been that developer that’s been blamed for countless problems after we leave — it doesn’t feel very good to know that it’s happening to you, so why do it to others? Take the moral high ground. Even if it is the previous guy’s fault, don’t frame it like that. Be a hero in the long run by being a solid team player that makes good judgement calls whenever you can. Don’t be the short-term hero that throws people under the bus. You’ll probably get away with it, but we (the developer community) won’t like you very much if you do. Now, granted, there are certain cases where the previous developer was a truly terrible developer. In those cases, make the stakeholders aware of everything all at once, rather than as a convenient excuse for you to use whenever you either don’t want to do something or can’t.

Rarely does a week pass when I’m not asked if I've seen some new JavaScript library or framework. Actually, some of them are new and some of them have been around for a while. A friend will tell me he has just completed a project using a particular technology stack. Then, I hate to admit I immediately go look it up and start thinking “I wonder if I should be using that too”. After this, the hunt starts for YouTube video tutorials and a few articles confirming that this is in-fact what I should be doing. I’m in search of confirmation that everything else I've been using sucks and this is the one technology which is better than the rest. What’s wrong with this? Its exhausting! It’s an exercise in tiresome repetition and a great way to not learn anything well. Most developers I know enjoy their work. They may not like their current project, but in general they like what they do. Despite whether they went to school to study computer science or got their entire education from Stack Overflow, the good ones will spend time outside of work improving their skills and trying to stay current with technology trends. But how do you choose what to learn when there is an endless amount of technology options out there? How do you stay current when you work a full-time job and live in one language or framework all day everyday? Here are a few suggestions I would like to make to help put your mind at ease. Don’t worry about what you don't know. There is a lot you don’t know, and by the time you learn something you will discover 3 other things you don’t know. Technology never stops moving . Do not torture yourself by worrying about it. Every developer gets the same 24 hours in a day as you. I used to think I was behind everyone else until I realized this obvious fact. Technology can move as fast as it wants, but individuals only have so much time available. There are not legions of developers out there learning day and night, leaving you behind. Logic is logic. If you are coding, regardless of language or framework you have the training to pick up another technology when time permits. All languages use loops, variables, arrays, functions…etc. You just have to learn new syntax and ways of doing things. “But you still haven’t told me how I choose what to learn!” I've narrowed this question down to three sub questions I think you should be asking yourself. What does my employer want me to learn? Ask yourself what you need to learn to move up or around in your current job. This may or may not be the most interesting technology to you but if mobility at your job is important, learning C# when every application your company builds is in PHP will not help your chances. What are people hiring for in the industry? A keyword job search on Cybercoders or any other tech job forum will tell you what people are hiring for in the development world. You can easily see areas that are in high demand and get an idea of where trends are headed. What do you have a personal interest in? Hopefully you are one of the developers that I mentioned above. You like coding and you are going to have something you want to learn regardless of the previous points. Whatever it is, start building something with it now. Your personal satisfaction is what drove you to study and its important to maintain that. In closing I would like to say “be knowledgeable”. I love to read articles on programming and web development. I follow a few awesome blogs and take the occasional tutorial. This is mostly just to keep my mind aware of what is available. If a problem surfaces, often I’ll recall something I read in passing that might help me solve it. I think this is the best any developer can do while working and keep his sanity. Try to stay knowledgable and sleep well at night. Tomorrow is another day.

Often, entrepreneurs ask me something to the effect of, “What’s the best way to let new users explore my product?” My answer is almost always a variation of, “Stop it.” In order to be slightly more helpful, let’s look at why this is a terrible question. Users Don’t Care About Exploring Your Product Nobody cares about your product. Fundamentally, what users care about is themselves. They are using your product as a means to an end. We knew this back in 1960 when Theodore Levitt explained that when customers buy quarter inch drills, they really are buying quarter inch holes. Think about the last time you bought a drill. Did you sit down with the drill in order to spend time exploring it? Not unless you’re some sort of drill fetishist. What you almost certainly did was try to figure out the fastest way that you could set about completing the project for which you bought the drill. The same is true of whatever product you’re building. I know that you care deeply about the user interface of your product and all of the delightful features you have so lovingly handcrafted. Sadly, nobody else does. At least, not in the same way that you do. People want whatever your product promises to do for them, and they want it to happen as quickly and easily as possible. They don’t want to explore your tax preparation software. They want their taxes done. They don’t want to delve deeply into the mysteries of your To Do List software. They want to not miss deadlines. But What About B2B Products? I know, I know. B2B products are different! They’re more complex! They have so many features! They require training and exploration! Nonsense. All of those incredibly complicated, feature-dense pieces of B2B software that require weeks of training are getting disrupted by things that humans actually understand. I worked with a company that required all documents be shared by filing a ticket with IT to create a personal folder on a shared server which then required mounting a new drive onto the desktop and…blah blah blah. Everybody just used Dropbox, even though it was officially forbidden by the company. The fact is, people in big companies are forced to work with dozens of complicated products every single day. The introduction of a new, complicated product does not instill in them the desire to spend a lot of their day exploring it. It tends to make them sigh resignedly and figure out if there is some way to avoid learning the new system until it goes away and is replaced by something else. The only way to make a product that people want to use at work is to make it so easy to use that they don’t have to explore it. They can just jump in, share a document, send an email, or do whatever task it is that they wanted to do originally. Users shouldn’t have to explore your product to do their jobs. But…but…but…Games! Nope. Sorry. Still very little open exploration for new users. I mean, sure, you can wander all over GTAV and steal as many cars as you want. But have you ever noticed how many quests and tasks and hints you’re given along the way as a new player? Actually, you probably haven’t. Really successful games are fabulous at getting you onboarded without making you feel like you’re going through a tedious training session but also without just dumping you directly into the deep end. In good games, the real exploration doesn’t come until users are pretty comfortable with all the basic actions they need to be successful. Often, advanced features are hidden from users until they are unlocked. This not only provides the user with an incentive to keep playing, but it effectively hides complexity until the user is ready for it. Think about hiding a rocket launcher from a new FPS player. Now think about not showing quarterly estimates to a tax preparer until you know that she needs to file quarterly estimates. There’s a surprising similarity. Note: hiding rocket launchers from people doing their taxes is also not a terrible idea. E-Commerce? Again, not really. While online stores do encourage you to explore and browse, you’ll notice that they don’t have you exploring and browsing the store itself. They have you exploring and browsing the products they want you to buy. When you’re selling widgets, it’s all about showing off the widgets as quickly as possible. Even while you’re looking at a widget, the site or app is immediately offering you more widgets that you might be interested in. It’s not about exploration of the product. It’s about getting you involved with the things the product is selling. What Should You Do Instead? Stop thinking about letting users explore your product. In fact, stop thinking about letting them do anything at all. When a new user comes to your product, give them a task. Have them do the most obvious, low-friction thing that they will need to do in order to become a slightly more experienced user of the product. Twitter is an excellent example. When you first join, they don’t just tell you to explore Twitter. They have you immediately start following people. This not only introduces you to the concept of following people, but it gives you a nice, low-friction way to start using the product in the manner it’s meant to be used. Of course, figuring out what that most obvious first task is can be tricky. In order to do it well, you need to truly understand why your user might want to use your product. What problem are they trying to solve? What task do they want to accomplish? How do they want to change their lives? What sort of hole are they trying to drill? Once you understand that, you’ll know how to create an onboarding experience that won’t force people to explore your product before using it. In fact, they’ll never have to explore it. They’ll just be able to accomplish their task and get on with their now-improved lives. And that, after all, is exactly why they wanted to use your product in the first place.

First, some background: I highly recommend that you read the following two blog posts: by Ashe Dryden: The Ethics of Unpaid Labor and the OSS Community and by James Coglan: Why Github is not your CV. They make some fantastic points and communicate the issues surrounding “Using Github as your CV”. Both of these were largely provoked by this tweet by Chris Anderson: Advice received on hiring software devs: reject anyone who doesn't have a @GitHub profile (the more active the better). Agree? — Chris Anderson (@chr1sa) October 30, 2013 I had a similar, extremely popular, tweet from 2011: When it comes to hiring, I'll take a Github commit log over a resume any day. — John Resig (@jeresig) February 5, 2011 I wanted to take this chance to clarify my position on using Github during the interview process a bit. To start, the position being posited by Chris is absolutely wrong. No one should ever require a Github profile in favor of a resume (unless you’re applying for a job at Github, perhaps?). Nor should anyone prefer candidates who provide a Github profile over those who don’t. (And to clarify, some people seem to be getting caught up in the terminology – I see many people using ‘Github’ as a placeholder for ‘any OSS activity’, I hope no one is being that literal.) When you’re applying for a job it’s generally advised that the more high-quality information that you provide, the better. Anything that emphasizes your work habits, the quality of work that you will perform, and your interests is ideal. Thus the more targeted information you’re able to provide, the better. Github can provide this for some but almost certainly can’t be the final arbiter of this information for all. We’ve had dev applicants at Khan Academy who’ve applied with traditional resumes, resume + Github profile, resume + personal web site, resume + links to projects they’ve worked on, resume + a custom project made special for the interview. Out of all of these submissions the ones that’ve had the most impact are the ones where the candidates have gone above-and-beyond and done some custom coding, made a custom web site, or contributed to one of our Open Source projects as part of the application process. A popular project is one where candidates make a custom exercise using our exercise framework. There are a few reasons why this particular approach is so effective: It communicates just how interested the candidate is in the job: That they’re willing to go above-and-beyond to demonstrate their interest. They show that the sort of things they’re interested in working on are largely aligned with what we’re trying to do (especially if they make an exercise with our exercise framework). If it’s a coding project you can get a sense for what their code quality is like and how they wish to portray themselves. Naturally this isn’t completely ideal as it requires a candidate to put in considerably more time into their application than just generating a single-sheet resume. That being said the level of information that is conveyed is so much higher that it almost isn’t comparable. The traditional interview process is broken. It’s high-stress and a poor representation of what you’ll actually experience working for the employer, or working with the candidate. Over this past summer I developed a new “take-home” project-based interview for JavaScript-centric candidates to Khan Academy. I wanted a way to try to better-quantify a person’s development ability without having to necessarily suss out their best code from Github, or elsewhere. I extracted a tangible, contained, project that I had assigned to one of my interns and turned it into a project. Thus far it’s worked extremely well as, as can be attested to by Pamela Fox (who completed the project with flying colors). I’m very pleased with this approach as it gets all the benefit of the candidate creating a custom project on their own but it has the added benefit of communicating to the candidate the exact type of projects that they’ll be working on here at Khan Academy. I’d love to open up the project at some point to show how it’s done but it’s still an effective tool in our interviewing toolbox and I’m not sure I want to lose that just yet! However, you can be privy to the project-based interview process if you wish to apply to Khan Academy! Specifically if you’re interested in working with Pamela Fox and me to build Khan Academy’s Computer Science platform (more details on the launch, a technical talk I gave on it after launch). If this really excites you then you should apply for a Software Developer position at Khan Academy and specifically request to go through the JavaScript project interview with myself. I’ll give you the project to work on and we’ll discuss the results extensively. The biggest drawback to this approach is that we’re demanding some of your free time to gather this information. We’re not sure what the best way is to offset this, as of yet. However by doing the project you’ll likely be able to skip a number of stages in our interview process and hopefully get started on changing the world with us at Khan Academy all the sooner.

SEO, content writing, and other futile endevours For the past six years or so, I have made at least a fraction of my living from writing things for the Internet. And I’d say about 80 percent of that writing was completely unnecessary and contributed nothing new to the sum of human knowledge. In fact, at least half of it was a creative restating of something someone else had already written somewhere else at the request of an employer desperate for additional eyeballs (and willing to pay me for them). The pay, while hardly glamorous, has kept a roof over my head and food (and drink) in my belly, so I can’t exactly complain about that aspect. But the situation itself makes me think: if even half of what freelance writers and journalists such as myself produce is superfluous (and I suspect the real figure is much, much higher), then what is the point of writing for the web? I understand the motivation, because it’s the same reason I do these things: I'd rather get paid to create worthless web content while working an average of four hours a day in my pajamas than the alternative of spending eight hours in an office to do something else that’s probably just as pointless in the end, and far more limiting to my lifestyle. I can also kid myself and say that getting paid to write anything is better than not getting paid to write at all, but over the years I've come to believe that this is a falsehood fed to countless young writers. In fact, writing for the web for the most part has made me a worse writer, as I now have to consciously undo the harm that accommodating keywords and templates has caused. Before I go any further, I should make it clear that I'm speaking exclusively about SEO and web content writing, the sole purpose of which is to increase clicks. This category also applies to some journalism as well, particularly the very common practice of editors commissioning stories on hot topics that have already been covered by other sources, just so they don’t miss out on the pageviews that keep the advertisers coming. This kind of writing rarely produces new information or thoughts; it simply repackages existing ideas. It seems that a vast majority of the writing that appears online belongs to this category, and the percentage is increasing with time, making original journalism and writing that much harder to find (with notable exceptions being a handful of publications that are now known for actual reporting in long-form articles — ahem, Medium). A large share of the blame, if not all, falls on the advertising-supported model of web writing that has led to a severe decrease in quality publications and journalists and has yet to be replaced by something more sustainable. When it’s much cheaper to hire someone to create derivative work rather than dedicating the resources to carry out original research, the model itself incentivizes laziness and repitition. So what exactly is the point of this kind of writing, other than to earn some amount of money for the websites publishing this content, and a significantly smaller amount of money for the writers slaving away to create it? Is there any actual value being produced, or is this just another aspect of our “information economy”, where we no longer make or buy things that have actual use? Is web writing up there with financial derivatives? And is this system so ingrained that it has now become permanent? After all, if Google suddenly changed their algorithms to weed out SEO writing, wouldn’t an entire industry collapse? Or would it find another way to game the system for profit? Or will there be a mass protest online, with readers finally punishing the makers of SEO content and only sharing writing that has value? I'm honestly curious about the answers to these questions, because at this point I'm trying to navigate a world where I get paid ten times as much for fitting keywords into coherent sentences designed to increase pageviews as I am for writing an actual book (or half of one, anyway) that has been printed and sold in shops and may even be of use to its readers. Similarly, at least some of the writing I do on my blog is somewhat original, even if not entirely novel, but if you count at minimum the cost of this blog’s domain and hosting, not to mention my time, I’m actually losing money every time I post. It’s thoughts like this that make me want to abandon writing for a living altogether and earn money designing apps or web pages instead.

SEO, content writing, and other futile endevours For the past six years or so, I have made at least a fraction of my living from writing things for the Internet. And I’d say about 80 percent of that writing was completely unnecessary and contributed nothing new to the sum of human knowledge. In fact, at least half of it was a creative restating of something someone else had already written somewhere else at the request of an employer desperate for additional eyeballs (and willing to pay me for them). The pay, while hardly glamorous, has kept a roof over my head and food (and drink) in my belly, so I can’t exactly complain about that aspect. But the situation itself makes me think: if even half of what freelance writers and journalists such as myself produce is superfluous (and I suspect the real figure is much, much higher), then what is the point of writing for the web? I understand the motivation, because it’s the same reason I do these things: I'd rather get paid to create worthless web content while working an average of four hours a day in my pajamas than the alternative of spending eight hours in an office to do something else that’s probably just as pointless in the end, and far more limiting to my lifestyle. I can also kid myself and say that getting paid to write anything is better than not getting paid to write at all, but over the years I've come to believe that this is a falsehood fed to countless young writers. In fact, writing for the web for the most part has made me a worse writer, as I now have to consciously undo the harm that accommodating keywords and templates has caused. Before I go any further, I should make it clear that I'm speaking exclusively about SEO and web content writing, the sole purpose of which is to increase clicks. This category also applies to some journalism as well, particularly the very common practice of editors commissioning stories on hot topics that have already been covered by other sources, just so they don’t miss out on the pageviews that keep the advertisers coming. This kind of writing rarely produces new information or thoughts; it simply repackages existing ideas. It seems that a vast majority of the writing that appears online belongs to this category, and the percentage is increasing with time, making original journalism and writing that much harder to find (with notable exceptions being a handful of publications that are now known for actual reporting in long-form articles — ahem, Medium). A large share of the blame, if not all, falls on the advertising-supported model of web writing that has led to a severe decrease in quality publications and journalists and has yet to be replaced by something more sustainable. When it’s much cheaper to hire someone to create derivative work rather than dedicating the resources to carry out original research, the model itself incentivizes laziness and repitition. So what exactly is the point of this kind of writing, other than to earn some amount of money for the websites publishing this content, and a significantly smaller amount of money for the writers slaving away to create it? Is there any actual value being produced, or is this just another aspect of our “information economy”, where we no longer make or buy things that have actual use? Is web writing up there with financial derivatives? And is this system so ingrained that it has now become permanent? After all, if Google suddenly changed their algorithms to weed out SEO writing, wouldn’t an entire industry collapse? Or would it find another way to game the system for profit? Or will there be a mass protest online, with readers finally punishing the makers of SEO content and only sharing writing that has value? I'm honestly curious about the answers to these questions, because at this point I'm trying to navigate a world where I get paid ten times as much for fitting keywords into coherent sentences designed to increase pageviews as I am for writing an actual book (or half of one, anyway) that has been printed and sold in shops and may even be of use to its readers. Similarly, at least some of the writing I do on my blog is somewhat original, even if not entirely novel, but if you count at minimum the cost of this blog’s domain and hosting, not to mention my time, I’m actually losing money every time I post. It’s thoughts like this that make me want to abandon writing for a living altogether and earn money designing apps or web pages instead.

And Why You Shouldn’t Make Them I recently had the opportunity to sit down with Brandon Stanton, the photographer behind the popular Humans of New York blog. (If you’re not familiar with HONY, here’s a short description: Brandon walks around NYC every day and photographs interesting strangers, posting their pictures and a poignant quote about their lives on his blog). At one point in our conversation, Brandon brought up a mobile app idea he had. He waxed eloquent about its potential, how much the app would help HONY and reach thousands of people, and he envisioned it having a real chance of success. So, when he dropped the not-unexpected bomb: “Yeah, I’ve been talking to someone to make it for me since I don’t know how to code. It’s hard to know if they’ll do a good job though, there’s so few people who can program so finding someone is tough.” I was ready. “Why do you need someone to make it for you? Learning to code is easy! Anyone can do it. In fact, there’s some people that think everyone should learn to code.” “Well,” he responded, “I think coding is really cool and I really do want to learn. But there’s never enough time-” Aha. I have him now. I’m ready with the low-time-commitment argument, Mr. Stanton! “-because although I’d love to learn to code, what I’m good at is taking photos. Even if it isn’t much time, any time I spend learning to code is time I could spend getting one more photo, finding one more moment to capture. Coding is really cool and I really wish I knew how, but the thing is, I love what I do instead too much to take time away from that.” …Oh The “Learn to Code” movement seems to have two fronts. On one side: “Everyone can code! Software is the future! Build everything!” On the other side: “Not everyone can code. It’s too hard, it’s too boring, it’s too advanced, it’s too weird”. Both are wrong. Yes, anyone can learn to code. Enough elite programmers have worked their way up from the depths of inexperience that this has become evident. Anyone — the eager junior high student, the unemployed forty year old, or the first-time hackathon attendee — can learn to program if he or she practices it enough. And, although this one is harder to show, I believe that anyone can like to code. The feeling of creating — of making an app, a program, from code that you wrote; of bending a computer to your will — is a joy that anyone who’s ever programmed can attest to. However, this does not mean that everyone will love to code, be passionate about code. “Find your passion” is a cliche that’s thrown around a lot, but at its core it makes sense; everyone has that one activity, that thing that they love above all else, that green light. And, in order to really become a good programmer, especially if you want to do it fast, it needs to be (as Paul Graham puts it), “The thing you think about in the shower.” The truth is that for many people, coding simply isn’t that thing. And that’s ok. Because instead of coding, they love writing books. Or solving math problems. Or, like Brandon, taking photographs. Project creation. Problem solving. Artistic design. Sound familiar? We praise programming not because of writing code, but because of the things we can accomplish with code. And, if there are people who are already accomplishing these things through other means? That’s perfectly all right with me. While everyone can learn to code, not everyone will learn to code. And we shouldn’t make them.

And Why You Shouldn’t Make Them I recently had the opportunity to sit down with Brandon Stanton, the photographer behind the popular Humans of New York blog. (If you’re not familiar with HONY, here’s a short description: Brandon walks around NYC every day and photographs interesting strangers, posting their pictures and a poignant quote about their lives on his blog). At one point in our conversation, Brandon brought up a mobile app idea he had. He waxed eloquent about its potential, how much the app would help HONY and reach thousands of people, and he envisioned it having a real chance of success. So, when he dropped the not-unexpected bomb: “Yeah, I’ve been talking to someone to make it for me since I don’t know how to code. It’s hard to know if they’ll do a good job though, there’s so few people who can program so finding someone is tough.” I was ready. “Why do you need someone to make it for you? Learning to code is easy! Anyone can do it. In fact, there’s some people that think everyone should learn to code.” “Well,” he responded, “I think coding is really cool and I really do want to learn. But there’s never enough time-” Aha. I have him now. I’m ready with the low-time-commitment argument, Mr. Stanton! “-because although I’d love to learn to code, what I’m good at is taking photos. Even if it isn’t much time, any time I spend learning to code is time I could spend getting one more photo, finding one more moment to capture. Coding is really cool and I really wish I knew how, but the thing is, I love what I do instead too much to take time away from that.” …Oh The “Learn to Code” movement seems to have two fronts. On one side: “Everyone can code! Software is the future! Build everything!” On the other side: “Not everyone can code. It’s too hard, it’s too boring, it’s too advanced, it’s too weird”. Both are wrong. Yes, anyone can learn to code. Enough elite programmers have worked their way up from the depths of inexperience that this has become evident. Anyone — the eager junior high student, the unemployed forty year old, or the first-time hackathon attendee — can learn to program if he or she practices it enough. And, although this one is harder to show, I believe that anyone can like to code. The feeling of creating — of making an app, a program, from code that you wrote; of bending a computer to your will — is a joy that anyone who’s ever programmed can attest to. However, this does not mean that everyone will love to code, be passionate about code. “Find your passion” is a cliche that’s thrown around a lot, but at its core it makes sense; everyone has that one activity, that thing that they love above all else, that green light. And, in order to really become a good programmer, especially if you want to do it fast, it needs to be (as Paul Graham puts it), “The thing you think about in the shower.” The truth is that for many people, coding simply isn’t that thing. And that’s ok. Because instead of coding, they love writing books. Or solving math problems. Or, like Brandon, taking photographs. Project creation. Problem solving. Artistic design. Sound familiar? We praise programming not because of writing code, but because of the things we can accomplish with code. And, if there are people who are already accomplishing these things through other means? That’s perfectly all right with me. While everyone can learn to code, not everyone will learn to code. And we shouldn’t make them.

I’ve been told that I get a lot of work done quickly. Both in terms of client work I take on, as well as the sheer number of side-projects and hobbies I’ve got on the go at any given time. Here are a few of the things I’ve figured out that work for me. Unsubscribe from any newsletter you don’t immediately want to devour. The less full your inbox is, the less you have to deal with and the less you have to filter through when the next email comes in. If an email that doesn’t require a response or action, archive it. A ‘zero inbox’ is a truly wonderful thing. Use your inbox as a todo list, and archive emails you don’t need. Use one program at a time. If you aren’t using social media, keep it closed. If you’ve finished checking email, close that. If you aren’t browsing the web, close your browser. Don’t even leave something open in the background. Multitasking makes it hard to focus and makes tasks take longer (because you’re constantly distracted). Turn off every notification. This includes notifications of new emails, new likes, new mentions. Everything. If it appears on your screen, turn it off while you’re working. Focus in tiny increments. 30-45 minutes at a time or so. Then take a break, stretch, pee, drink some water, stare blankly out the window, check social media. Stop after a minute or two, then get back to it. If you’re frustrated, leave. Get some air, eat a snack, meditate for 10 minutes. Come back with a fresh mind. Donate your television. It’s amazing how much you can get done in a day if you aren’t passively sitting on a couch and staring at moving pictures. Keep a log of what you eat during the day and how you feel afterwards. You’d be amazed at how food affects your mental state. It can make you tired, hyper or unable to concentrate. So figure out what foods do that and avoid them. You’ll probably also see a correlation between fresh, whole foods and being able to focus more. Follow fewer people on social media. Remove folks you aren’t finding value in. It’s nothing personal, and you can still think they are awesome people. Focus on relationships and value, and less on the numbers game. Work at your peak time. Everyone has a time of the day when they seem to be able to focus more and get more done. During that time, turn off your phone and email, never schedule meetings and remove distractions. Turn off emails from social media networks. Do you really need to know when someone friends you? Mentions you? Suggests a book? Invites you to an event? Don’t let those networks bombard your inbox with notifications. You can log into these networks and check messages, mentions or likes when that’s what you’re actually doing. It’s funny how hours spent on a task can be used as a badge of honour. Don’t work hard, work better because busyness doesn’t equal productivity. Make tasks take less time, so you can accomplish more and then have time for other, better things. Know that efficiency doesn’t (and shouldn’t) work for everything or every situation. Don’t be efficient with: spending time with loved ones, laughing until your stomach hurts, cuddling with pets or walking in the woods. Things like that don’t need time-limits, end games or any goals. The more you lose yourself in these, the better they are.

I’ve been told that I get a lot of work done quickly. Both in terms of client work I take on, as well as the sheer number of side-projects and hobbies I’ve got on the go at any given time. Here are a few of the things I’ve figured out that work for me. Unsubscribe from any newsletter you don’t immediately want to devour. The less full your inbox is, the less you have to deal with and the less you have to filter through when the next email comes in. If an email that doesn’t require a response or action, archive it. A ‘zero inbox’ is a truly wonderful thing. Use your inbox as a todo list, and archive emails you don’t need. Use one program at a time. If you aren’t using social media, keep it closed. If you’ve finished checking email, close that. If you aren’t browsing the web, close your browser. Don’t even leave something open in the background. Multitasking makes it hard to focus and makes tasks take longer (because you’re constantly distracted). Turn off every notification. This includes notifications of new emails, new likes, new mentions. Everything. If it appears on your screen, turn it off while you’re working. Focus in tiny increments. 30-45 minutes at a time or so. Then take a break, stretch, pee, drink some water, stare blankly out the window, check social media. Stop after a minute or two, then get back to it. If you’re frustrated, leave. Get some air, eat a snack, meditate for 10 minutes. Come back with a fresh mind. Donate your television. It’s amazing how much you can get done in a day if you aren’t passively sitting on a couch and staring at moving pictures. Keep a log of what you eat during the day and how you feel afterwards. You’d be amazed at how food affects your mental state. It can make you tired, hyper or unable to concentrate. So figure out what foods do that and avoid them. You’ll probably also see a correlation between fresh, whole foods and being able to focus more. Follow fewer people on social media. Remove folks you aren’t finding value in. It’s nothing personal, and you can still think they are awesome people. Focus on relationships and value, and less on the numbers game. Work at your peak time. Everyone has a time of the day when they seem to be able to focus more and get more done. During that time, turn off your phone and email, never schedule meetings and remove distractions. Turn off emails from social media networks. Do you really need to know when someone friends you? Mentions you? Suggests a book? Invites you to an event? Don’t let those networks bombard your inbox with notifications. You can log into these networks and check messages, mentions or likes when that’s what you’re actually doing. It’s funny how hours spent on a task can be used as a badge of honour. Don’t work hard, work better because busyness doesn’t equal productivity. Make tasks take less time, so you can accomplish more and then have time for other, better things. Know that efficiency doesn’t (and shouldn’t) work for everything or every situation. Don’t be efficient with: spending time with loved ones, laughing until your stomach hurts, cuddling with pets or walking in the woods. Things like that don’t need time-limits, end games or any goals. The more you lose yourself in these, the better they are.

How I learned web design. In the beginning, I already knew how to program (albeit in different languages) and what I knew of design was only related to print/layout (yes I’m that old). Everything I taught myself about web design was stolen from other websites. I looked at the layouts of other websites and would replicate them in photoshop. And then replicate them again to see if I could improve and speed up my process. Then replicate them again to see if I could improve the way they looked. Sometimes 100s of times. All on the privacy of my computer, not on a client’s dime. I did the same for code. I’d look at someone else’s source code and write it out again for myself. Then I’d try and write the same source from scratch. Then I’d try and improve the code, or morph it to work with the updated designs I had done. Once I felt I had a good grip on taking and replicating single sites, I moved onto stealing multiple sites and using the best elements and code in my experiments. And I’d do the same thing, draw them, then draw them again, and draw them again. Mashups of several sites, merged into one consistent design. I’d do this until I was happy with the process and the time it took, and happy with the changes I had made to them to make them look better. And by the time I’d be done, the result wouldn’t look like any one specific site I had stolen from. Not much has changed between and than doing web design professionally. I still steal ideas to kick-off my own. Mostly I steal ideas from nature, clothes, magazines, books, architecture, art. But I do see good ideas on the web for small pieces and lift them completely. Then iterate them over and over until I get something I’m happy with, which invariably looks and works different from it’s source. There’s no need to be concerned with a process like this in the beginning. Especially if you’re teaching yourself something. Steal entire ideas. Shamelessly use them as a base or starting point (although I don’t recommend using these for profit). Iterate on them until you’re comfortable with your process. The iterate more on what you think would work better. Then steal from lots of sources and do the same thing. Iterating until the process is sound and the end result has embodies your voice and creative hand as well. This way you don’t have to worry about being inspired or finding a muse at the start. Your muse is other work and other work is abundant. That way you only have to worry about adding your story and flavour to something existing, instead of starting with a blank slate. It’s difficult to sit at a blank screen and simply create. It’s daunting and even terrifying. Starting with something that already exists and riffing on it until it’s your own can create the spark required to start. When I break it down, that’s exactly how I’ve learned everything I know. Through theft and iteration.

How I learned web design. In the beginning, I already knew how to program (albeit in different languages) and what I knew of design was only related to print/layout (yes I’m that old). Everything I taught myself about web design was stolen from other websites. I looked at the layouts of other websites and would replicate them in photoshop. And then replicate them again to see if I could improve and speed up my process. Then replicate them again to see if I could improve the way they looked. Sometimes 100s of times. All on the privacy of my computer, not on a client’s dime. I did the same for code. I’d look at someone else’s source code and write it out again for myself. Then I’d try and write the same source from scratch. Then I’d try and improve the code, or morph it to work with the updated designs I had done. Once I felt I had a good grip on taking and replicating single sites, I moved onto stealing multiple sites and using the best elements and code in my experiments. And I’d do the same thing, draw them, then draw them again, and draw them again. Mashups of several sites, merged into one consistent design. I’d do this until I was happy with the process and the time it took, and happy with the changes I had made to them to make them look better. And by the time I’d be done, the result wouldn’t look like any one specific site I had stolen from. Not much has changed between and than doing web design professionally. I still steal ideas to kick-off my own. Mostly I steal ideas from nature, clothes, magazines, books, architecture, art. But I do see good ideas on the web for small pieces and lift them completely. Then iterate them over and over until I get something I’m happy with, which invariably looks and works different from it’s source. There’s no need to be concerned with a process like this in the beginning. Especially if you’re teaching yourself something. Steal entire ideas. Shamelessly use them as a base or starting point (although I don’t recommend using these for profit). Iterate on them until you’re comfortable with your process. The iterate more on what you think would work better. Then steal from lots of sources and do the same thing. Iterating until the process is sound and the end result has embodies your voice and creative hand as well. This way you don’t have to worry about being inspired or finding a muse at the start. Your muse is other work and other work is abundant. That way you only have to worry about adding your story and flavour to something existing, instead of starting with a blank slate. It’s difficult to sit at a blank screen and simply create. It’s daunting and even terrifying. Starting with something that already exists and riffing on it until it’s your own can create the spark required to start. When I break it down, that’s exactly how I’ve learned everything I know. Through theft and iteration.

I wanted to share some things I wish someone could have told me when I started out in design and development. I am by no means saying that these are definitive, nor should you take my advice, but I hope that some of these may give you a little advice on how to approach a certain situation you come across over the next few years. *** University alone will not get you a job Although university is great for teaching you some of the essentials in design and development, they will not actually get you a job. The job market for students straight out of university / college is the most competitive, so you need to differ yourself from the next applicant. During university is the perfect time to build up your portfolio. (and your bank account) Put yourself out there, ask around for people who need work doing, introduce yourself and your skills to that local restaurant, shop, anything. Employers want to see examples of how you can apply yourself to real world situations. If you can’t get someone to do work for, then come up with a concept project. If you are a designer, design a poster for your favourite band, redesign a website of a brand you like. If you are a developer, think about a plugin that could be useful, develop an app. The more examples of how you can apply yourself differs you from the next applicant. *** It is ok to say NO This is one of those things that I definitely didn’t do in the early days of my career, now don’t get me wrong, there are certain occasions where you need to make compromises. However, one thing you need to understand is that it is perfectly fine to say no to a clients demands. There are a number of reasons why saying no can be so much more productive, than just agreeing to all demands. There are a lot of articles on this subject, so I thought here are a few links to have a browse over instead of covering old ground. http://alistapart.com/article/no-one-nos-learning-to-say-no-to-bad-ideas http://blog.jpdesigntheory.com/learning-to-say-no-to-bad-freelance-projects/ *** Sweat the details! The details are the parts of projects that will get you noticed by your peers. In fact, I would say that these finer things in projects are what really hit home the potential and vision that you have as a designer or developer. Take a step back and really think about every detail your project has to offer, time will always be tight, deadlines will always be bearing down on you. However, if you can add just one thing to a project that will make your peers step back and go “Nice, he thought about ...” The prospects for that place on the cool project coming in next month are increasing every time. *** There will always be someone better than you If you want to progress and become a better designer / developer, there is something you have to do right this minute… Put your ego to one side! Embrace contribution, criticism and advice now. You will never be the best at something, there is always someone you will be able soak up a bit of knowledge from. Having an ego will only limit your progression up the ladder. *** Sharing nothing, gets you nothing Don’t be afraid of putting things out there, that idea is never going to get any feedback sat on your computer. Get it on the internet, get criticism on your work, it will only make you better at what you do. Hell, it can even lead to more work if people dig it. It can be very nerve-racking at first getting feedback, don’t get your back up if it’s not great, just use it to your advantage on your next piece. So hopefully the above may have given you a few little things you can take away and put into practice, the main thing you need to take away from this is to create for the love of it. Don’t always think about your pocket or bank balance, money led projects are easy to spot, enjoy what you do.