It was great to meet you: learning how to say “no”

As I’ve progressed on my journey toward become a developer, I’ve encountered a strange problem: there’s a surplus of work being presented to me. I don’t mean that in an arrogant or conceited way, so allow me to further explain.

When people hear that you’ve quit school/work/life to become a front-end web developer, not too many people are sure of what that means. It’s then your job to explain that, in the simplest of terms (because nobody really wants to hear what SASS, Grunt, AngularJS or whatever new tool you’re excited about) that you make websites. At this point, the conversation will usually go something like this, “Oh, you make websites? That’s GREAT! I[‘ve been meaning to make a/ I know someone who needs a/ My company needs a] website for a [business/ school/ bake sale]”.

This, my friends, is where I had to make an important decision. I’ve had to say “no”, which is a little more difficult than it might sound. It’s extremely difficult to me because I’ve had no income over the past few weeks while I’ve been going through the HackerYou bootcamp. I’ve had to say no because while I’m flattered that people would select me to do work for them, I feel like I might sacrifice my opportunity to learn at HackerYou by becoming immersed in something other than the lessons and projects. If I’m being completely honest, it’s also usually due to the fact that most people’s budgets haven’t warranted me wanting to drop everything to work on their project (I realize this is a bold statement coming from someone who is more or less surviving on mustard sandwiches right now, but I don’t want to set a terrible precedent for either myself or my freelancing brothers and sisters).

I can usually get around seeming ungrateful for work passed my way by simply telling people that I know that I straight up avoid mixing personal and professional life at all costs because it can get super weird super fast. This is usually enough to explain myself, and everyone that I’ve told this to is very understanding, and I usually also have a handful of other people I can recommend in lieu of myself.

This is, as I understand it, a very Jerry Seinfeld approach to saying “no” to people. Why Jerry Seinfeld? In his latest show, he talks about how he’ll meet people in the street and have a quick conversation with them, ending it with the phrase “it was great to meet you”. That phrase it pretty much the most well-crafted phrase to essentially tell someone “this conversation is ending now”, while still giving them a compliment. What a guy. Class act all the way through.

Code is one thing that I knew that I would be developing my skill set in by coming to HackerYou, but I’ve found that I’m developing a whole new set of abilities that I hadn’t planned on: my people skills. These are the kinds of skills that you can try and teach all you want, but the truth of the matter is that you just have to socialize a lot, and put yourself in situation that might be uncomfortable at first, but let you grow immensely.

Meetups: The First Encounter

Sometime last week I decided that I’d like to make JavaScript my “thing” within the next few months. A lofty goal, even for seasoned developers, but I’ve always loved a good challenge. JavaScript seems to be an area of development that’s showing a lot of potential (not that it ever wasn’t, but there are tons of new frameworks like Angular, Ember, and Yeoman emerging, which is super exciting).

One thing that’s particularly of interest to me is Node.js – a server-side programming language written in JavaScript. Pretty much every front-end web developer’s dream come true. I’ve been pining to go to these meet-ups that I’ve been hearing a lot about from some of my other dev friends. So when I saw that would be hosting their own meet-up in town, I jumped on the chance. The meet-up was advertised as accessible for all skill levels, which seemed right up my alley, as I had no experience with Node, and have very limited experience with JavaScript.

So, thinking that I might have a shot at understanding some of the material, I went to the meet-up with a few pals in tow – Wisam (programming whiz, and awesome dude) , Burger Boy Matty M, and Jonny James (handsomest man this side of Yonge St).

The task assigned to us (“us” being the “total beginner table” – shoutout to our table-mates Connie and Tobi, you guys were awesome!) was to complete four tasks, and then collectively come up with some kind of project using Node between the 6 of us. Seems easy enough, right?

Well, the tasks jumped from “wow this is not as hard as I thought it would be,” to “… I don’t even know what these words mean”. Jonny and I paired up and tried to tackle the problems, which was my first time doing a paired-programming exercise, and I’ve gotta say that I really enjoyed it. We ended up only completing two of the four problems, but it was a really great process of brainstorming, coding, troubleshooting, repeat, and eventually triumph. Many fist-bumps were had. I even got to explain for loops using my nacho analogy (ask me and I’ll go into more depth. Also, I want it to be publicly known that I love nachos).

After exhausting all my smarticles by learning about JavaScript functions, arrays, and objects all day at HackerYou, and then going to the meet-up and having my mind bended in ways I didn’t know were possible, my brain was feeling like mush and Jonny and I decided to head out.

