Learn That Language/Framework Faster!

The one thing I like more than coding and fancy tacos is dropping the kind of knowledge you can’t get in a college. Every Sunday, I put on my teaching hat and work a with a small class of students at a part time web development bootcamp. I also work as a full time web dev so Sunday’s class is usually a breeze for me… for the students, not so much.

HTML and CSS are usually the fun weeks. ‘Oh cool! Some shit appeared on a screen.’ Neato. Bootstrap adds another layer of complexity and then things get a little hairy… the moment I introduce variables, booleans and conditional statements in javascript, things go south in a hurry. That word ‘var’ just scares people. Because our class only meets once a week, I encourage students to do a lot studying on their own. I’ll admit, it can be a little frustrating watching students struggle through a basic for loop for the 30th time. Why don’t they just get it? Now, in all fairness, I work with javascript (and other languages) 8 hours a day, 5 days a week, so it’s easy for me to forget just how difficult it is learning new things. Well, now I find myself in their shoes…

You see, two weeks ago I got a job offer at a startup (of course… fuck, I am a stereotypical Bay Area dev now). Cool motherfucking beans! Now, comes the hard part: I’ve been using AngularJS, C# and .Net for the last two years and Node, React and Python at home. Well, this company uses EmberJS, Ruby on Rails and Postgres. Shit. Here I am on day 12 after I heard the news and I feel comfortable enough with Ember after studying a bit after work each day to hack together a crappy front end app. Two years ago I also didn’t know .Net, C#, or AngularJS. I’ve found a pretty decent method to learning things (well enough) to be dangerous in a relatively short amount of time. Here it is:

Mix Up Your Learning Methods

Some people need books, some need videos, and others might need a paint-by-numbers style tutorial. I need all of these and more. I will use at least three mediums to learn a new language/framework. I will scour the net for blogs, short books and of course the docs on said topic and see what I can glean. My goal here is to get some basic information and best practices and to know what I’m dealing with. I’lll usually buy a cheap Udemy course after that (usually around $10) and work my way through about half of it. The reason I rarely finish these courses is because they become more of a crutch than anything around the midway point (more on that later). Lastly, I might find a meetup, join a slack channel or listen to podcasts about this new language/framework and check out some open source work to see some good examples of it in action.

Tutorial != Understanding

I used to complete a tutorial and read a book about a language and think I’d be an expert as soon as I was done. When I needed to learn C#, I bought a book then completed a 19 hour tutorial the week before work at my new job began! I went into work that Monday at my new job and had absolutely no fucking clue how to write C#. I knew what a static void, namespace, class and other trivial shit was but that didn’t help me write production level code. While I encourage reading and tutorials to my students, I always warn them about relying too much on books or tutorials. How may times have you finished a tutorial which is essentially coding by numbers (they type then you follow) and then when you go to fire up a new project, armed with your newfound skills, you are utterly lost? I’ve been there.

Build Shit

Ok, you’ve read about this new tech and have a general understanding of how it works and some of the gotchas. Check! You completed a few video tutorials or some todo app. Double motherfucking check! Sweet. Now here’s the part where you get lost in the weeds: think of something very simple that is reasonable to build over a week. Great. Now build that shit. You will be stuck, you will be frustrated and you will be googling furiously, perhaps cursing out the inventor of said language. “Why isn’t this more like here?!” You should be cycling back to steps 1 and 2 during this stage to supplement your barebones skills and by the end you will likely have a crappy app that shouldn’t see the light of day.

