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.