Close enough is close enough


I used to estimate too precisely.

Like anyone, I do a lot of estimation: how long a work-project will take, how expensive a trip will be, how long it will take until I feel confident about my tennis-serve, and so forth. 

For work-projects, I used to say something like: "Based on estimates for the sub-tasks, it will take exactly 26 days."

There were two things wrong with that. 

First, people are _really bad_ at estimating, especially when the variables get complex. How can I predict that we'll discover a rare-but-urgent edge case that adds a week to the project? Or that someone will get sick?

So maybe I need to be less precise. Maybe instead of "26 days," I need to give an estimate of "around a month."

But what about those ~four days that we've glossed over? 

Most of the time, they don't matter. My audience (manager, product manager counterpart, etc.) doesn't need or care about that level of precision. 

So that's the second thing wrong with my example estimate. In addition to being impossibly precise (emphasis on "impossible"), I didn't consider how precise I actually needed to be.

These days, I like to start by asking: "how _imprecise_ can I be for this estimate?" In many cases, that means to the nearest order of magnitude, or identifying if it will take days, weeks, or months.

Following that approach, I can be far more accurate. And what's more: I can avoid the many-flavored stresses of false-precision. 

Find problems, not solutions


Software is a solutions-oriented business. It's what we do: ship solutions as quickly as we can. But one common pitfall is jumping to solutions before defining problems. 

It seems obvious to say "start with the problem." But it's easy to forget when you are in the thick of solution-mongering.

My manager reminded me of this a few weeks ago in a specific context, and it was a great help.

There are a lot of benefits:

- **Problems explain "why?"**
Problems provide a shared sense of purpose in a way that solutions do not.

- **Problems provide a north star.** 
Starting with a problem asks the implicit question: "Does your solution actually help?"

- **Problems allow for creativity.** 
Two people can look at the same question and see different answers. By sharing the problem, you might learn of new solutions.

- **Problems promote ownership.** 
It's more inspiring to get problems to solve than solutions to implement.

Some examples of where this can help:

- **Defining a new role:** start with what problem the role will work to solve, not what duties it will do.

- **Making a process change:** start with the pains of the current process, not what you want the new process to be. 

- **Creating a new initiative:** start with what problem the initiative tries to solve, not what projects you plan to implement.

Learning to accept intermediary imperfection.

Sand in the box, then castles


For the longest time, I couldn't bring myself to start writing a novel. 

Don't get me wrong. I _want_ to write a novel. I've got an informal checklist of things to accomplish during my lifetime. Writing a novel is on the list.

No, I couldn't begin writing a novel because I was worried that it wouldn't turn out well. That it would validate deeper fears about the quality of my own writing. That it would cross me off some cosmic list of potential authors. 

I admit, these are silly fears. But I suspect they're not uncommon.

A little over a year ago, I gave myself a push—I joined a writing group and kicked off a draft of the book, fingers crossed that it would turn out well. If I were lucky, at the end of the process I'd make a few copy-edits and send it off for publication.

Well, I've written most of a draft now and that won't be happening. It's definitely not publishable in its current form.

I realized this early on, maybe halfway through the draft. Character arcs are half-developed. Some of the world-building needs deeper thought. It's readable, but not what I'd hoped it would be. Facing that was tough, and I was very tempted to quit. I had failed, right? 

Fortunately, my writing group gave me just enough motivation to question giving up.

So I googled. What did other authors have to say about first drafts? How the heck are you supposed to write these things, anyway? Doing so, I ran across a quote from Shannon Hale. It went like this:

> "When writing a first draft, I have to remind myself constantly that I'm only shoveling sand into a box so later I can build castles."

I was very taken with that. It was a way to understand what I was doing and view it as productive. Incremental, even.

I think that's the trouble with huge undertakings. They take a long time to resemble what you envision. When the intermediary stages are messy and progress is slow, it's easy to be discouraged. For me, viewing the mess as—well, not just "okay", but _good_. That was a crucial shift in mindset.

I had a similar situation at work, actually. We're starting to re-architect a huge, ancient piece of code. It will likely take months or even years. And I found that it inspired in people similar concerns that I had when I started writing the novel. What if...what if we draft up a re-architecture and it's not great? How should we view early brainstorms during this process?

Again, it was helpful to emphasize: sand in the box now. Sand-castles later.


I was annoyed that my typing was slow, so I taught myself to touch type. And what a change it's been.

Touch typing is worthwhile


Until a few years ago, I was a point-and-peck typist. It wasn't too bad, I thought. Sure, I made a lot of mistakes. And I had to stare at the keyboard when I typed. But with years of practice, I could putter along at a decent speed. Maybe 30-40 words per minute?

