Dimes, demons, and desperation

Note: I'm currently publishing pieces from my vault. This was supposed to be published on 2016 July 31 when I was on the fence about dropping out. In the end, I didn't.

Buzzword sandwich

1. n. a carbohydrate-rich environment composed of "virtual reality", "startups", and a bunch of empty space in between

2. n. where I currently find myself in

It's been three days since I left academia for money and I've already seen a lot of improvement in my skin tone. Doctors hate me now! Kidding aside, it's my first time in this dog-eat-dog industry and my team and I are definitely not past the Great Filter for Startups yet ¹. I have been a reader of HN for more than half a decade now so I'm kind of cheating here but as with all fields, the gulf between theory and practice can go on for miles.

The Highs

Everything I do in the office feels like productive work. From distributing shares (in a three-person team) to the cleaning of the all-powerful whiteboard, every little thing hides a rush rarely seen in timid environments like, say, in front of a chalkboard. Everything is new and learning feels like doing something, but it is difficult to hide the gnawing behind me that it's all a temporary farce that pulls me away from the Important Stuff like actually creating value. Still, it ain't so bad to enjoy oneself every once in a while.

Some observations:

• When what you do is measured in $$$, you tend to feel the loss of your time (e.g., coding what you did not know has already been done) more painfully.
• It is easier to be honest with yourself about what you can and cannot do. Yes, this means you have to face the latter more often but it also makes it easier to extend the former. I.e., it's a Double-edged Sword.
• You will have ideas that sound good. Some of them you will be able to test and some will even pan out. But you will only be able to give birth to a tiny fraction of them. Thinking is much, much faster than making.

Confessions of a green coder

Prior to this, I've never been part of a large coding project. And when you're as bad as me upon entering this rat race, you are going to want to catch up pretty soon. If you're like me, the best way to do that is to try and jump a couple of levels up the Dreyfus model²: from novice to competent in one fell swoop. How do you do it?

The problem with this approach is that it's a textbook example of cargo-culting. Mr. Feynman has really done a lot for us by giving this thing a name and it is what it is. A game of pretend, of blindly copying the advice of many years of software engineering experience distilled in a couple of lines on Stack Overflow. I don't even know at this point what singletons can help me with but it sounds like a good idea so let's do it, this kind of thing.

When you're googling "best practices" for everything, you tend to climb up the abstraction elevator³ without knowing which floor you really want to go to. And this freezes you because there are so many possible abstractions that you can decorate your code with and you don't really have the intuition to decide which one to use, let alone if you ought to use an abstraction at all. The net effect of this is that you go farther and farther away from what's important, i.e., creating something that works.

That's Lesson #1. The razor of all philosophical razors. The way of the void. If you learn anything from shoveling the sludge of software engineering advice, let this be it.

Chromesthesia

The hackathon is probably the most overdone team-building activity for tech companies out there. So it's a no-brainer for us⁴ to join one.

The first few hours of a hackathon will probably feel the most productive. My team and I set up this sticky-note-like system very roughly inspired by Jared's Scrum implementation in Silicon Valley⁵. We had six boards and a flow that went like this:

1. Notes and reminders, mostly used for sharing IDs and the idea description
2. Milestones, which in retrospect was full of fluff
3. Things to implement, a feature request board
4. Bugs to squash, self-explanatory
5. Tasks, which had features or bugs that were being currently worked on
6. Completed, which had to be beautiful by the end

(If you were wondering, no, we didn't bring six physical boards with us. We used Trello.)

The way we allocated tasks was to assign colors to everyone, make them colorise the notes under Things to implement or Bugs to squash using their assigned color, and move said tasks under Tasks. Hence the quip about beauty. You might be wondering though, why color? Color is evil. It's not C-f or C-s searchable and it reminds us of those people who used six to n highlighters when taking notes back in uni. One of the first principles you must learn in code sprints like this is:

Always pick the simplest thing that works.

Hold your applause. This is a standard, internet-tested, Good Thing slogan so it's hard to actually pause and think about it before moving on. All general advice is mostly useless and this one's no exception. So let's make it more specific. What do we mean by "simple"?

People brandish "simple" as if it's immediately obvious to everyone what the simple thing to do is. Most of the time, you describe something as simple only after the fact and only if you understand enough of the underlying principles that it is possible to appear simple to you. In other words, you have to be ready for simple. So suppose you did your homework and know all the relevant bits. Here's an expanded view of how we decided the color issue:

We have a set of tasks. We need a quick way of showing who's responsible for what. We could go with colors or labels. For sets of a few well-defined elements, it is quicker and easier to distinguish by color than by label. Hence, color it is.

Decisions like these happen at the speed of thought. Sometimes you think of two or three approaches, sometimes none. But the process is clear: your purpose should tell you what's simple. And in a hackathon, your purpose is to quickly make something that works. So trust your gut and choose -- technical debt be damned!

Two bottles of wine

It's a sad world we live in that people cheat during hackathons⁶. It's even sadder that me and my team also did. Why?

• We brought a VR headset, thereby cashing in on a trend.
• We made some of our models beforehand.

I might be naive but the second one is particularly insidious. Hackathons are where you flex your fast-twitch mental muscles prototyping as fast as you can. So I was stuck between having to argue our only artist away who insisted on making his models beforehand or accepting that the primary reason we joined was to improve our teamwork. I chose the latter. Sorry.

It was a classic case of "Everyone is doing it, so why shouldn't we?" Now compare "No one else is doing it but us." and you'd be disappointed at the level of doublethink people are willing to sustain to stay optimistic in a startup.

I'd have to share some of the guilt here however. I dabble in the Dark Arts. If I believe that a point must be made, that it is of absolute importance that my team takes to heart what I am saying, despite all considerations of integrity I am willing to use fallacious arguments to get there. My bullshit reason so that I don't think about it too much? I don't actively promote rationality in my team because being only-sorta-rational is at odds with being in a startup. There's a region in the range of rational ability where you'd balk at the level of risk you're taking if you're in one. So you have to embrace it fully or it will be your death.

There, I said it. Sorry.

Note: After some thought, I realised it isn't right to feel this way. Cheating put me in a really bad mood, I caught a really nasty case of cognitive dissonance and it bled out here. In the end, I think it didn't really matter that I didn't stick to my guns (partly because we only came in third place anyway) but I still kind of wish I didn't make as big a moral concession.

---

Definitions

• Dark Arts

  exploiting the wonky ways in which the human mind works for one's benefit

• Double-edged Sword

  the phenomenon where seeming disadvantages become advantages in a different situation, and vice versa

• HN

  Hacker News

« The land after time I have no idea what to say »