Closure to Your Dreams

There are so many bad puns that can be made involving closures and I’ll try my best to avoid them all here. As a father of 3, that’s a harder task than you might know.

If you’ve studied Javascript or maybe just studied for an interview (wink wink), you’ve likely come across the concept closures and maybe you even have a boiler plate definition in your back pocket you can spout out when a hiring manager asks. Maybe it goes something like this:

`A closure is a function within a function` or the even more ambiguous yet technically correct answer `A closure is a stateful function.` Yes, a closure is a function within a function, but so what? I found myself lulled into comfort simply knowing what a closure was but not having any concrete uses I could think of. So who cares about closures?

Closures allow us to access variables in the surrounding function even after that function has returned. Why is this powerful? Well, let’s see:


function employee(name, initialAmt) {
const employeeName = name;
let amt = initialAmt;
return {
getName: function() {
return employeeName;
},
addMoney: function(amount) {
amt += amount;
},
decreaseMoney: function(amount) {
amt -= amount;
},
getAmt: function() {
return amt;
}
};
}

var bob = employee("bob", 100);

console.log(bob.getName());

bob.addMoney(200) //mutates the outer function variable;

console.log(bob.getAmt()) //returns 300, the new amount;

console.log(bob.amt) //undefined - haha, you can not get direct access to the amount;

With this function, leveraging the power of a closure, we’re able to update the state in the outer function without declaring a global variable (eg. having `amt` be in the global scope) and only exposing methods we want for public use.

Unlike other more traditional programming languages, JS does not offer public and private methods and variables but closures allow us something very close.
If we were to refactor our code above to make use of a private function to update the amount, it might look something like this:


function employee(name, initialAmt) {
const employeeName = name;
let amt = initialAmt;
return {
getName: function() {
return employeeName;
},
addMoney: function(amount) {
_increaseAmt(amount);
},
decreaseMoney: function(amount) {
_decreaseAmt(amount);
},
getAmt: function() {
return amt;
}
};

//private

function _increaseAmt(amount) {
amt += amount;
}

function _decreaseAmt(amount) {
amt -= amount;
}
}

var bob = employee("bob", 100);

console.log(bob.getName());

bob.addMoney(200);

console.log(bob.getAmt());

console.log(bob._increaseAmt); //nuts! can not access that private function

Now we’ve declared a private function that only our public methods can access. Pretty slick.

You could spend an afternoon diving deeper into closures and scope but hopefully I was able to shed some light on some practical use and give you some clos… some, uh, more information on closures. Yeah, that’s it.

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.

Impostor!

So I work as a software dev, which you may have gleaned, you smarty pants, you. I started late in life, had the wrong degree and was never that much of a nerd to begin with. Through study, some luck and a lot of reading, I landed a job, then another, then another and another yet again. I’ve been getting paid to code for a little over two years now. But you know what? I still feel like I’m one bad piece of code away from someone ‘finding me out.’

The first three months of my first job as a dev, I felt like I might get fired everyday. It was awful. I wondered if they had made a mistake, were the just filling a quota by having me, was there literally no one else that applied? I felt pretty useless, made more bugs than I fixed and one particularly bad program I wrote in my first year actually cost the company around $10,000. Fuck.

Around year one, I felt like I belonged. I started having the answers to difficult questions, creating user stories and offering my opinion during code reviews. I even created a few full stack applications on my own that affected hundreds of stores across the nation. Then… I left. I worked at a couple bootcamps during my first job which allowed me to sharpen my skills but then I took the big plunge and joined a start-up as dev #1. Double fuck.

Here I am, two years in as a dev, at 34 and with 3 kids and still feel like a kid playing dress up. Part of me knows that I’ve been here before and this too shall pass, another part of me wonders why I and others feel like this in the first place. Working in a super technical environment can be tough: there are clear benchmarks for your success and your product, for better or worse, is on display and open to criticism. Developers are also a smart bunch. I work with an MIT grad, a former Googler and a guy that wrote a fucking testing library that we and thousands of others use. The amount of big brains in the room can be a little daunting at times.

If you’re starting off your first developer job or in my case your second and you’re feeling like me: I can tell you, after talking with a lot of engineers from non-traditional backgrounds, that the feeling will subside after a while and when you begin making regular contributions you’ll feel more at one with the team. I can also say that in the last two years, despite all the cringe-worthy things I’ve said in interviews, on the job or making small talk over code that showed my lack of knowledge and noob-ness, not once was I ever laughed out of the room. Turns out devs aren’t such a bad bunch.

I was surprised to see just how far up the rungs impostor syndrome can ascend. I spoke with the VP of Technology at my last job, a man who I respected as one of the smartest guys in any room. He told me how he felt like the dumb kid, even now, 25 years into his role when he was around other CEOs. My lead developer, a stone-faced prodigy who seemed to be able to tackle any problem, told me he almost quit during his first six months on the job because he felt he would never figure it out. The more devs I’ve spoken with, the more variations of this story I get. Triple fuck.