We were taught touch typing in school, but I didn't pay attention during those lessons.

Later on, coworkers would tease me good-naturedly about it: 3-finger point-and-peck is not a graceful maneuver. Though in some ways, it was a point of pride. One coworker exclaimed: "how do you even do that so quickly?" It's fun to be different.

But many of the things I love require typing: notably, writing and programming. Both of those also require a lot of thought, which was the trouble.

Point-and-peck takes a fair bit of attention. Attention I could be giving to my writing or programming. I forget the exact breaking point, but eventually I got fed up, frustrated that I kept losing my train of thought.

I wasn't sure how much better touch typing would be, but it was worth a try.

The principle behind touch typing is obvious: smaller motions can be done faster. Taken further, this feeds into some pretty cool ideas, like Dvorak keyboard layouts and Vim-style interfaces. But I just wanted to learn touch typing for now.

No problem. I glanced over some finger charts and typed out some sentences. I immediately found that my typing was...much, much slower.

I was convinced touch typing could let me go faster, but first I needed some practice.

Problem was, touch typing was way too slow for writing or programming. So I looked for some way to practice that didn't involve "composing" the text.

Typing tests were perfect for this, but it's boring to type the same passage over and over. So I found [Key Hero](https://www.keyhero.com/free-typing-test/), which uses a random quote as the target passage. Once I found Key Hero, it was just practice, practice, practice. I spent about 20-30 minutes a day doing the tests. 

Admittedly, this is an effective strategy if you want to feel like a giant nerd. But it also had an incredible effect on my touch typing. My WPM (words per minute) shot up, and I found myself "slipping into" touch typing, even when programming. 

After a month of this, touch typing felt faster and easier than point-and-peck. My WPM was 50-60, faster than it had ever been. And it's only gotten better since. Now, I exclusively touch type. 

Cool, stats. But, unless you're a competitive typist, what's the point? Simply put: I'm a better writer and a better programmer because I learned to touch type.

Sure, those things are hard to quantify. But let me explain.

The most obvious reason is that it shortens the time between my thoughts and the page. And in addition to being quicker, touch typing requires less active thought than point-and-peck, so it's easier to focus on...whatever I'm thinking about. 

As a result, I've written more and been happier with my writing. It's also far less frustrating, since I don't need to circle back on a train of thought I've lost (as often). I'm writing a novel now, and I can't even imagine how hard that would be with my old style of typing. All of those benefits apply to programming, too.

I'm not the first person on the Internet to make these observations. But seeing the effects in action has been mind-boggling.

And there are other perks. My meeting notes can be as detailed as I want, and I can stay more engaged with the meeting while I take them. Not the raddest claim I've ever made ("oh cool, _meeting notes!_"), but I do think it's made me more effective at my job.

And finally, when I'm typing I can look wherever I want. I've spent much of the time during this post looking out the window, since it's bright and sunny today in San Francisco. I think a sunny day is a nicer thing to look at than a laptop keyboard. 

Your mileage may vary. But typing is the lowest-level, most fundamental way you will interact with text. Everything else builds off of it. And given how much text I create, touch-typing is one of the best skills I've ever picked up. Worthwhile and more.

People are often surprised by my background. Here's how I took an untraditional path into the software industry.

From english major to software engineer



I studied English as an undergraduate, but since then I've taken an untraditional path into software engineering. Years later, I'm working as an Engineering Manager at Yelp. 

I've heard everything from curiosity to scorn when people learn my background. 

I'm writing for the curious, to share how I changed from one career to a very different one. I'm also writing for those who are considering a similar jump. Hopefully my story sheds some light on the road ahead.


#### English Major

I majored in English for the usual reasons. I like reading, writing, diagramming sentences, and picking apart complex narratives. I wanted to learn more about those things. And at eighteen years old, I was not particularly concerned about the future.

As graduation approached, I realized that in order to make money, I would need a job. So which job?

#### Law

Law seemed like a good fit. It's meaningful and interesting work. There is plenty of reading, writing, and picking apart complex narratives.

But becoming a lawyer means law school, which is expensive and itself requires the LSAT. And the LSAT takes months of study in order to do well. I needed time to scope out the industry before committing all that money. 

So I became a paralegal. I worked at Cadwalader, Wickersham, and Taft (CWT), which is a very old, very large, and very traditional law firm. If you've heard of BigLaw, that's CWT.

I had a productive first year at CWT. I got the LSAT score I needed, I secured some strong recommendations, and I feel like I got an excellent window into the industry. 

