How I Got Into the Web Development Industry

I’ve been getting a lot of questions from students recently about how I landed my sweet gig at Lab Zero, or, more generally, how I got into the industry in the first place. It’s really nothing out of the ordinary, but I thought I’d write it up here so I can cut down on repetition. (DRY is an important practice!)

The main reason people ask me about my own path is because they’re often so torn nowadays between going the bootcamp route, or just soaking up as much free knowledge as possible and then dipping their toes into a small-time position. I can’t say whether one’s better than the other. Bootcamps have the benefit of teaching you a massive amount in a short time, while also taking a lot of your money and giving you unrealistic expectations about how many hours per week you should be working. The DIY route allows you to learn at your own pace and climb the career ladder, but it takes much longer until you’re making a six-figure salary, or whatever.

I chose the latter, mostly because the bootcamp option didn’t exist when I was starting off as a full-time professional in 2008 – but also because I had been making websites since I was 9 years old, in 1994. This, of course, gave me almost a decade and a half of experience before I entered the professional world in earnest. And I cannot stress how important years of experience are. No matter how much a bootcamp attempts to cram into your skull, there is no way in three-ish months that you will be able to come up with an exhaustive set of creative solutions to the myriad problems you will encounter in the real world.

It’s a bit disingenuous for me to say my career started in 2008. Even though I wasn’t getting paid for it, starting off and making my own websites was a very important step. As a kid, I found it very freeing to be able to create anything I wanted to express and put it on the web. Some comics on my site date back to 1996. This very blog started out in 2001 as a place to experiment with designs and new technology.

Here’s the results of what was probably my first paid gig, probably from around 2001. I got this job because my step-brother lives at this home and they heard that I was at “whiz kid,” so they asked me what I could do.

When I was in college, I took two summer internships at Sun Microsystems in 2005 and Autodesk in 2006, found through my dad and I think through craigslist, respectively. They were paid internships, and generally focused on me picking up the slack with the group I was in – doing some testing of features, writing simple forms (my first brush with PHP), and generally learning how to function in an office setting.

Speaking of college – I chose to be a Linguistics major, after an attempt at Computer Science didn’t work out (mostly thanks to my ridiculous fear of math). Some might argue that Linguistics has a lot to do with programming, and to that I say: that’s a pretty big stretch. Syntax trees and morphology are pretty interesting to the analytical mind, but they’re not programming. I even started off on a grad program at UW Seattle in Computational Linguistics in an attempt to rope computers into my study.

The summer before I started grad school, I found a craigslist posting from a business owner looking for help with his site. I ended up working with a designer to overhaul some HTML and add a few extra pages to the site. I ended up continuing to work on the project from time to time throughout the school year.

By 2008, family matters made me decide to move back to the Bay Area. Back to living at my dad’s house, I decided I’d get a job while I was deliberating about whether to continue my grad program. I searched craigslist again, and found a posting for a web developer position at Diabetes Health, a small magazine in Marin. This became my first full-time job. I even bought a car for my commute (which turned out to be a poor decision as I used it for less than a year). I was basically thrown onto an existing PHP stack and had to basically learn the language on my own, fixing up the previous developer’s work and starting to add features of my own. Despite being the “smartest person in the room” (that is, the only developer in the company), I learned a significant amount about full-stack web development out of necessity.

While living in Marin, I started to cultivate a group of friends mostly based in San Francisco. It became apparent after a year that 1) I didn’t want to continue my grad program, and 2) I shouldn’t stay at my dad’s house forever, so it was about time to find a job in the city.

I scoured craigslist for a position – yet again – and found a nice challenging one at Linden Lab, working on their marketing sites and a few behind-the-scenes tools. At this point I was pretty much ready to say my career had begun.

Although I was fired for weird reasons after a year, a former coworker referred me to Lab Zero, which I joined in May 2010, and I remain to this day, doing all sorts of things for all sorts of companies.

I have to say, referrals are really the way to go. But of course, you have to get your foot in the door first, and make some good connections (read: be nice to your co-workers). If you don’t yet have the connections, craigslist was pretty much the place for me, and I’d assume it continues to be a good source to this day.

It’s also worth noting that I’m happy where I work, and barring anything terrible, am not looking to “climb” the job ladder into a bigger or cushier position. Pay’s good, responsibilities are good, and I personally don’t want to end up in a situation where I’m delegating all the actual work to other people. But that sort of thinking isn’t for everyone. People at LZ have come and gone, looking to become managers or executives or what have you. And if hopping from place to place is for you, tech is currently the right kind of industry for that.

