TODO: Write Better JS

If you’re writing javascript these days, why not write good javascript? Duh, right? Well, a couple years ago, good javascript to me was code that did what it was supposed to do. User clicks button, function runs and no errors appear in my console. Ok, we’re done here. This is the attitude I had when I wrote my first professional web app. ‘It works!’ I said, enthusiastically.

That tangled web of javascripts did what is was supposed to do for nearly a year. Then we switched to a new framework and I was tasked with porting the app that contained all that js as well as add some new features. I stepped into the code time machine which was this app and saw the mess I’d made:

I’d wrapped up some pretty complex logic in a massive 100 line if-else statement. Ambiguous variables were everywhere: var credit, var otherCredit, var creditTransfer, var transferCredit. And the functions, oh the functions! They were long and horrendous to read through. It’s as if I wanted conserve variable names by slamming as much logic as I could into each set of curly braces.

I now see the err of my ways and hopefully you can learn from my mistakes. Some lessons I’ve taken away from that months-long refactor of my old code were:

Var Names Matter

If you’re reading this, you’re likely new to the world of JS. Maybe you’re writing variables like var x or var y. Don’t do that. Take the time to give your variables meaningful, unique names. This can seem trivial at first, maybe there are only a handful of vars in your app in the first place. Well, that’s what I thought too, until the scope of my project increased tenfold over its duration. I was also wary of using variables with names that were too long. I regret this. Better to have a descriptive, long name for a variable (ex: catWithBlackHair) than a short ambiguous one (ex: cat). A variable should yield no surprises. If the name of var or function ever makes you scratch your head a little, it will make you want to pull your hair out six months from then, when you’re knee deep in a refactor.

Your Functions Should Be Shorter

That twenty line js function you wrote that takes in a user’s input, does some UI update, makes an ajax request and then does another update… well, you may want to change that up. I know it works now but think ahead, far ahead. When your PM, you or some external force causes you to change the logic in that function. Well, now you’re in a game of code jenga, where refactoring part of that massive function may break the rest. Keep your functions small. How small? They should really just do one thing. ‘Doesn’t this mean I will have a lot of functions?’ Well, yeah, but that can be OK. You will greatly increase the readability of your code by abstracting logic into small functions and you will also decrease the potential for duplicating the same code when you have many small functions. Do two different ajax requests update the UI? Great, have a function they can share to do this rather than duplicating those lines within each request.

Comment that Shit

A year is a long time. Reading through my old code was like reading a novel written by a drunk version of myself. I mean, I vaguely remembered writing it, but it seemed so foreign, so incomprehensible, so dumb… A wiser me would have left a trail of breadcrumbs explaining some of the more difficult parts of the code and why I was doing what I was doing where I was doing it. Short and sweet functions and descriptive var names would have greatly enhanced the readability as well but I was batting 0 for 3 here. If you follow the first two pieces of advice here you shouldn’t need to rely on comments for another dev to follow what’s going on in the story you’re weaving through code, but good comments, especially those explaining things that may provide insight to the business logic or why an odd choice was made will be invaluable in the future and probably prevent you from having one of those ‘Oh, so that’s why she left that function in the code’ moments, after a deployment blows up in your face.

I’m surprised by how many of these n00b mistakes I’ve seen in more senior developers’ code over the years. When we begin writing javascript, we’re often so caught up in just getting it to work at first, that we neglect to pore over our code and really analyze its structure, readability and longevity. Will future me, hate current me for writing this? The response to that question is the answer to whether you should reconsider the style of javascript you are writing and maybe use some of the advice from above.

If you want to take a deep dive into writing good, clean code, check out this book.

Before You Join A Coding BootCamp…

So you’ve decided you want to become a web developer eh? If frustrating yourself for hours on end with bug fixes, staying up late on pins and needles as another one of your deployments fails to build in production, keeping up with the breakneck pace of Javascript and constantly fighting off imposter syndrome sounds like your cup(s) of tea, then you’re in the right goddamned profession.