After all that, I was dismayed to admit: I didn't want to be a lawyer. While I liked many of the people I met at CWT, the lifestyle of the profession didn't appeal to me at all.

As someone who self-identifies as "quirky" at minimum, I felt like I would need to drastically alter my personality to suit the profession. Even more frightening: I thought I might be capable of doing that. What a terrible fate.

Back to square one. My paralegal job felt like a dead-end and law school felt like an expensive mistake. What to do?

#### Learn Everything

While continuing on as a paralegal, I tried to learn everything I could about other industries. Maybe one of them would stand out.

After a few months, my friend said to me: "You like linguistics, right? How about you try programming in Python. There are lots of cool linguistic applications for Python programming." 

I'd never programmed before, but...sure. Why not? 

So at 23-years-old, I wrote my first line of code. And let me tell you, when I saw "hello world" printed in the terminal, it was glorious. 

Silly as it was, I was drunk with power. I could make the computer print out _anything_. In a strange way, I found programming similar to the creative / logical act of sentence diagramming, which I loved. So I was hooked. I started spending all of my free time programming. 

#### Learn Programming

There were several initial hurdles to overcome. What curriculum would I follow? What language should I learn? Heck, what editor should I use to write code and where could I even execute it?

I imagine these things are obvious to someone who goes to school for Computer Science. But I was sitting at home with just the internet and a few spare hours. Fortunately, I had two great resources. 

First, my programmer friends. I'm sure they got sick of my endless questions, but their help was invaluable. Working on your own, it's easy to get lost in StackOverflow posts and wind up dismayed. My friends kept me on track and cleared up a lot of confusing points. ("What's a constructor function?" "What's a list comprehension?") 

