collaboration, Github, software development

There’s No “I” in Software Development

Business schools often proclaim fostering teamwork by assigning tons of group projects. Yet, it’s at General Assembly – the three-month programming bootcamp I’m currently enrolled in – where I’ve been immersed in the most intense team environment of my career. Without a doubt, the depth of collaboration has been the biggest surprise of my summer in software development.

General Assembly boasts three immersive tracks: user experience (UX) design, product management, and web development (the one I’m taking). These tracks reflect three of the main functions inside of many early-stage Internet firms today. The role of the developer is pretty obvious: to build a product using code. UX designers, on the other hand, focus on shaping the experience of a user when interacting with the product. As our lives become cluttered with applications, excellent design is quickly becoming paramount to capture and retain our limited attention. Finally, product managers liaise between UX designers and developers, and validate customers desires for a specific product. I think of product managers as “mini-CEOs” of a product.

The cross-immersive project allows UX, product management, and programming students to work together.
The cross-immersive project at GA allows UX design, product management, and programming students to work together.

The climax of General Assembly is a “cross-immersive” project during weeks 9 and 10 where 2-3 programming students are paired up with a product management student and a UX design student. I was a bit apprehensive at first because I had no idea what kind of project our product manager would assign us to, but I was pleasantly surprised that instead of diving into a predetermined idea we had a day-long brainstorming session to figure out what we should build. To me, the key criteria to decide on a project centered on 1) finding a reasonably cool idea and 2) making sure that the project was within scope (in terms of time and ability to execute given our rather limited skill-set). We decided on a web app to create and join pick-up soccer games in and around New York City.

As a business school student, I found it both refreshing and challenging to collaborate with a product manager. It was refreshing because we could finally talk about “customer validation” or “monetization strategies” which are part of my daily b-school vocabulary. At the same time, I constantly had to stop myself in team discussions regarding the direction we should take because as a junior programmer my role in the team is completely different. Instead of focusing on the merits of the idea and how we should proceed, I homed in on understanding the requirements, features, and time horizon of the project. Hard as it may be, I think learning to follow is a crucial leadership ability that more business students need to practice.

On the first few days, I also found myself pushing back – more than my programmer teammates – on many of the features thrown at us by the designer and the product manager because I could foresee that they would take way more time than originally estimated. This reinforced my notion that serious product managers should take the time to learn how to code – at least enough to understand the time, effort, and pain it can take to create something as simple as, say, a login page.

This cross-immersive project was also the first time my fellow coders and I really used Git and Github. It’s taken me a few months to really understand how these two tools really work together, so explaining it fully requires a standalone blogpost. But at the most basic level, Git and Github allow for “version control” of the code in a big project. In production settings, programmers will work on a “clone” of the master codebase, making changes to the code on their own computers. If the workflow is coordinated well, then no two programmers should be working on the same files. Parallel workflow would then allow each programmer to essentially save their work and “push” it into the cloud (Github) without producing a problem. At this point, all the files that have been changed are merged back into the master codebase and process then repeats itself.

Basic flow of version control using Git and Github
Basic flow of version control using Git and Github

At first, the process of pulling, saving, pushing, and merging felt arduous and we maybe completed a cycle per day. This, however, proved to be a huge mistake because there were just too many changes to keep track of and each person’s work spilled into the files of another teammate, creating merge conflicts at the end of the day. By day three, we were communicating much more explicitly – telling each other exactly what were going to work on – and after 30 minutes or so, we’d all stop and integrate our files on Github.

Building software requires teams to be truly synced up, both on a developer-to-non-developer level as well as on a developer-to-developer level. Failing to do so only leads to deployment delays, conflicting code, and an overall crappy product at the end of the day.

Meet Octocat, Github's cute mascot. Makes you think Github is a friendly tool, but given the steep learning curve, it's anything but.
Meet Octocat, Github’s cute mascot. Makes you think Github is a friendly tool, but given the steep learning curve, it’s anything but.
backend, javascript, Node

