Getting back to basics

One of my biggest disappointments with coding bootcamp is the scant amount of time we spent with vanilla JavaScript – only one week! By week four we were into Webpack and then React and Angular came quickly after. And while I was glad to get experience in those technologies, I set a goal in January of 2017 to practice a lot of vanilla JS. I stuck with it for a month but then I got a job and it required learning SQL and then a couple months later that job got crazy and it required learning C# and then I realized hey that language is fun and I even asked for (and got!) this book for my birthday and that ended up being a three-month side trip and then I had an idea to build an app for work and I thought hey I should use all these things I want to know in it! – so then came postgreSQL, graphQL, node, express, and vue and then October showed up and I was asked to help out with the local FreeCodeCamp chapter and I looked at all those algorithms in the course which I had never finished and always wanted to and I was sad and I also looked back on the goals I had set at the beginning of the year because fall is a great time to evaluate one’s life and I saw the ‘get super comfy with vanilla JS’ goal and I was disappointed in myself as usual but I was also really enjoying getting familiar with TDD because I think it makes me a better developer and I didn’t want to stop doing that and then Eureka! I decided this was the perfect chance to combine vanilla JS and TDD and put everything else on the back-burner for three months.

It’s terribly easy to get distracted by the shiny new thing in programming. I thought I would be better at not being drawn in because I’m that person who maps out annual and quarterly goals and checks in on the progress weekly but no – turns out, I’m only human! So this is me recommitting, in public view so I feel held accountable, to studying vanilla JS, to finishing these algorithms, and to learning TDD at the same time. You can check up on my progress here. I’m going to try my damnedest to not let anything get in my way, and soon it will be a year since I said I wanted something and we’ll see if I’ve accomplished it. BOOM.

The LaMarr List: October 29, 2017

I’ve been on a TDD kick lately and have found some cool resources:

  • Sometimes, a difficulty about learning TDD is understanding how to construct those test functions and how they interact with the code you’re writing. Check out this tutorial to get a basic understanding of how it all works.
  • I’ve been exposed to mocha, jasmine, chai, and selenium during my first year as a developer, and here’s what I discovered: I’d start thinking about an app I wanted to make, then I’d start telling myself I should obviously do TDD with it, then I’d get overwhelmed by all the ins and outs of those testing frameworks and stay stuck in that decision-making limbo for far too long. Then I discovered tape, thanks to a mentor. Use this tutorial to see how simple tape is.
  • While you’re working through those tutorials, you’ll notice a code coverage tool called istanbul. I turned to my local Software Craftsmanship group and asked them what their preferred code coverage tool is, and the conversation turned to whether code coverage is even necessary. Here are a couple of excellent opinions to give you some food for thought:

“It’s useful to have coverage when you’re just starting out with TDD as you’ll often not realize you’ve written more code than necessary or you should have and will miss conditions. Once you can consistently do quality TDD, only writing the code required by the tests, coverage becomes less useful.”

“I tend to avoid those coverage tools as well. While I can see the allure, I think it is the wrong metric to track. Covering a function with a test does not guarantee that the function is fully tested. I prefer to track bug counts that I discover after shipping — I feel that this metric is more telling of code quality.”

So check out how istanbul works, too! Give TDD a shot, and chances are you’ll find it makes you a better developer. It’s only partly about testing your code automatically – I’d argue it’s mostly about getting into the habit of really thinking about your code before you start writing it, which saves everyone, including you, so much time in the long run. Cheers!

The LaMarr List: September 29, 2017

  • This blog post by Trevor D. Miller covers running a Node server on a Pi with a physical button. I’d really like to try this with my son, for whom I recently bought a Pi.
  • These fantastic slides on the “tremendous social pressure to constantly learn and migrate to new technologies.” Great stuff from Brandon Hays – it will make you think!
  • And one of my very favorite learning resources ever, Fun Fun Function on YouTube. Mattias makes learning about JavaScript fun AND real! Lately I’ve been using him for the GraphQL videos but he has so many great ones – check him out!

The LaMarr List: August 29, 2017

Um, can you tell it’s hard for me to find time to write? My last List was over a month ago, and on vacation to boot. At the time I had grand aspirations of doing these once a week, because I consume A LOT of content and there’s no reason it shouldn’t be easy to share the best of it with all of you, and yet here we are. Maybe once a month is a more realistic goal?

  • I enjoyed this piece about being a better male ally. A particular line really hit home:

    “A boss has season tickets to see a baseball team. He generally invites men from work to join him — not because of discrimination, but because he’s worried about how the invitation would be perceived if he extended it to a woman.”

    How many times have you seen that happen? And it’s pretty understandable! As a woman, I can attest that this happens from our side, too: Countless times, I’ve held back from connecting with male colleagues outside of work because I’m worried about the perception. What steps can we all take to fix this?

  • Utah’s very own Tyler McGinnis has some great podcast episodes, and you should give them a listen! The two up now feature Kent C. Dodds (also Utah’s own), who is active in the OS community, and Dan Abramov, who helped create Redux. I love how the topics include burnout and work/life balance.
  • Last week I had the opportunity to attend React Rally, and it was fantastic. When I told Brian Holt it was my first tech conf, he insisted that it would be all downhill from now on. So many great speakers, so many ‘online idols’ I was able to learn from and meet! I’ll have to write a detailed post about it later, but in the meantime, keep an eye on their website for next year’s tix, because they sell out QUICKLY.

This weekend we enjoyed Snowbird’s Oktoberfest with some of our favorite people, and when my mother-in-law asked us to send her the picture with the mountain, well….we couldn’t resist sending her this:

An image of Ashly LaMarr at Snowbird Ski ResortAt Snowbird’s Oktoberfest

No time to write

Fascinating blog post title, right? Well, it’s 5:30am on the kids’ first day of school and it’s all I can come up with. And it’s the truth.

I’m seven months into my first developer job and I haven’t had time to write about any of it, which is very disheartening. Every day is an adventure of learning and I want to document it all, but when the workday is over, there’s just enough time to hit the gym, bury my eyes in icepacks, hang out with my family, and hit the sack. Which means mornings and weekends are generally reserved for the extra studying I’m doing on my own. Which means writing falls by the wayside. And I hate it. But priorities are priorities.

So yes, I’m still here and yes, I’m still loving being a developer. My team is amazing and makes every day a blast. I am realizing the appeal of a job where I’d get to use all the latest and greatest tools/frameworks/libs – then I wouldn’t have to spend tons of my time outside of work learning them. But I cannot believe the rate at which I’m learning JavaScript, SQL, and C# – sometimes I feel like that Matrix download thing is happening. It’s the learning that makes everything worth it!

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!