Still, after working in other, non-tech related fields, I will say that a career as a web developer is the most fulfilling and challenging career I could hope to have. So now you want to join the pack too. If you’re not looking to go back to school for 4 years, you’re likely debating which bootcamp you should join, combing over blogs like this to help you reach a decision. Well, I’m a bootcamp grad, turned full time developer who also works as an instructor for a local bootcamp on weekends, and here’s some things you may want to know before you take the plunge:

You Might Not Make It..

I’ve taught many classes and worked at two different bootcamps. The class you have in the beginning is not the class you will have in the end. People just stop showing up. It’s really a phenomenon I don’t understand, as you’re likely plopping down around 10k for the privilege of being bombarded with work for the next 3+ months. I think a lot of people either don’t fully understand how much work is involved to be a marketable web dev in a few months or they just plain don’t like it and see a bootcamp as a sort of cheat code to jump from their regular job to untold fortunes. The most successful students I’ve had weren’t always the most academically astute, but the ones who persevered and basically, just weren’t lazy.

Actually liking coding will help as well. This may seem like an obvious point, but if you don’t know whether you like code or not, a bootcamp is not the place to find out. Try codecademy, download a text-editor, write some code. Cool. Now imagine doing it eight hours a day… still sound cool? Great, you are on the right track.

Don’t JUST Learn What They Teach You

The best skill you can take from your bootcamp, besides the strong fundamentals you’ll gain, is the ability to learn things quickly. Look, your program can’t teach you anywhere near half of what you will be doing on the job. There just isn’t time and that isn’t plausible. Oh great, you know React, well we use Vue at Company Y, son. Oh, you learned some SQL pard’ner, well we’re all about Mongo here cowboy. (In this professional world, your boss is a big guy with a 5 gallon bucket hat). No matter where you end up, you WILL be learning new systems, code styles and probably digging into some legacy code that will be a lot less pretty than what you’re used to. Once you are armed with the fundamentals, take time outside of class to dig further into those fuzzy parts you’re not clear about, some new framework you’ve heard of and build things you aren’t required to. This will teach you, arguably, more than any class.

Just Being Good At Coding Won’t Get You Hired

Now this is a harsh truth: No one cares about your bootcamp certificate/degree. In fact, saying you went to a bootcamp may do you more harm than good. They’re new, they’re unregulated and maybe that employer hired one lame bootcamp grad that’s spoiled them on the rest. Fair? Maybe not. But hey, it is what it is. That being said, if you’re coming into your first web related job, your employer likely isn’t gonna be expecting a ton from you code-wise. They know you’re a n00b. So why hire you? Well, after sitting in on some interviews at my own job, and hearing others’ experience, don’t ever discount good old fashioned likability. People want to hire people that are like them, that can communicate and are fun to be around. Unfortunately, this can really hurt you if you happen to be a really bright, coding genius that is completely unlikable. Don’t skimp on polishing up your soft skills, learn how to interview well and think about how you come off. I can’t tell you how many super smart students have found themselves un-hireable because they don’t take time to craft better soft-skills.

Also, realize you might not be hired the week or the month you graduate. You will get slammed by rejection. You will think you’re not good enough. You’ll be tempted to retreat to more self-study to be ‘ready’. You will feel like a fraud. Keep going. Use LinkedIn to meet up with people for lunch. Go to meet ups. Take that first job, even if it’s not that great. The second job is so much easier to get than the first and the third will likely be easier than the second.

So with that being said, bootcamps aren’t the magic bullet to turn you from lazy bum to coding hero. They will you give the skills to possibly pay your bills, but you’re gonna have to meet them half-way. Keep that in mind and you’ll likely be a happy camper (I’m so sorry, there’s just no way I couldn’t do that, I hope you’ll understand).

 

 

SERN/SEAN Stack?

