How I Lost $5000 With Bad Code

Erm…. maybe it was more. You see, around 2 years ago, when I first started writing code professionally (a term I’m using pretty loosely here), I was tasked with building an app that allowed store owners to request reimbursements for damaged and expired items. The app used SQL, C#, an archaic IDE called BPM and Javascript, the former 3 of which I had been introduced to while on the job.

The app was a complete mess. From lengthy SQL queries that slowed to a snails pace when the app grew to handle 10,000 rows, a particularly embarrassing 100 line long if else statement (not kidding) and a UI which looked like it might have belonged to the late 1990’s. Still, it was finished! And to me, at the time, working meant finished.

I should also mention our team was not using test driven development while making this app. We relied on a one-man (at the time) QA Engineer to test all our apps. With little oversight and no real way to test the many edge cases that the app presented, it was shipped and it kinda worked for a couple weeks.

Then, a woman from accounting came over. She was curious to know why we were rounding up every transaction. Was this a new policy? Oh shit. You see I had been dealing with decimal number types using Javascript. In order to get them to two decimal places, I was calling a combination of `round` and `toFixed()`.

It’s amazing, in retrospect, that no one caught this bug. We had the habit of using the same items for testing and in this case, those items worked perfectly. It took around 300 stores, using this app apparently around the clock to return meat, popsicles and Hawaiian shirts. Around 10,000 requests later, all that rounding had cost our company around 5k.

I was sure I’d be fired. Fuck, just a few months in to my first software job and I’d wrecked the company. I waited for the team to kick me out, their disapproving fingers wagging back and forth after I walked out the door with my items in a sad cardboard box.

That day never came, thank Bob. I fucked up. We came together as a team and fixed that app and I learned a $5000 lesson. Our company was making around 2Bil a year, so that amount didn’t exactly tip the scale. Still, it taught me a lot about getting the requirements for an app before you code, understanding the code you end up writing and most importantly, test that shit.

That wasn’t my first or last mistake involving writing bad code but I pray it’s my most expensive.

I Got a Project, Now What?

Congrats! You created a nice (or maybe not so nice) web site or web app using your newly (or oldly) acquired CSS, HTML and JS skills. You’re so excited you want to share this thing, but none of your non-tech friends know how to use github and no one wants to unzip a folder, then open it up on their desktop. You writhe in agony, unable to release your beautiful masterpiece to the world. Life doesn’t need to be this way.

While Heroku is great for deploying node projects, and you can always shell out some bucks to push your site to a live server, if you just want a FREE option to show off your static web page, github provides that.

It seems so simple in retrospect, but getting my gitpage set up for the first time was a real hassle. Follow the steps below and you can add a git page as well as subpages that users can actually visit to see your work.

**NOTE: Gitpages can sometimes take up to 15 minutes before rendering your ‘site’


1. Create a new repo that is named `<>` where <> is your GitHub username. Double check that you use exactly your username. (For example, would be the GitHub pages repo name for the GitHub user “janedoe”)
2. Create a new project folder
3. Add an HTML file named `index.html` and code out a basic webpage (or use a previous page)
4. Add, commit, and push your changes into the repository
5. Navigate to `<>` and you will find that your new web page has gone live!


1. Create a new repository on your GitHub account. *You can name this repository whatever you would like.*
2. Add your static project (HTML, CSS && JS) to this repository, and then navigate into your repository’s `Settings` tab.
3. Scroll down to the GitHub Pages section and then, in the section labeled `Source`, select that you would like to use the `master` branch as your source.
4. Navigate to `<><>` and you will find that your new web page has gone live! (For example, if your GitHub username is `johndoe` and the project is `cssDemo`, your URL would be ``)

How to Not Suck at Interviewing…

In my former life, I was… well, I was many things to many people, but for the purposes of this post, I’m speaking about my former life working in the Career Center of a local community college. It was an interesting job and I met a lot of cool people in different careers, helped students prepare for interviews and was also on the hiring committee for the school which taught me a lot about how fucking awful interviews truly are.

As a web developer I’ve been on somewhere around 20 interviews in the last couple years (some for fun and some because I was genuinely interested in the position, cause I’m a sick fuck like that). Recently, at my job, we were looking for a developer and I got to sit in on a couple interviews, while at the bootcamps where I work part-time, students are constantly asking me what to expect during an interview and how to not suck at them.

“How do I not suck?” they ask.

Well, that’s a tough question, because, more often than not, I find that interviews aren’t just about what you know, but how well you can sell yourself.

Sure, there’s the group that will tell you to study “Cracking the Code” like it’s the holy grail of acing coding interviews or whiteboard your ass off until you can spit fibonacci’s sequence using recursion out of your ass while debating the runtime complexity of insertion sort vs. merge sort. While those are great things to know and they may come up if you’re interviewing at one of the Big 3 (or 4, or is it 10? Fuck, I don’t know), you’re much more likely to find yourself in a semi-traditional interview with a group of devs who have a ton of code debt and little time to think of witty, head-scratching code challenges.

