Harold Treen

Contributing to prettier-atom 💅

Mon, 15 Jan 2018 00:00:00 -0500

“Contributing to {project}” is a series of blog posts where I highlight a helpful project I’m using and an open source contribution I made to it.

Today I’m going to talk about prettier, the prettier-atom package and how I reduced it’s activation time by 75%.

What is `prettier`?

prettier is an opinionated code formatter.

Should I break this chain of function calls into multiple lines? Should I add a space before each bracket?

Deciding on a code format raises many mundane questions like these. In reality, the answers don’t really matter. The most important thing is to decide on a format and stick to it.

Consistency.

prettier is exactly that - a tool for consistently formatting your code to an opinionated style.

npm install prettier
npx prettier poorly-formatted.js
# -> Outputs nicely formatted file

What is `prettier-atom`?

prettier-atom is a package for the atom editor that allows you to format open files.

I really like having prettier in my editor because it allows me to format my files as I go. Rather than writing a bunch of code and formatting it before commit, I can see exactly what prettier is going to give me.

This also helps me be more efficient as I code. Rather than spending time writing out spaces and brackets, I can just type code freely and prettier will handle the formatting on save.

prettier-atom also integrates with eslint. That means in addition to applying a consistent format, it can also fix linting issues (it does so by running the prettier output through eslint --fix).

This helps reduce the number of linting issues I encounter when I go to commit.

Amaze! 🎉

Finding issues with `prettier-atom`

As much as I love the Atom editor, it can be quite slow at times. One of the things that slows atom down is “package activation”.

Whenever atom boots, it runs an activate function in each package. Activation allows packages to queue any initialization and get ready for use. It also blocks the editor from loading, so slow activation in a package can bring atom to a crawl.

I had been noticing some lag with atom’s boot, so I opened up Timecop to see what might be causing the issue:

Atom -> Packages -> Timecop -> Show

Sure enough there were some packages taking a long time to activate - prettier-atom being the worst offenders.

This seemed like an issue. Most packages activate in < 50 ms. What would be causing prettier-atom to take so much time?

Opening an issue

I’m pretty unfamiliar with atom packages - so I wanted to open an issue and get more info before trying to contribute.

Here’s the repo for prettier-atom.

The repo has an ISSUE_TEMPLATE.md. This means when you go to open an issue, the description is pre-populated with a template. The one for prettier-atom asks the submitter to double check the issue doesn’t already exist and include output from a prettier-atom debug command.

I followed those instructions and opened my issue.

The maintainer replied a few days later saying he’d done a bunch of things to reduce activation time, but was out of ideas. Receiving a reply that was receptive to help gave me the necessary encouragement to dig deeper.

Collecting debug information

I did a simple google search for “Debugging Atom Packages” which led me to this handy page on debugging atom.

Atom is basically a web application, so it has all the same debug tooling as Chrome. The article also mentioned a --profile-startup flag that could be used to collect performance information for the initialization stage.

I ran the following command in order to start atom and collect a profile of the startup phase.

atom --profile-startup .

Analyzing profile information

This is what the profile looked like in the Chrome javascript profiler.

The chart shows all the function calls that happen during initialization. The length of the bar indicates how long the function ran for. The layers represent functions called from within other functions.

In other words, it’s a flame graph.

By hovering over these bars, I was able to find the one corresponding to the prettier-atom.activate function and dig into what was causing the slow activation time.

Looking at the chart, a few things stood out.

Loading code adds up. Every require triggers a file to be read, parsed and compiled.
One file was requiring something called toConsumableArray which was taking 64ms to load.
Another file was requiring lodash/fp which was taking 111ms to load.

These were both occurring from a require. That means it wasn’t time spent computing useful stuff, it was time spent simply loading the libraries. Yuck!

If we could avoid loading these packages, we would save ~170ms from the activation time! ⚡️

Optimization 1: Removing toConsumableArray

I noticed that the toConsumableArray import was coming from babel-runtime. Babel runtime is a collection of polyfills to allow ES6 syntax in ES5 code. I looked at the file triggering the require, and sure enough there was some fancy syntax going on.

const getAllScopes = () => [
	...getJavascriptScopes(),
	...getTypescriptScopes(),
	...getCssScopes(),
	...getJsonScopes(),
	...getGraphQlScopes(),
	...getMarkdownScopes()
];

The ... operator allows the arrays to be cleanly combined, but it’s also not supported in ES5. So babel sees that syntax and adds toConsumableArray to polyfill the functionality.

It’s nice syntax, but not nice enough to warrant 64ms of activation time. Converting the expression to an ES5 compatible version stopped babel-runtime from being included.

const getAllScopes = () =>
	Array.prototype.concat(
		getJavascriptScopes(),
		getTypescriptScopes(),
		getCssScopes(),
		getJsonScopes(),
		getGraphQlScopes(),
		getMarkdownScopes()
	);

Sure enough, the require disappeared and the activation time reduced substantially.

Optimization 2: Lazy loading lodash

A common pattern in nodejs code is to include all your requires at the top of the file.

Here’s an example:

const _ = require("lodash");

function reverseAndCompact(arr) {
	const reversed = _.reverse(arr);
	return _.compact(reversed);
}

function activate() {
	console.log("Activating!");
}

This is nice for keeping track of what’s required, but slows down the initial load of the file. Anything that requires the above file will need to wait for lodash to be fully parsed before it can even see the reverseAndCompact function.

This is especially annoying if we just want to use the activate function. It doesn’t depend on lodash, but still needs to wait for lodash when it’s imported.

Boo!

This is more or less what was going on. One of the helper files was requiring lodash/fp at the top of the file, despite only 1 function actually using it (and a function that was not needed for activation).

The solution? Lazy loading!

let _;

function lazyLodash() {
	_ = _ || require("lodash");
	return _;
}

function reverseAndCompact(arr) {
	const reversed = lazyLodash().reverse(arr);
	return _.compact(reversed);
}

function activate() {
	console.log("Activating");
}

By placing our require within a function, we stop it from being loaded when the file is required. Now when I go to import the activate function, there’s no waiting for lodash to be required.

Those two changes saved the expected 111ms and more. Yay! 🎉

Submitting a PR

Once I had validated my fixes for the issue, I was ready to open a PR.

The prettier-atom repo contained a CONTRIBUTING.md file with instructions for opening a PR.

Some highlights from it:

The project uses something called nps or “node package scripts”. This means all the development scripts are run with yarn start <script-name>. The scripts were also defined in the package-scripts.yml to reduce the size of package.json.
The project has an addContributor script. That script allows you to update the README with a link to your Github and notes about what you contributed. Such a cool way of acknowledging contributors!
To commit you use yarn start commit. This starts a little cli to create your commit. The command ensures that all commits conform to a consistent style and make things like generating a CHANGELOG easier.

I followed the instructions, opened a PR and had my changes merged within a few days!

Takeaways

Contributing to prettier-atom was a great experience. Many projects I’ve contributed to in the past are pretty ad-hoc and don’t have a clear process for contributing. The maintainers of prettier-atom are very experienced open source maintainers and seeing their process taught me a lot about managing my own open source projects.

Some other learnings…

Profile your code: It’s amazing the optimizations you can find if you just dig a little. You can’t understand the performance of your code by simply reading it. You need to run it and analyze it. I would never have guessed imports accounted for 75% of startup time.
Improving performance is a great contribution: Most people aren’t profiling their code, which makes it a great area to look for bugs. It’s also extremely satisfying to have a measurable impact on the project.
Babel has a cost: Writing code with the latest ES6 features is all the craze, but there’s not much discussion about the cost of doing so. Simple things like using the ... operator might require extra dependencies. How much are you willing to slow down your code to use the new fancy syntax?
Open source is a great way to learn about project management: Seeing the amount of tooling and documentation that existed for prettier-atom was really inspiring. Having a command to update your contributors list? For generating a release? For creating consistent commits? These are things I’d never really seen. It’s a great lesson in making projects beginner friendly and easy to setup. These things are easy to gloss over, but provide a lot of value in the long run.

I’m going to continue looking for ways to speed up my atom activation 😊.

Thanks to @cqfd and @vaibhavsagar for helping me make this post prettier 💅.

Contributing to redux-saga-tester ⚛️

Sat, 13 Jan 2018 00:00:00 -0500

Hello internet! It’s been a while.

I’ve been getting back into open source recently by contributing to some libraries I use.
When it comes to open source there seems to be a lot of questions:

How do I find a project to contribute to?
How do I find an issue to work on?
How do I open a PR without looking like a n00b? I don’t want to look like a n00b! 😭

So I thought it would be fun to turn my OS contributions into blog posts! Hopefully it can inform people about cool libraries and the process of becoming project contributor.

So without further ado, I present…

The "Contributing to {project}" Series! 🎉

In today’s edition:

Contributing to `redux-saga-tester`

redux-saga-tester is a library to simplify testing redux sagas.

…???

Alright… that might not mean anything to anyone. Let’s take a step back…

(Or skip ahead if I’m preaching to the choir!)

What is Redux?

Redux is a state management library for javascript. It allows you to take all the state in your application and centralize it to one spot. It also enforces consistent conventions for reading and updating that state.

The heart of redux is called the store. All reading and writing to the state is done through the store.

import createStore from "redux";
import reducer from "./reducer";

const store = createStore(reducer);

