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.

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 Nodeschool.io 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.

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”.

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…

Packages!

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, proudfeet.io/wheresdrake 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.

Last week I was tasked with creating a 5-10 minute presentation on anything I wanted at HackerYou. I had wanted to explore the beast that is JavaScript a little further (all I had done with JavaScript up to this point was simple things like add, removing, and toggling classes after a click). I remembered a plugin I had seen some weeks ago called Shine.js, which served as inspiration in that I now knew that it was possible to make things move relative to the position of your mouse.

I was struggling to think of a way to implement something to do with mouse movement, when I was told about the JQuery UI Draggable and Droppable, which somehow led me to thinking about searching. Then, like a lightning bolt it hit me – Where’s Waldo! For those not aware, Where’s Waldo (or Where’s Wally in the UK) is a children’s book game where you have to find the namesake character in huge image filled with many diversions and distractions.

My first attempts at creating the “spotlight”/”lightbox” effect were by and large huge failures. That, however, is not to say that they weren’t valuable exercises – I feel like you learn more from your failures than you might from your successes (don’t be afraid to try something new!). Nevertheless, it turned out that creating a circular div with the image of the Where’s Waldo page with a giant div of all black spanning the whole screen would (somehow) not create the effect I was looking for. I don’t know why I thought this would work, but it most definitely did not in any capacity. Back to the drawing board.

After playing around with a couple more options (including creating a giant black image with a circle cut out of it in photoshop – this probably would have worked, but I was convinced that this effect would be possible using CSS), I was brought back to my old friend background-attachment: fixed. Most people use this declaration on images when they want to give the effect of another div scrolling overtop of it on their web page (an example of such on my own website), however, it turned out to be exactly what I needed to remedy my situation. Remember: this property essentially makes the image stationary, regardless of whatever else is happening on the page. Here’s what my CSS looked like at this point:

Boom shakalaka. One important thing to note was that I put a 10px border of solid red just to see where the div was actually positioned on the page before I started tinkering with it’s position (which was absolute and then adjusted the top and left – don’t use margin here, you’ll move the whole div and the “spotlight” effect won’t be apparent)

Next was bringing in the JavaScript. If you’re anything like most entry-level developers (like myself), you lock up slightly at the mention of JavaScript, much less JQuery, and you probably aren’t even aware of JQuery UI (don’t worry, I didn’t either, it’s not that scary). Here is where things get a little more involved, but not terribly so, and by the end of it you’ll have something pretty cool that you can show off to your friends that seems a lot more complex than it is. Onward!

To do this, we’re going to need to access JQuery, which is a library built on top of JavaScript (essentially gives JavaScript a new skin, making writing JavaScript much easier for developers – all praise JQuery!). To do this, we need to load the JQuery Content Delivery Network (CDN), which Google has kindly hosted for us. Paste this snippet in the head of your document.

Next, we’re going to need to access the JQuery UI, which allows us to another set of plugins built into JQuery. If you’re familiar with other programming languages, think of this like importing a module such as math or antigravity. This snippet for this is available once you’re viewing one of the plugins, I got it from looking in the head of Draggable, but can be a little tricky if you don’t know what you’re looking for, so here’s the snippet: <scriptsrc=“//code.jquery.com/ui/1.10.4/jquery-ui.js”></script> . Paste this snippet in the head of your document, and we’re ready to rock.

For the sake of brevity, I’m just going to cover using Draggable, but you can take using Droppable (which has Draggable already built into it) pretty far by setting a target (such as on top of Waldo) and have the script do something when you drop your spotlight on him – an example of which is up on my Codepen.

Now that we have JQuery and the JQuery UI loaded on our page, we can get started. Head on over to the Draggable page and click “view source”. A window with all the code necessary will become revealed. Copy every thing from the beginning of the opening script tag (<script>) to the ending of the closing script tag (</script>). Paste this into the bottom of your document before your closing body HTML tag. This is important because JavaScript is what is called “blocking”, meaning that if you put it at the top of your document and it does not load, or takes a long time to load, the rest of your page will not load until JavaScript is done loading (or won’t load at all if for whatever reason your JavaScript fails to load – a reeeaaaaal pain in the everything).

One thing to note about this snippet is that you’ll have to change a few things about it. If you noticed, the script provided targets something with an id of draggable because the example on the page targets something with an id of draggable. So, accordingly, we must change our selector (or, at least I do because my “spotlight” div has a class of “spotlight”). At this point, here’s what my CSS and JavaScript looked like before I saved:

After a quick save and opening up in the browser, I was elated to find that my crazy idea (which I’d previously thought was impossible, or overly ambitious) totally worked! Again, not that hard to implement, but looks pretty darn impressive, and made me a lot more comfortable working with JavaScript/JQuery. I’d definitely recommend this for anyone who wants to explore JavaScript but doesn’t know where to start, or for those who are acquainted with JavaScript, but are comfortable with things like adding, removing, and toggling classes. I did end up implementing Droppable and writing a little extra script to show a success message once you found Waldo, the code for which (in case you didn’t catch it the first time) is available at my codepen.

Not long after I finished the Where’s Waldo example, my good friend Vanessa Merritt showed me the infamous video of Drake lint rolling his pants. Since we live in Toronto, and pretty much anything involving Drake and the internet is nothing shy of hilarious, one thing led to another, and, well… Where’s Drake was born. My mom is very happy that I dropped out of school to make this.