Why is that you rarely (meaning never) stumble across a tutorial for <–insert js framework here–> that makes use of one of the most widely used databases available? It’s MERN (Mongo, Express, React, Node) this or MEAN (Mongo, Express, Angular, Node) that. Has everyone unanimously given SQL the finger in favor of using Mongo?

I use SQL every day at work and have come to really enjoy it. Perhaps not as much as after embarking on a project making extensive use of Mongo. What’s the difference you ask? Mongo is a key-value store that stores data as JSON, has its own query language and is lightning fast at retrieving info. Mongo, like Firebase, another key-value store (that I highly recommend for start-up/weekend/light data projects), are NOSQL databases, meaning the data is not relational, or table-based.

SQL on the other hand is, well, a SQL database that holds data that is relational, or tabluar. If you’re not familiar with SQL, imagine Excel for coders. That’s really what it equates to. SQL is great for storing relational information in tables, like a table with users for your app, a table for their passwords, and another for messages they’ve posted. All three of these tables are related by the user name or id and the data types are unlikely to change. SQL makes use of data types, so you once you’ve defined a column and datatype, it’s set in stone, which has its pros and cons. PRO: your data maintains integrity and you can expect certain datatypes being returned. CON: In today’s JS-centric world, we’re used to receiving JSON and if you’re unsure of how your data will be structured or the types you will allow, SQL may pigeon-hole you too early in the game.

Rather than thoughtfully choosing a database based on the type of application I was building, I decided to be like the cool kids and jumped headfirst into Mongo although my data would likely have been easier to wrangle in a SQL type structure… oops. Being a SQL guy, I incorporated Mongoose (a library for Mongo) to create a schema for my json data that allows you to define data types and things like length and whether a field is required or not. Basically, I was trying to SQL-ify my Mongo instance.

Things were going great at first and I really enjoyed Mongo’s query language and the fact they have their own query editor (Robo 3T) which made designing my queries all the easier. Things began getting hairy however, when I wanted to do things like join documents like you would with relational tables. My queries were getting more complicated to try to force some relation between documents in an inherently non-relational database. You see, in a SQL world, I would have created a users table and a messages table, with the messages table storing messages from a user, the user id, the time created and who they were sent to, then easily joined that table to my user table. Easy fucking breezy. With Mongo, I created a users document and a messages document but joining these documents and maintaining their order has proven hairier than I anticipated.

I’m glad I joined the cult of Mongo however, as I’ve really come to enjoy its flexibility; decided you don’t want to include user id anymore? Fuck it, just don’t use that property anymore in your new entries, meanwhile, try dropping a column in SQL that another table depends on, or just changing up a datatype for a column or storing different datatypes in the same column (you just forget about that you sick bastard!).

I’m gonna see this MERN project through and get a nice break from my day to day SQL queries but I think I may have to pioneer the SERN/SEAN stack next.

If you’re thinking of using Mongo for your next project, I recommend using Mlab which offers a free tier that hosts your mongo database and Mongoose if you want to add some rules for your datatypes and schema.

Angular Vs. AngularJS

In my advanced age, I’ve discovered I like change less and less, which may explain why it took me so long to come around to love enjoy React. If you’ve followed this blog at all, you’re no doubt familiar with my love/hate/love relationship with ReactJS. While I love a lot of what React offers in the way of component based architecture, re-usable elements and advances in making the framework more accessible through create-react-app, there’s still the issue of the state.

Ahh, the state of state in React. So, you got a few options: mobx, flux or the crowd-favorite Redux. Though Redux and React go together like SQL and .NET, they are two completely different frameworks. The only real state management React offers out of the box is passing props around which can get hairy. Using Redux made me pine for Angular’s sweet, sweet factories and services which allow you to communicate between controllers (why do they have both factories && services…. who knows, they basically do the same thing). A service in Angular is a module, composed of an object which usually returns functions which can be injected into other components as a dependency. You know what’s even better about factories and services? They’re built right the fuck in there. Yeah.