In redux, state mutations are done by dispatching an action to the store. An action is a plain javascript object describing a change:

const action = {
	type: "ADD_TODO",
	id: 10,
	description: "Use Redux"
};

store.dispatch(action);

Actions are taken by redux and handed off to a reducer (that thing we passed createStore above). A reducer is a pure function that takes the current state, an action and returns new state.

const initialState = { todos: [] };

function todoReducer(state = initialState, action) {
	switch (action.type) {
		case "ADD_TODO":
			const newTodo = {
				id: action.id,
				description: action.description
			};
			return { ...state, todos: state.todos.concat(newTodo) };
		default:
			return state;
	}
}

const state = { todos: [] };
const newState = todoReducer(state, action);
// -> { todos: [{ id: 10, description: "Use Redux"}] }

Your application can then subscribe to the store and render the new state.

class TodoList extends React.Component {
	render() {
		return (
			<ul>
				{this.props.todos.map(todo => (
					<li key={todo.id}>{todo.description}</li>
				))}
			</ul>
		);
	}
}

reduxStore.subscribe(() => {
	const state = reduxStore.getState();
	React.render(
		<TodoList todos={state.todos} />,
		document.getElementById("app")
	);
});

That’s all you really need to know!

Here’s a link to the docs in case you want to dig deeper.

What is `redux-saga`?

Cool! So redux is this thing that:

Accepts actions (plain javascript objects)
Passes them to a reducer (plain javascript function)
And returns the new state (plain javascript object)

This model works great for synchronous state changes…

I have a todo! Add it to my state plz!

But it doesn’t really work great for asynchronous state changes…

Make a network request for my todos! Show an error if the request fails!

Enter redux-sagas, a redux middleware.

Reducers listen for actions with a certain type and perform synchronous updates to the state.
Sagas are generator functions that listen for actions with a certain type and perform asynchronous updates to the state.

You might have a fetchTodosSaga that listens for a FETCH_TODOS action and handles the necessary network requests.

function* fetchTodos(action) {
	try {
		const todos = yield call(Api.fetchTodos);
		yield put({ type: "FETCH_TODOS_SUCCEEDED", todos });
	} catch (e) {
		yield put({ type: "FETCH_TODOS_FAILED", message: e.message });
	}
}

function* fetchTodosSaga() {
	yield takeLatest("FETCH_TODOS", fetchTodos);
}

(takeLatest and put are just functions to listen for actions and dispatch other actions)

This is nice because we can trigger complex behavior with actions along with update the state.

…Once again, you can find much more info in the docs.

What is redux-saga-tester?

Great! So redux and redux-sagas allow us to centralize all our state storage and management.

But now that we have all this logic in sagas… how do we test it?

According to the redux-saga docs, by calling the saga and inspecting the yielded values.

it("fetches the todos", () => {
	const generator = fetchTodos();
	const todos = [];
	expect(generator.next().value).toEqual(call(Api.fetchTodos));
	expect(generator.next(todos).value).toEqual(
		put({ type: "FETCH_TODOS_SUCCEEDED", todos })
	);
});

But this is not ideal…

What if we add an intermediate yields between the first API call and the dispatched action?
What if the order values are yielded changes?
What if we have a lot of steps in our saga?

These types of tests end up being long and fragile (any change to the saga offsets everything and breaks the test).

In reality, we don’t really care all the nitty gritty details of what our fetchTodos saga is doing.

Does it log stuff? Does it dispatch other actions? What are the order of those?

¯\_(ツ)_/¯

What we care is:

It runs when we dispatch FETCH_TODOS.
A network call is made for todos (or our API library is called).
The returned todos end up in the store.

So something like this:

it("fetches the todos", async () => {
	const todos = [];
	sinon.stub(Api, "fetchTodos").resolves(todos);

	const sagaTester = new SagaTester();
	sagaTester.run(fetchTodosSaga);
	sagaTester.dispatch({ type: "FETCH_TODOS" });
	await sagaTest.waitFor("FETCH_TODOS_SUCCEEDED");

	expect(sagaTester.getState().todos).toEqual(todos);
	expect(Api.fetchTodos.called).toBeTrue();
});

This setup is much nicer.

We’re using the saga the same way it will run in our application.
The test describes behavior instead of implementation details.
Our test is less likely to break due to minor changes to the saga.

The second setup is what’s enabled by redux-saga-tester. It allows you to run your sagas to completion and observe the resulting actions and state changes.

Finding issues in `redux-saga-tester`

redux-saga-tester is a library I discovered after becoming frustrated with the recommended testing strategy.

Originally when I read the docs for redux-saga and “How To Test”, it simply read:

WIP

Not super helpful…

How can they recommend these patterns without also understanding the testing implications?!

I began googling around and eventually found a github comment by the creator of redux-saga-tester describing their workaround. Switching to redux-saga-tester instantly made my tests simpler and more robust.

But while writing tests with redux-saga-tester there was a strange error I would run into.

Timeout - Async callback was not invoked within timeout specified.

Wahhh? 😰

It turned out to be caused by the waitFor method.

it("waitFor might never resolve", async () => {
	const sagaTester = new SagaTester();

	sagaTester.run(fetchTodosSaga);
	await sagaTester.waitFor("THIS_ACTION_WILL_NEVER_DISPATCH"); // Boom 💥
});

waitFor allows the saga to run and resolves when a certain type of action is seen.

Unfortunately, waitFor would not resolve if the action never occurred. The saga might run to completion, but the waitFor would never get resolved.

This was annoying for a few reasons:

The error was a timeout, so the test suite would hang for 5 seconds failing.
The error was extremely unhelpful (timeout provides no indication what went wrong).

I opened an issue on the repo which received a few responses from others also experiencing the issue. Normally I’d wait for the maintainer to comment before moving forward with a fix, but enough people seemed effected that I decided to work on it.

Fixing the issue and opening a PR

For the longest time I let the issue sit.

I don’t want to dig through the internals to figure out how it works. It’s probably complicated.

Eventually I realized that the first step to fixing the issue wasn’t “learn how everything works”. It was simply “write a test that demonstrates the issue”.

Luckily the library had a nice test suite. I was able to capture the issue with a simple test.

it("Rejects if saga completes without emitting awaited action", () => {
	const sagaTester = new SagaTester({});
	const NON_EMITTED_ACTION = "NON_EMITTED_ACTION";
	const emptySaga = function*() {
		yield;
	};
	sagaTester.run(emptySaga);
	const wait = sagaTester.waitFor(NON_EMITTED_ACTION);

	return expect(wait).to.be.rejectedWith(Error, NON_EMITTED_ACTION);
});

Once there was something exposing the issue, working on a fix was much easier. I could read through the code, add console statements and inspect what was being run with my test. That was all the momentum I needed in order to implement a fix.

Turns out that running a saga creates a promise to alert when it’s complete. Nothing was listening for that completion, so I added a callback to verify the awaited actions.

function _verifyAwaitedActionsCalled() {
	Object.keys(this.actionLookups).forEach(actionType => {
		const action = this.actionLookups[actionType];
		if (action.count === 0 && action.reject) {
			action.reject(
				new Error(actionType + " was waited for but never called")
			);
		}
	});
}

task.done.then(() => this._verifyAwaitedActionsCalled());

Whenever waitFor is called, it saves the promise in the actionLookups object. This object also stores the number of times that action was dispatched. My function looked for actions with no dispatches and rejected their unresolved promises.

This got my test passing! Yay! 🙌

I pushed the change to my fork and opened a PR.

redux-saga-tester doesn’t have a CONTRIBUTING.md or a PULL_REQUEST_TEMPLATE.md, so I just ensured my commit history was minimal, the commit messages were clear and my pull request was well explained.

A few days later the maintainer merged the change after some additional testing 🎉.

Updating the README

While working through this issue, I was surprised to discover some additional functionality that wasn’t documented. The README contained some usage examples, but gave no overview of the API.

Having to read the code to learn about everything was not ideal, so I added a more formal API to the README. Once it seemed to match the source files, I opened a PR for that.

It was merged with no additional comments 😊.

You can view that API here.

Takeaways

Test behavior, not implementation: Seeing the tests for redux-saga made it extremely clear why testing implementation is a bad idea. Tests become extremely flakey! If your tests are too coupled to your implementation, it may be a sign to test at a higher level. redux-saga-tester allows for testing at a higher level where you don’t need to think about implementation details.
Open Issues: It takes very little effort and is the first step to discovering whether others want a fix and if the maintainer is responsive.
Start with a test: Digging through source files can be very intimidating if you don’t know the project. Writing a test is a great way to expose the issue and provide a path to implementing a fix.
Improve the project: As a new contributor you have insights into the project that the maintainers don’t have. Is this project easy to understand? Easy to contribute to? Is there any documentation missing? Once you’ve got your feet in the water, you’ll likely be able to spot other things that can be improved… improve them!

So there you go! A fun open source contribution I made over a weekend.

Now go forth and contribute to a library that you’re using!

Thanks to @cqfd, @jimjshields and @vaibhavsagar for thoughts and feedback! 😊

Debugging A Passive Aggressive Server 🤖

Sun, 11 Jun 2017 00:00:00 -0400

Since last year, I’ve been working on a project called EpubPress.

(It’s a Chrome extension, Firefox extension, npm module and web service for creating ebooks from a collection of web articles.)

EpubPress and I generally get along great.

