Learning to code is more popular today than ever before. It seems like everyone has a website or an app idea, and as soon as your friends, family, or coworkers discover your new coding abilities, many will ask for advice and help.
No matter whether you’re dabbling at it after work, or attending an intensive ten-week coding boot camp, learning to code can be a challenging journey. It can pay to pick up a few pointers from some of the people who crossed the finish line ahead of you. Keep the following tips in mind, especially when starting your coding journey.
Pick a language, any language
As a novice coder, you may not be sure where to start. If you have never programmed before, start by learning a language used to create web pages, because with these languages it’s easy to get started and publish work for others to see.
HTML and CSS are markup languages, which are the easiest to learn, and let you put content on a web page with HTML, and style that content with CSS. After you understand some of the basics of presenting content, you can then learn a programming language to manipulate that content.
Define a goal
When you start learning to code, picking a goal can help you stay motivated. You can pick any goal you like, but make sure it’s something you would be really excited to accomplish. Good goals for beginners include
Creating a small website — consisting of one to four different pages — for yourself, a business, or a group.
Building your coding vocabulary so you can understand what developers or designers say in meetings at work.
Creating a prototype, or a basic version, of a website or app idea — for example, an app that tells you when the next bus is arriving to your current location.
At first, practice doing very small coding tasks. These tasks, such as bolding a headline, may leave you feeling disconnected from your ultimate goal. But as you keep learning, you will start to piece together individual coding skills and see a path to accomplish your goal.
Break down your goal into bite-sized steps
After defining a goal, break it down into small steps. This helps you
See all the steps needed to complete the goal
Research how to do each specific step
Ask others for help easily when you’re stuck on a step
At first, the steps you create may be broad or incomplete, but with time you will improve your ability to detail these steps, which are sometimes called specifications.
Distinguish cupcake from frosting
Whether you’re at home creating your first app, or at work on a team building a website, your projects will tend to include too many features to build by a specific deadline. This leads inevitably to one of three results: The project launches on time but is buggy; the project launches late; or your team works overtime to launch the project on time.
Decide upfront which features are the cupcake — that is, which are essential — and which are the unessential frosting, the ones that are nice to have but optional. This shows you where your priorities are. If your project is running over on time or budget, you can build the optional features later or not at all.
When building your own apps make sure you distinguish the essential from the optional features before you actually start coding.
Google is a developer’s best friend
Developers constantly use the Google search engine to research either general questions on how to code a feature, or specific questions on syntax for a command or tag. When searching, the programming language, such as HTML, the intended command, and the word syntax should be sufficient to find a good set of resources.
Zap those bugs
While you’re doing all this coding you will inevitably create errors, commonly referred to as bugs. There are three types of errors:
Syntax errors occur when you write invalid code the computer doesn’t understand.
Semantic errors occur when you write valid code that has an unintended effect. For example, trying to divide a number by zero is a semantic error in JavaScript.
Logic or design errors occur when you write valid code that has the intended effect, but the code produces the wrong result.
The best way to find and eliminate bugs is to first check your code syntax, and then the logic. Review your code line by line, and if you still cannot find the error, ask another person to take a look at your code, or post it on an online community forum like stackoverflow.com.
Just ship it
Reid Hoffman, the founder of LinkedIn, famously said, “If you are not embarrassed by the first version of your product, you’ve launched too late.” When you start coding, you will likely be reluctant to show others your creations, whether it’s your first basic website or something more complex.
Hoffman was commenting on this desire to keep trying to perfect what you have built, and says instead to release (or “ship”) your code to public view even if you feel embarrassed. Regardless of the size of your website or app, it is better to receive feedback early and learn from your mistakes, then to continue heading in the wrong direction.
Also, remember that the highly trafficked, highly polished websites you use today started initially from humble beginning and very simple prototypes. Google’s first homepage, for example, had only a fraction of the functionality or style of its homepage today.
Collect feedback
After you finish coding the first version of your website or app, collect feedback on your code and on the final product. Even if everything is working and your website looks great, that doesn’t mean your code was written correctly or that your site does everything it could. For example, YouTube initially started as a video-dating site, but changed to a general video-sharing website based on user feedback.
The best way to obtain this information is to collect quantitative and qualitative data on your code and the product. Measuring the places where visitors click and how long they stay on each web page gives you quantitative information, which helps you diagnose and improve low-performing pages.
You can collect qualitative information by surveying users, either by emailing them survey questions or by watching people in-person use your website and then asking questions. Often this data will surprise you — users may find confusing the features you thought were obvious and easily understood, and vice-versa. Similarly, if possible, have someone examine your code, in a process called a code review, to ensure that you didn’t overlook any major problems.
Iterate on your code
After you’ve collected feedback, the next step is to “iterate” on that feedback: Keep coding until the major issues in your feedback have been addressed, and until you have improved both the code and the product. Keep in mind that it’s usually best to confirm the usefulness of your product first, before spending time improving the code.
This process — building a product with a minimum set of essential features, collecting feedback on the product, and then iterating on that feedback — is sometimes referred to as the Lean Startup methodology. In the past, manufacturing processes, once set, were extremely difficult to change, but these days, changing software is as simple as modifying a few lines of code. This contrasts with the way products used to be coded, which involved longer development cycles and less upfront feedback.
Share your success and failure
While coding you may have come across documentation on a website you found confusing or just plain wrong. The best thing you can do for yourself and the larger community is to blog about your successes and failures. Blogging benefits you because it shows others the issues you’re thinking about and trying to solve.
Similarly, blogging benefits others who will use Google to search for and read about your experiences, just as you used Google to search for ideas and solve problems.
