The LaMarr List: July 21, 2017

This week I drove down to Vegas for some quality poolside time and you know what road trips mean – time to catch up on ALL THE PODCASTS! Today’s picks are:

  • JavaScript Jabber’s episode #270, “The Complete Software Developer’s Career Guide with John Sonmez.” I’ve gone ahead and ordered the book ($.99 on Kindle, woot!) and will read it when I can, but I’m recommending this episode because of the discussion on computer science knowledge (algorithms, data structures, design patterns) and how necessary it is – or isn’t – for your career. Check it out!
  • Front End Happy Hour’s episode #32, “Imposter Syndrome – These are not the drinks you’re looking for.” Join some of my fave Twitter follows for a discussion that proves maybe Imposter Syndrome isn’t 100% awful after all. You’ll come away feeling a little less stressed out, I promise. Listen here!
  • Patrick Wyman’s “The Fall of Rome” podcast, 23 episodes. History is fascinating and the rise and fall of Rome has captivated me for some time – I’ve been trying to find the perfect way to learn more about it. This just might be it! Give it a couple episodes before you quit 🙂

In the meantime, greetings from Las Vegas!

An image of a pool in Las Vegas
Did I mention quality poolside time? BOOM.

TDD with JavaScript

Do you love books? I LOVE BOOKS. I just got this one in the mail and I can’t wait to spend my evenings with it for the next few months!

A book written by Christian Johansen
Time for some fun!

Do I sound nerdy to you? (It’s because I am.) I can never get enough of learning. This has been a really difficult part of being a developer for me, because I’m interested in so many things, plus I have zero patience, so I try to study multiple things at once. You can imagine how this works out for someone with unmedicated ADD. After months of trying to balance learning a new language at work with studying other things in my ‘spare’ time (hardee har har), I decided to take a couple of weeks off and see if there was one thing that would rise to the top – one thing I wanted to learn more than the others.

Now, take note of that word, ‘wanted.’ This is another difficult thing for me, because I like to make the practical decision, the responsible decision, the decision that will lead to better employment/more money/good stability for my family. Often this does not correlate with what I actually want to do. All you adults out there feel me. But over the last few months I’ve realized that if I’m going to find the motivation or energy for extra learning after a full day of work, it’s got to be something I actually want to know more about. Enter this book.

Here’s what I know about TDD:

1) TDD is something that needs to be done, should be done, and often isn’t done.

2) Every time I’ve paired with someone on it, I’ve felt so clueless I wanted to cry.

3) Every time I’ve paired with someone on it, I’ve thought, “This stuff makes me a better developer.”

That’s about it. So TDD it is. I’d like to commit myself to a post a week about what I learn, but I’m already overextended so nah. (But maybe.)

I’ve been a developer for six weeks. Here are the code school skills I actually use.

In December 2016 I finished the Front-End Engineering program at The Iron Yard in Salt Lake City. In January I was offered a job and in February I started that job. So what did I learn in bootcamp that’s helped me daily?

How to read code

I used to beat myself up constantly for being able to read code and understand what it’s doing, but not being able to write it myself. And then I got a job at a place with multiple giant codebases and it turns out that reading code and understanding it is the more important thing (at least right now – I was here four weeks before I needed to write anything from scratch). Every week I’m introduced to a new thing at work, and lo and behold, all that practice I got reading code during school comes in handy again.

How to focus among a gazillion distractions

Write/read/test code while groups chat and laugh five feet away and there are Nerf gun torpedoes being shot at my head and some delicious smell is coming from the nearby kitchen? Yes, yes I can. In school we were encouraged to spend our afternoon lab time together, so I quickly developed the ability to be in a small area with a bunch of people and a lot of talking and interruptions, and still stay on task. At my previous job, I often had to use earbuds and brown noise to block everything out – now I don’t even notice it.

How to learn

I’ve always been a capable student and never had a problem learning things. But with bootcamps, it’s a firehose of information, and this job has been no different – learning in this kind of environment is a beast. The brain has to quickly filter through the hundreds of things being thrown at it, decide what’s most important and useful, grab onto those varying pieces of information, and then plug them in where needed hours or days or weeks later. I was able to practice this at The Iron Yard for twelve straight weeks and it has paid off immensely.

How to ask questions

Part of our pre-bootcamp coursework was to watch this talk on getting technical help. You should definitely check it out. Asking for help is complicated in our field. Knowing what information I need to convey to my team and how to communicate it succinctly, quickly, and in a way that gets the most helpful answer is something I work on daily – if I hadn’t spent so much time practicing it at The Iron Yard, my first weeks here would have been much worse.