It serves my requests. It restores from errors. It does what’s expected.

But all that being said, I’d noticed a persistent issue with EpubPress - sometimes it would just stop talking to me 😭.

EpubPress! Give me the homepage!
*crickets* … *timeout*

EpubPress! Let me connect to you via SSH!
*crickets* … *timeout*

EpubPress! Respond to my pings!
*crickets* … *timeout*

What was going on? It had just created a beautiful book for me an hour ago! Why the cold shoulder?

Whenever this happened, I would go through the same steps:

Is the server overloaded? Nope. CPU usage was stable.
Did the app need a restart? Nope. App is running fine.
Had Nginx failed? Nope. Nginx was working normal.
Did the logs for the instance have clues? Nope. Nothing out of the usual.

By this point I’d be freaking out. My server was losing ‘nines’ of uptime by the minute!

My last resort was to restart the machine - that put everything back to normal. Phew! 😌

…But only for so long.

By the next day, the issue would be happening again 😫.

Enough is enough

Communication is important to me - so I was bothered that my cherished server wasn’t using its words.

After multiple occurrences of this issue, I decided to get to the bottom of it.

Talking to friends

When someone is giving you the silent treatment - sometimes you can find out why via a friend.

In this metaphor, my friend was DownForEveryoneOrJustMe.

Harold: Hey DownForEveryoneOrJustMe, EpubPress is ignoring me. Is it talking to you?
DownForEveryoneOrJustMe: EpubPress is talking to me. Problem is only for you!

Huh? That can’t be true…
I tried talking to EpubPress via another server.

Harold: Hey HaroldTreen.com, is EpubPress talking to you these days?
HaroldTreen.com: It sure is! EpubPress is responding to all my texts.

What?! Betrayal! 🔥😡🔥

I now knew that…

EpubPress was not responding to anything I sent it.
It wasn’t because EpubPress was busy. I checked and it was sitting idle at home.
It wasn’t because EpubPress was unwell. All the internal components were operational.
It wasn’t because EpubPress was anti-social. It was talking to everyone else.

I was stumped.

Reaching out to others

At this point, I decided I needed more guidance. What else could cause my server to ignore me at random?

Luckily I had attended a batch at the Recurse Center and had a community of knowledgeable programmers who might be able to help.

My pleas for help on Zulip.

From there, I heard from @pirate and @imccoy who helped me do some better debugging™.

Better debugging ™

My initial debugging strategies were pretty rudimentary.

Restart nginx.
Restart pm2.
Make a request using Chrome.
Make a request using curl.
grep some log files.

Talking to others introduced to me to an awesome set of tools that helped get to the root of the issue.

`netstat`

netstat (network statistics) is a command line tool for displaying information on network traffic. I used it to see all the ports my server was listening to.

Using the netstat -ap, I was also able to see what processes were listening to each port. There was a normal number of connections and my app was listening to the right ports…

In the output you can see nginx and pm2 connected and listening away:

Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name
unix  3      [ ]         STREAM     CONNECTED     XXXXXX   31485/nginx -g daem 
unix  3      [ ]         STREAM     CONNECTED     XXXXXX   31485/nginx -g daem
unix  2      [ ACC ]     STREAM     LISTENING     XXXXX    1486/.pm2)
unix  2      [ ACC ]     STREAM     LISTENING     XXXXX    1486/.pm2)

Maybe my packets aren’t making it to the server?

`mtr`

mtr (my traceroute) is a program that combines traceroute and ping. It continually pings the provided host and shows a live view of the path taken to deliver the ping.

Using mtr <host>, I was able to see how packets were travelling to EpubPress. I noticed packets were getting blocked somewhere down the line (all the ???s).

mtr epub.press output. At hop 13, packets are swallowed into the void.

It’s interesting to note that some intermediate servers were also returning ???s. This could be because they are configured to forward traffic but ignore pings. That’s fine, but my server is not one to ignore a friendly ping.

Could it be a server in the middle ignoring me?

`tcpdump`

tcpdump is a program that lets you inspect all the packets being sent and received by a machine. It was like peeking into EpubPress’s brain and seeing every word received and how it was responding.

Using tcpdump host <my-ip> I discovered that my packets were arriving, but no packets were being returned. Not even a modest SYN-ACKs was being returned 😥.

This is what tcpdump produced on the server while my laptop was sending pings:

06:08:21.069515 IP pool-XXX-XX-XXX-XX.nycmny.fios.verizon.net > epubpress-backend.c.epubpress-XXXX.internal: ICMP echo request, id 10677, seq 33022, length 44
06:08:21.167963 IP pool-XXX-XX-XXX-XX.nycmny.fios.verizon.net > epubpress-backend.c.epubpress-XXXX.internal: ICMP echo request, id 10677, seq 33023, length 44
...etc

This is what working output looks like:

06:13:49.763522 IP pool-XXX-XX-XXX-XX.nycmny.fios.verizon.net > epubpress-backend.c.epubpress-XXXX.internal: ICMP echo request, id 10770, seq 33161, length 44
06:13:49.763556 IP epubpress-backend.c.epubpress-XXXX.internal > pool-XXX-XX-XXX-XX.nycmny.fios.verizon.net: ICMP echo reply, id 10770, seq 33161, length 44

ping uses a protocol called ICMP (Internet Control Message Protocol). No matter how many ICMP echo requests I sent, EpubPress would not reply.

Could it be a firewall issue?

`netcat`

netcat is a program for reading/writing directly to a network connection. I think of it like cat, but for printing whatever a given port receives.

Using nc <host> <port> on both machines, I was able to test if a program separate from my application could communicate back to my laptop. As expected, this did not work - but I tried it anyway because it was fun using all these new tools.

On working computers, I was able to type in the terminal and see the characters appear on the other end! Wow!

Teehee, I’m chatting with myself!
*5 minutes later*
Alright, enough tomfoolery! What is our firewall doing…

`iptables`

iptables is a tool for modifying tables of firewall rules. It can be used to define how individual packets should be treated.

Using iptables -L I was able to list all the rules in the tables. Sure enough, there it was:

chain sshguard (1 references)
target     prot opt source               destination
DROP       all  --  <my-ip>              anywhere

The sshguard chain had a rule for blocking all my requests! 😱

Who is this sshguard character?!

`sshguard`

sshguard is a tool for protecting against brute force attacks. It aggregates and inspects system logs to detect suspicious activity. It then blocks the suspicious traffic.

In other words, EpubPress had this friend sshguard who I didn’t know existed. sshguard had noticed me constantly talking to EpubPress and become worried whether this was a good use of EpubPress’s time.

So sshguard decided to brainwash EpubPress into ignoring me so it could focus on creating books.

Issue Solved 🎉

I had a talk with sshguard, settled our differences and had it add me to its whitelist.

sshguard -w <my-ip>

Now whenever I to talk to EpubPress, sshguard doesn’t try to interfere.

The moral of the story?

Smart tools exist for protecting against brute force attacks!
Sometimes strange problems arise and it makes no sense what’s going on - but if you dig deep enough you’ll likely find a fascinating explanation!
Reach out to others when you’re facing an issue - they might have a wider array of tools to help debug the problem.

EpubPress and I resolved our differences and we are looking forward to making more beautiful ebooks together.

The End

👨❤️🤖

Thanks to @jvns and @vaibhavsagar for helping me debug this blog post 💕.

Two Months Of Tech Interviews 💼

Thu, 16 Mar 2017 00:00:00 -0400

The time finally came.

Full. Time. Job. Search.

Over the last 5 years, I’ve accumulated over 2.5 years of paid software engineering experience. I’ve also accumulated a fair amount of self-directed experience.

But, I’ve never accepted a full-time job…

Sorry, I have more school to finish.

Sorry, I want to work in a different city.

Sorry, I want to travel and focus on my own projects.

Sorry, I want to attend the Recurse Center.

…until now.

On Monday, I accepted a full-time offer with Squarespace 🎉.

Job hunting was far from the seamless process I imagined it would be. Here’s a review of my 2 months interviewing in tech.

Interview prep

The first step of my journey was interview prep.

In December I was finishing a batch at the Recurse Center. During the final weeks I switched gears towards interview prep.

I highly recommend taking a week or two to prep. Most of the time between mid-December to early-January was just switching my brain to interview mode.

During this time, I made the mistake of scheduling a phone interview before I was fully ready. I failed pretty spectacularly and ruined a really great opportunity… not good 😢.

Resume cleanup

I updated my resume before starting applications and a few times throughout the process. Some things I tried to do:

One page: Companies get tons of resumes and they have limited time to read each one.
Use bullets: They are easier to skim and help separate discreet accomplishments.
Show, don’t tell: Let experiences speak for themselves. Building something with a 10/10 rating is better than saying “my project was popular”.
Less is more: At the start I thought more things meant more impressive. Later on I realized that each item has diminishing returns. Too much just creates clutter.
Consistency: I tried to be consistent with how I mention technologies and structure items.

With each update I shared my resume with a bunch of people for feedback. Here’s a .gif of all the iterations it went through.

Resume evolution (6 versions)

It changed quite a bit over the course of the 2 months. Looking back, I feel a tad gross having sent out the original version 😅.

Sending applications

Over the course of my 2 month search, I applied to 43 companies.

Here are the stats^*:

Type of application	# Interested	% Interested
Online	4 / 22	18.2 %
Referral	12 / 21	57.1 %
Total	16 / 43	37.2 %