First, let me preface the rest of this by saying that I straight up ripped this technique off from Christina Tosi of Momofuku Milk Bar, but I’ve added a few tweaks to it, making it slightly more my own, although it is quite true to the original.

Sometimes, when I need a mental break from coding, I bake stuff. This is one of those times.

I first came up with this when trying to come up with a new dessert for the restaurant I was working at at the time. I was trying to find something that would add texture to the dish, while still being packed with flavour – I find that a lot of “crumb” components in desserts lack flavour, and I’ve always tried to make sure anything I put on a plate has a function. I also wanted something playful, and something that people would recognize. After a little brainstorming, Captain Crunch came to mind, and I also thought that corn was a flavour that was constantly underplayed in the pastry world.

Once I decided upon Captain Crunch, I looked through a few of my cookbooks until I stumbled upon this technique from the Milk Bar book. I knew immediately that the “crunch” technique needed to be married with Captain Crunch (I mean, come on – it’s right in the name!). Now, how to make it my own?

A quick look through my pantry would answer that for me. Korean red pepper flakes – a product I’d taken to dousing on more or less everything I eat – stood out as another flavour that was criminally underplayed in the pastry world. My logic went something like: “Captain Crunch is made from corn, corn and dairy is delicious, corn and chilies are amazing… so mixing all three must be super amazeballs!” I merged the two and a star was born.

The only problem with this recipe is that I never got to actually use it – all the other cooks and I ate it all as a snack before it ever even touched a plate. Now when I bring it out, it’s kind of a special occasion, and it always takes less than an hour before it’s devoured (usually as a topping for sundaes or as a garnish on top of a slice of cake for some texture). Anyways, without further ado, caramelized Captain Crunch:

Well, today it finally hit me: I just quit my job and dropped out of school to become a web developer. You’d think I’d be terrified (maybe I should be), but I’m more excited than anything. Coming hot off the heels of HackerYou‘s part-time web dev course, I feel like I’m at a stage somewhere just passed “web n00b”, but not quite at “l337 web ninja” just yet. Hopefully over the next 9 weeks I’ll end up closer to the latter, but until then the internet will just have to deal with me stumbling through the web.

It’s been an interesting first few days at the full-time bootcamp, there’s a distinct sense of community already within the first few days, which is something that only formed in more or less the 11th hour of the part time class. I think it’s mostly due to the fact that all of us are more or less fish out of water, which is not a bad thing at all, and I’m definitely embracing.

So far, there’s been a lot of review – which, while it may seem boring, has actually been amazing! While I was doing the part-time course, I was constantly trying to juggle between working two jobs, school, and coding in class or the few precious moments that I had free time. As you can imagine, there wasn’t much time to really absorb the content – now I feel like I can really process the content, fix any bad habits, and help out with other people who might not be as exposed this web voodoo as I’ve become over the past few months – which is rewarding in it’s own way.

Since we’ve got our first project coming up at the end of the week, I decided to take a look at the first project I did for the part time class. It’s hilarious. Hilarious in the “looking at pictures of yourself in middle school” kind of way – a little cringe-worthy, but still awesome. If nothing else, I can say that I’ve made progress away from being that clumsy with my code in the past few months, but I’m still nowhere near where I’d like to be. Even my final project, which I finished just says ago, has a number of flaws that I’ll most definitely touch up before I pitch it to the intended client.

With that said, here’s a list of things I’ve picked up along the way for anyone just getting web dev to consider:

Don’t try and design while you code – This is a terrible habit that I have, and it makes absolutely no sense as to why I picked it up . There are plenty of free online resources to give you templates, use them, but don’t copy the code. Ever.

Good photos make your website look infinitely better – There are plenty of online resources like Unsplash that give you awesome photos for free. Hire a photographer if you need head shots or specific photos taken. Whatever you do, you need to promise me that you will never ever ever use a photo from your phone on a website.

More complex ≠ more awesome – Have the content speak for itself. Too much information can be disorienting and lead to terrible user experience, as well as leaves a large margin for messy code

Don’t be afraid of Javascript – After hearing about how complex Javascript can be, I was pretty terrified of it. Then I reached a point where I realized that I would need it. As it turns out, it’s not so bad. It has an odd syntax, and it’s a bit of a pain when it doesn’t work – but it’s no worse than your Python program not working, and much less worse than accidentally getting yourself stuck in a “for loop” in the Python IDE (for those of you who are lucky to have not have done this yet – you need to restart the program to get it to stop)

Take a break – I’ve encountered a few times where I can’t figure out what’s stopping my code from looking the way I want it to. Thinking I could somehow brain-muscle the code into working, I would spend hours trying to tweak it to get it to work. When my smarticles had been exhausted (I have precious few), I’d end up going to the gym, where, of course, the answer to my problem would come to me (usually mid-squat or some other equally unfortunate time)

Learn to say “no” – This one is probably the hardest to learn. Telling your friends that you can’t come out, or your significant other that they can’t come over, because you’re “in the zone right now” or “are really trying to nail floats” goes over about as well as trying to tell people that rollerblading is cooler than skateboarding (I tried this when I was 11 – 0/10, do not recommend). Unfortunately, part of getting awesome at anything is actually taking the time to get awesome at it in the first place, and that means that at times, it might eat up other parts of your life. Tough break, kiddo.

Anyways, I feel like that’s probably enough of my ramblings for the evening. I’ll try and keep this thing updated as often as possible, until then – keep your stick on the ice.