But everybody left Angular right… right? Well, this last week I got taken to school on Angular at a VisualStudio Code Conference and sat down with a woman actually on the team of people working on Angular’s new features. I asked about version 1.xxx which my team is still using and she made the clear distinction between AngularJS (any version before 2) and Angular (every version after 2). You see AngularJS had a complete and total overhaul at V2 making it unrecognizable and essentially a completely different framework that leverages typescript (think JavaScript meets C#) with data types, public and private functions and variables and, oh yea, component based architecture.

My mind was blown once I saw an Angular 4 app scaffolded using their CLI and ready to be served using webpack in a few commands. While there’s many similarities between React and Angular as far as using component based architecture, use of web pack and the very familiar file structure, what sold me was when I saw they were still using services to communicate across controllers. No external libraries or insane amount of files to create a simple connection between pieces of the app, just baked in simple logic to do what should be a fairly simple task.

I honestly don’t know why everyone isn’t using Angular at this point. I’ll continue using ReactJS because it’s a lot of fun but I guarantee my next project will be using my old friend in a new way. Check out the docs
to see how easy it is to begin building an AngularJS Angular app.

Are You a Front End Dev Afraid of JS?

These days, front-end dev can cover a lot of ground: at one company it could be the guy who does web content updates and tweaks the HTML and CSS on the public facing site, while at the start up next door it could be the girl who doesn’t do as much UI as she does complex client side javascript code to manipulate and traverse the massive amount of data being retrieved from the backend, writing unit tests and doing Tuesday night deployments… either way, the mistake I see too many devs make who are looking for front-end work make(I was guilty as well) is they think they can avoid the ‘hard’ parts of javascript.

What are the hard parts, you ask? Sure, things like recursion, scoping, hoisting, closures and bumbling your way through ‘this’ are some of the conceptually difficult parts of JS but I’m talking about the ability to solve problems.

You see, this is the part of web development that’s not so easy to teach: how to solve shit. You can memorize a whole bob damn book on MVC, Routing with Express and spout off some little known facts about how `setState` works in React, and that’s great, don’t get me wrong, but can you figure out how to remove duplicate objects from an array of objects?

Well, can you? It’s easy to say ‘Yea I could figure that shit out,’ then, lulled into a false sense of JS mastery you come across a problem like this at an interview, or likely, on the job, think back to this article and punch yourself in your quinoa eating face for not attempting it.

Many new devs, especially those on the front-end of things try to forgo solving these seemingly trivial problems using JS either out of fear or they don’t see the value. I’ve been there. I tried my hardest to avoid JS beyond DOM manipulation until I was forced to do so.

As a FE dev, you’ll probably be calling lots of APIs to populate a page with some data. That data will likely be an array of JSON (or XML if you’re unlucky) and you probably won’t need all of that data or you’ll need to manipulate that funky object your neck-bearded backend team created.

One of the tools I use that has improved my JS and logical skills the most has been codewars. I believe the first problem I solved took around 3 hours or more. Still today, I may toy around with a problem for a day or two (or a whole fucking week) until I get it. While approaching many of these problems can seems overwhelming, I can guarantee that the path you take to either solve or fail at it will lead you to greatly improve your JS skills and more importantly, your ability to just solve stuff.

The best part of CodeWars is that you get to see the clever attempts other devs have made and get a glimpse at some really stellar code. For you savvy code challenge aficionados who ask why I didn’t give leetcode or hackerrank a shout out is simply because their IDE wasn’t as friendly for writing JS code (IMO).

Now go back and figure that shit out!

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’

*CREATING A GITPAGE*

1. Create a new repo that is named `<>.github.io` where <> is your GitHub username. Double check that you use exactly your username. (For example, janedoe.github.io 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 `<>.github.io` and you will find that your new web page has gone live!

*ADDING SUBPAGES*

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 `<>.github.io/<>` 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 `johndoe.github.io/cssDemo`)

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.