* Interested means I was contacted for some type of interview.

Something to note: Referrals were 3x more likely to get a response.

I found referrals via:

Working with the jobs team at the Recurse Center.
Contacting past coworkers.
Broadcasting my job hunt on Facebook.
Joining online tech communities (eg. a slack group for technologists in Toronto).
Talking to independent recruiters.

I would highly recommend reaching out to your networks. Referrals are so much more reliable.

Of the places that weren’t interested, it generally fell into the category of “looking for senior engineers” or “looking for US based engineers” (I’m Canadian 🇨🇦).

Side note:
Extra thanks to the Recurse Center. They were incredibly helpful during my job hunt.

Before working with them, I assumed recruiting was just a means to an end.

“We don’t run the Recurse Center so we can recruit, we recruit so we can run the Recurse Center.”

RC User Manual

After working with them, I’m super grateful they recruit. It was another amazing perk of attending.

Interviews

Of the 43 companies I applied to, 16 went forward with some type of interview.

The process generally followed:

Coding test (sometimes)
Phone interview
Technical phone interview #1
Technical phone interview #2 (sometimes)
Onsite interviews
Hiring decision

When I accepted my job offer, I was in the middle of a few other processes. I ended up having to withdraw my applications (not enough time to finish 😥). When I was applying, I tried to avoid this as much as possible by spacing out my interviews.

Here’s how I progressed through my interviews:

Interview challenges

Interviewing was a bunch of ups and downs.

Some days I’d be applying all over and feeling super excited about my chances.
Other days I’d be freaking out because weeks had gone by without any responses.

Some days I’d be scheduling interviews non-stop.
Other days I was looking back on rejections and feeling defeated by all the failures.

Some days I felt bad about my interviews but then got forwarded along.
Other days I felt great about my interviews and then got rejected.

It’s also a well known fact that interviewing is not an exact science.

After my first couple of rejections, I started getting really frustrated with technical interviews.

These coding problems are so arbitrary! If I ever needed to know this, I could easily Google it.

I’m not allowed to run the code? How is this testing my actual abilities?

Yikes! I’ve been doing nothing but algorithm prep for a month and this is a CSS question…

I wished people would just ask me about my past projects and how I work with other people.

Then I had some really laid back interviews that did just that - those left me concerned.

That was all conversational… what if they just hire random people who can talk but can’t code?!

He didn’t write any notes. What’s he going off of other than just gut instinct?

This is too easy…

By the end I had a new appreciation for how hard it is to interview.

You can keep things really conversational, but how does that show if someone can actually code?
You can assign a project, but how can you know if the person will have time to do a good job?
You can dive into quick algorithm problems, but how much does that actually tell you about the person?

All the while you have a growing stack of applicants just waiting for an interview. 😩

I wonder if any companies let candidates choose their interview style. Give a few different options and let the candidate pick the path that works best for them. I’d like to see how that type of system would work out.

Interview highlights

Luckily, not all my interviews left me banging my head against a wall. Some were really fun!

Simple Website: One company asked me to build a simple website in 4 hours. I enjoyed being able to focus on a project without having an interviewer breathing down my neck. The followup was working with some team members to add features to the site. Since it was my code, the choice of what to work on was completely open ended. The focus was on working as a team instead of finishing a list of tasks.
Life Story: Two companies had me tell my life story. Where I grew up, how I got into programming and all the steps that led me to my job hunt. I love asking people to tell me their Origin Story, and have spent a decent amount of time thinking about my own. It makes me happy when people have a self-awareness about their past and are willing to share. I liked that the company valued those things as well.
Independent Coding Problems: At one onsite, I was given a sheet of questions and an hour to program solutions. Once again, I enjoyed being able to focus all my attention on the problems. It also gave a break from talking, talking, talking. That was nice.
Pass The Tests: One interview asked me to implement a function to pass a suite of tests. I loved that! As someone who does a lot of TDD, I find it really helpful to have a set of test cases I can work through. It helps me concentrate when I can tackle the problem bit by bit.
Pairing: I did a few interviews where I was allowed to use the internet and ask questions. They were described as pairing interviews, but didn’t feel like it. They usually involved an interviewer sitting across from me looking at their own laptop… not much different than sitting across from me as I write on a whiteboard. I had one really awesome pairing interview though. We both sat at the same workstation and faced the problem together. As a result, it was much easier to point at things and collaborate. That small change made a big difference.
Team Lunch: Most companies with full-day onsites will schedule in some sort of lunch interview. It’s supposed to be a chance to relax and ask questions to an engineer. At one company, the lunch was with my entire prospective team. Having everyone meant I could just shut up and see how people interacted regularly. I also got to feel what it was like to spend time with my potential future colleagues.

Besides the interviews themselves, I also had some really good recruiters. People who were super attentive and eager to move things along at whatever pace I felt comfortable.

Interviewing was tedious, so every supportive recruiter and well thought out interview was much appreciated ❤️.

Offers

Learning I had offers was really stressful.

Do I take it or finish interviewing with these other companies?

Is this my market value? Should I negotiate?

Company A is really cool, but I’ll have to move so far. Company B is smaller, but in a better city. How do I choose??

I don’t plan on moving again for a while, so it was a big decision. The factors that led me to choose Squarespace:

Well established company with a good reputation.
Team with a bunch of friendly people and interesting projects.
Being close to the Recurse Center and the awesome communities in New York.
At the same time, being close enough to Toronto that I can visit easily.

Places in Vancouver were a close second. I met a bunch of wonderful people there during my time at Mobify. Still sad that I won’t be as close to them as I would like 😢.

Some notes for past me

Now that it’s all over, what tips would I have for past me?

Prepare early: Interviews are a whole other skill-set - you can’t just wing it.
Clean up your resume: Squishing a year’s worth of activities into one item is confusing. It’s better to break things up properly and skip some details.
Focus on referrals: It might be easier to upload your resume everywhere, but your chances are way higher with referrals.
Research the companies: Interviews are much more interesting if you can go in knowing what they’re working on and why you want to contribute.
Write more code by hand: Interviewing involves a ton of communication. How you work through the problem is just as important as coding the final solution. Practice that thought process.
Focus on interviewing resources: Things like HackerRank are fun because you get to write code and test it out. But working code isn’t everything. Resources like “Cracking The Coding Interview” give in depth explanations of all the other things interviewers are looking for. Did you realize there’s a faster solution that uses more memory? Or that assuming a sorted input lets you cut the runtime in half?
Accept the circumstances: Some interviews are frustrating. Others are great. Analyzing the problems with one over the other never helps. The system isn’t perfect, but it’s what you have to work with. Do the best that you can with it.
Calm. Down.: Stop worrying about the pros and cons of job A vs. B. Chances are they’re both equally amazing for completely different reasons. Flip a coin. Make a choice. The second you do, you’ll move on and be excited for what lies ahead.

Thanks

I couldn’t end without sending out some appreciation…

To everyone who helped me prep.
To everyone who read over my resume.
To everyone who forwarded me along to their HR department.
To everyone who listened to me rejoice after a good interview.
To everyone who listened to me vent after a bad rejection.
To everyone who gave guidance and advice along the way.

Thanks ❤️.

It’s been a hectic 2 months, and I’m so excited that it’s over.

Let the Squarespace adventure begin! 🙌

Thanks to @kracekumar, @zormit and @Khaleed for providing feedback on this post! 🥇

Applying to the Recurse Center...twice 💌

Sun, 26 Feb 2017 00:00:00 -0500

The Recurse Center.

A free, self-directed, educational retreat for people who want to get better at programming, whether they’ve been coding for three decades or three months.

I heard about it through some well regarded friends back in 2014.
In 2015, I finally got up the courage to apply.

I was promptly rejected (literally the same day 😅).

It was both disappointing and confusing. What had I done wrong? I thought I’d be a great candidate…

I had just finished my Computer Engineering degree.
I had worked at numerous tech companies.
I volunteered with diverse, tech focused organizations.

But I swallowed my pride and moved on.

Fast-forward to June, 2016. ⏩

I was travelling South America, working on some side projects and starting to crave a better coding atmosphere. Willing to try anything, I decided to reapply to RC.

A few days later I was invited to interview over Skype.
Then came an invitation to a pair programming interview.

…then came an acceptance email! ❤️

In Fall 2016, I had the joy of attending a 12-week batch at the Recurse Center.

Diffing my applications

While at RC, I learned that you can actually look back at past applications. I pulled up my first and second to see what had changed between the two.

Here’s my first application.
Here’s my second application.

I definitely think my second attempt was an improvement.

Here’s some quick thoughts on how my application changed.

Disclaimer: I don’t recruit for RC and have no insight on my applications performance. These are mere humble thoughts. 🤔

Code CracklePop

I think both answers are acceptable.

The first decouples message generation from message printing, BUT prints the number on every iteration - which is WRONG. (See problem description)
The second is a short function that does everything it needs to do.

I think we all know why Harold got rejected now. Case closed!

Please link to a program you’ve written from scratch.

I referenced the same project in both applications. In the first I tried talking it up whereas in the second I just left the link and a description.

I worked on that project more after my first application, so it may have been more complete the second time it was reviewed…

What is the most fascinating thing you’ve learned in the past month?

First application I was obviously trying to appear as sentimental as possible 😅. References a bunch of vague stuff like “being vulnerable” and “connection”

