Researching what you want to build

Your manager comes to you with a feature or product she wants you to build. Before writing any code, it helps to do some investigating. Consider the possibilities for your project as you answer the following questions:

• What similar website or app already exists? What technology was used to build it?
• Which features should I include — and more importantly exclude — in my work?
• Which providers can help create these features? For example, companies such as Google, Yahoo, and Microsoft may have software already built that you could incorporate into your app.

To illustrate, consider the restaurant app mentioned earlier. When conducting market research and answering the preceding three questions, a Google search is usually the best resource. When I searched for restaurant reservation app, the results included OpenTable, SeatMe, and Livebookings. The OpenTable app, for example, allows users to reserve a table from restaurants displayed on a map using Google Maps.

In the restaurant app example, you’d want to clarify beforehand the type of restaurant information to provide and how extensive the reservation system portion of the app should be. Defining your program’s scope is one of the most important tasks before you begin.

In addition, for each of these questions, you must decide whether to build the feature from scratch or use an existing provider. For example, when providing restaurant information, do you want to just show the name, cuisine, address, telephone number, and hours of operation, or do you also want to show restaurant menus and reviews? When displaying restaurant data, do you prefer extensive coverage of a single geographical area, or do you want coverage in many cities even if that means you’d cover fewer restaurants in any specific area?

MenuPage, a site that aggregated restaurant menus, initially took the first approach and extensively covered a few major cities such as New York, Chicago, Los Angeles, and San Francisco. By contrast, Savored, a company that offered a 30 percent discount on food during restaurant off-peak times, used the second approach and worked with twenty to thirty restaurants in each of twenty to thirty cities.

Designing your app

Your app’s visual design incorporates all your research and describes how your users will interact with every page and feature. Because your users will be accessing your site from desktop, laptop, and mobile devices, you want to make sure that you create a responsive (multidevice) design and carefully consider how your site will look on all these devices.

At this stage of the process, a general web designer, illustrator, or user interface specialist will help create visual designs for the app.

The type types of visual designs, which are shown in Figure 3-2, are

• Wireframes: Low-fidelity website drawings that show structurally the ways your content and your site’s interface interact
• Mockups: High-fidelity website previews that include colors, images, and logos

Balsamiq is a popular tool used to create wireframes. For creating mockups, professionals often use Adobe Photoshop, Adobe Illustrator, or Sketch. However, you can create your app designs and avoid paying for additional software by using PowerPoint (PC), Keynote (Mac), or the free and open-source OpenOffice.

Professional designers often create mockups using graphic layers, which isolate individual site elements. A properly created layered file helps developers more easily write the code for those website elements.

In addition to visual design, complex apps will also have technical designs and decisions to finalize. For example, if your app stores and retrieves user data, you need a database to perform these tasks. Initial decisions at this stage include choosing the type of database, the database provider, and the method for integrating the database into the application.

Coding your app

When the research and design are complete, you’re ready to code your application. In everyday web development, you would begin by coding certain pages and features. Knowing how much to code and when to stop can be tough. Developers call the first iteration of an app the minimum viable product — meaning you’ve coded just enough to test your app with real users and receive feedback. If no one likes your app or thinks it’s useful, it’s best to find out as soon as possible.

An app is the sum of its features, and for any individual feature it’s a good idea to write the minimum code necessary and then add to it. For example, your restaurant app may have a toolbar at the top of the page with drop-down menus. Instead of trying to create the entire menu at once, it’s better to create the toolbar menu options first, and create the drop-down menu effect later.

Another timesaving approach is to reuse your own or other people’s code. For example, a programmer may have already written code for drop-down menus, and published that code under an open-source license. Use a search engine to find code others have written, rather than reinvent the wheel.

Projects can involve front-end developers, who code the appearance of the app, and back-end developers, who code the logic and create the databases. A full-stack developer can do both front-end and back-end development. On large projects, it’s common to have specialized front-end and back-end developers, along with project managers who ensure that everyone is communicating with each other and adhering to the schedule.

Debugging your code

Debugging is a natural part of any application. The computer always follows your instructions exactly, and yet no program ever works as you expect it to.

Debugging can be frustrating. Three of the more common mistakes to watch out for are

• Syntax errors: These errors are caused by misspelling words or commands, omitting characters, or including extra characters. Some languages, such as HTML and CSS, are more forgiving of these errors and your code will still work even with some syntax errors. Other languages, such as JavaScript, are more particular and your code won’t run when any such error is present.
• Logic errors: With a logic error, your syntax is correct but the program behaves differently than you expected. One example of a logic error is when the prices of the items in a shopping cart of an e-commerce site do not sum up to the correct total. Logic errors are harder to fix than syntax errors.
• Display errors: With display errors, your program might run and work properly but won’t appear properly. This type of error occurs mostly in web applications. Because web apps run on many types of devices, browsers, and screen sizes, extensive testing is the only way to catch this type of error.

The word debugging was popularized in the 1940s by Grace Hopper, who fixed a computer error by removing a moth from a computer.

Salary and equity

