Hackbright: Starting from the Middle

>>> Hackbright is a 12-week software engineering program for women in San Francisco. Four months ago, I applied for and was accepted into Hackbright’s 13th Cohort, starting in January 2016. As a very warm and pleasant February sweeps in on the tail of the Chinese Lunar New Year and Super Bowl 50 festivities, I am now 7 weeks into the program, hands and knees steeped in my final project, and decide it’s time to reflect upon my experience at Hackbright.

In novels, the midpoint is usually a critical moment, where things are about to get interesting. At this point, the character takes a figurative look at herself and wonders: What is she becoming? How will things be different? What are the odds against her? What does she have to do to keep going?

The same happened to me. After 5 weeks of immersive lectures and pair programming, I started to have Inception-type dreams of nested JSON dictionaries, callback hells, mazes and recursions, and flickering bash error messages. When job search, technical interviews, and hackathons crept into the lunchtime conversations with my fellow Hackbrighters, I started to feel a tiny pinch from the impending future.

That was when I reached the “look in the mirror moment,” examining my self-worth through the lens of my 5-week bootcamp life: Is my final project good enough to make me proud and get people excited on Career Day? Am I qualified enough to break into the industry? Who wants to take a chance on me and hire a bootcamp grad as a software engineer?

Then one day, when I checked the mail, a familiar bright yellow envelope caught my attention. It was a call from my past, a reminder to renew my bar licenses, which felt no more urgent or significant than the other notices to pay the PG&E bill, renew the DMV registration, or continue the insurance policies. All of a sudden it dawned on me that my pre-Hackbright time seems like a lifetime away.

Because of Hackbright, my life will never be the same again.

I am no longer that lawyer who went to coding workshops on the weekend and got strange looks when I introduced my profession. I am no longer that outsider perpetually looking into the tech world through a glass wall, wondering where’s the door to the other side. I am no longer that professional student always getting started on the next Coursera, Udacity, Udemy, and you-name-it class.

People ask me, “What do you do at Hackbright?” My answer is, “Making software!” The untold part is that I am also making myself — and the struggle, the growth, and the sisterhood are all part of that making.

My story starts somewhere in the middle, and it does not stop there.

>>> My project is a web application called “Destination Unknown,” a roulette mystery trip planner with an instant “swept away by Uber” feature. The two weeks of working on my project gave me a taste of what it feels like to be building something from ground zero. Most of the time, I don’t feel like a cool hipster “maker,” but more of a menial brick-layer — I am slow, clumsy, and easily out of my depth.

As our Hackbright instructors repeatedly remind us, the No. 1 goal of our project is to learn, and we are encouraged to keep track of our bugs and progress. So here are some of my notes from conceiving my project and putting down my code bricks.

{{ MVP: The Ambition of A Scooter}}

MVP, short for Minimum Viable Product, is a foreign concept to me. It originated from the Agile Development methodology, and its central tenant is to not build things you don’t need. The bottom line for MVP at Hackbright is to build something in 2 weeks that I can present to a recruiter on Career Day.

At the project planning phase, I had trouble narrowing down my MVP, partly because I incorrectly thought MVP should encompass all the core features of the app, and partly because I abhor half-baked efforts and MVP sounded dangerously close to a race to the bottom.

Then I found this illustration on twitter, which explained a lot about MVP:

Using this vehicle analogy, I could finally connect the dots between features and functionalities:

  • Scooter: must have features; a product with a story that serves a single purpose
  • Bicycle: like to have features; a product that has performance and aesthetic advantages over the earlier version
  • Motorcycle: nice to have features; a product with a strong identity and more complex technologies
  • Car: shoot-to-the-moon features; a product with a market and revenue stream

My project’s MVP is therefore the functional equivalent of an ambitious scooter: toy-sized and practically useless, but full of hopes and dreams.

The goal of the MVP is to begin the process of learning, transforming what started out as a simplistic, bare-boned product to a more sophisticated version with each iteration.

