Chapter 16
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.
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!
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
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.
After defining a goal, break it down into small steps. This helps you
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:
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.
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.
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:
The programming language, the intended command, and the word syntax should be sufficient to find a good set of resources.
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.
While you’re doing all this coding you will inevitably create errors, commonly referred to as bugs. There are three types of errors:
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.
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.)
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.
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.
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.
3.140.242.165