Salary and equity (an ownership stake in the company) are the most visible and widely used benchmarks when looking for a job. Measuring and comparing salaries is easy but doing so with equity can be more complicated. Equity is either granted as common stock, which is an outright ownership stake in the company, or as options, which are the right to purchase for cash an equity stake in the company.

According to the Department of Labor, entry-level software developers across all companies earn between $60,000 and $80,000 per year. Compensation at startups is similar, with junior software engineers earning $50,000 to $100,000 and up to 0.25 percent in equity. See Figure 3-3.

The greater the risk of joining a company, the more equity you receive. A well-capitalized and profitable company that pays a market salary will offer far less equity than a startup company without a revenue model or funding. Expect as much as 50 percent equity if you join someone else in a garage, less than 1 percent if you receive a competitive salary, and somewhere between 1 percent and 50 percent if you receive a below-market salary. See more salary and equity details at www.wealthfront.com/tools/startup-salary-equity-compensation.

Equity is used more frequently in the technology industry than in other industries. For companies that eventually mature and go public on a stock exchange, equity compensation can generate individual employee wealth. Bill Gates and Mark Zuckerberg, for example, both made their billions not from their annual salaries but from equity. For public companies and late-stage private companies, the equity issued to you has a relatively stable and predictable value.

Cash is scarce in new private technology companies, such as startups, so they pay employees lower than market salaries but grant more equity than a public company. They figure that the equity will be worth more in the future when the company is successful. The caveat: Greater than 90percent of early-stage private companies fail, so the value of your equity is volatile. When accepting a job at a startup, you may feel like you’re joining the next Facebook, but you should treat your equity as a lottery ticket — worth nothing today but potentially worth something in the future.

For information on different types of equity a company can grant and the resulting tax consequences, go to www.nceo.org/articles/stock-options-restricted-phantom-sars-espps.

Equity documents are always long and confusing, and slight wording changes can greatly favor the company instead of the employee. If the amount of equity is a large portion of your total compensation, seek qualified legal counsel to review your employment documents before you sign.

Benefits and perks

The demand for coders is so high that companies, especially in the technology sector, provide numerous employee benefits and perks. For example, Google famously provides employees with gourmet meals, free massages, and on-site daycare.

Although benefits and perks should not be the reason for joining a company, they help make daily life more comfortable. Here are some common perks:

• Healthcare: Medical and dental coverage with a low deductible and low copay is standard at large companies and at startups that have received funding.
• Parental leave: Large tech companies offer more than 15 weeks of paid leave for the birth of a child, more than any other industry. Depending on the company size, parental leave may be either paid or unpaid.
• Flexible work and vacation policies: Companies of all sizes offer flexible start times, remote work, and generous vacation policies. Some smaller startups even have unlimited vacation time policies, allowing you to take as much leave as you like, although presumably your vacation may become permanent if you take too much time.
• 401(k): Company-sponsored retirement accounts are common among larger public companies but rarely seen at startups except for late-stage large ones.
• Catered meals: Large and small tech companies alike provide meals prepared by chefs in-house or ordered from local vendors.
• Transportation: Large companies have shuttle buses to make commuting easier, and some smaller companies provide transportation vouchers.
• Continuing education: Companies want you to keep learning and will often subsidize expenses for classes to help you learn new technologies and for conferences so you can promote the company and meet other developers.
• Equipment purchases: Except at the smallest startups, companies will provide you with a work laptop and often let you customize it to your specifications.

Many of these perks are non-negotiable. The ability to work remotely, however, is one perk with flexibility. Because coding work can be done anywhere, you may be able to work remotely and appear in person one week a month or even less frequently.

Advancement

Company size, industry, and market growth affect your advancement, which should be considered when benchmarking your overall compensation package. In fast growing industries such as healthcare, insurance, and technology, people can join a company near its inception and lead major divisions just a few years later. For example, Marissa Mayer, an early Google employee, became the VP of Search after five years at the company, left Google after thirteen years to become the CEO of Yahoo!, and at the age of thirty-seven is the youngest CEO of a Fortune 500 company.

Restrictions on employment

The compensation and benefits detailed previously are usually subject to the following restrictions:

• Vesting and clawback: When you start coding for a company, they make a significant investment in you to bring you up to speed. To make sure that investment pays off, companies incentivize you to stay by vesting, or granting your equity package in installments.

  Usually, your equity will vest over four years, with 25 percent granted after one year of employment, and the remaining equity granted on a monthly basis. If you leave before four years, you keep only your vested equity and forfeit the unvested equity. Similarly, some companies claw back, or require partial repayment of, salary and upfront bonuses if you leave before some time limit, usually one year.

• Noncompete: The enforceability of a noncompete restriction varies from state to state, but generally the clause prevents you from working in the future at a company that competes with your current employer. The employer wants to prevent an employee from using sensitive intellectual property to aid a competitor; the employee wants to continue using and developing specialized skills. Usually, to decrease the burden on the employee, the noncompete clause is limited either by time or by geography. For example, the language may say that you cannot work for any competitor for up to one year or for any competitor within 50 miles of any company location. In either case, negotiate to minimize the effect of a noncompete clause.

Noncompete agreements governed by California law are generally void, except in a narrow set of circumstances involving the sale or shutdown of an entire business.