Second application felt a lot more real. It was a specific and unique thing I’d just learned about myself while travelling.

What do you want to be doing in two years?

Kinda funny how similar these two are in places! Both talk about building communities.

I feel like the second was more specific and direct. It includes a reference to external viewing material and avoids vague phrases like:

“I want to be working for a company/organization with a strong culture…”

Powerful words… identity shaking, earth shattering words…

Why do you want to attend the Recurse Center?

I think this is where I lost a lot of points.

From my first application:

For the past 4 years I’ve been doing a lot of work with software, but 90% driven by the organizations and groups I was working with.

Not. A. Good. Reason.

The Recurse Center is 100% self-directed. This sentence basically says.

I’ve been coding for 4 years and never built anything in my spare time. I only code when I’m employed.

Compare this to my second application:

Because for the last 5 months I’ve been working on projects in awful environments.

So. Much. Better.

I’ve actually been working on things. By myself.
I’m working in really poor environments. Coming to RC isn’t just about “time to work on stuff”, it’s about needing a better physical space.

What would you like to work on at the Recurse Center?

I listed my ebook building tool in both applications!

The first time I applied, it was just an idea. I also included a bunch of random explanation as to why I wanted to build it.

The second time it was a fairly mature project. I also had specific improvements.
Talking about my desire to experiment with content extraction algorithms also demonstrated an interest in more theoretical concepts. Having a balance between practical and theoretical is important.

I’m not sure if past applications are referred to, but if they are, demonstrating the progress made on my previous idea probably looked good.

Describe your programming background in a few sentences.

My first application contained more than “a few” sentences 😬. It was more like a origin story of entering programming and all the random organizations I’d been a part of.

My second application was much cleaner. A list of specific technologies that showed a wide range of experience.

A+ instruction following 👍.

Have you worked professionally as a programmer?

It’s interesting to note that the first word is the same between both applications, but the punctuation is different.

Application #1: “Yes!”
Translation: “I’m not sure if I’m qualified for RC, so please accept this extra enthusiasm in lieu of reasons for admitting me!”
Application #2: “Yes.”
Translation: “You probably have a million of these to read, so I’ll keep it brief.”

First application had more superfluous details. Second application listed past positions and focuses much more succintly.

Do you have a Computer Science degree or are you seeking one?

In both I just mention my degree, but I love how first Harold also included the exact geographic location of the University.

Final thoughts

It’s easy to laugh about these things now, but being rejected from RC is hard.

In a job application, you might get rejected because of a technical shortcoming.
In a RC application, it feels like a personal shortcoming.

But if you have been rejected from RC, don’t give up.
RC’s own website states that 6% of RCers apply at least twice. I met multiple such people during my batch - they were wonderful.

Keep programming, keep working on side projects and keep striving to be a better programmer.

Looking back, I’m actually glad I got rejected.

Self-directed work is not easy. Learning that skill before going helped me get the most out of my experience. South America was also a much cheaper place to learn than New York.

But I’m also glad I reapplied.

It was an awesome 12-weeks of becoming a better programmer and a better person.
If you’re curious about what I got up to, I wrote up a whole summary.

Now that you understand there’s nothing to lose, maybe you should consider applying! 😉

12 Weeks @ The Recurse Center 🤔

Fri, 27 Jan 2017 00:00:00 -0500

On December 15th, 2016, my time at the Recurse Center came to an end 😔.

Since then, I’ve been home with friends and family who have been asking to summarize the experience.

Did you like it?

Was it what you expected?

Was it worth it?

So to better collect my thoughts and summarize the experience - I’m going to write this post!

Applying to the Recurse Center

When I applied to the Recurse Center I was in Lima, Peru.

My plan for the year had been to travel the world and code (7 months in South America and 5 months in Europe). Live out of a backpack, meet locals, get off the beaten path… all that jazz.

It was fun for a while, but I eventually started getting really burnt out.

Reasons for that included:

Never-ending uncertainty about where I would sleep/eat.
Constant turnover of people.
Lack of people with similar goals/interests.
Lack of settings where I could explore my interests.
Pressure to be continually moving.

I decided I was tired of chasing cities and instead wanted to focus on meeting interesting people and becoming a better programmer. Some options I considered:

Flying somewhere with more nomadic programmers (eg. Southeast Asia)
Getting a full-time job
A conference for remote workers
The Recurse Center

After exploring the options, I decided the Recurse Center seemed like the best fit.

Expectations for the Recurse Center

When I decided to go to the Recurse Center, this is what I was looking to get out of it.

Work environment
- Wifi wasn’t great on the road.
- Hostels were hard to focus in.
- People regularly warned against carrying a laptop in public, which discouraged me from going to coffee shops.
- A city/space with more opportunities to pursue my interests.
People
- Interactions that would last for more than a week.
- Guidance on my projects from more experienced people.
- Exposure to new ideas and encouragement towards personal growth.

Things lacking from these lists:

Dedicated time to program: I took a lot of time while travelling to focus on coding. Being at RC gave me a 3 month block of time to code, but I was already dedicating time to code.
Build/Learn X: While I did come to RC to learn new things, I didn’t have some grand vision for what success would look like. I was mainly looking to collaborate with others and learn from those experiences.

The environment at the Recurse Center

Coming in, I had a certain set of expectations for the environment at RC:

Room full of programmers.
Talk about technical stuff.
Work on technical stuff.
Programming nirvana, please discuss your non-technical interests elsewhere.

This was reinforced by what I read in the RC Manual:

You should be here primarily because you want to become a better programmer and spend the majority of your time here programming and doing things directly related to programming.

Well, we could ask you to be respectful of speakers and keep conversations on-topic in the Recurse Center space during the day (i.e. if you want to take a break and chat about your weekend, go grab a coffee).

That wasn’t my experience of the space.

How I came to see it:

Room full of curious, friendly, wonderful people from all all walks of life.
Talk about technical stuff. Talk about emotional stuff. Talk about what excites you.
Work on technical stuff during the day. Attend events and explore non-technical interests in the evenings.
Educational nirvana, with a primary focus on programming and a secondary focus on everything.

It was the best learning environment I’ve ever been in ❤️.

Best doesn’t mean perfect though. Working at RC was at times inspiring and exciting. At other times difficult and confusing.

Here’s my breakdown of those two sides.

The Hard Parts 😰

Imposter Syndrome

You could probably relate much of what felt “bad” back to imposter syndrome.

Imposter syndrome is normally used to describe people who are doubtful of their programming abilities. My imposter syndrome was more doubting my value as an RCer.

Those people are reading academic papers and reimplementing Raft… but I just want to build silly web apps.

Those people just finished their bittorent clients… but I spent my entire day writing a presentation on Non-Violent Communication.

That person just shared a tech meetup and everyone seems excited… I just shared a concert and nobody wants to go.

The comparisons started making me wonder.

Am I working on what I’m supposed to?

Am I less technical than these people?

Is my presence distracting?

The first time I applied to RC I was rejected. Thinking about that didn’t help calm the worries that maybe I wasn’t a good fit.

Logically, I knew it was silly. RC has lots of other people interested in the same things that I am. I gained a ton from putting my ideas out there and finding others to collaborate with.

But the imposter syndrome was always lurking in the back of my head - ready to flare up if things weren’t going the way I wanted.

People v.s. Projects

People and projects were two opposing forces that took a lot of energy to keep in balance.

Projects:

I have 3 months to focus on whatever I want!

I’m surrounded by knowledgeable people who can give project advice and help me progress.

I need to code as much as possible because I’m here to be a better programmer.

People:

There’s so many interesting people! I just want to talk to them all day.

I can code anytime and anywhere. Being here is special because of all the people around me.

There’s so many things to do in New York and so many curious people willing to do them with me.

I definitely leaned a lot more towards the people end of the spectrum. At the end of my batch I felt so excited about all the interactions I had, but disappointed about the amount of programming I had done.

Other people leaned a lot more towards projects. I didn’t see them at many events, but by the end of their batch they’d built some really cool things.

It was interesting talking to the project people.
I lamented not having accomplished as much as them. They lamented not getting to know more people.

Grass is always greener 🐄.

I don’t regret anything, but it’s definitely a balance I worried about during my batch.

RC Bubble

It’s easy to get immersed in RC.

Coming from Toronto, I didn’t really have any social group when I arrived in New York. If I wanted to be social I could:

Hang out at RC, where everyone is friendly and willing to chat.
Go out to things by myself.

Option 1 was always the easiest/default. But always being in RC would tire me out. It meant constantly talking about projects and programming.

Interacting exclusively within RC also made the relationships feel RC dependent… context dependent.

Sure, we could talk and hang out… but I felt like we were hanging out as RCers, not friends.

People would always be keen on hanging out at RC, or going as a group to do things. It was a lot more rare to hear:

“Hey Harold, I’m hosting a thing and wanted to invite you!”

I fell victim to this too. It just felt easier to put general invitations out rather than try and make time with individuals. It’s also something that takes a while to happen… 12 weeks isn’t a lot of time to navigate all the people and opportunities within RC.

Nevertheless, getting to know people as friends as opposed to batch mates was something I frequently craved.

(Thanks to all the people who did put themselves out there and made stuff happen outside of RC. It was very much appreciated ❤️.)

The Awesome Parts 😃

Learning from others

RC provided so many opportunities to learn from others.