Eric Ries, author of The Lean Startup, claimed that Dropbox’s MVP was a 3-minute demo that its founder Drew Houston created, because he built the minimum needed to illicit feedback, and the strong customer response to the demo validated his product-market fit before he invested in building a working product.

While I don’t believe that a demo can pass as MVP in most cases, certainly not for my purpose, I had come to appreciate the psychology and workflow from having a MVP:

  1. Nothing is perfect on the first try.
  2. Learn and produce something better each time.
  3. Dream big. Start small. Lower the expectations. Enjoy the journey.

{{ API: Where Words Fail }}

I find word choices in programming languages curious at times. What? JavaScript is not an offshoot of Java? What’s going on with Android’s sweet tooth obsession? So drinking coffee does not give me the superpower to write in CoffeeScript?

Then there’re the acronyms, and developers love their acronyms. To me, a study of programming is also a study of abbreviations: SQL for Structured Query Language, JSON for JavaScript Object Notation, and HTTP for HyperText Transfer Protocol. But the most elusive of them all is API, Application Programming Interface.

Before I started at Hackbright, my knowledge of API came solely from the Oracle v. Google case, where the Ninth Circuit painstakingly explained what is an API package in its opinion:

Sun wrote a number of ready-to-use Java programs to perform common computer functions and organized those programs into groups it called “packages.” These packages, which are the application programming interfaces at issue in this appeal, allow programmers to use the prewritten code to build certain functions into their own programs, rather than write their own code to perform those functions from scratch. They are shortcuts. Sun called the code for a specific operation (function) a “method.” It defined “classes” so that each class consists of specified methods plus variables and other elements on which the methods operate. To organize the classes for users, then, it grouped classes (along with certain related “interfaces”) into “packages.” […] The parties have not disputed the district court’s analogy: Oracle’s collection of API packages is like a library, each package is like a bookshelf in the library, each class is like a book on the shelf, and each method is like a how-to chapter in a book.

While the court’s description above was all true and perfectly colloquial, I failed to grasp what was an API — a program, an interface, a shortcut, or a how-to chapter in a book on a shelf in a library? What is it after all?

(Google would certainly argue that the court’s understanding of API is wrong, which is another story.)

It was not until I started writing code myself that I started to understand web API and what it can do. In essence, API is a broker between a programmer and an application. This broker receives requests from the programmer, and if the request is allowed, delivers the data requested.

API is a two-way street: third-party developers can access data that they otherwise don’t have, and API providers rely on third-parties to build tools and further their core product.

For example, in my project, I make API calls to Uber, Yelp, and Mapbox, which is a fancy way of saying that I follow a set of commands set by these companies to request data for my use in my app. Each company’s API has its own flavors, rules, and limits. With the Uber API, for each user logged in to Uber through my app, I can request private user information permitted by Uber and make test (“sandbox”) ride request on behalf of the user. With the Yelp API, I can search through businesses and get basic information about the filtered result, such as a business location, its Yelp rating, and a short review snippet. With the MapBox API, I can pull a map from Mapbox and show it in my app with user-generated data sprinkled on top of it.

Looking back at the time when I tried to understand API with my lawyer brain to no avail, I saw my former self struggling with not knowing and feeling immensely stupid. In the legal system, the plain meaning of words is the basis to interpret and infer the objective and intent of the parties, and in a perfect scenario, you’re supposed to know everything you need to know just by staring at the words.

But it does not work that way in programming. API does not mean a thing on paper; it has meaning only in the context of its usage.

I didn’t understand API from the Google v. Oracle case. I understood API from working with it.

More and more often, I see people trivialize the difficulty of programming. Look! Kids are coding! Everyone is coding! Coding is so easy breezy! But the truth is, programming is a lot messier and harder than people are willing to remember, especially when you are doing it all on your own. People don’t mention the tedium of reading the API documentation, studying the code examples, and getting the OAuth security token, before charging to the juicy part of making actual API calls.

But that tedium and that feeling of being slow, stupid, clumsy, lonely, and out of depth is something I learn to live with. When I pat myself on the shoulder and say “I’m okay with that,” that’s a small victory worth celebrating.