Joining a company versus freelancing

Formally joining a company and enjoying the benefits just described may be ideal for some. Others, however, want the flexibility provided by freelancing, or working as a contractor-for-hire.

For someone just beginning a coding career, taking on smaller freelance jobs is a great way to build up a portfolio to show potential future full-time employers. For more experienced coders, freelancing can supplement income and provide higher pay than full-time work, especially when the employer is short staffed and on a tight deadline.

For highly experienced coders who know the latest cutting-edge programming languages, so many companies demand their skills that freelance work can become a full-time job. For example, when Apple first released the iPhone (and even today), so many companies wanted an iPhone app that programmers with the necessary skills could engage multiple companies at once. In addition to higher pay, freelancers can also work anywhere — a beach in Bali or a sailboat in Saint-Tropez — but the work comes with less job security and fewer benefits, and can be lonely.

Visit www.remoteok.io for a listing of companies advertising jobs that can be performed remotely. Similarly, www.nomadlist.com lists the best cities for the remote worker, ranked by cost of living, weather, Internet access, and safety.

Monday

I have no set start time to go into work, but I usually get there by 9 a.m. on Monday because the company has a 10 a.m. all-hands meeting, where the team shares work updates, new hires, and events during the week. I spend the rest of the morning catching up on email from the weekend and reviewing code that developers have submitted before it is pushed, or uploaded, to the web server. I find a few lines of code that might create bugs, so I write email the developers who wrote the code for more information and schedule a meeting if needed.

After lunch, I’m supposed to be working a new feature: an email alert that is sent when an item goes on sale that was in the customer’s shopping cart but did not result in a purchase. This feature is part of a planned website overhaul that the company will be launching at the end of the week. Instead, I check a few of my favorite websites, such as Hacker News (news.ycombinator.com), Techcrunch (www.techcrunch.com), and Reddit (www.reddit.com). I get sucked into reading some articles about the sensors on Apple Watch. After an hour, I’m back on track. I’ve planned how this feature will work technically, but I need to resolve a few issues. I need to know how far back in time I should check the shopping cart, and whether an email alert should happen for all sales or only deep discounts. I send a few emails to my product manager, write some more code, and leave by 7 p.m.

Tuesday

Tuesday starts off normally, and I’m in my desk at 10 a.m. After my routine check of email, I pick up where I left off yesterday coding the alert feature. I need to complete the code and test it before I present it at the Wednesday afternoon product meeting.

I eat lunch at my desk, and watch an Amazon presentation on their new content delivery network, thinking about how it could improve our site speed and prevent attacks.

Mid-afternoon, I receive numerous alerts and email messages saying that the website is down. I drop everything and spend the rest of the afternoon with the four other developers reviewing and reversing changes made to the website in the last 24 hours. The pressure is on to find what is causing the error. Eventually, we find that our website server software automatically upgraded database drivers to a new version that conflicted with the software used on the rest of the site. We roll back the software, using an older version of the driver, and turn off automatic updates. It’s late at night before I work to finish coding the email alert feature.

Wednesday

I spend Wednesday morning in a race to test the email alert feature, and finalize the remaining details, such as choosing the address from which the email should originate, dealing with bounced emails, and implementing tracking to see whether customers click and purchase products shown in the emails.

The product meeting starts. See Figure 3-4. I haven’t completely finished — some emails are not being sent and I’m not sure why. But for now, I’ve met the internal deadline.

The rest of the day is spent on my least favorite activity — bug squashing. One monitor displays my code editor, and the other monitor displays a list of all site bugs and their priority. I scan the list looking for a high-priority bug that I can fix today.

After four hours of squashing bugs, I head home. Usually, on Wednesday nights, a company engineer or an external speaker gives an engineering talk, but tonight I’m going to work on one of my side projects. Inspired by a $180 flight I took from New York to Milan, I’m creating an app that will send an email and text message when a deeply discounted or mistaken airfare is published.

Thursday

On Thursday, I hear back from the product manager, and have a list of updates to make to the email alert feature. One main issue is that the feature specification calls for animated effects on the website along with the email alert. These effects are easy to implement on newer browsers, but some customers use Internet Explorer 8 and supporting that browser is difficult. I meet with the product manager and designer to discuss a few comprises. I keep testing and fixing bugs that pop up.

In the afternoon, I have four candidates to interview for a junior back-end developer position. I need to choose a few challenging code examples to see how the candidates solve problems. I’ll also assess whether the candidates have researched the company and whether they would fit in with the culture.

Friday

I’ve tested the email alert feature, and on Friday I think I’ve fixed all the bugs. I check one of the email alerts, and it appears correctly on an Android phone but has incorrectly sized figures on an iPhone. I find another developer more experienced with HTML and CSS, and we work together to debug the issue. By 4 p.m. we’ve solved all the major problems. I put the email alert feature in the queue to be reviewed by another developer. With that developer’s approval, the app will be released to all users.

Over the weekend, I’ll check email deliverability rates, and whether users have sent feedback through email or on Twitter. For now, I’m off to a happy hour with other coworkers to close out the week.