Instead, you’ll likely be in a room talking with some developers who are probably just as nervous as you, making small talk, talking about your experience and maybe doing some whiteboarding. Out of all the interviews I’ve been on, I was only asked to whiteboard once. Yes, one fucking time. I think people forget that understanding how to memorize and then write with a marker on a board, one of the answers to a question that every other company uses to test devs, isn’t the best indicator of one’s aptitude for solving problems.

Yes, we had the dev in our interview whiteboard but it was more to see how comfortable he felt under pressure, explaining a concept to us. Because, guess what the fuck we do during meetings when one or all of us just doesn’t quite get how this API is supposed to work? Either we sit there in silence, awkwardly passing the time, pretending we know what the fuck is going on, or some brave soul gets up on the damn board and draws that shit out for us. That’s the kind of girl/guy we need. Someone who’s comfortable standing up, scribbling the abstract on a board and making us whole again.

A much wiser man who I listened to on a panel regarding getting a job in tech, echoed much of what a lot of interviewers know to be true: “If they like you, they’ll find ways to excuse your lack of technical skill. If they don’t like you, they’ll find ways to justify their decision not to move forward.” If that sounds kind of sucky, well, it is. We’re humans and we want to work around people we like. I say, use that to your advantage.

Research the company. How do people dress? Dress like that when you walk in (maybe a little better). What are some of the projects team members have contributed to outside of work? If it’s something you’re familiar with or like, bring that shit up! Are they big into a certain group activity or a company that fits a certain lifestyle, like a website for single goat-herders? Casually bring up that you grew up with goats in the backwoods of Kentucky!

Seriously, if you’re already sitting in the hot seat, chances are that they trust your coding skills enough. Bring the human aspect to the interview. Have opinions, look interested! All that shit counts. Believe me, we were this close to hiring a wordpress dev for a full stack position just because we liked him. Shit, I got hired for a job using a stack I’d never used in my life and much of that was based on how I fit in with the team.

If you do face the dreaded whiteboard, here’s some fucking tips:

Before you just go all Good Will Hunting on the board, ask some questions from the panel. Verify the expected input and output.

Don’t fall silent! The people want to hear how you think, what’s going on in that peanut of yours.

Don’t fully turn your back on the audience. Take the role of lecturer, it should hopefully be a collaborative code challenge.

If you don’t know… well, ask more questions. Use pseudo-code instead of actual methods and functions. Maybe explain how/what you would need to know in order to get to the answer.

If the people show no emotion, refuse to speak with you while coding or sit behind a shiny, two way mirror, you may just want to get the fuck out of there. Seriously, I’ve heard horror stories about intense interviews like this and it usually denotes a sick kind of perversion during an already tense exercise. No one needs that shit. Unless you’re into that sort of thing.

Until robots start hiring, you will certainly be judged by a group of humans with likes, dislikes and types of people they jibe with. Be likeable, or if you can’t do that, just be you. Maybe there’s some single goat herder site out there with a team of weird ass devs just waiting for you.

Put Your Code to the Test

You’ve probably run into this problem: some nerd on your team made some function that found it’s way into production. It works well and all, functioning as a function should function… except when it doesn’t. Sometimes, this function has some unintended side effects that throw off a part of your application. No problem says some clever nerd on your team, she’s got a quick fix that should nip this thing in the bud. She squishes this bug then hands off the product to QA who tests it to make sure said side effect no longer occurs. All is well again.

And then… a few weeks later, a user discovers another bug related to the fix for the function clever dev #2 made. Another nerd joins the dogpile and puts in a fix for the first fix. The cycle continues for months until your team is on fix #28 for this function with a rich and profane history of git commits. Fuck that function.

I will admit, I’ve been/am in this position: writing code on a team, leaving testing to QA and my own, incredibly biased logic and console logs. I’m a bit embarrassed that I just began unit testing and still have quite a ways to go, but I now see my reluctance was really due to my fear of the unknown.

While I’m using Chutzpah and Jasmine on Visual Studios for Angular apps, let’s make a quick test suite using mocha-chai and node:

First, get a project with js folder and file app.js –> && test folder with file test.js.

npm init -y to initialize your package.json file

npm install mocha chai -g to install mocha and chai globally (mocha is the testing framework while chai is the assertion library or the thing that allows you to actually test your functions)

Ok, we’re on a goddamned role here. Let’s write some sweet ass code:

In your app.js file let’s make a testable function:

var testFunction = function(str){
return parseInt(str);

if(typeof exports !== 'undefined') {
exports.testFunction = testFunction;

That conditional statement below is how we will export our browser functions if we are running mocha in our node environment.

var test = require('../js/app.js')
var expect = require('chai').expect;

describe('testFunction', function(){
it('should return a number when given a string', function(){

First, we require our js file and then require chai’s `expect` method. The rest of our test suite is pretty self-explanatory: we describe what we expect our function to do and then assert the output of our function given a certain input. In this case we say that the string value ‘3’ should return the integer 3 after getting run through our sweet (haha get it) test.

To actually run this test, open up your terminal, navigate to the the test folder and mocha test.js. You should see this in your terminal:

Screen Shot 2017-09-07 at 9.33.50 PM

Now, that was a pretty simple function, but that’s kinda the point. Testing really only works if you’re writing code the way you should be with functions that do one thing rather than many. The added benefit of using testing is that it forces you to really think about what your functions should be doing and hold them to their word, creating nice documentation for future nerds and hopefully saving you from the 23rd iteration of that pesky production bug.


Bootcamps, Bootcamps, Bootcamps

Sweet baby Jesus, you can’t swing a dead cat without hitting a news story either praising or villifying coding bootcamps these days; The detractors say they cram too much information into a short period of time, gloss over or plain don’t cover CS fundamentals and give students unrealistic expectations of the job market, cranking out sub-par devs. On the other side are the bootcamps, rebutting that many cs grads can’t actually build a website or app despite knowing the runtime complexity of an insertion sort algorithm which they probably won’t use anyway.

With the closing of two prominent bootcamps, DevMtn and IronYard, the flood gates have opened and people are questioning whether this whole bootcamp thing has finally failed.

Like most things in life, and much to the chagrin of all your programmers out there who would like a definitive, black and white answer; both sides have some valid points…

Traditional CS education has some flaws: cost, time, practical application (in some cases) and the break neck pace at which web development moves. Can we really expect a four year uni to keep up with whatever JS paradigm/framework is in style and expected when their students approach the job market? In the other corner, we have the scrappy underdog, your local bootcamp, which doesn’t abide by any standard, both making it flexible and able to easily keep up with national and local trends but also worrisome in that there’s no freaking standards!!! Bootcamps vary wildly in some instances from program to program but have the ultimate goal of making job-ready developers who can crank out code but likely don’t have data structure and algo skills that CS grads have.

‘Well, my bootcamp taught x, y, z,’ you protest. Yeah, I get it, I’m making some generalizations but after working at two bootcamps and a community college, as well as speaking with grads from all sorts of bootcamps and colleges, I believe the largest difference between the two developers is that bootcamp Cindy can create a full stack app in React while she may need to lean on four year degree Lisa to create an algorithm for production that is efficient in terms of space time complexity or what’s going on ‘under the hood’ of the code they write. Conversely, Cindy may need some handholding on her CSS skills and front-end frameworks.

(Many) Bootcamps scoff at CS fundamentals (‘Scoff!’ they say) and seemingly trivial knowledge of binary search trees and sorting algos or superficially explore them. When are you gonna need to know that outside of an interview amirite??? While that is likely true for the majority (or at least a whole helluva lot of us), the underlying logic and deep understanding of these concepts is timeless; they won’t change when your current JS framework dies and gives rise to another cobbled mix of who knows what that arises from its ashes like a Frankenstein-ish Phoenix.

So, in the end, it’d be great if bootcamps/colleges/whoever could offer a combination of traditional, time-tested concepts like algorithms, exploring compilers and operating systems while still teaching all the cool shit that employers want you to know, but that’s not the case.

I feel whatever path you choose in your pursuit to be a coder/web-dev/engineer will lead to a lifetime of studying. I knew as much about data structures and algorithms as your cat knows about astrophysics… so I picked up a couple books, then some code challenges and then some more books, which I’m currently confused by as of now (seriously, what the fuck all you search algos…. get it together), but I really want to gain a better grasp on these CS fundamentals as I know they’ll make me a better problem solver.

So maybe the answer isn’t one or the other, but to supplement whatever you are ‘missing’ as you delve further into your career. So go out there and CSS some shit with your four degree self and you, bootcamper, learn how a fucking BST works… and then write a blog explaining that shit, cuz I’m still lost.

All the JS Stuff You’re Supposed to Know but too Afraid to Ask

I’ve been writing JS for a couple years now professionally and I felt/feel fairly confident with it. Hell, I even teach a class on weekends at a bootcamp going over the basics of JS. So there I sat, on the phone with a much more experienced dev, getting bombarded with all those questions you can expect in a technical interview: ‘What’s `this` in JS’, ‘Give me an example of prototypal inheritance’, ‘Explain some random concept that will almost certainly never affect you in a real world situation.’ You know, typical stuff.

For the most part, I felt pretty decent about my answers, even though I had more trouble articulating my answers than I would have liked (I was on speaker while driving with a particularly drunk friend as my passenger… don’t judge me). Everything was going splendidly, until he probed a little further on a few of our question: ‘Well, why does that happen,’ he asked. Oh shit. Well, it just fucking does, I mean, I’ve seen that shit like a 100 times. I realized I know less about how JS works in some situations than that it just has in the past and will in the future.

That’s not good enough.

Sure, part of me protested these types of questions: when you’re writing code, it’s seldom you dig deep into the concepts or ‘under the hood’ functionality of that object constructor you’re using or what reduce is really doing to your array. But, I think knowing what’s going on behind the scenes and the logic that fulfills your expectations when you write a function with a closure can only help you to be a better developer and reduce your reliance of just seeing what happens when you write a function/object/array/reducer/class/or use `this`.

Thank Bob I work with some smart motherfuckers who actually took the time to write down all those pesky JS concepts along with some great examples. So get your ass some knowledge you won’t find in college (well, maybe you could but I couldn’t pass up that dope ass rhyme) and check this out.

What to Expect When You’re Expecting…

So you went to a bootcamp, slogged through days of grueling CS fundamentals, built a poop-ton of CRUD apps, CSS’d the shit out of your front end and maybe even did some white boarding. Fuck yeah. But now what?

The now what phase happens the moment you step out of your structured environment and begin the second, equally challenging phase of your path in the world of code… getting someone to pay your ass to git add. git commit -m and git push, find and squish pesky bugs and write elegant, manicotti (the opposite of spaghetti… seriously, it’s true) code.

Many things are no doubt entering your mind. “I don’t know enough.” “Jane is the best dev in our class and she’s already got like 3 rejections.” “I still can’t explain ‘this’ in JS, help me lord please!” The coding gods revel in your misery, cackling from their compiler dungeon, bwahahaha.

Yeah, I’ve been there and so has nearly every dev I’ve ever talked with. You may almost feel audacious as you apply as if you don’t have the right. Maybe the fear of rejection has crippled you into taking yet more time to learn that new framework or language or whatever it is you’re telling yourself will make you a sure bet.

Fuck that noise.

Your first job will teach you more than another 6 months or a year of self study. Working on a team, with a large codebase, writing code to be consumed outside your circle of friends or instructors will make you level up faster than anything else… not to mention you’ll be writing code for about 8 hours a day.

Here’s the tough part: you’re gonna get rejected. You’re gonna get lots of calls from terrible recruiters (if you’re linkedin and resume don’t suck) and some people may even discourage you, telling you it’s a hard market for a bootcamp grad. Fuck them and fuck that. I’ve been hearing that since 2013 and yet every month I see more of my own students (not just the top ones… ) get great jobs coding for a living.

Here’s some tips I’ve amassed from smarter people and through my own trial and error:

Get a linkedIn. Put your skills on that bitch and have a something in your title section other than “Passionate developer looking for blah, blah, blah…” How bout, “JS dev with a thing for API’s, unit testing and getting shit done!” Well, maybe not that far, but I’d rather go for weird over boring. I was a hiring manager and trust me, that “safe” resume/cover letter shit is boring. When there’s 100 other resumes in the stack and they all sound the same, guess who’s going to stick out? Just my two cents.

On your resume and cover letter, maybe don’t put that you went to a bootcamp. Some people are biased, don’t give them a reason to toss you out based on that. If your job history is mostly sales or retail or professional cos-player or whatever, just leave that shit right out of there. “Well, what SHOULD I put on there then?”

First off, I don’t like the cut of your jib asking me a question with that tone, secondly, maybe put the projects you’ve done, the tech used and a link to that shit so recruiters/employers can see what you’re made of.

Get a nice pic of yourself and put that on the old linkedIn, endorse your classmates, write some recs and expect the same in return. Switch the order of your skills so the most impressive stuff is first on the list (you don’t want HTML and CSS at the top or that’s what you’ll be mostly endorsed for).

Always accept recruiter connections, be kind even if they don’t have their shit together, you never know when you may need them. Now, strap on and get ready to go on some interviews, have your ego crushed and get back up and do that shit all over again.

When the calls start drying up, change your resume and linkedIn slightly, they will shoot back up in the ranks on job sites like Indeed and Monster. This little hack got me keeping a steady stream of calls for months!

Remember, you’re applying for a skilled job that most people have no clue how to do, so act like it!

Lastly, don’t neglect self-study or your precious github the moment class stops. This is a life-long learner’s trade and nothing shouts “I just went to a bootcamp to get a job but don’t really like coding” more than a robust git commit history that mysteriously drops off after a certain date. Really, don’t be that girl/guy.

That’s it. Seriously, stop lolly-gaggin around here. Get your ass up (or continue to sit really, I suppose, I mean, no need to stand and type) and get hired!