How to ride the emotional rollercoaster of dev work

You caught that, right? What I said about it being worse? It implies those first weeks on the job were bad, and they were. If you’ve read my posts, you know that I almost quit in week 3 of bootcamp. Every week was so full of ups and downs that I could oscillate between wanting to quit and knowing I’d made the right career change decision four times a day! And so when I wanted to walk out of this job in week three and never return, I knew enough to ride it out. When I’m feeling especially stupid (happens often), I know that I just need to give it time and I’ll get it.

How to talk to complete strangers

Not only were we encouraged to go to meetups all over Salt Lake City, we were often thrown into on-campus networking events with little notice, or required to pair with people we didn’t know at all. The result? I can approach anyone at my job or at meetups, and I can successfully pair with any teammate. I know this isn’t a big deal to plenty of folks, but this was a skill I did not have before The Iron Yard, and it’s been huge for me.

* * * * *

I can’t be the only bootcamp grad whose first job uses a different language than the one studied in school, and I’m so glad I can still get some ROI for my $25,000 (tuition plus three months of not working). So, my advice to anyone attending or considering code school — spend as much time focusing on the soft skills as you do on the actual code. It’ll pay off.

From accountant to developer

Career changes. How do we come to the conclusion that we need to upend our entire life? To risk safety, routines, and having an idea of what the future will bring to take on the completely unknown? And what makes some people willing to do it, and others refuse? I’ve recently made a career change, and I’ve discovered that my feelings about it are not very cut-and-dried. I’m so happy I did it, and full of regret that I did it, and so unsure of how it’s going to turn out, and so cavalier about if it turns out well or not.

In the summer of 2015, I found myself in a cardiologist’s office listening to him say, “You need to find a way to reduce the stress in your life.” I was way too young to be having that conversation but all the same, it was true. For a decade I had made my career the first priority, and years of being in executive management of a company with constant growth and change had finally taken its toll. My Type A behavior didn’t help.

As I thought about what I could do to make my career less stressful (how in the world could I ask for a demotion now?), I spotted a bigger set of problems. I realized I wasn’t coming up with fresh ideas anymore. I had become accepting of problems because I no longer had the energy to tackle them. I was burnt out, and I felt stagnant. These things gnawed at me, but I couldn’t see a way out.

I had just received my BS in Accounting – four very long years of full-time credits, full-time employment, freelancing on the side, and raising two kids – and it wasn’t the most optimal time to be thinking, “Eh, I don’t really want to do this anymore.” So I persisted down the path I’d set for myself long ago: get my MBA, then sit for the CPA exams. I started looking at grad school and settled on two prospects. I had the transcripts sent, the recommendations written, and I filled out the applications. But when it came time to write the essays – that most simple of questions, why do you want an MBA? – I struggled mightily. Writing has never been difficult for me, and I can bullshit my way through plenty of things, but the only honest answer I could come up with was, “To make more money.” I realized I didn’t really want to be a CPA – it was just the next logical step and the way I could provide more for my family. When I weighed going $60-$80k in debt for something I felt only lukewarm about, I knew I couldn’t do it. And there was no more denying the truth – I had zero interest in being an accountant anymore.

Turns out that deciding to change careers wasn’t the hardest part for me – it was figuring out what else I’d like. It took months of exploration, and several bouts of frustration, yelling at myself, “WHAT KIND OF IDIOT DOESN’T KNOW THE THINGS THEY’D LIKE TO DO?!” I finally resorted to thinking about myself as a kid and the things I’d liked then. Two things bubbled to the surface: writing and programming. Writing was immediately slapped away as a too-frivolous dream, but programming…maybe there was something there. In middle school I’d had a BASIC class and adored it. In high school (think “You’ve got mail!” era), we had the chance to create our school’s first website, which I also loved. More recently, I’d taught myself Access, then designed and built a database for my employer – a hefty project I’d enjoyed immensely. Looking back on my career, I could see what I really liked doing was solving problems. And helping people. And that I needed to have an unending well of knowledge to keep drinking from.

I turned to Google. I found this amazing piece by Paul Ford and I read it through immediately, fascinated. I tried every little tutorial I could find to see if I was right, to see if this coding stuff would hold my interest. It did. But how to go about actually learning to program? I figured I could use self-guided online study, but I didn’t really want to – I’d earned my bachelor’s that way, and I wanted to be with people this time. Plus, my job as a financial controller was stressful and draining, leaving me with no brainpower at the end of the day to devote to learning. One day my husband told me his colleague’s brother had gone to something called a coding bootcamp; I googled it right then and there. After a couple of weeks of research, I decided on a school and a language, gave a three-month notice at my job, and traded one stack of books for another:

Sometimes, you’ve just got to make the leap, safety net or not.

Console.log is my friend (yours, too)

I don’t get to use a lot of JavaScript at this point in my new job, so to keep up on my JS skillz I spend some of my weekend time practicing old things or learning new things. Right now I’m learning Node. And while reading some code for a basic Express server, I was reminded of the lovely thing that is console.log.

Here’s the code:


var express = require('express')
var app = express()

var jsonData = {count: 12, message: 'hey'}

app.get('/', function(req, res){
  res.sendFile(__dirname + '/index.html', function(err) {
    if (err) {
      res.status(500).send(err)
    }
  })
})

app.get('/data', function(req, res) {
  res.json(jsonData)
});

var port = 3000
app.listen(port, function(){
  console.log('listening on http://localhost:', port)
})

I can see the code is pulling in Express, that it’s declaring a jsonData variable and assigning an object to it, that the get method will call one of two functions depending on the path that’s being requested, and that the listen method will show me what’s happening on my localhost:3000. And I can see those two get functions are going to use req and res, and I can see what happens with res…but what about req? I figure it’s the request coming in, but I have this need to know what all parts of all things look like, so how do I find out? Put a console.log in those functions, of course! It’s about a gazillion lines of data so I won’t repost it all here but at the very bottom, I see something like this for the first get function when I ask for the root path(‘/’):


route: Route { path: '/', stack: [ [Object] ], methods: { get: true } } }

And something like this for the second get function when I ask for the data path (‘/data’):


route: Route { path: '/data', stack: [ [Object] ], methods: { get: true } } }

Doing things like this helps the code make more sense in my brain. While I understood that the functions were taking in requests and returning responses, now I can see what the requests actually look like and I can see how the functions are seeing the path. Yay!

Flex-basis, flex-grow, & flex-shrink

Flex-basis, flex-grow, and flex-shrink are three Flexbox properties that can make things easier when dealing with responsive design. So what’s the difference between them? Let’s take a look at some code and find out!

Flex-basis is how much space we want our element taking up in an ideal world, before we start addressing extra space or less space. So in this instance, we want each of these divs to be 100px wide.

.div1 {
  flex-basis: 100px;
}

.div2 {
  flex-basis: 100px;
}

Now, when we’re viewing these two divs in any browser wider than 200px, there’s going to be some leftover whitespace. Flex-grow helps us decide how we want to divvy up any extra whitespace between our elements. So, as whitespace expands, div1 will take up twice as much of it as div2:

.div1 {
  flex-basis: 100px;
  flex-grow: 2;
}

.div2 {
  flex-basis: 100px;
  flex-grow: 1;
}

Flex-shrink helps us decide how we want our elements to behave as space decreases. In this case, we want div2 to shrink twice as much as div1:

.div1 {
  flex-basis: 100px;
  flex-grow: 2;
  flex-shrink: 1;
}

.div2 {
  flex-basis: 100px;
  flex-grow: 1;
  flex-shrink: 2;
}

To make it much more concise, we can re-write our code like this:

.div1 {
  flex: 2 1 100px;
}

.div2 {
  flex: 1 2 100px;
}

I hope that helps make sense of these three properties. If you want to learn more about Flexbox, you can’t go wrong with Wes Bos’ free series.

On object manipulation in JavaScript

Honesty is important to me, even when it means coming clean about things I struggle with. Today, I confess that I struggle with comprehending object manipulation in JavaScript. Earlier this morning I was pairing with a friend on some katas in Code Wars, and I was struggling to understand what was happening with this code:

let staff = {
  tim: 'finance',
  jim: 'accounts',
  randy: 'canteen'
}

function boredom(staff) {
  var map = {
    accounts: 1,
    finance: 2,
    canteen: 10
 }

  var score = Object.keys(staff).reduce((a, b) => {
    return a + map[staff[b]]
  }, 0)

  return score <= 13 ? 'kill me now' : 'party time!!'
}

As you can see, boredom is taking in the staff object, where it wants to match up the staff values with the corresponding numbers in the map object, then tally the numbers to produce a score and return that score’s relevant string. So theoretically I understood all that, but not this specific part:

map[staff[b]]

My brain was reading it like this…

map.staff.b