Second, I found a fantastic e-book called [Invent Your Own Computer Games With Python](https://inventwithpython.com/invent4thed/). It's targeted at an audience...much younger than I was. As a result, the writing is exceptionally clear and simple. Perfect for an absolute beginner with limited guidance. 

Armed with these tools, I wrote dozens of sloppy, rudimentary programs. Notably, I made a "chatbot" with hard-coded responses to common phrases. I was so proud of that, and success felt like it was just around the corner.

Except it wasn't.

I sent out a blizzard of internship applications, and every single one was rejected. It was a seemingly endless stream: rejection after rejection after rejection. I was even rejected from Yelp, where I work as of this writing.

Around this time, a well-meaning acquaintance told me that I should give up trying to be a software engineer. It was too hard, there was too much math, and didn't I know? Software Engineers were _really_ smart.  

Boy did that make me mad. I'm still mad, just thinking about it. 

Any thoughts I had of giving up were promptly sidelined. I was _sure_ I could break into the industry, given enough time. Maybe I needed more education.

#### What Sort of Education?

By whatever fortune, during that period I was blessed with clarity of vision. I was going to be a software engineer, full stop. I wanted to build the foundation for my life's professional work.

Programming bootcamps had become very popular, and I spent a long time weighing them against a traditional graduate school.

It's easy to understand bootcamps' appeal. They teach you industry-relevant skills, help you apply for jobs, and promise that you can shift careers at supersonic speed: often in just a few months. 

I thought for a long time about enrolling in a bootcamp. But, for whatever reason, it seemed risky. 

Maybe it was the horror stories about poorly-run bootcamps. Maybe it was a personal bias towards traditional education. Maybe it was the impression I got online, that companies looked down on bootcamp graduates. Or a worry that I'd miss out on theoretical aspects of Computer Science. 

Switching careers already felt risky, and I was desperate to reduce uncertainty. Bootcamps were out.

I've met many bootcamp graduates since then, most of them highly driven and intelligent. Some have found success, some not. 

It's worth acknowledging that I enjoy several privileges which made it possible for me to quit my job and spend two years in grad school. I am very fortunate in that respect, and very grateful.


#### Applying to Grad School

Applying to grad school was pretty straightforward. The GRE felt like a piece of cake after the LSAT. I just needed to relearn high-school math (English major, remember?). 

Few schools would accept me without a bachelor's in Computer Science. So that narrowed the field for me, in some ways a blessing. I applied to about five schools.

Of those, Brandeis was my top pick. There, I could take remedial undergraduate classes while I did my Master's. And they had a strong Computational Linguistics program to boot.

My background actually made parts of the application very easy. Writing a personal statement? No problem. Verbal portion of the GRE? Forget about it. 

After submitting the applications, I took a mid-summer trip to Boracay, an island in the Philippines. I ducked in from the white-sand beach to check my email and found out that Brandeis had accepted me. Despite all the surf and sun, I could only dream of Boston in winter.

#### First Year at Brandeis

Brandeis was as great as Boston was cold.

I spent my time learning Computer Science, surrounded by intelligent people who had similar interests. It was like paradise.

Except for Discrete Math, that is. Everyone has that one class where they struggle. But even tougher than the material was the imposter syndrome I felt as a result. It was my first semester and, heck, I was just an English major. If I was already struggling, maybe I didn't belong in a Computer Science program? Surely I'd be exposed as a fraud.

In the end, I managed to scrape out a hard-won B+. And boy was I relieved. I won't say it fully alleviated my imposter syndrome, but it was a good start.

There were high points too, like the Computational Linguistics classes I took. I've rarely had so much fun being challenged intellectually. Finally I was back to diagramming sentences, but now the computer did it for me.

#### Internship

That summer, I was lucky to get an internship with Ginger.io, out in mythical San Francisco. I'd never been to SF and didn't know much about Ginger.io. But on paper, it was perfect.

Ginger.io was a small-ish startup, with ~20 engineers. Their goal was to provide mental healthcare to people without the usual means of access—something I'm personally passionate about. 

Their tech-stack was Python-based too. That meshed with the programming I'd done at Brandeis. Finally, _this time_ success was just around the corner.

Except it wasn't.

The people at Ginger.io were patient and kind. But, to be frank, I was woefully underprepared. 

I'd done very little collaborative programming. I was somewhat baffled by the command line, and _exceptionally_ baffled by git. I'd never even dreamed of a codebase bigger than a few files. 

It was one of the most difficult periods of my life. I spent much of the summer trying to learn all the things software engineers take for granted—automated testing, development environments, version control, architectural patterns, and so forth. I worked very slowly and I felt like I'd let the team down. It was doubly painful, since I cared deeply about the company's mission.

#### Second Year at Brandeis

As difficult as it was, that summer at Ginger.io was transformative for my education. I was determined to be better prepared for the next opportunity.

Suddenly, it was obvious which courses I should take. It was obvious which modules I needed to pay close attention to. I still managed to take a few Computational Linguistics courses, but I added other electives like Databases and Web Development. 

As the year wound down, I felt vastly more prepared for professional software engineering than I had the previous summer. Letting the challenges of my internship guide my education was one of the most effective things I've done.

#### Interviewing

Many people have written about the software industry's interviewing practices. I won't dwell on that, except to say that it ain't no fun.

The process is long, emotionally fraught, and exhausting. As many as five or six separate interviews per company, where they can ask you to solve whatever problem they want. As a result, the questions can be very unpredictable. 

And it's surprisingly hard to program while you describe what you're doing. I found there to be a steep learning curve.

#### First Job: Practice Fusion

My first "real" job as a software engineer took me back to San Francisco. I'd loved the city and was raring for a second chance to prove myself in the industry.

I wound up at Practice Fusion (PF). PF maintained a free electronic health record system. They were especially geared for smaller practices—the mom and pop shops of medicine. It was a small-but-mature company, with maybe as many as 50 developers.

I was hired as a "Frameworks and Tools" engineer. We were given free rein to fix developer pain points anywhere in the stack, with any tool we wanted. At first, I was frustrated that my role wasn't more user-facing. I wanted to build software for people, dangit!

But as I grew into it, I realized that the flexibility of my role was perfect for growing my skills. I got to do things I otherwise wouldn't have, like building a development environment, prototyping a database, and dabbling in frontend work.

It helped that my team was great. I learned a lot from their camaraderie, their pursuit of excellence, and their technical experience. 

Unlike my internship, I felt like I had the skills to contribute to my team. Armed with confidence, I dove into any project I could get my hands on, and I learned a _ton_. 

#### And Beyond

Since then, I've landed at Yelp. There, I've written features that millions of people use every day. I've even taken on the role of Engineering Manager. I lead the team that handles the search experience, across Android, iOS, and web. 

My road to software engineering was long, difficult, and felt uncertain at every step. It took a series of great mentors, lucky breaks, and a level of perseverance that brought me to my limits often.

But, for all that strife and uncertainty, I can't imagine another life that would make me happier. I do interesting work with great people, and have the opportunity to touch people's lives daily. 

Finally got around to setting up my blog. This is just a quick hello.

I have a blog now


Well hey presto, I've finally set up a blog. 

I had fun making it—it reads in markdown files and renders them into a React layout. Since I prefer to write in markdown _anyways_, I hope that should lower the barrier to writing these posts.

The tentative plan is to record whatever hobby I'm going deep on currently (it's always something...). But who knows? The sky's the limit. 

That's all for now. Catch you next time.