So that’s it! I hope this has been helpful and given you an idea of how one developer got to where he is today. I benefitted from growing up in a household that encouraged computer use, turning web development into a very long-running hobby for me. But if you’re on the job hunt, this predisposition is certainly not expected of you. Unless you’ve decided on the bootcamp route, start small and you’ll get somewhere sooner than you know it.

What is a function?

I’m trying my hand at writing a ridiculously easy-to-follow guide on JavaScript essentials. There might be many of these out there, but this one is mine. Tell me what you think and whether I can clarify or simplify at any point.

In JavaScript, a function is a bunch of code that can be run, or called, repeatedly.

Creating a function

Here is an example of a function being created:

var doStuff = function () {
  // Code you want to run goes here!

In this example, we are first creating a variable called doStuff. doStuff is then being assigned a function as its value – which means, from now on when we refer to doStuff, we are referring to a bunch of code that can be called.

Calling a function

Whenever you see parentheses following a variable, it means we are calling a function – the code inside it will be run:

doStuff(); // the doStuff function is being called.

This is in contrast to just referring to a variable, which is valid, but doesn’t do anything:

doStuff; // no-op


Some functions can change what they do, based on how they are called.

When we are writing code for the browser, we automatically have access to a function named alert, which tells the web browser to pop up a dialog box. When we call alert, we need to specify what exactly to show inside that dialog box:

// the alert function is being called with the string 'Hello!'

In this example, we are putting a string inside the parentheses. Anything placed inside these parentheses is called an argument. In the case of alert, the argument determines what text appears in the dialog box that shows up:

Screen Shot 2013-04-05 at 5.19.18 PM

If we want to create a function that makes use of an argument, it would look like this:

var takeThis = function (foo) {
  // Inside these brackets,
  // we have access to a variable named foo.

// foo's value will be "Hello!" when the function is called.

// foo's value will be 3 when the function is called.

In this example, we are saying that whatever is passed in as an argument when we call takeThis will be referred to as foo as the function runs. We can name the argument whatever we want, but it only affects how it will be referred to inside the function’s code.


Functions can also give back a result after they’ve been called. This is called returning. Returning is important if we want to receive the result of a function and use it someplace else:

var giveMeSomething = function () {
  return "Here you go";

var something = giveMeSomething();
// now something's value will be "Here you go"

In this example, we are using the command return to specify what comes out of the function when it is called. Upon calling giveMeSomething, we are taking its result and assigning it as the value of a new variable named something.

Multiple arguments

Functions can accept multiple arguments. It is as simple as separating the values being passed in with a comma. In this example, we are creating a function that can add two numbers together and return the result:

var add = function (addend1, addend2) {
  // add the two arguments together and then return the result
  return addend1 + addend2;

// pass 1 and 2 when calling add and assign its result, 3, to sum
var sum = add(1, 2);

Having called add with 1 and 2 as the arguments, those values are then assigned to addend1 and addend2, respectively.

Calling functions inside other functions

There’s nothing stopping us from calling functions within the code of another:

var sayHello = function () {

Here, we’re creating our own function and calling it inside another function we’re creating:

var bar = function () {
  // do something

var foo = function () {

foo(); // call foo, which will call bar

Here’s a more complex example where we’re passing in arguments and getting things returned to us:

var bar = function (arg) {
  return arg - 1

var foo = function (arg) {
  return bar(arg) - 1;

var result = foo(3);

Seem complicated? Hover over these steps to see how this code will run:

  1. bar is defined and assigned
  2. foo is defined and assigned
  3. foo is called with 3 passed as the argument
  4. foo begins to run, with arg having a value of 3
  5. bar is called with arg passed as the argument
  6. bar begins to run, with its own version of arg having a value of 3
  7. arg is subtracted by 1, and returned
  8. The result of bar(arg), which is 2, is subtracted by 1, and returned
  9. The result of foo(3), which is 1, is assigned to result.

Passing functions into other functions

To take it one step further, we can even pass functions themselves as arguments:

var bar = function () {
  // do something

var foo = function (callMe) {
  // we are assuming that the argument is a function

// we are not calling bar here,
// merely passing it in as an argument while calling foo

This last example might take a bit of time to understand. The difference between merely referring to a function versus calling it is an important distinction.

  1. When we run foo(bar); we are calling foo, but not calling bar – remember, we don’t see a pair of parentheses following it – we’re only referring to it and passing it in.
  2. When foo begins to run, it has access to a variable named callMe. Having specified the function bar as the argument, callMe now refers to it as well.
  3. callMe, or bar, is called.

Why would we want to do this? So we can call foo multiple times and tell it specifically which function to run each time. In the real world, foo would do more than just call another function – it might do something with the result of that function, or return something itself.

That’s it for an introduction. I’ll see if I can write something about more complex topics like scopes, this, recursion, closures, asynchronicity, et cetera – but we’ll start here and see how it goes.