4 Technologies that I use at work on top of the Grace Hopper stack.

I have now been a real, live full stack developer for over two months! I was lucky enough to find a position that used, essentially, the same stack taught at Grace Hopper. We use a MySQL database, and Express server on Node, and React on the front end. This has made my transition into the job pretty seamless, I was able to quickly understand the existing codebase and start working.

There are, however, a number of technologies that we use that I had either never heard of before, or never used before, that I have learned on the job

1. Flow: 

Flow is a static type checker for JavaScript. What does this mean? Well, JavaScript is a dynamically typed programming language – in plain English, it doesn’t care how often you change the types of things. You can define a variable as a string and then reassign it as a number. A function can return a number sometimes, an object other times, and undefined the rest of the time. JavaScript doesn’t care.

Especially when you are just starting out, it’s great not to worry about type. However, Having strict typing (meaning, a variable or argument will always expect to be the same type, a function will always expect to return the same type) is a good way to catch errors before they happen. Flow essentially allows you to use JavaScript as a strictly typed language.

It works well with React, because you can use flow to specify what types of properties your component should receive. Then, if you try to render a component without those properies, Flow will error. This can be, in many cases, clearer and more efficient than writing tests. Once you beat the learning curve, flow is a great way to catch errors before they emerge.

2. Jest

Speaking of efficient react testing, we use Jest on the job. What sets Jest apart from other front-end testing frameworks is the ability to take “snapshots.” A Jest snapshot creates a separate file that contains the return value of a function at the time the snapshot was created. You can use this with a React component, capturing a stringified version of the HTML that the component renders. Then, in the future, if you accidentally change something in the snapshot, the test will fail. Of course, if you intentionally change something, it is easy to update the snapshot. Because much of the labor of writing React tests is just making sure everything renders correctly, this can save a lot of time – which, in turn, makes developers more likely to write tests.

3. Yarn 

We use yarn instead of npm for dependency management. I’ll admit, I haven’t taken much time to learn about yarn, mostly because the switch to yarn has had almost no effect on my workflow. The commands for yarn are almost the same as for npm, i.e. you can just run `yarn install` instead of `npm install`. Your package.json looks the same. The only major difference, as I understand it, is that yarn is faster (or something)… seems cool.

4. Async functions

I can’t lie, I freaked out a little bit when I realized that the codebase at my job almost never used promises to handle asynchronous operations. Instead they use async functions, a feature of ES2017, the newest version of javascript.

Here’s what happens. If a function needs to do something asynchronous, you define it as an async function. Then, inside the function, you get a nifty keyword “await”, which basically says “wait for this async thing to happen and then give me the result as an actual useable value.” No more chaining thens, forgetting to return a promise, or fishing around for the actual value you want. I can’t say that I am yet an expert in async function syntax, but I tentatively have the feeling that this is the best solution that exists for async in JavaScript.

 

Live!

Screen Shot 2017-04-05 at 4.44.53 PM

Above: the amount of work I have done on the website, compared to the amount of work two others had done before me.

My past month on the job, I have been helping to put the finishing touches on a website that was very nearly complete. My tasks were varied – add a hover state to a button here, block certain users from taking the test there. When I started work, it was with the expectation that the site would go live very soon, but it seemed every week we uncovered another thing that was not quite ready, and delayed the launch.

A week ago, the CTO declared with a defiant conviction, “we’re going live first thing Monday morning.” And this time, unlike the other times, we could all tell that it was actually going to happen.

Our whole team, not just the developers, started testing every edge case and making note of bugs. Suddenly, the site started to look very different. The flaws in things that we were used to seeing every day came to the surface. We worked through the weekend, and Monday morning, things were looking pretty good.

Then we tried to open the site on an iPhone, and several new and deeply inexplicable errors emerged. We powered through the rest of the day. I went home unsure what would happen, and when I checked slack once I got off the train, there was a message saying “we’re going to hold off until tomorrow morning.”

We finally launched Tuesday evening. It was exciting to see the site go live (and we’ve already had our first orders come in), but it was also a bit daunting – what would be the first thing to go wrong? Would my code stand up to actual users, and potentially hundreds of them per day?

We shall see…

 

Code in the Real World

So I have officially done what I set out to do – I have become a professional software developer. I started work this Wednesday at a small start up in the city. The company has about 15 employees as of now, and is located on half of a floor that is being rented out by a design company with too much space. It  has a decidedly modern feel. The walls, furniture, and fixtures are all white and cyan and frosted glass. Everyone sits together at a large white table, and the wall is lined with a few standing desks that I occasionally take advantage of. The kitchen, I am told, once was stocked with snacks, but, tragically, this is no longer the case. Still, there is a Keurig machine and a nice assortment of Tazo teas, so it’s hard to complain.