The diversity of experiences meant that whatever you were learning, there was someone who knew it.

People would pair together, answer questions on Zulip and share their favorite resources.
People would organize reading groups, presentations and viewings of screencasts.
People openly talked about their failures, their struggles and their 4 hour debugging sessions.

The whole environment at RC made learning collaborative and fun.

RC also hosted a variety of residents - experienced programmers who were willing to sit down and provide insight on a wide range of topics.

Outside of RC there was all of New York. A bustling city full of interesting events and meetups.

So grateful for all the learning that was shared!

Redefining “Programmer”

Before RC, I had this idea of “tech culture” that I didn’t feel comfortable identifying with.

In tech, I’ve felt like my interactions with others had to be technical or not happen. Asking questions about interests and hobbies drew blank stares. Not knowing about the latest framework or tool meant you were a bad programmer.

Other friends had felt it too. We’d even talk about tech as some other entity we just had to deal with.

The people at RC wiped all those assumptions away.

“Nerdy sweethearts” is how one RCer described the group. Thoughtful, passionate, empathetic and friendly are other adjectives that come to mind… but that’s all pretty vague.

To put it in more concrete terms - “programmer” was redefined for me:

At non-technical talks, when people talked about Brexit or “How did blue/black become the most used inks?”.
During feelings checkins, where everyone would sit and share their emotional state from that week.
At after hour events, which ranged from RCers doing improv together to learning hip hop dance.
On Zulip, where alumni from 2012 still hang around to share and ask advice.
In the homes of RCers who organized potlucks to bring everyone together (and seeing the culinary talents of coding accomplices 😋).

…and so many other wonderful moments.

All moments which were created/proposed/executed by RCers. People willing to put out there ideas, and people excited to support those ideas and run with them.

I once again feel excited to call myself a programmer.

Spirit of experimentation

The curiosity at RC makes it such a great place for experimentation.

Should we do in person checkins? Zulip checkins? End of day checkouts? Try them all and choose for yourself!
Want to try being nocturnal? The space is accessible 24/7!
Interested in academic papers? Start a reading group!
Want to get into meditation? Join the meditation sessions!

Anything you could want to experiment with, there’s a way to do it at RC. There’s also probably a handful of curious individuals willing to try it out with you.

It’s so much fun getting to try all the things!

Being myself

At RC, I felt like I was working on more parts of myself than in any other community.

Any interest I had, there was someone equally curious about it and willing to chat.
Any feeling I was experiencing, I could share without fear of judgement or shame.

It was a pretty awesome feeling.

I should note that it’s something that took time to feel. At first I definitely came in with worry and imposter syndrome:

Omg, these people are so much more socially aware than I am… I’m going to screw this up… I’m going to break a social rule.

Is this thing I’m writing going to offend someone? Did I just say something -ismy? Oh god oh god 😬.

Oh god, I just wrote a blog post that was 90% feels… I’m not programmer enough to be here 😨.

But with each interaction and conversation, I felt more and more at home.

Overall

So…

Did you like it?

YES ❤️

Was it what you expected?

NO ❤️

Was it worth it?

ABSOLUTELY ❤️

The Recurse Center provided total freedom to work on what I wanted. It surrounded me with a wonderful group of people to work on those things with.

Did I become a significantly better programmer?

Not through lines of code, or deep dives into new languages.
But I got to work on all kinds of things that left me feeling like a better person.

And becoming a better person makes you a better programmer. 😊

Thanks to all the staff for all the work you do to keep RC running.
Thanks to all the RCers who invested their energy into making RC such a great place to be. ❤️

If you’re looking to become a better programmer, you should apply.

Week[11] @ The Recurse Center 🏆

Mon, 26 Dec 2016 00:00:00 -0500

Published before the end of the year! What an achievement!

Overview

My time at the Recurse Center is complete. I am both incredibly grateful for my time there and excited to be moving on.

Emotional 😱

Moving Stress
No matter where I go or what I do, transitions are stressful. A sort of impending doom that can’t wait to get over with.

The last week also started loading on the thoughts of
“Have I done enough?”,
“Have I seen enough in New York?”,
“Will I have a chance to say bye to everyone?”.

Gah! Get me to Toronto already!

Defeat
Perhaps as a result of the stress, I allowed myself to feel defeated.

Game over. No coding is getting done this week. Focus on moving, exploring and socializing.

Coding needs a certain amount of mental focus that I just didn’t have. Others seemed to feel similar.

Trip to New Jersey
In 2013, I did a trip to Asia and met a bunch of cool people.

In 2014, one of those cool people (who I met in Japan 🇯🇵 !) was going to be in Niagara Falls. Naturally I bussed down from Toronto to meet up with her.

It’s 2016 and that cool person now lives in New Jersey. I had meant to make a visit, and the last week motivation finally made it happen.

Got to take a little walk around the other side of the water and catch up with my friend.

With all the moving around, I run into a bunch of people and always leave wondering when/if I’ll ever see them again. Encounters like this one (still being in touch with someone I met in Japan 3 years ago) give me hope.

(If you’re reading this and want to meet up, let’s make it happen!)

Circling
@sofiajeanne ran another round of Circling sessions this week. So many people were interested that the groups needed to be split into 2.

I showed up in the morning to find only 3 other people had arrived on-time. We got to have a really nice session with just the 4 of us.

This week I worked on being less protective of others. Being able to speak to my experience and not worry about how it affects others. Letting others have their feelings without the need to comfort them or push them towards other feelings.

Really loved it - so thanks for sharing it with us Sofia-Jeanne!

RC Goodbye/Christmas Party
As with every goodbye, RC threw a party!

One of the things mentioned in the party description was that it would have no dress-code. The example of pajamas was given as an acceptable outfit.

So naturally…

It was nice to have one last night of silliness with all the pals. 😊

A bunch of alumnus were also in attendance, which was super lovely! Was a good chance to say all the goodbyes.

Ended the night at 3am, sitting in a circle, being nostalgic.

Intellectual 📡

Make RC Better Meeting
One of my favorite things at my last company were the weekly “Retrospectives”. They were a time for the team to discuss the past week and how things went.

At the end of the last half, I asked a few people if they thought a reflection meeting at the end of the batch would be useful. Most said no ☹️.

BUT RC ORGANIZED ONE THIS TIME AND I REALLY ENJOYED IT.

The focus was mainly on the first day. I found that a bit strange… RC is so much more than the first day.

One of my realizations from the meeting was that many people wanted there to be more group projects. When I came to RC, I felt very primed for taking ownership of my own learning and doing my own projects. The application process even asks what you will work on. In a way, knowing what you want to work on is a criteria for getting in.

So with that, I had not been thinking about group work.

Some interesting ideas passed around about how to get more long-term collaborations. Hopefully that gets integrated.

Non-technical Talks
On Monday, there was another round of non-technical talks.

I had been really interested in presenting, but when Monday rolled around I felt totally unprepared. I took my name off the list, felt bad for not giving presenting one more go, put it back on, took it off. Bleh.

Shouldn’t have spent so much time hanging out with people!

Job Interviews
This week I had some job calls. In retrospect, I really wish I hadn’t started getting in touch with places. Having to take calls and practice for interviews during the last week was very stressful.

Niceties
As with the past outgoing batch, everyone took some time this week to write nice thoughts for each other. This was WAY more time consuming than before. Mainly because:

There was now 2 batches worth of people to write messages for.
Having spent more time with people, there was much more to write.
After spending 12 weeks with people, I had nice things to say about almost anyone. I needed to actively stop myself from getting it all out (so if you didn’t get one from me, it’s not because of 💔 - just had to stop after 4 hours of writing. Hearts for you! ❤️).

Logging “Experiments”, “Activities” and “Events”
When I first got to RC I did not expect how welcoming, open and supportive RC is. The breadth of events/activities/traditions/experiments/whatever you what to call them - it’s ridiculous.

Unfortunately, I couldn’t find a comprehensive log of all the things that had been done at RC.

So now that my last week of RC is complete, I’ve been trying to create that log. Within the RC wiki, I’ve been creating new sections for highlighting all the things that happen at RC.

Really happy with how things have turned out, and hope others get inspiration from seeing the history of events.

No Coding
As hinted to above, got NO coding done this week. That was a bit sad 🙁.

Physical ⛳️

This has been the most useless section. I neglect my health so bad!

…I guess I danced a bunch at the social
…and finished most of my groceries
…so those are things.

¯\_(ツ)_/¯

</End>

So there you have it! A rough, incomplete and angsty summary of my time at RC.

It’s been a time writing this log.

Much love to all the RCers who helped me review it at some point or another. Definitely gone mad overthinking what I should write some weeks.

I’ll go through all the posts and create some sort of Return Statement.

RC has definitely been one of the coolest things I’ve ever been a part of. The people, the projects, the space.

So with that, I’ll sign off one last time! 👋

Much love everyone, it’s been a blast 🚀❤️!

Thanks to @vaibhavsagar for providing updates via PRs 😊.

Week[10] @ The Recurse Center 🌈

Wed, 21 Dec 2016 00:00:00 -0500

(It’s currently December 21st! I’ll be trying to backfill using my daily log. Where has the time gone?!)

Overall

The end of the batch is nearing. I feel both pressure to do all the things and apathy for doing all the things. What a combo!

Emotional 🥕

Batch Gift Angst
There were a few things this week that stressed me out. The first was the batch gift.