…which is sort of right, but also why I was getting confused.
I mean, map and staff are two separate objects, not connected in any way, so how is that working? Let’s walk through it! And by let’s I mean me, so I can solidify my understanding 🙂

Alright, so the first time through, a is 0 and b is ‘tim.’ Which means map[staff[b]] is basically map['tim']. And what’s Tim’s value? It’s finance. Since Tim’s value is ‘finance,’ map['tim'] is basically map.finance. And what is map.finance? That’s right, it’s 2! So the first time through, 2 gets added to 0, and on the next time through 2 becomes a, and b is now ‘jim,’ and on and on until the numbers are reduced down and boredom spits out how you feel about your office’s fun level.

Check out the reduce method on MDN.

Find out more about objects in Eloquent JavaScript.

And don’t forget, you can walk through code step-by-step on this site.

That time my blog got hacked (or did it?)

You may notice there’s a bit of a lapse in time between this post and the one before. You may be wondering what happened to weeks six through twelve. Well, let me tell you a little story.

Bootcamp got crazy about halfway through and I could not keep up on writing posts. Every week, I would take notes and compose a quick draft, but could never find the time (or leftover brain power) to polish the piece.

Fast forward to the end of school (middle of December). We were given three weeks to create our final project and there I was, four days before demo day and thinking, “I finished early! Yay! Now I have time to get my blog up to date!” I try to log in and can’t. I quickly figure out my site has been blacklisted for phishing, which I find hilarious because I don’t have users on my blog, I don’t allow comments, etc. – it’s mostly just a place for me to lay down my thoughts and show people that I can indeed put sentences together. So, good job phishers! You picked a winner! I find out it takes about $200 to get a site ‘cleaned,’ which I can’t justify spending. I turn to the AMAZING Utah JavaScript community for input, and a complete stranger offers to log in to my site and clean it for free. Thing is, he can’t find any malicious code at all once he gets in there. So we ask Google to review it, and they say, “Nah, it’s still blacklisted.”

Meanwhile, school is over, then the holidays come and go, then job hunting begins in earnest. Why yes, I am still paying monthly hosting and domain fees, because annual contracts, don’t ya know! I spend a lot of my time coding and decide that since I can’t have the site cleaned, maybe I’ll just copy what I can to a web app I built myself. So just a few days ago I pull up my site to find a posted date, and what do you know, it’s not blacklisted anymore!! And there they all are, my 18 or so drafts waiting to be finished and published. Which maybe I’ll do someday, after I have a job 🙂

Thoughts from week 5 of coding bootcamp

Early in week 4 I’d wanted to quit for at least the 10th time; things got better after that. I don’t think it was because the material became easier or my brain suddenly understood everything – rather, I finally realized I am doing all I am capable of and there’s little sense in beating myself up over incomplete or not-up-to-my-standards homework. There is literally nothing more I can do. I barely see my family, my TV time is limited to Sunday evening’s Westworld, I haven’t gone to a movie or out with friends in who knows how long, I’m not doing the cleaning or the laundry or the cooking or the grocery shopping – all I am doing is bootcamp stuff!

And while my brain isn’t necessarily understanding things completely, it is beginning to grasp how all the pieces fit together and that’s making me feel a little less like drowning and more like (mostly) keeping my head (halfway) out of the water. I am still struggling with the execution of JavaScript itself, but conceptually I’m having no difficulties comprehending things like this, objects, constructors, or prototypes. We’re also dealing with Webpack this week and that’s been fun and interesting. If given the chance, I will still spend 10 hours of an assignment on the logic itself and maybe a half hour on styling and I don’t expect that to change anytime soon. JavaScript is just too interesting 🙂

Let’s learn about objects and this

No really, let’s. Because I’ve learned this already, but I need all the reviewing I can get. This should take 6-8 hours.

First, watch these videos by one of my very favorite JS resources, Mattias P. Johansson. (And later on, find time to watch all his other videos – he’s highly entertaining, very human, and also super nice on social media.) No need to code along.

Then read chapters 1 and 2 of this book by another one of my favorites, Kyle Simpson. You may, like me, feel both dumber and smarter after reading Kyle’s material, but that’s okay – he knows his stuff and it’ll be worth it. I like to code along with the examples Kyle provides, but you don’t have to.

Now, code along with Mary while she makes a fun little game. She moves fast and you may have to stop the video every few minutes to catch up. After you’ve got all your code written and working, watch the video again while adding comments to your code about what every single thing is and what it’s doing. You’ll learn more in this second run-through than you could catch in the first, trust me.

There, now you’re an expert! Okay, not really – but you learned some stuff, right? BOOM.