There wasn’t much of an onboarding procedure. They bought me breakfast on my first day, and everyone stood around and introduced themselves to me. I received my new macbook pro, 15 inches, space gray. Within an hour, I was working on my first assignment, which was to add my name and picture to the company website. After that, I was given my second assignment, which was to build out an actual feature for the website.

I started to get fatigued pretty quickly. When I was a student at Grace Hopper, I got used to focusing on code all day long, but I slipped up a little during the fellowship when I didn’t have urgent projects to work on every day. So my first full day of coding took a lot out of me. I managed to get the feature working by the end of the day, but as soon as I got on the train home I immediately realized several things that were missing from my work. I spent, essentially, the next two days refactoring and polishing the feature. I also wrote tests for it and did some bug fixes throughout the site.

I have been working closely with another female developer, which is great. She has worked extensively on website that I am working on, and has been a very good resource as I am getting started. I have mostly been using React, which I feel comfortable with, but we also use some new libraries that take some getting used to, so it’s good to be able to turn to the person next to me and ask a question when I need to.

The company I work at does a lot to be transparent, so I have also been attending meetings that are not at all technical in nature. It is a glimpse into a world that, up until now, I knew little to nothing about. Perhaps, within a few months, I’ll be able to say more about the process of startup funding, or the politics of telemedicine. For now though I’m just absorbing all that I can.

The Job Search

The job search… the big question mark at the end of every coding bootcamp.

“Will I really be able to get a job after this?”

“What does that 97% hiring rate that Fullstack Academy advertises really mean?”

My job search was postponed when I became a teaching fellow, so I was able to watch some of my former classmates go through it from a distance. Some of them were lucky and landed dream jobs within a few weeks. Others, the majority, I think, seemed to struggle more.  The anticipation built.

I told myself that I would start my own job search on January 1st. This would give me 6 weeks before the end of my fellowship (and looming last paycheck). I procrastinated. I submitted my first job application on January 3rd. I received my first job offer on January 27th, and my second offer on February 1st. I accepted an offer on February 2nd. The whole thing was over and done with in less than a month.

This was, obviously, a favorable outcome. Do I know what I did to make this happen? No. I must have done something right, but other things I almost certainly did wrong. Here’s a bulleted list (yay!) of facts about my job search. I think it serves as a nice contrast to some rather frantic posts I have read about the post-bootcamp job search, although I do not propose that any of these things are “lessons” or in any way indicative of what is typical or will work.

  • I applied to a total of 10 jobs. I found all of them through online job postings. This is not recommended.
  • The only two sites I used to find jobs to apply to were Angel List, which has a collection of job postings at start ups, and Tech Ladies, which is a community of women in tech that has a job board.
    • The great thing about Angel List is that, once you fill out your profile, applying to jobs is very easy. You simply write a short message to the employer, no long cover letter. I did write personalized messages for all of my Angel List applications, but each one took only about 10 minutes.
    • The great thing about Tech Ladies is that it provides contact information of someone at the company for each job post. This allows you to reach out directly to a real person after you send in your application. I got a pretty good response rate from my applications through Tech Ladies (3/4 of my applications through that site got responses).
  • I played up my previous non-technical experience as a teacher A LOT. I genuinely learned a lot of valuable lessons from teaching, and I know that I have more to offer because of it, even if the “hard skills” are not the same.
  • I made a portfolio site and linked to it in all of my emails with employers. I used an html5up template for my site, because I wanted it to look very clean and professional (and be mobile responsive), and I didn’t have a lot of time.
  • I keep a blog, which a lot of employers mentioned (too meta?)
  • I didn’t go to any meetups (not recommended).
  • I limited my search to smaller companies, since I hate bureaucracy.
  • I sent thank you emails after literally every conceivable interaction.
    • In the company at which I accepted an offer, I tried actually sending thank you emails to every person I talked to during my onsite (I talked to 4 or 5 people within the company). I didn’t actually have everyone’s email addresses, so I sort of creepily guessed their emails until I found something that went through. I wasn’t sure if that would work out, but apparently it did.
  • I wrote new, personalized cover letters for each company I applied to.
  • I applied to jobs even if they said they wanted several years of experience.
    • The position that I accepted said it required 3 years of experience. LOL.
  • I had my cute story about how I became a developer down.
    • Something like: I took my first comp sci class in college, and I really liked it, but I didn’t become a major. When I graduated, I started teaching math, and I was teaching myself to code on the side. I started to spend more and more time on it, until eventually I found myself sneakily coding in the teachers lounge when I was supposed to be doing my real job. And I realized that, if this was what I wanted to be doing at work, I should just make it my real job.

In any case, today is my second to last day of work at Grace Hopper, and I start my next job next Wednesday. I am very excited to get started!

The Search for Stable Search

