CODING WHILE FEMALE

My name is Lizz. I'm learning to code.

[codingwhilefemale-blog]

Developer Week SF

Last week I attended my first tech conference: Developer Week SF. It was a really interesting experience, to say the least. 

As interesting as listening to sweaty businessmen talk about software development like the process goes a little something like this:

I attended several talks. (I mean, I had to attend 5 to get a free VR headset so I had to make that happen) I found it interesting that nearly all of the speakers were on the business side- it was definitely a new perspective for me. 

If you check out my twitter story you can see the kind of topics that were being covered. It was actually pretty disheartening to hear a bunch of people who haven’t coded in 30 years but want you to understand how important security is in the development process. I think there may be a disparity between what modern-day software engineers want to experience at a conference and the kind of topics that are being covered.

I actually overheard a conversation between a conference organizer and an attendee. The attendee was a businessperson and the organizer asked what they wanted to get out of the conference since it was geared toward developers. I couldn’t help but laugh because I felt the exact opposite. 

However, I really enjoyed the expo. I got to experience a VR development experience (Coding with a VR headset on. Yeah, they’re working on that.) I got to demo a lot of interesting software, and of course, I learned a thing or two about what’s on the horizon in the tech industry. 

I think I will attend a hackathon next time. :)

For now, I'll wait patiently until I can code in a VR environment. 

[codingwhilefemale-blog]

The Psychology of Code Testability and the Importance of Updated Information

This week I took a course on code testability on Front End Masters. It was taught by Misko Hevery, of AngularJS. I found Misko’s explanation of testing to be super clear and a great introduction to testing even for someone who hasn’t tested before.

However, Hevery argues that the best code can be easily tested from the beginning of the development process. I think this is a fault in his logic, but this video was made in 2011. Lightyears in the tech industry.

I was convinced from the beginning that I needed to fact check this video. It felt like taking outdated HTML advice from W3Schools. 

Exhibit A: Hevery’s Blog. If you look past the awful UI, you’ll find that the content of his blog was mostly written in 2008. This is also a warning sign that his advice may not have withstood the test of time. 

So I turned to the internet for Exhibit B: A great medium article on Unit Testing.

Another fault in Hevery’s logic is that he does not cover Test Driven Development in such an actionable and streamlined way like this blog did. He actually spent most of the beginning of the course asserting that developers do not write tests because they do not know how. 

So here are a few great best practices on Unit Testing: 

1. Write tests first.

Tests are your first line of defense against bugs, and can also serve as a guide to figuring out the logic of your code. It’s like good pseudocode that also flushes out your edge cases if you are writing robust tests. 

2. Write Robust Tests.

A good question I always ask myself when i’m testing is “What will my code do with a type that does not match it’s intended input type?” I find that this question brings out a lot of edge cases I may have not thought of.

3. Refactor your code to be testable and readable.

There are several developers who have written about writing code that is intended to be testable, but I disagree. I think refactoring is an important process in development and refactoring to a testable codebase can show your edge cases very easily. 

So, dear Front End Masters, please give us an updated course on testing. 

[codingwhilefemale-blog]

Finding the Big O of Algorithms

This week I spent some time flexing my programming muscles by solving some common algorithms used in programming interviews. 

I also referred to Brian Holt’s FEM course ‘Four Semesters of Computer Science in Five Hours’

That title is what I like to call an alternative fact. You can’t actually learn four semesters of computer science in five hours. 

However, there was one part of the course that I found to be pretty eye opening and that was the explanation of Big O. Big O is a way that we measure the efficiency of an algorithm. 

I attempted to break down a few of the ways that we measure the amount of time it takes an algorithm to run since this concept is pretty mathy and confusing. The three methods I'll explain are Linear, Exponential and Logarithmic. 

Say we have an Array- let’s give it a good name like linearArray. 

var linearArray = [1,2,3,4]

If we use a for loop to iterate over every element in the array and stop when it has gone over the length of the array, it is a linear method. This is referred to as O(N). 

Now say I have another nested for loop running inside of this for loop. Once the second for loop is added, it’s an exponential method because for every element in the array another iteration is added. The amount of time it takes this algorithm to run is referred to as O(N)^2. 

Now here’s the really weird one: O(log N). Logarithms are used when the logic is more tricky. I like to think of my stomach as logarithmic because I may not want to finish my dinner because I am full but I definitely still have room for ice cream. Or, since I am five inches shorter than my friend, that doesn’t necessarily mean my stomach is of proportional size and therefore I can’t eat more than them. 

Here’s a great resource with visuals on what kind of runtime we’re talking about with common algorithms and data structures. Big-O Cheat Sheet

When in doubt, eat more dessert. It helps. 

[codingwhilefemale-blog]

ES6: Is the const keyword really immutable?

I’m a green software engineer. That is to say, I often get confused by very simple concepts and end up in an infinite loop of self-doubt until I can find that magical explanation.

A source of a lot of my confusion comes from learning the fundamentals of Javascript in good ol' ES5 syntax, then being introduced to ES6. There's a lot about ES6 that I feel would be confusing even for the seasoned dev, don't even get me started on arrow functions. However, I thought I was really clear on one thing: the new variable naming conventions.

I recently took the course ES6: The Right Parts on Front End Masters. It’s taught by Kyle Simpson. I’m a big fan of his book You Don’t Know JS, because well I don’t know JS.

Before taking this class I was under the assumption that const is an immutable variable that will never change, a let is a variable you eventually want to mutate and using var is some kind of social faux pas and you shouldn't use it anymore.

However, Kyle proved me wrong:

Consts are constant- You can't re-declare them, but say you have an array and you run a map function on it. It can be mutated!

Also, there is a time and place for var. Using let is great, but sometimes, stylistically you mean to use a variable across the scope of your code. 

So all along I had thought const variables could not be mutated. But what if you actually need to declare an immutable variable? Luckily, after a little bit of googling, I have a solution for this problem. Immutable JS.

Thanks again, Facebook. 

A takeaway: you shouldn’t focus on using var, let or const but really focus on having good naming conventions for your variables. Readable code is much more important.