Building My First App With Node

I’ve made it through the end of the first half of my programming intensive course at General Assembly. Just barely.

After a 3-week frontend introduction, we shifted gears to the backend. To do so, we downloaded something called Node.js. We also installed a bunch of “modules” onto Node to do specific things.

Traversing from the frontend to the backend
Traversing from the frontend to the backend of software development

I’m going to level with you: during my first week of learning about Node, I was completely lost. Like “I-have-no-effing-clue-what’s-going” lost. And it was particularly frustrating because I spent countless hours after class trying to understand what exactly Node was. I read a bunch of “intro” tutorials, watched at least 10 videos on YouTube, and even bought a few books on the basics of Node. Despite all my effort, I still couldn’t explain Node to my wife.

The tutorials, videos, and books presumed some basic knowledge of server-side applications. But I had no foundation to connect so many new concepts and terms. It reminded me of a recent passage by Tim Urban on his blog “Wait, but Why?“:

I’ve heard people compare knowledge of a topic to a tree. If you don’t fully get it, it’s like a tree in your head with no trunk—and without a trunk, when you learn something new about the topic—a new branch or leaf of the tree—there’s nothing for it to hang onto, so it just falls away. By clearing out fog all the way to the bottom, I build a tree trunk in my head, and from then on, all new information can hold on, which makes that topic forever more interesting and productive to learn about. And what I usually find is that so many of the topics I’ve pegged as “boring” in my head are actually just foggy to me.

So I set out to build a “tree trunk” and stick all these branches of knowledge together. I started at the most basic level by asking simple questions such as: “What’s a server?” Of course, I kind of knew what a server was, but “kind of” was not good enough.  I needed to understand how things worked at a more fundamental level. Admittedly, I was embarrassed at first to google these things or ask my instructors these questions during review sessions. Once I got over my fear of sounding ignorant, I started getting a much clearer and deeper picture of how the Internet and our computers work.

So, what is Node?

Node is a platform that extracts JavaScript out of its natural habitat – the browser (ie. Chrome or Firefox) – and provides a non-browser environment that JavaScript can run on. Through Node, we can access databases, listen to network traffic, and receive/respond to http requests – all with JavaScript. By embedding Google’s really fast and really awesome JavaScript engine onto our computers, Node allows us to build scalable network applications using solely the web’s lingua franca.

Since JavaScript is the only language I have been exposed to thus far, I initially failed to grasp the magnitude of Node’s impact. Before Node, a JavaScript programmer would have been confined to the frontend or would have had to learn a server-side language such as PHP, Python, or Ruby on Rails in order to connect to the backend and create a full-blown application. Thanks to Node, frontend developers can now work in the backend as well, and that’s pretty sweet since there’s now language consistency across the technology stack. More importantly, because of JavaScript’s asynchronous nature, we can write code that is non-blocking. In other words, a chunk of code doesn’t have to wait around for previous chunks of code to finish before it can start executing. Two or more chunks of code can run in parallel. The result: blazingly fast web applications.

An illustration of how Node's event loop enables non-blocking code
An illustration of how Node’s event loop enables non-blocking code

Using Node, I could create a chat server, an ad server, or a real-time data app. Indeed, using Node I was able to create my first application: a simple Wiki on startups. As a user, you can sign up and log in (I’ve encrypted passwords) as well as create, edit, and delete posts. Node is pretty low-level, so I also used a number of modules (such as Express and EJS) to build the server. Lastly, I hooked up to a Mongo database to store and retrieve information related to users and any posts on startups created.

I tried to go for a minimalist style that should make it intuitive to navigate. Due to the time constraint, I wasn’t able to build out all the functionality I wanted, but I’m still happy that I was able to build this Wiki over the course of a weekend. As simple as this application may be, the feeling of creating something from scratch is second to none.