This holiday season, I discovered a new favorite tradition: Advent of Code. It’s an online advent calendar with two new coding challenges each day. On day 4, I ran into a perplexing problem. I tested my code in every way I could think of, and I was pretty darn sure it worked, but I couldn’t get the right answer.

Why couldn’t I? Well, to find out, let’s flash back a couple months. I was answering questions for one of my first workshops as a teaching fellow. The students were writing two different sorting algorithms: merge sort and bubble sort. There are a number of sorting algorithms out there with different efficiencies, and learning to write them is a good way to build fundamental programming skills. Most developers rarely have to write these algorithms themselves, however,  because languages like JavaScript have a built in sorting function. The last question I was asked on that workshop was,  “So… under the hood, which algorithm does the JavaScript sort function use?”

“Interesting, ” I said, “let me look that up.”

It turns out that, like many things in JavaScript, the answer is “it depends.” It depends on the engine that JavaScript is running on (in most cases, this is determined by which  browser you are using). So, in short, different browsers will interpret the line array.sort() in different ways.

Fast forward a month. It turns out that my solution for day 4 of Advent of Code  relied on JavaScript’s sorting function. And my solution made an assumption about that function: that it would use a stable sorting algorithm.

A stable sorting algorithm will take two elements that it sees as equivalent and leave them in the order that it found them. An unstable sorting algorithm makes no such promises. It could leave them in the same order, or it could swap them.

A lot of the time, that makes no difference whatsoever. For example, let’s say you want to sort the following array:

[5, 3, 2, 3, 1, 4, 7]

 

It doesn’t really matter which 3 comes first in the solution –  you will get the same answer either way. An unstable sorting algorithm will do perfectly fine here. But let’s consider a situation in which you are sorting objects instead of numbers. These objects have both a name and an age property, and you want to sort by age.

[{name: 'bob',  age: 3},  {name: 'alice',  age: 5 },  {name: 'willow', age: 3}]

In this example, an unstable sorting algorithm might tell you Bob comes first, or it might tell you Willow comes first. A stable sorting algorithm will always say that Bob comes first.

And sometimes that matters, especially when you are trying to sort by two keys. For example, if you wanted to sort the above array by age and then alphabetically by name, you would need a stable sorting algorithm. This is essentially what I was doing in day 4 of Advent of Code.

So here’s the thing. Most browsers don’t consistently use a stable sorting algorithm. I was running my code in Node.js, which uses Chrome’s V8 engine, which does not use stable sorting. As soon as I ran my code in Firefox, I was able to get the correct solution. Magic!

 

 

 

Allergic React.js-ion

I can’t believe it, but the students are currently in their final week of Junior phase. This past 6-week session has felt quicker than any so far.

When I was a student, we spent the last week and a half of the program learning Angular.js, and, as avid readers might remember, I was very fond of it. But technology changes quickly, and Fullstack/Grace Hopper has already updated the curriculum to teach React.js instead of Angular. This means I have been learning a brand new technology, and then pretending I know enough about it to help other people learn it a few hours later.

React has been a bit of a tough sell for me. One thing I really like about Angular is the emphasis on separating concerns. The problem with this is that, in a large scale app, things can become very disorganized. The codebase of Learndot, the website used by Fullstack students, is an excellent example of this. Usually everything works, but when there is a bug it can be very difficult to track down. I have read that Angular is easy to write but hard to maintain for this very reason.

I am surprised, however, how much React seems to solve this problem by taking the exact opposite approach. At least in the workshop that the students have been working on this past week, there is a great deal of shared information between disparate apps. While this makes things clearer, to an extent, I can also imagine this structure getting out of hand in a large-scale application.

I am still very much in the process of learning React, and maybe I will be sold once I have a better sense of typical application structures. But, as of now, my opinion is that one can write clear and maintainable code using either React or Angular. One can also write terrible code using either framework.

 

Tessel, Again

One of the highlights of my week was being a team leader for this round of the tessel hackathon, helping to bring in another victory for Grace Hopper.

The project, called Stop, Teaf! is designed to help to protect the user against the rampant herbal tea theft in the Grace Hopper kitchen. Simply slip a discrete tessel into one of your tea bags, and the  accelerometer module will sense a thief trying to snatch it. This sets off an alarm on your computer, and you will receive a command line prompt, into which you can type a stern message to the thief. Back in the kitchen, the tessel’s audio module will then robotically shout this message to the thief using text-to-speech technology. And if that’s not enough to scare them, there is also a little flag waving that says “Stop, thief!”

This time I wasn’t doing any of the coding or planning (although the result had some things in common with my first tessel project). Instead, I spent my time running around trying to help my team of four debug and refine the plan to fit the time constraints. We ultimately got the project fully functional about 5 minutes after the judges came by, but nonetheless we took home the “Best Campus Solution” award.