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.