Coding For Dummies (2015)

Part V. The Part of Tens

Chapter 16. Ten Tips for Novice Coders

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. Should you learn C++, Python, Java, Ruby, PHP, JavaScript all at the same time, sequentially, or just pick a few? If you have never programmed before, I recommend 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. Within this set of languages, I recommend starting with HTML and CSS. Both 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. Keep in mind that you don’t need to learn every programming language — JavaScript, which adds interactivity to the web page, is a common starting point for beginners, along with either Ruby or Python, which adds more advanced features like user accounts and logins.

Learning to code is similar to learning to drive a car. When you first learned to drive, you probably didn’t worry too much about the type of car you were driving. After passing the driving test, you could operate just about any car, even one you hadn’t driven before, because you knew to look for the ignition, accelerator, and brake. Learning a programming language works the same way: After you learn one language, you know what to look for, and learning and using another language becomes easier. In other words, just start somewhere!

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 — the equivalent of chopping vegetables in culinary school. 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.

Pick a simple goal at first to build your confidence and technical skills. As you gain confidence, you can build more professional-looking websites and apps.

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

For example, if you want to build an app that tells you when you can expect the next bus to arrive closest to your current location, you can list the steps as follows:

1. Find your current location.

2. Find the bus station closest to your current location.

3. Identify the specific bus that travels to the closest bus station.

4. Determine the location of that bus traveling to the bus station.

5. Calculate the distance from the bus’s current location to the bus station.

6. Assuming an average speed for the bus, convert the distance into time using the equation distance = speed × time.

7. Display the time to the user.

This level of detail is specific enough to start researching individual steps, such as how to find your current location using code, and it gives you a complete list of steps from start to finish for the intended goal.

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. The only other choices for a project behind schedule are to extend the deadline, which usually does not happen, or to add additional programmers, which usually is not helpful because of the time needed to get the new programmers up-to-speed.

A better strategy is to 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. In the bus app example above, determining my current location could be optional. Instead, I could select one specific bus stop, and first complete steps 3 through 7. Then, if time allows, I can make the app more flexible by finding my current location, and then finding the closest bus stop.

The phrase minimum viable product is used by developers to refer to the set of features essential to the proper functioning of the product.

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. For example, imagine that a few months from now, after reading this book, you need to add an image to a website. You remember that HTML has a tag to insert images on a website, but you don’t recall the exact syntax. To quickly and efficiently find the answer, you could follow these steps:

1. Go to www.google.com.

2. Search for HTML image syntax.

The programming language, the intended command, and the word syntax should be sufficient to find a good set of resources.

3. For syntax questions in HTML and CSS, you will likely see these domains names in the top 10 search results, and you should read their content as a next step:

· w3schools.com is one of the best resources for beginners to find basic information.

· developer.mozilla.org is a crowdsourced documentation and tutorial site. Its documentation is very accurate, although some content is not beginner-friendly.

· stackexchange.com and stackoverflow.com are crowdsourced discussion sites where developers can ask and answer questions.

· w3.org is the governing body that creates HTML and CSS standards. Its documentation is the most accurate, but it’s dry and not beginner-friendly.

You can use this same process to research questions in other coding languages, or to find code examples from other developers who are building features similar to yours.

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. For example, in CSS, you’d write color: blue; to change the color of an element. If you wrote font-color: blue; instead, you’d generate a syntax error because font-color is an invalid property.

· 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. For example, in JavaScript, converting miles to feet using var miles = 4000 * feet is a logic error. Although the code is written correctly and does what the programmer wants it to do, it still produces the wrong answer — there are actually 5,280 feet in a mile, not 4,000.

Your browser will do its best to display your HTML or CSS code as you intended, even in the presence of syntax errors. However, with other programming languages, such as JavaScript, code with syntax errors won’t run at all. 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.

Developers use specialized tools in the browser to diagnose and debug errors. You can learn more about these developer tools in the Chrome browser by going to www.codeschool.com/courses/discover-devtools.

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. (See Figure 16-1.)

Figure 16-1: Google’s original homepage in 1998.

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.

Just like with document drafts, save the old versions of your code in case you realize an older version was better, or in the event you find bugs in the current version of your code and you have to use an older version of the code to debug it.

Share Your Success and Failure

While coding you may have come across documentation on a website you found confusing or just plain wrong. Maybe you found a great resource or a tool that worked especially well for a product you were building. Or perhaps the opposite happened — no one used the features you built with code, and you had to give up the project.

In all these situations, 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. Many non-technical entrepreneurs, such as Dennis Crowley of Foursquare and Kevin Systrom of Instagram, taught themselves enough coding to build small working prototypes, built successful products, and then shared that journey with others.

You can blog for free and share your experiences using blogging sites like Wordpress (www.wordpress.com), Blogger (www.blogger.com), or Tumblr (www.tumblr.com).