I guess the bad news is, that feeling of imposterism might be yours for a while. The good news is, you’re in good company.

Confessions of a Coding Bootcamp Instructor

After a busy week of fathering my three badass kids and creating and squishing bugs as a software dude at a startup, I take the weekends to recharge… (chuckles) it was hard even typing that. No silly, relaxing weekends are for guys without three kids. On my weekends, well for at least one day out of them, I work as a mentor at a coding bootcamp. You’ve no doubt heard about the proliferation of these quasi-vocational schools which claim to crank out software devs at a dizzying pace. I’m not here to argue whether they’re good, bad or in between. I went to one and coupled with intense studying, I landed a job and wished I had entered the field much sooner.

During my regular week of software devloper-ing around and usually feeling like the dumbest guy in the room, it’s kinda satisfying to walk into a class of complete noobs and getting to feel how I imagine our senior dev does everyday. I’ve been doing this for about a year and a half now and here’s what I’ve learned:

I Don’t Know That Much More Than You

Sure, I’ve been getting paid to write code for a couple years, but in the big scheme of things, I’m just a noob too. Students still look a little bewildered when I have to conference with Google to find out why their div isn’t floating near their other div or exactly what is `this` in JavaScript. `Don’t you know this?` they say with their beady, judging eyes. Well, sometimes no. Other times I just don’t know how to explain that shit to you in a way that makes sense.

I Know Who Will Make It

Usually, after week 3, I can tell who will make it and who won’t. I’m very rarely surprised by the girl who gets hired after the course ends or the guy who drops out around week 10. I ask a question at the beginning of the program, `Why do you want to learn to code?` If you said `Money` then I hate to tell you, but according to my observations, you are likely not gonna make it bub. I mean, hey who doesn’t like money, but if you got into this game just for the dough, you’re probably not going as far as the person who is intrinsically motivated(read: actually interested in coding).

I Will Only Teach You About 10% of What You Need

Does that sound bad? Well, hate to break it to you, but it’s probably less than that. Web development covers a large territory. A comp sci degree is four years long, and many of those students come out less prepared to work in software than a bootcamp grad. The field changes fast and every team has their own process, code style, culture, etc. I’m here to teach you the basics, and besides coding, teach you how to think through problems and learn on your own. Guess what you’ll be doing when your team decides to use a framework noone has heard of because the senior dev used it in a hackathon? That’s right, you’ll be learning that shit on your own… and getting paid to do it.

I Get A Lot Out of Teaching You

When you think of software developer, you’re probably not picturing some guy in a power suit, leading a meeting. No, it’s probably a burrito eating, nebbish type who has trouble talking to women. Well, fuck you, first off. Secondly, yeah, it’s true: a lot of devs have trouble when it comes to communicating or speaking in groups. In fact, forget devs, that’s like, everybody. Speaking to a class of people for three hours (twice a day) about technical things has made me more comfortable speaking in public, though I do feel bad for those first few classes who had to sit through my sweat-filled bumbling. Thanks y’all!

So while you’re enjoying some local sports on Sunday, kicking back with a cold, moderately priced domestic beverage, I’ll be grooming a class of soon to be kombucha-swigging, burrito-eating SF hipsters. Not all heroes wear capes.

Why You No Like CSS?

Ok, I’ll admit, I’m not the biggest fan of CSS. Well, maybe I’m just not a fan of ME writing CSS. Many of the devs I’ve met over the years seem to echo this sentiment as well. But why? CSS is what makes our sites look not like Craigslist, it engages users and sets the tone and feel of our application. It does so much for us and yet here we are complaining about it. What a pack of ungrateful fucks. For Shame.

I mean, I do get it. If you’re not on the design team you may not be doing that much CSS or maybe, like too many of us, you’re more concerned with logic and functionality of your site to care about the style. `I’ll let Bob handle that part of the app,` you say. Fuckin’ Bob. I have the sneaking suspicion that most of us who don’t like working with CSS just don’t know it that well.

I had the opportunity to sit down with one of the members on my team and walk through the re-design of one our pages for our web app. I expected it to be a curse filled 8 hours of trying to figure out why this div didn’t float near that div but this guy was actually looking forward to it. Sicko. We (he) finished the re-design fairly quickly and I was amazed at his command of CSS. Our site looked better and I learned a lot along the way.

What I really learned from watching this master at work was how rudimentary my knowledge of CSS was. I wasn’t making use of CSS’s native answer to Bootstrap, FlexBox, wasn’t taking advantage of pseudo-selectors to implement logic that we had unnecessarily delegated to Javascript and hadn’t used SASS very much up to this point.