Congrats, you now know more than 92% of all people who complete a Udemy course or pick up one of those ‘Dummies’ books.

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

 

 

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.

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`)

Web Dev Self Study Guide

Wow, let me blow the cobwebs off this blog before I get down to business. In the last couple months I began a part-time job as an instructor/developer at a local bootcamp and added another human to my family and unfortunately this blog was left in park but then something happened…

A few weeks ago, a friend of mine, looking for a bootcamp, sat in on one of my classes and was interested in joining but the price tag and uncertainty of the job market upon graduation were major concerns. As a member of one of my favorite coder’s, Laurence Bradford’s Facebook group, Newbie Coder Warehouse, I noticed this same issue was preventing many other people from joining bootcamps or online programs. Now, it may not be in my best interest to tell you, or rather write you, nah, let’s just go with tell you it sounds better… anyways, what I’m trying to tell you is that you don’t NEED a bootcamp to get a job.

Here’s what bootcamps give you that self-study won’t: motivation, peer pressure, access to a developer who will have the answers to all those gotcha questions that may take you hours to find online, and a clear and concise path to web dev super stardom. Now, the motivation and peer pressure mainly come from the high price tag most camps charge: you tell your friends you’re shelling out upwards of 15 grand for a camp and quitting your job, then you damn well better finish that assignment on CSS media queries on a Tuesday night. For many people, keeping their interest and engagement in learning is not an intrinsic process and they need an external influence to keep them on the straight and narrow… that’s not a bad thing, it just may mean you will benefit more from a traditional class enviro (I just shortened environment, let’s try and make this a thing… enviro!) than the free wheeling self study path.

Here is the email I wrote to her outlining what I think is necessary, in the Bay Area, in 2017 to become an entry level developer; there are many places where I encouraged her to write me with any questions or further explanation on what to study and that offer is open to you the reader as well (my email is at the bottom of the page and in the contact section)

***
I thought about what I do at work and what I see as a typical day for a junior developer and what skills are necessary to join a team as a contributing member. Here’s a rough outline of what I think you’ll need:
HTML & CSS:
Take codecademy’s HTML and CSS course as well as their bootstrap course. Replicate two web pages: Google’s home page and a much more difficult page like the front page of air bnb or the home page of apple (not the functionality) just the look.
You should also be using web development tools in chrome like inspecting elements on the page and feel comfortable adjusting the css from the browser.
You should have a good concept of how to create a basic web page, ids, classes and how to use images, add links, etc.
This could take 2-3 weeks and I would watch some videos or read about what you can do with chrome browser tools, css box property, positioning elements, inline vs block style display.
More CSS:
CSS is tricky and you’ll really need to get a good hang on it before moving forward. Google ‘PSD’ (photoshop design) and pick a couple PSD’s of web pages/sites and replicate them using html and css. These projects can be used in your portfolio which you will need later.
Github:
Get a github and push some code to your repos every few days and at least once a week. You should feel comfortable creating new repos, and pushing code to them through the command line. Try to pull some other projects from people as well. Every recruiter will look at your github so keep it up to date. Git is perhaps the least friendly language you’ll come across so watch a video or reach out if it’s difficult to get started doing that.
Bootstrap and Responsive Design:
Understand Bootstrap’s grid system and make use of their components like dropdown menus, navigation menus, etc. Start using bootstrap for every site you create because nearly every company is using bootstrap or something like it. Responsive design is basically what people use to make sure their website sizes down properly when looking at it on different devices. Codecademy has a great course on Bootstrap you should take. When it comes to media queries, reach out to me after you’ve done some Googling on the subject and we can go over how to implement them.
Make a Site:
Google free bootstrap templates, get a template, and make a site for a friend or a local business. This will be your first “real” project that shows people that you can do developer stuff. BTW, using a template is not frowned upon, in real life you’ll be using a template or working with a large code base and updating features so this is more like what you’ll likely be doing than creating something from scratch.
JQuery:
Use codecademy’s course on Jquery to get down the basics. Learn how to make elements disappear, fadein, fadeout and change their css through button clicks. Add some jquery to your previous projects.
JS:
Once, again, use codecademy to get the basics down and maybe even buy this book. Do everything you can do with jquery with plain javascript. Make a one page quiz that tells user’s their score after completion. A random quote generator. Google fizz pop challenge and do that. Create a simple login system. Make a site that iterates over an array of objects with car info, including pics and display it on a page. Go on codewars and frustrate yourself with some challenges as well. You should be able to iterate, do for each loops, shift, pop and push into arrays and create objects.
More JS:
Learn about object constructors, object literal notation and prototypal inheritance. These are all fancy ways of constructing and replicating objects in JS.
AJAX:
Make http requests using Jquery’s ajax method. Search the web for API’s (todd motto has a great list) and use these API’s to retrieve information from a server and display it on a web page on a button click or allow users to enter a search term that will retrieve info. I can walk you through all this when the time comes. AJAX and using web services is how many companies accesses their databases so getting a good grip on ajax and calling web services is key to getting a job.
Databases:
MongoDB is pretty hot but so is Firebase. Firebase takes only a few minutes to set up and stores your data in JSON format (just like mongodb) through an API call. It’s easy to use and will give you a nice intro to databases and hosting data outside your local machine. I’d create a simple login using Firebase and a page where users can post and retrieve messages or whatever…
Node:
Download nodejs and express through your command line and learn how to set up a server on your machine to host your files. There are about a million tutorials on this. Node allows you to write server side code in javascript like creating apis, accessing databases and other server stuff we can go over.
JS Framework:
Learn React! React is javascript but just a different way of writing it and it’s super hot in the bay area so get down the basics. By this point you should be able to pick up a framework and tinker around with it and find online resources to help you. That’s basically how you’ll pick up whatever framework is in style if you decide to get a full time dev job.
The most important thing is to code for a little bit everyday and always google stuff you’re curious about or don’t know. Create a codepen account and make fun things for POCs (proof of concept). You don’t need to know everything on this list, in fact I would begin applying once you can create a basic web page, make ajax calls and feel comfortable using javascript in a functional way.
You will learn more on your first job than any amount of studying and things change constantly so the best asset is a desire to learn and pick things up quickly. React won’t be here in five years, maybe less, but javascript will so feel comfortable with it!
As you go down this list, you should have many questions lol so always feel free to reach out and send me a link to your projects on your github account if you’d like me to check them out. If you have time, go to meetups and meet with other coders as it will allow you to see how others work and different ways of achieving the same goal.
***
I hope you found this email I wrote to a friend helpful and if you think I should add anything to this list, or have questions as you embark upon your path to web dev hot shot, feel free to email me: hotdevdude@aol.com brianjenney83@gmail.com

So… What Do you DO Exactly?

The week before I began my first job as a web developer, I scoured the internets looking for the experiences of other junior devs: What would a typical day look like? What would be expected of me? Did I just get in way over my large(ish) head?

Surprisingly there were few examples of what a your day to day looks like as a dev, and unsurprisingly, similar to looking up symptoms for your cold on Google, I left more afraid of my first week than if I had never done that search.

I crammed as much information about prototypal inheritance, C# and data structures in my head as I could and walked in to the office (un)prepared for whatever was going to come my way. I sat down next to our lead developer and watched him punch through code on an IDE I’d never seen at break neck pace, throwing around javascript terms I pretended to know and spewing off business jargon that I wrote down to google later. My notebook swelled to 15 pages within the first week and I went home afraid he and the team would figure me out as a charlatan, a fraud a phony!

You don’t understand the nuances of protoypal inheritance? What a noob!

I didn’t get outed as a noob developer in my first month, in part because I didn’t actually code… Most of the time was spent learning the applications we were making, practicing on our IDE and watching much better developers create code.

After a month of shadowing, gaining confidence and doing small tasks here and there I was finally ready to break out on my own and contribute to the exponentially growing number of bugs our team creates. Here’s what my day looks like now:

Our morning consists of a short meeting where we each summarize what we did the day before, what we will do for the current day and bring up any issues the team should know about, like a critical bug in our app.

After meeting I walk to my desk, put my earphones on and code out to the illest country and gangster ass rap music Spotify has to offer. Before I get too deep in my playlist, I’ll look over the user story for the feature I’m responsible for working on. A user story will outline what the feature does, a mock up to help us as we design the layout and an estimate of the hours it should take complete.

While we have a lot of user stories, we have more bugs. This is the reality of coding; I’ll spend about a quarter of my week or more fixing these pesky critters.

In between user stories, I’ll inevitably get an email asking me to update the intranet site our company uses or a software support ticket from one of our users that may require a phone call, a code update or walking someone through uploading Adobe Acrobat.

I’ll leave work, go home and work on side projects and usually spend my mornings thinking about how to attack a bug before I get in.

While my dev job is at a mid-sized established company, my experience seems pretty typical based on conversations I’ve had with other developers. Is it sexy coding? Yeah, sometimes. I mean creating API’s and developing apps people will use with real world consequences is just cool. Software support… is well, software support and this part of the job has forced me to develop a better understanding of how customers use our apps and gives me the needed human contact that is often devoid when you’re staring at a screen with earphones on for most of the day.

So if you’re reading this, freaking out about your first day, week, or month as junior dev, hopefully this has calmed your jittery nerves and once you survive your first few months, hopefully you’ll contribute to the blogosphere and share your (hopefully) less than awful experience as well.