It’s a tradition that every batch gets a gift for RC. I was aware of this, but didn’t feel like gift planning was something I wanted to get super involved in.

Luckily, a fellow batch-mate picked up the job of rallying people to brainstorm gifts.

A bunch of ideas were thrown around (I suggested Emoji pillows 😂), but there was nothing that everyone agreed on.

Attempts were made at arranging a meeting, but they were too last minute and people weren’t RSVPing. Gah!

I figured that it was hard to vote in a chat thread. I decided to gather all the ideas and take a poll. I started reading the ideas to do so, but it quickly became too stressful. All the serious ideas were mixed in with ridiculous (or so I assumed…) ideas.

I pictured trying to sort through and having to decide what was “serious” vs. “joke”. I got frustrated by the extra work that would be involved because people weren’t taking it seriously. So I just gave up. That was bleh 🙁.

Eventually people gathered and we figured it out.

Disclaimer: I proposed some jokes too… oops!

Dinner Party Angst
The second thing was a dinner party.

It had been planned a week back and a few people had RSVPed. The day of, I was doubtful that anyone was going to show up. Nobody had really said what they were bringing and only a few people still seemed engaged.

I kinda wanted to flake. Say screw it. I didn’t want to do all the prep work if it was potentially just going to be me and a couple others.

Luckily @hsubox joined forces with me and we decided to commit. Jennifer went and grabbed a bunch of supplies so we could cook/bake (thank you!). We ended up having a good time baking up a storm. I posted baking pictures on Zulip to reassure any other potential doubters that things were on.

We ended up going and being greeted by a swarm of people. The dinner party was awesome. Worries were unfounded. Yay! 🎉

Passiveness
With only 2 weeks left, I was feeling very passive towards work. I felt drawn towards socializing and checking off some end of batch plans… so I did that.

Did a bunch of social stuff this week. Time with RC people is running out - so why nawt!

Firepit
Dinner Party @ RC
Glassroom
Circling
Board games
Cleaning party
Visit w/ @spiside

The RC dinner party was a lot of fun… I’m a sucker for dinner parties (something about a group made meal shared amongst friends makes me 😍).

Dinner partying it up @ The Recurse Center 🍽

Circling
Circling was another really unique experience. You can think of it like group meditation.

Everyone sits in a circle and shares their experience of the moment. As people share, thoughts and feelings start to bubble up which then feed into the discussion.

The experience didn’t strike me as particularly enlightening at the time. It wasn’t until the following days I noticed how much it affected me. Suddenly I felt much more aware in my interactions. I also became likelier to vocalize my feelings while interacting with others.

Sooo now I’m hooked and will be seeking more when I return home 😊.

Intellectual 🌶

R0ml
This week was the last week of R0ml’s residences. His speeches are very much geared towards stirring the pot and getting people to question their assumptions.

During Monday’s talk he discussed anti-patterns. In particular, the following were some of the things described as anti-patterns:

Having code in separate files.
Build pipelines.
Interpreted languages.
3rd party libraries.

It was interesting watching everyones reactions to the talk. Some people were really frazzled. R0ml has a conviction while speaking which is hard to argue…regardless of whether you agree.

Also had a good chat with R0ml about the future of programming education.

His main idea was that we are wasting our time teaching people to code. There’s already tons of code in the world and there’s people always writing more.

What the world does need is people to combine existing software in new and interesting ways. People who can submit bug reports and small code fixes.

Sure, some coding is necessary for that - but in general its a different skill set then teaching programming from the bottom up.

Testing time
I love testing.

Over the course of my batch, my testing pride brought people to me asking testing related questions. Many people were very confused about how to test, what to test, when to test, etc..

I don’t blame them.

Writing a test suite can feel like a completely separate project. Technically it’s not even necessary. Sure a good test suite can make your life 100x easier, but it requires an upfront investment of time.

I don’t think this is a problem with the materials. There’s lots of GREAT content for learning about testing and TDD. If anyone wanted they could do a google search and find relevant tutorials.

What there isn’t a lot of is people who are excited about testing and willing to push others to start. I only got into TDD because I pair programmed with some awesome people who showed me the way. Before then, I was happily writing out code without a worry for whether it was tested.

With time at RC running out, I decided to run a collaborative work session called “Testing Time 🕑”.

The plan:

People would bring existing projects they wanted to test.
I’d provide a bunch of testing related “challenges” that could be applied to a variety of projects.
As a group we’d work through the challenges and learn by doing.

There was a reasonable amount of interest. Some people came and only stayed for the talk. Others stuck around and did the collaborative portion. I had a lot of fun helping people setup linters and get their test suites up and running.

I like to think it helped people chip away at their testing fears.

Haskelling
I worked through more of the NICTA course. I managed to finished Functors and Applicatives… less than I would have liked…

But socializing!

Resume review & job applications
One of the under appreciated aspects of RC is the career guidance.

This week I had Nancy review my resume. It was encouraging to get feedback from someone who has seen a lot of tech resumes.

She gave some good feedback and I spent part of the week trying to clean it up. Felt very torn between:

RC is for becoming a better programmer. I can do this when I get home.

and

I should really get on this so I’m not running around last minute looking for jobs.

Who knows ¯\_(ツ)_/¯.

Physical 🍿

Sick
Been noticing that even small amounts of alcohol at RC social events have left me feeling sick.

It’s extra crappy when it happens on days where I slept in…
and an RC social event is in the afternoon…
and I get no work in before having a beer and getting a horrible migraine 🤒.

No more drinking!

Living off limited groceries
With the batch coming to an end, I’m trying to be aware of all the food I need to finish.

I always find myself hesitant to grocery shop when I’m staying somewhere short term. It surfaces worries that I won’t be able to finish whatever I buy.

In practice groceries are WAY cheaper and not that hard to finish. But even leaving a few $2 bags of pasta unfinished gives me angst!

So gotta chow down before leaving.

</End>

Did it! Another week done.

These have been exceedingly harder to write as time has moved on.

Maybe it’s the thought that I’m being boring…
Or the worry that I’m holding back in person and then revealing way more in this blog…
Or embarrassment for not having more done…

In any case, I think it’s been a good experience. One of my more uncomfortable pursuits.

One more to go! ❤️

Week[9] @ The Recurse Center 🔎

Thu, 08 Dec 2016 00:00:00 -0500

Overall

I’m currently trying to distill through what is essential, and focusing on that. Stripping away the excess has left more energy for the important pursuits.

Emotional 😰

Frantic
Feels have been evolving recently, but at the moment I feel frantic. There’s now only 2 weeks left.

Looking back, it seems like I got more done in the first half…
So far I’ve done a bunch into Haskell but haven’t made progress on any projects.

I’m disappointed that I haven’t built some “Pièce De Résistance”. I’ll have completed all the Haskell resources, but typing out function definitions isn’t that gratifying.

I feel frantic to build something in the next two weeks that will prove I’m a better programmer. A DRASTICALLY better programmer.

This desire has kept me constantly working.

It’s 9pm… but I don’t feel accomplished. Gah! Stay later, work longer, we’ll be drastically better soon.

Maybe if I went back 3 months, the improvement would be more obvious. I feel drastically better than a year ago, but it’s hard to know how much of that has come from RC.

Anyway… I’m frantic to feel accomplished, and it hasn’t hit me yet. 😓

Cookies and Blanket Forts
On Saturday, some housemates and I baked cookies! Turns out the house had all the extra ingredients I bought… oops!

In addition to cookies, we also constructed a blanket fort. The cookies were then consumed in the blanket fort while watching a movie. It was glorious:

@hsubox & @NEIA20 critiquing the cinematic qualities of “Finding Dory” in “Chateau Del Sheets”

Weapons of Math Destruction
On Thursday I went to a meetup hosted at Postlight.

I was partly motivated to go by the talk, and partly motivated to learn more about Postlight. I got a chance to talk to some employees about their projects, a few of which had overlaps with what I’m working on. The rumors of it being an interesting company were true.

The main event was a talk by Cathy O’Neil on problems arising from the use of Big Data. It was really scary to hear how algorithms can obfuscate problematic systems. Looking forward to reading her book - “Weapons of Math Destruction”.

Intellectual ƛ

Changing Project Plans
When I first started reading up on Haskell, I was really interested in using it to build a javascript code generator. Pattern matching and types made it seem like a good fit for the task.

After finishing my Haskell course, I felt differently. I was still interested in that project, but my understanding of Haskell still felt too fresh to be really productive on a project. I also was worried the project would involve more Javascript grammar definitions than actual coding.

Instead, I want to continue improving my Haskell knowledge. So rather than start a project, I’ve begun working on a second Haskell course. (For those interested, it’s the NICTA course)

One of the main features of the course is a test suite, which I LOVE. Why can’t every course just be a bunch of unit tests to fix 😍.

Doing another course doesn’t feed my need to accomplish a big project while I’m here - but I can build a project in Haskell after RC.

Interview Preps
This past week I did 2 interview prep sessions. These have been super helpful.

I’ve done interview prep with friends in the past, but nothing to the level of detail done at RC. Since first starting interview prep at RC, I’ve become much more systematic in my whiteboard interviews.

Some things I’m trying to do:

Restate the problem
Write down assumptions
Write out an example input and output
Brainstorm out loud possible solutions and write them down (noting the tradeoffs)
Write out the API for my code (eg. “I’m going to write a function X that will accept an object with properties a, b and c”).
Be as verbose as possible with any doubts getting me stuck. Ask questions.
Create test cases and walk through the final implementation.

This is way better than my previous strategy:

Code a solution while being as verbose as possible.
Walk through it if the interviewer asks you to.

Advent of Code
I’ve passively been working through Advent of Code. It’s an Advent Calendar that hands out difficult coding problems instead of delicious chocolate.

It’s fun, and many people are doing it which has lead to good discussions. On the other hand, I’ve been feeling less enthused about random coding problems. I’m more interested in working on projects.

Essentialism
I’ve started reading “Essentialism: The Disciplined Pursuit of Less”.

Ironically, I think reading about time management is non-essential - but I’m going to put that aside and pretend it’s the book teaching me that 🤓.

In the past week I’ve been thinking a lot about what is essential. Sometimes I think of things to strip away, without any immediate idea of what to replace them with. My plan is to fill a lot more of my time journalling and meditating.

Physical 🚶

Park walk
On Sunday I went for a walk through Prospect Park with some housemates. It was nice to be away from computers and technology and just stroll about. Fresh air always makes me feel better.

Blob
Days on end of sitting at a computer is really starting to make me feel out of shape. REALLY looking forward to settling in somewhere and being able to do a better job of focusing on my health.

</End>

Woo! We did it!

While I may not be feeling like a massively better programmer at the moment, I sure feel like a much better person.

I was thinking about how much time I’ve invested in blogging and reflecting. It can be exhausting having to reflect on every week. At the same time, I’m excited to have this log to look back on. It’s super interesting seeing all the ups and downs I’ve felt throughout the batch.

Thanks for reading ❤️.

Thanks to @vaibhavsagar and @stanzheng for providing this weeks round of blog feedback.

Week[8] @ The Recurse Center 🦃

Fri, 02 Dec 2016 00:00:00 -0500

Just another week late post! No. Big. Deal. 😁

Overview

A lot of recovery from the Hackathon. RC was also closed most of the week for Thanksgiving, so not as productive as usual.

Emotional 😩

Apathy
This has become a big feel:

“There’s no point…”

Here’s how it goes:

Outgoing Me: “I should ask X to do Y.”

Apathetic Me: “There’s no point. I don’t know X that well / They probably won’t want to do Y / They will be too busy.”

Outgoing Me: “Who cares! How do you know? You want to, so try!”

Apathetic Me: “…I only have 3 weeks left. It’s not enough time to significantly improve my relationships with anyone / I should be focusing on coding.”

That’s been bothering me.

I’ve been really enjoying coding and do want to give that more energy…
But I’m also in this new city with cool people… maybe I should leave the coding for when I’m at home…

Deep down, I know time with people is what I really want. When invitations come my way, I happily drop what I’m doing to hang out. But when I start thinking about initiating that time myself, that’s when the stories of “Coding is more important” pop-up.

Nervousness and Fear
I was reading books to try and better understand my apathy and came across an idea that clicked.

Apathy is a defense mechanism. It’s a way of avoiding what we’re afraid of.

It rings true for me. The things I want to do make me uncomfortable.

But I don’t want to acknowledge that discomfort (thinking of myself as fearless and in control is way nicer 😎).

So instead I deny it.

Apathy = Fear + Denial

It’s not that I’m afraid.
I just don’t care ¯\_(ツ)_/¯.

Since starting to ponder this I’ve been better at noticing it and acting anyway.

Chill time with friends
Despite my apathy, it’s been really nice getting opportunities to hang out with people outside of RC.

On Monday, I finally got to see a friend from my Microsoft Intern days.
On Friday, I went with some other RCers to a board games cafe.

Hearts for low-key socializing! ❤️

Potlucks and parties
Thanksgiving caused RC to be closed for the majority of the week. A bunch of us aren’t from New York / didn’t have plans, so @ebb-tide hosted a Thanksgiving potluck.

It brought me back to my dinner party days in Vancouver.
Tables full of food and drink. Couches to snuggle up on. Wonderful humans to talk to.

Was so full of gratitude and happiness the whole evening. Gah! 😍

Wednesday there was a smaller gathering. It was nice being with close pals and also meeting some people from outside the RC community. 🙂

Such a lovely mélange of socializing this week!

Intellectual 🔮

Building communities
I had a lot of great conversations throughout the week about “What comes after RC?”.

Another idea that’s had me excited is starting a coliving space. I spent most of Saturday:

Asking people about past experiences with coops/coliving.
Researching existing coops/coliving spaces.
Aggregating lists of resources.
Debating ideas with friends.

I’ve started looking for spaces to visit or apply to. One consistent piece of advice was to give it a try before diving in.

Nevertheless, questions around community building have been fascinating me and it seems like a stream of enthusiasm worth following.

How to spend my time?
Another question I’ve been pondering is “How do I want to spend my time?”.

My one approach to making time decisions, is:

What are my goals? Is this the most impactful way to move towards them?

It’s interesting how this changes the way I spend time.

One example:

I used to read a lot online. In fact, EpubPress was created to help me manage my intake of reading material.

Quora
HackerNews
Newspapers
etc.

I’ve since realized the majority of what I read isn’t immediately useful to me.

“How we scale @ {insert_startup}”
Ooo! How DO they scale? 😱

I don’t know… but why does it matter? I see no need to create a hyper growth system any time soon. If I ever do, I’m sure there’s better resources than something from HackerNews.

“Introducing {insert_generic_word}. A simple, elegant and intuitive JS framework”
Ooo, I write Javascript! I haz need for this 😱!

No you don’t, Harold. You’re in no need of a framework… in fact, nobody writing Javascript needs another framework.

I’ve generally found this value has pushed my time towards more fulfilling activities.

Haskell Progress
The other day I finished my CIS194 course! 🎓

By the end of it, I really started enjoying Haskell. It’s so different from Javascript and required learning a whole other set of concepts.

I think it was the right choice 😊.

Physical 🛌

So much sleep!
The Hackathon last week in addition to the night-owling really messed up my sleep schedule. On Wednesday night I got home at 3am and cooked myself dinner…

Getting things back on schedule so I can live a more normal life again. @hsubox also found me a pillow, so goodbye pillowcase stuffed with sweater! 😁

Pending baking fiasco
I cooked Chicken Parmesan again last week!

I also bought 2.25 kilograms of flour a month ago because my Eggplant Parmesan recipe called for a 1/2 cup of flour…so I’m currently rolling in excess flour.

Decided to just go all in and buy a bunch of cookie ingredients. So hopefully no wasted flour! Look at me, making sure none of my $2.50 bag of flour is wasted by buying an additional $10 of ingredients. #Smart 🤓

</End>

Done! Made it! Fantastic!

Action items:

Wake up to what an opportunity these next few weeks are. Make the most of them!
Keep reshuffling time towards better priorities.
Bake five-dozen batches of cookies.

Can’t. Wait.

Hearts for you dear reader! ❤️

Thanks to @vaibhavsagar and @yuliaju for easing my blogging worries through feedback.

Harold Treen

Contributing to prettier-atom 💅

What is prettier?

What is prettier-atom?

Finding issues with prettier-atom

Opening an issue

Collecting debug information

Analyzing profile information

Optimization 1: Removing toConsumableArray

Optimization 2: Lazy loading lodash

Submitting a PR

Takeaways

Contributing to redux-saga-tester ⚛️

The "Contributing to {project}" Series! 🎉

Contributing to redux-saga-tester

What is Redux?

What is redux-saga?

What is redux-saga-tester?

Finding issues in redux-saga-tester

Fixing the issue and opening a PR

Updating the README

Takeaways

Debugging A Passive Aggressive Server 🤖

Enough is enough

Talking to friends

Reaching out to others

Better debugging ™

netstat

mtr

tcpdump

netcat

iptables

sshguard

Issue Solved 🎉

The moral of the story?

Two Months Of Tech Interviews 💼

Interview prep

Resume cleanup

Sending applications

Interviews

Interview challenges

Interview highlights

Offers

Some notes for past me

Thanks

Applying to the Recurse Center...twice 💌

Diffing my applications

Code CracklePop

Please link to a program you’ve written from scratch.

What is the most fascinating thing you’ve learned in the past month?

What do you want to be doing in two years?

Why do you want to attend the Recurse Center?

What would you like to work on at the Recurse Center?

Describe your programming background in a few sentences.

Have you worked professionally as a programmer?

Do you have a Computer Science degree or are you seeking one?

Final thoughts

12 Weeks @ The Recurse Center 🤔

Applying to the Recurse Center

Expectations for the Recurse Center

The environment at the Recurse Center

The Hard Parts 😰

Imposter Syndrome

People v.s. Projects

RC Bubble

The Awesome Parts 😃

Learning from others

Redefining “Programmer”

Spirit of experimentation

Being myself

Overall

Week[11] @ The Recurse Center 🏆

Overview

Emotional 😱

Social 🎉

Intellectual 📡

Physical ⛳️

</End>

Week[10] @ The Recurse Center 🌈

Overall

What is `prettier`?

What is `prettier-atom`?

Finding issues with `prettier-atom`

Contributing to `redux-saga-tester`

What is `redux-saga`?

Finding issues in `redux-saga-tester`

`netstat`

`mtr`

`tcpdump`

`netcat`

`iptables`

`sshguard`