So, considering that I only got two of the four problems solved and I left with more questions than answers, would I say it was a success?  Yes and no. Did I get a lot out of it? Absolutely. Did I wish that it was a little more guided and there was some more direction? Absolutely. I still don’t really know the potential, syntax, or simple implementations of Node.js, which is a little disappointing. Will I go to future meet-ups? Of course! I wouldn’t say that I had a bad experience, just not the experience that I was expecting. Such is life. Either way, it was a good exercise in trying something new, meeting a few new people, and really pushing the limits of what I know about JavaScript, which is exactly what I should be doing if I want it to be my “thing”.

Don’t bring a banana to a gun fight – stepping your web dev game up with some tools and tricks of the trade

Over the past few weeks, I’ve been learning a lot of little tricks and tips from the instructors and mentors at HackerYou – most recently SASS (which I prefer) and LESS, which are CSS pre-processors. To abreviate: they make writing CSS much easier and more awesome. All this is to say that my workflow has increased exponentially since taking the full-time bootcamp course. So I thought I’d detail a few of the things that I’ve stepped up since taking the full-time course, something that every dev should be looking to do to streamline their workflow.

First and foremost, we need to start with what text editor you’re using. Personally, since I’ve started working in HTML and CSS I’ve used nothing but Sublime Text, and I have nothing but good things to say about it (heck, I even paid for it!). I used version 2 for a long while because I hadn’t upgraded my OS, but I eventually caved and upgraded both my OS and Sublime. I didn’t notice a huge difference, but one slightly annoying thing was that I had to re-install all the packages that I had on my Sublime previously. Speaking of which…


This, to me, is one of Sublime’s biggest draws – the ability to create, modify, and install packages created by other users or yourself. One of the most popular ones is a package called Emmet, which you absolutely must install if you’re using Sublime. Sublime will still work if you don’t install Emmet, but it’s a bit like buying a Ferrari and only driving it in the parking lot of the car dealership. People have blogged about all the crazy awesome shortcuts and tricks you can do with Emmet, and the folks at Emmet have actually prepared a handy-dandy cheat sheet for you to reference. Resident web ninja/tool junkie Wes Bos is currently writing a book about how awesome Sublime Text is, and has a few blog posts about how you can visually tweak Sublime Text to help you out (post numero uno, post dos). 

Additional hardware

Alright, this one may be a little far fetched, but hear me out: you should think about getting an external monitor. I know, I know, it seems a little excessive, but I swear it’ll improve your workflow. I thought having a second monitor was excessive, until I found myself having to constantly have to write code, save, tab over to my browser, refresh, look for the change etc. I know that all these things can be automated to keystrokes, but that’s still time (a LOT of cumulative time) that you could be coding and not tabbing between windows. So after a while, I started looking into getting another monitor. Turns out they aren’t as expensive as I thought they were (mind you, they’re not cheap, but they’re not the $500+ I thought they were for a decent one).

You might even be able to score a good one off Kijiji or Craigslist for cheap – but if you’re going this route make sure that you get a chance to see it actually on before any money exchanges hands, dead pixels are the worst. Even if you’re not going the preloved route, I definitely recommend seeing the monitor actually functioning, and I’d also recommend going to a site like Unsplash, so you can see how the colours and resolution are. Sometimes a monitor looks like it’ll be great, until you try and look at a high res picture with intense colouring and it looks like you’re staring at a crayon drawing of a potato. No bueno, my friends. No bueno at all.

This is my current setup:



In the top monitor I’ve got Sublime going, and I’ve split my window in two – one half has my HTML, the other has my CSS. The laptop below has my browser, onto which I’ve installed a plugin called Auto Refresh Plus which I set up to refresh every 5 seconds – just one more thing that I’ve set up to expedite my work. I’ve also got an external keyboard and mouse plugged in – without it the setup felt extremely uncomfortable and I was working with shoulders hunched up and ruining my back. The mouse is essential because using the trackpad is awful for your wrist, and I (for some crazy reason) don’t want to end up with carpal tunnel.

Testing mobile

This is a tricky one, as it’s difficult to do because you’re building the site on your computer and testing it locally. I know that this may not be the most recommended method, but what I like to do is create a directory on an already existing site and test the site on my phone, or a friends iPad if available. As an example, takes you to the site that I was testing my Where’s Drake app on before I went and bought my own URL for it (full disclosure: this app is not responsive at all, and probably won’t work properly on your phone). I know that a lot of you might be thinking why I don’t just do this by resizing the browser or using some of the dev tools in the browser. While those are all great options, and generally what I do before I put the final touches on, nothing really compares to the feel of using the website on your phone. What looks great on your screen might not translate the way you thought it would on an actual phone – text sizes may be too large, something might be too far adjusted to the right etc. Mobile site are all about the feel and while resizing the browser will get you pretty close, it’s still no substitute for the real thing. Here’s me testing out my latest HackerYou project on my phone, it feels good to know that the designs don’t just work in theory, but I now have definite proof that they translate well to the device.


Until next time, stay SASSy (womp womp)… I’ll see myself out.