Some Takeaways:

  • Use percentages/em over fixed px for things like width, or font. This way you won’t need to create more media queries than necessary and your content will be more proportional to the browser window.
  • Just use SASS already. Jesus, how did I miss this train? SASS let’s you nest CSS rules in components so you can have clear separations of CSS logic (and a lot more). Here lemme show you:

  • .myBigDiv{
    font: 'Roboto';
    .btn{
    background-color:'green';
    &:hover{
    background-color: lighten(20%);
    }
    }
    p{
    text-transform: capitalize;
    }
    }

    Now I have rules that apply to all my buttons and paragraph tags that are in my div with a class of big div. I even put a nice hover effect on my btn that will make it appear lighter when hovered over.

  • Is there logic like capitalizing an input that you’re using JS for or truncating a string? Maybe CSS can just do that for you? We were doing just that and replaced that logic with CSS properties text-transform and text-overflow:ellipsis, respectively.
  • Let your framework do the heavy lifting! There were many places on our page that was reinventing what Bootstrap is already capable of like adding padding, floating elements or the like. Check the docs… can this be done without me actually coding it?
  • My advice, to myself and perhaps to you if this applies, is to stop running from CSS! Aside from Craiglist, users expect to see some visually engaging UI. Embrace the CSS, love the CSS.

    Books For Nerds

    I began writing this blog with the assumption that you, like me, are either a self-taught programmer or new to the world of code… or maybe just a fan of off-kilter, profanity-laced blabbing. Like you (or not like you) I do not have a CS degree. I went to college, studied liberal arts, alcohol and drugs. After bumbling about and doing a number of different jobs over a decade, I found my calling in writing code.

    I remember the first year I was paid in actual US monies to write turrible code; I was happy when the code ran, left few comments and relied heavily on the work of more senior programmers to help get me out of logically tough spots. I gradually got better at writing code and understanding how the internet works. Through days of coding for work and nights and weekends working on side projects, I figured I was pretty damn good at my job.

    But, coding only took me so far. I felt like I missed out on the CS fundamentals that no amount of coding could replace, so I put the one skill my liberal arts degree gave to me use: reading. A lot. I scoured blogs like this one (with notably less profanity) for suggestions and read my way to a better understanding of CS fundamentals and problem solving skills.

    Here’s a few books I recommend if you’re looking to round out your knowledge as a software developer:

    Programming Pearls. This is an older book but will introduce you to many of the complex problems you will likely see and gives you a glimpse of how a master programmer tackles them.

    Clean Code. This book reinforced some of the principles of writing code I learned on the job and introduced me to many techniques I hadn’t considered. A good read with many, many examples.

    The Complete Software Developer’s Career Guide. It’s a hell of a read at around 1000 pages but nicely broken up into chapters that deal with many aspects of a career as a dev. The advice is great and whether you’re looking to get a raise or a first job, it has some great insight.

    Data Structures and Algorithms with Javascript. There are many books that tackle this subject but I chose this one because I’m most familiar with JS and if you’re self-taught or out of a bootcamp, you likely are too. This book will take you through the most common data structures and goes into more depth than many of the online courses I’ve seen.

    There around a fuck-ton of books out there that cover the world of software and I gave you like, 4. Some of these books may tickle your fancy, or maybe you’ll think they suck. If you got any gems you recommend, please drop ’em on me.

    My StartUp Life

    So for the last two years, I worked at a mid-sized corporation on a small agile team creating software. It was a great experience and as my first job in software, I learned a ton. You’d think in my advanced age, and with a family that I would welcome the kind of stability a traditional business would bring… and I did. But something inside me wanted to go out there to really ‘prove’ myself at another company, to learn a different way of doing things, to take a risk. So here I am three weeks into my new job as software engineer at a 7 person startup as the only non-remote engineer and the one with the least experience. Reading that last sentence aloud now makes me wonder if I’m as crazy as it makes me sound.

    At my old job, it must have been a good two months before I pushed out any real code and I didn’t see it in production for another few months after that. There were meetings with higher-ups, a project manager, a department VP and other support staff to help us tread the agile process. Today marks the end of my third week at my start-up and I’ve pushed about three features into our production branch. The fuck.

    Of course I expected the start-up life to be fast paced but when your in the throes of it, it’s amazing how much autonomy you really get working at a small company and how quickly change takes place. The relaxed dress code, open schedule and the fact that most of the team is remote create a casual atmosphere but the break neck pace at which the code changes and new feature requests are added is already dizzying, especially as the guy in the room that knows the least.

    Part of me misses the hand-holding and gentle on-boarding that I was so used to, but when your company is too small to play a full court basketball game, you’re gonna have to get up to speed on your own in many ways, whether it be learning the business, navigating the code, setting up your tools or choosing a health plan.

    For my first job, I’m incredibly happy to have worked for a larger company. They gave my the opportunity to dip my toe into the water of software development before having me swim a few laps in the channel. Conversely, about now I feel like I’m treading water in the ocean, wondering what the hell that thing is bumping against my leg… in a good way though. I think.

    If you’re interested in jumping into the deep end and working in the startup scene, I recommend checking out Angel List.