For years, I seldom posted on social media platforms: nothing beyond random questions I had for niche subreddits or tweets to companies asking for customer service.

If this describes you too, we’re in good company. There's a principle in internet culture called **the 1% rule**: in any internet community, 99% of people lurk and only 1% add content. Researchers have studied this concept and found it to be consistent across many internet forums.

I started doing Ship 30 for 30 to force myself to publish more. It’s helped, but the real value from the course has been internal. From having to hit the “publish” button a bunch of times, I’ve had the opportunity to reflect on the fears that used to hold me back:

### 1. No one will engage with my content

The thought of pouring my soul into an insightful (to me) blog post only to watch it get 0 upvotes/hearts/unicorn points was tough to stomach. I know there are some people who naturally don’t care about this, but I’m not one of them, as much as I’d like to be.

#### The mindset shift

Not caring about engagement is a trainable skill. I’ve posted with the explicit focus on ignoring engagement, and I’ve noticed the sting of disappointment fade with every post I publish.

Also, if I never post, I’m **guaranteed** to get **zero** engagement with my ideas.

### 2. I’ll be wrong publicly

One of the toughest habits I’ve fought in writing is eliminating the phrases “I think”, “I believe”, or “I feel”. My writing implicitly reflects my opinions. I feared writing authoritatively because many of these opinions were possibly wrong, the result of either narrow experience or flawed thinking.

#### The mindset shift

Keeping my wrong opinions to myself doesn’t make them less wrong. And finding out they’re wrong is the first step towards correcting myself.

At work, I encourage people to be wrong openly and accept correction. Why wouldn’t I do the same on the internet?

### 3. Someone out there will judge me

I used to compose blog posts or even just comments on threads, only to hesitate and close my browser tab before posting. I constructed a narrative of someone:

1. disagreeing with me
2. posting a scathing reply
3. going through my post history, continuing to judge me

#### The mindset shift

I guess I’m still scared of the off-chance of becoming [Twitter’s main character](https://knowyourmeme.com/memes/twitters-main-character). Barring that, there’s a tiny contingent of people who would bother judging an internet stranger based on a few opinions. Even if they do, **why does it matter**?

I’ll always have detractors even if I have good ideas. Might as well get used to it now!

## My current fear

I’m still fearful when I hit publish, but it’s a fear grounded in reality. It’s that **I am irrelevant and no one cares at all who I am and what I have to say**. If I care about avoiding this fate, I **have to keep hitting that publish button**, putting myself out there, and figuring out what resonates with people.

If you’re like me, from one lurker to another, I hope you will too.


From internet lurker to content creator: 3 mindset shifts that helped me overcome my fear of publishing

My journey in the tech industry began with a tiny salary at my first programming job where I was barely making rent. When I left, I found a job that tripled my salary.

I moved to Silicon Valley, where my salary increased 50-100% each time I changed jobs, depending on whether I moved up a level.

During my Silicon Valley years, I was promoted once. It was a brutal process, and my salary increased 25%.

> Job hopping, especially in tech, is the single best way to improve your salary.

## Why not job hop?

There are a lot of good reasons to stay at a company for a long time. It’s rewarding to build deep, long-lasting relationships with your team and see the impact your work long-term. Just don’t do it as a financial choice.

## How do you job hop effectively?

> Learn how to interview and negotiate well.

Both skills are learnable; here's what I found most valuable:

### 1. Interviewing

Tech interviews are [truly terrible](https://www.tiktok.com/@shmemmmy/video/6880323857903799558). Most of them don’t test you on anything remotely related to your day-to-day. Preparing for them takes a long time and typically doesn’t make you a better engineer.

Many of my peers refused to learn how to interview because interviews are so stupid. I agree in principle, but this stance is costly.

For self-taught programmers like me, I found 3 resources particularly helpful:

1. a 2-part data structures course on Coursera ([part 1](https://www.coursera.org/learn/algorithms-part1) and [part 2](https://www.coursera.org/learn/algorithms-part2)) — helpful for learning fundamentals if you went straight to the practical
2. [Cracking the Coding Interview](https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850) — widely considered the bible of tech interview prep
3. [Leetcode](https://leetcode.com/) — platform for practicing technical challenges

### 2. Negotiating

For a long time, I never negotiated. I took the first offer I got. Good enough, I thought, better than my current salary. I never even knew how much I was leaving on the table.

There are a whole host of tactics you can use (e.g. using market data, negotiating other perks), but the two I needed to hear most when I was younger are:

1. **Get comfortable doing it**. It's not rude. Most recruiters and hiring managers expect you to negotiate.
2. **Interview at multiple places simultaneously**. With Big Tech, all negotiation tactics pale in comparison to having multiple offers in hand and igniting a bidding war. I’ve had initial offers increase 30-60% by the time the dust settled.

**Note**: #2 applies even if you’re asking your current company to increase your salary. Many tech companies only believe you’re more worth more than your salary if another company tells them.

## Wrap-up

At this point, you may think all I care about is money. In reality, I always  left my job for non-financial reasons. I just left in a way that maximized my salary bump.

Ultimately, this one of the most frustrating aspects of the industry and contributed to me leaving Big Tech. I wish companies rewarded loyal, skilled employees more freely than they do new recruits who interview well, and that I wouldn't have to write posts like this.

But everyone should get the most out of their time working, and I hope these tips help you do just that.


You're in the game already, why not play to win?

The two most lucrative skills in the tech industry

## My journey with productivity and optimization

I got my first taste of my productivity obsession right out of college with the (in)famous *Getting Things Done* system by David Allen. I had lived my entire college career a minute at a time: zero time management skills, no routine to speak of, frequent cram sessions or all-nighters to wrap up problem sets or study for exams.

*Getting Things Done* taught me how to capture my random thoughts and surface them at the appropriate time. I bought [Things](https://culturedcode.com/things/) — to date, the cleanest and simplest implementation of *Getting Things Done* I’d ever seen — and rigorously adhered to a routine of documenting my life. I felt, for the first time, a sense of control over a life that had been utter chaos up to that point.

Ever the engineer, I sought to further optimize my life. I read all about the power of habits and routine in [The Power of Habit](https://www.amazon.com/dp/B0055PGUYU/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1), [Atomic Habits](https://www.amazon.com/Atomic-Habits-Proven-Build-Break-ebook/dp/B07D23CFGR/ref=sr_1_1?crid=1GHH659NU53GP&dchild=1&keywords=atomic+habits&qid=1633795573&s=digital-text&sprefix=atomic%2Cdigital-text%2C228&sr=1-1), and many others.

I developed my own habit system: a group of colored stones I’d move from one box to another daily, each one representing one of my habits I wanted to develop — e.g. write, meditate, draw, do something nice for my wife.

I’ve attempted plenty of other convoluted micro-optimizations as well throughout the years:
1. I tried to program my Google Home to add tasks to my Things list by connecting it to automation software that sends an email.
2. I bought an Apple Watch in part to give me ubiquitous access to my todo list (spoiler alert: it didn’t work because Siri sucks).
3. I built a Chrome extension version of [this calendar](https://www.kickstarter.com/projects/simonegiertz/the-every-day-calendar) to track my daily progress.

In short, I spend a lot of energy to feel like I’m bettering myself, meeting the goals that I set, and generally being in control of my life.

## Is there such a thing as too much productivity?

I’m now wrestling with some beliefs I picked up from my immersion in productivity culture, no longer certain they’re serving me.

First is that all goals are within reach given proper time management. Many productivity systems care little about human limitations. Every hour has the same potential productivity so long as you plan.

Second is that consistency trumps all else. Thirty minutes to an hour a day of deliberate practice produces great results you need in the long term.

When I combined these beliefs, I concluded that I should be able to pursue all my goals simultaneously. Just give a bit of time to each every day. However, when I write all my goals down in one place, it feels a little absurd:

1. Be a great husband and father
2. Achieve fluency in Mandarin
3. Play more music: practice guitar fingerpicking and piano improvisation
4. Pick up drawing again: pencil sketches and pixel art
5. Create a videogame
6. Get better at writing
7. Build a startup
8. Become a better leader and engineer

In theory, I **could** make progress on all of these ambitious goals with just a few hours of dedicated time per day.

In practice though, my time investment produces uneven results. It took me so long to accept an obvious truth: there are occasions I have all the time in the world for my goals but lack even an ounce of energy. Pursuing 8 ambitious goals simultaneously consumes tons of energy, and doing so for a meaningful stretch of time is unsustainable.

Ultimately, these goals are more than things I want to do; they define who I want to be: creative, artistic, and entrepreneurial. Even if I were able to “time manage” my way to doing everything, I would be mediocre at best.

The challenging part is I’m approaching an age where letting something go feels like — with every-increasing job and familial responsibilities — I may never come back to it. I’m learning that I need to be okay with that. Unrealized goals that I cling to take up a lot of mindspace, even if I’m not actively pursuing them.

## So where am I now?

I realize now that I had assumed a concept in productivity culture that may not have been there: unlimited human potential. I wanted to believe there was no limit to what I could accomplish with the right tools. But everyone has limits, whether they acknowledge them or not.

I’m instead focusing on a few of the above goals that have an immediate impact on my career and family life. And I’m going to think of productivity for what it is: a means to achieve a few goals at a time.

I hope I’ll get to do all that I want to someday in this life, but trying to force it seems to guarantee I’ll accomplish little of substance. I’m excited to see where recognizing my limits gets me.


My learnings about the limits of productivity and time management

Productivity as fantasy

## What’s a postmortem, and what makes it blameless?

Many engineers are familiar with the concept of a [postmortem](https://sre.google/sre-book/postmortem-culture/). Postmortems are a tool used to examine mistakes engineers make resulting in a severe problem, such as an outage or data loss.

In these situations, the most common alternative to the postmortem is scapegoating the person who made the mistake and punishing them.

The logic behind punishing people in these situations is unclear to me. It feels to me like it’s so management can feel good about saying they did something to address the issue.

This approach is short-sighted though. Where human error is possible, it’s inevitable given enough time. Punitive action assumes that people are only trying to avoid mistakes to avoid getting punished, not because they want to do a good job. If the former were the case, maybe the company’s hiring process is the problem?

In contrast, blameless postmortems focus on the system or process surrounding a human mistake rather than the mistake itself. Barring rare cases of malice or gross negligence, the engineer was applying their skills to their problem in a way that made the most sense to them at the time.

For example, say an engineer at your company deleted a huge chunk of data. Nightly backups were running but no one had ever tested them, so the data loss was catastrophic. Here are some questions that might come out of the postmortem process:

1. Were there any guardrails on the engineer being able to delete a massive amount of production data?
2. Why was the engineer doing any work on the production database directly? Why wasn’t there a UI where they could get that work done in a less dangerous way?
3. Why weren’t backups routinely tested?
4. Was the engineer aware of the inherent danger of what they were doing?

The ultimate goal of the postmortem is to produce a list of corrective actions. These actions should prevent similar mistakes from happening in the future for anyone in the errant engineer’s position.

## The principles behind blameless postmortems

While companies’ implementations of postmortems are often far from perfect, I’m completely aligned with the principles behind them. I often wonder why other disciplines don’t adopt similar principles.

In engineering, the postmortem-worthy problems might look like outages, data loss, and data breaches. In other disciplines, there are lost sales, bad hires, and PR disasters. Many of the reasons the postmortem is such an effective tool have nothing to do with engineering.

### Transparency

To me, the most valuable element of postmortems by far is the level of honesty required to conduct them. Everyone involved is allowed to be 100% forthcoming about their roles knowing their jobs are safe. Without the honesty piece, engineers (and everyone really) would default to an approach of hiding mistakes, and teams would inevitably repeat them.

### Grace

Blameless postmortems emphasize that you can make mistakes and still be competent. We’re all just doing the best we can with the information we have. The goal of the process is continuous improvement, not perfection.

### Thoroughness

Many postmortems ask a chain of [five whys](https://en.wikipedia.org/wiki/Five_whys) in order to get to the root cause of a mistake. This root cause analysis is critical to treating the underlying issue instead of the issue’s symptoms.

## A postmortem for my behavior

I’ve become fascinated by the theory behind human behavior and motivation in recent years. My interest started with Daniel Kahneman’s terrific book _Thinking Fast and Slow_, which discusses the competing priorities in two different parts of your mind.

This was a startling revelation — I’m not a single coherent self. I’m just a bundle of competing priorities with the illusion of being in total control of my actions.

Armed with this realization, I’m able to step back from my problem behavior and see it for what it is: a mishmash of conflicting emotions and goals rather than a “self” deciding what I’ll do. In other words, there are broken systems informing my behavior. As the postmortem process has taught me, broken systems can and should be repaired.

## An example: analyzing my sleep habits

I’ll use my constant battle to get to sleep at a reasonable hour as an example. Since becoming a parent, 6:30 AM is the latest I can wake up and be on track for my family’s morning routine. However, I routinely find myself sleeping near or after midnight and feeling guilty about myself when I eventually go to sleep, then again when I wake up feeling like a zombie.

Guilt has been a bad solution. It’s roughly the same concept as a company reprimanding someone for making a mistake, and it’s equally ineffective. I thought about how to reconcile the inconsistency between how I treat problems at work vs. problems in my personal life.

When I apply the postmortem to my life, it’s more of a mindset shift than a full process. I don’t produce any written documents or go through the issue to the level of depth I would at work, but the exercise is helpful nonetheless.

First, I admitted this was an issue and that I wasn’t going to solve through willpower alone. Jury’s very much out on [whether it’s possible to increase willpower as a long-term solution](https://hbr.org/2016/11/have-we-been-thinking-about-willpower-the-wrong-way-for-30-years), or [whether it even exists at all](https://nautil.us/issue/45/power/against-willpower).

Next, I committed to stop being annoyed with myself. The negative feelings weren’t actually changing my behavior, so they weren’t worth keeping around. This is easier said than done, but I’m able to ignore them more easily after noticing how unproductive they are.

Lastly, I examined the emotions surrounding my decisions that lead to late bedtimes. I noticed a strong sense of urgency around finishing up some personal projects (like this blog) or having some time to decompress. This led me to two sub-problems:

1. I have a 7-month old and the time after he goes to sleep is the only real free time I have. Apparently this mindset is common enough that it has a name: revenge bedtime procrastination.
2. I lose track of time, possibly because I’m sleep-deprived from the previous night
3. I’m overcommitted on projects and want to get too much done in any given day.

Each of these problems has its own set of potential solutions. For now, I’m working on the first issue by using a gratitude journal to cultivate my sense of thankfulness for having a healthy child that I get to spend a lot of time with. For the second, the solution involves changing my environment by setting reminders and alarms. I haven’t quite figured out the issue yet, but I’ll get there!

I’ve experienced a surprising amount of success with my strategies so far. In particular, the connection between gratitude and my late bedtime would have been totally opaque to me if not for this exercise.

## Stop feeling bad, start solving the problem

If you’re anything like me, your bad habits impose a great deal of guilt on you. Rather than unproductively trying to change yourself through guilt or blame, give this process a try. It works for many tech companies. Maybe it can work for you too.


How to use the tech industry’s greatest contribution to corporate culture to fix your bad habits

Blameless postmortems and personal problems

## Then

I don’t know how relatable this is, but I have two deeply-ingrained habits when it comes to communicating online:

1. I relentlessly edit all forms of written communication, such as Slack messages, Github PR comments, and email. Immediately after I send something, I go back and apply little irrelevant edits, even though the original message communicated my point just fine.
2. I’m a hyper-lurker in all my online communities. Even in the rare cases I have something unique to contribute, I generally start typing a response, get halfway through, then close my browser window.

I suspect that these habits stem from an insecurity around publicly looking stupid, so I censor myself as a defense mechanism. After all, if I never express my opinions, I can’t be wrong! Flawless logic.

These habits had a toxic influence on this blog’s sad 6-year history. When I started writing, my hope was to become a superb teacher. I carefully considered my “target audience” of programming newcomers, only posting things I felt they would find helpful. This mindset produced three bad outcomes:

1. I didn’t write unless I had something truly insightful to say. Note that my standards for “insight” were nothing more than a stab in the dark since I had no readership.
2. I seldom wrote, so I never hit a stride, nor did I improve in proficiency or comfort with the process.
3. What little writing I did was almost entirely devoid of my personality and inner life.

A few years ago, I read James Clear’s book *Atomic Habits*, and [his story about the proven relationship between practice and art](https://jamesclear.com/repetitions) struck a chord with me. A photography professor at University of Florida divided his students into two groups, a “quantity” group and a “quality” group. The quantity group was graded solely on the amount of photos they produced and submitted. The quality group only needed to submit one photo as close to perfection as possible.

In the end, most of the best photos that the class produced came from the quantity group. So it seems great art is about consistent producing and iterating rather than obsessing about perfection.

I struggle to relate this story to writing, since writers have a limitless capacity to edit their work. Indeed, this used to be my writing process:

1. I brainstormed ideas, rejecting 99% of them as too unoriginal or trite
2. I produced a rough draft for my 1% idea in a day or two
3. I edited it for several days, sometimes even weeks, after that, trying to get as much feedback as possible from friends and family
4. I got in my head about whether anyone would find anything I say valuable
5. I scrapped the post

There’s not enough motivation in the world to keep me going through a more than a cycle or two of this process.

The questions I want to answer going forward are: when am I done with my posts? How do I best improve as a writer and teacher? I’ve seen enough to believe the answer involves caring less that I’m being insightful, unoriginal, or uninteresting.

## Now

I’m making the priority for my blog the practice of sharing my thoughts. Someday I’ll need to find a better balance between editing myself to produce premium-quality work vs. getting used to sharing my thoughts publicly. For now, I’m going to optimize for the latter.

Who is this blog for then? Who’s my “target audience”? There’s value in the answer primarily being “me”. I love the idea of capturing my beliefs about life and work, being able to look back later at the way I’ve grown in my thinking and skills. Someday if I ever develop a readership, which no longer matters to me much, I hope it’ll give my readers a connection to who I am.

Before I redesigned my blog, I toyed with the idea of removing publication dates. I was embarrassed by the infrequency of my writing. I see now that was simply another way of censoring myself. I’m choosing to leave them up as a means of honesty, and I’m betting on a more consistent and fruitful future of writing.


My struggle with perfectionism, i.e. how to publish a blog post once every 3 years.

Starting over

Software developers who aren’t familiar with the name Linus Torvalds are almost certainly familiar with his work. He’s widely regarded as one of the most prolific software developers in the world due to his authorship of the Linux kernel and Git, two of the most important projects in modern software and computing.

Unfortunately, he is also well-known for his abusive language towards colleagues. In September 2018, Torvalds announced that he is taking a break from his leadership of the Linux project. [In an apology email to fellow maintainers](https://lkml.org/lkml/2018/9/16/167), he mentioned that he will “get some assistance on how to understand people’s emotions and respond appropriately.”

Torvalds’s behavior fuels long-standing stereotypes that leads to questions on social media such as “[Why are most programmers weird? They just seem to not have any social skills.](https://www.quora.com/Why-are-most-programmers-weird-They-just-seem-to-not-have-any-social-skills)” and “[Why does programming have so many negative stereotypes associated with it?](https://www.reddit.com/r/AskMen/comments/1wxzkx/why_does_programming_have_so_many_negative/)”. If you look at most of the negative images surrounding software developer stereotypes (antisocial, overly technical, condescending), many of the bad qualities stem from a lack of empathy.

At a high-level, empathy is simply the ability to put yourself in the shoes of another human being, to feel their feelings and to imagine what it would be like to have their problems and their goals. With rare exceptions, we as humans are wired to feel empathy instinctively, but by being mindful of situations where empathy is important, we can all develop this vital quality.

From my years working at major Silicon Valley tech companies as a software developer, I observed empathy to be among most underrated and important skills. Here’s what empathy might look like in your career as an engineer:

### Empathy for other engineers

<figure class="post-image">
<a href="https://xkcd.com/1513/">
<img src="https://imgs.xkcd.com/comics/code_quality.png" alt="XKCD Code Quality comic" />
</a>
<cite>XKCD // <a href="https://creativecommons.org/licenses/by-nc/2.5/">CC BY-NC 2.5</a></cite>
</figure>

Unless you’re only engineer on your team, you’ll almost certainly be spending a lot of time communicating with other engineers in the form of technical discussions, design docs, and most of all, code reviews. Depending on the size of your team, all this interaction can easily be one of the most time-consuming parts of the job.

Be mindful that even though responding to your comments and doing code reviews for you is a part of your fellow engineers’ jobs, asking for their input is essentially asking them for their time. You’re asking not only for their time, but for them to take their mind off their project, which can be exceedingly disruptive to their day. Consequently, it makes a lot of sense to minimize the amount of time and number of back-and-forth interactions that it takes to help you out. How can you best accomplish this?

#### 1. Be your own critic first

You’ve just finished writing some code, and you’re about to request a review. But wait, who should be the first one to review it? You!

I can’t count how many times someone has sent me a code review and there are obvious glaring issues in the first few lines of code that I read. Issues that would most certainly have been caught had they done the very thing they are asking me to do (read their code). Before you send any code review, take the time to scan through your code for clear issues. Avoiding the need for someone else to point out obvious issues in your code is one of the key ways you can be respectful of their time.

#### 2. Anticipate your coworkers’ questions

We’ve all had to commit code that we're not proud of — maybe an impending deadline or working with a rough API made you do some questionable things. This is something of a corollary to #1, but read your own code with not only a critical eye for issues, but things that will confuse the crap out of your coworkers.

Be proactive in documenting the sacrifices in code quality you’ve had to make, and why. In other words, leave comments (in the code or in the PR, however your team decides to deal with comments) with answers to questions that you know your reviewers will have.

#### 3. Seek first to understand

It’s safe to consider it reality that other engineers in your organization are going to disagree with you. Unless you are able to get to a point where you make all your technical decisions unilaterally, you simply have to accept this fact and learn how to deal with it productively.

Earlier in my career, I would view disagreement and debate as personal attacks. Those who have worked with me know that I hold strong opinions. As I matured in my career, I realized that it’s actually quite harmful to identify with your opinions (not only about technology, but really anything) to the point that you feel attacked when someone disagrees with you. This feeling is all about ego, for which a healthy engineering culture has little room.

Nowadays I still hold strong opinions, but I try my hardest to view disagreement as an opportunity to learn from someone else. Make every effort to understand your disagreeing coworker’s point of view. Underneath the surface is likely a goal or a premise that the two of you can agree on. Ask (as non-confrontationally as possible) why they hold their belief. Do you agree with that? If not, keep asking why until you can agree on what you’re trying to accomplish, and figure out where the disagreement stems from there.

This process almost always yields a wealth of information from your coworker’s experience that you wouldn’t be able to get if you kept your disagreement at the surface level. If you work in an environment where ideas can compete openly and the best ideas win, this means the eventual outcome will be best for your team, even if it’s not your idea. That is, unless your coworkers are just dogmatic parrots repeating something they read in a blogpost somewhere on Medium, in which case I’ve never quite figured out how to deal with that and I have no idea how to help you ¯\_(ツ)_/¯

#### 4. Be positive

Programming as an industry can be regarded as one of the most critical. You’re constantly putting your work out there to be judged by your teammates. If you’re like most engineers, myself included, your code reviews will be littered with nitpicks and things you need to improve, and rarely will you find a word of encouragement. In many ways, handling this criticism is just part of the job. We want to constantly be learning, growing, and pushing ourselves towards excellence.

However, pushing others towards greatness and providing positive reinforcement are not mutually exclusive. Is your teammate killing it with this feature they’re working on? Did they clean up some part of the codebase as part of their PR that they didn’t have to? Did they slog through your 800-line code review with you? Tell them you appreciate it!

There has been plenty of research on how the ideal ratio of positive comments to criticism should be at least 5-to-1. Building trust by offering genuine praise can help constructive feedback land much more effectively. When people know you care about them, they’ll know that your criticism comes from trying to make them better rather than trying to tear them down.

Some people in this field legitimately don’t really care about stuff like this, and that’s okay — but many do. I would be even prouder to work in an industry where we all actively work to create a culture where it’s okay or even expected to encourage one another sincerely.

### Empathy for other teams

You’ll invariably end up spending a lot of time with cross-functional teams as well, e.g. coordinating with design teams to provide constraints and direction for their mocks, working with product managers to understand specs, working with marketing to build a landing page, etc. When someone makes a request or asks you for something, put yourselves in the shoes of someone who doesn’t know all the terminology and details of the issue that you might. How might they want their engineer to respond?

I find that the most valuable concept during this communication is the level of detail that your audience is interested in. Avoid technical details and jargon as much as possible. It’s typically not their job to understand the details — it’s yours.

As engineers, we tend to be in the weeds of a problem, and it can indeed be hard to zoom out a bit when explaining issues to other people. Sometimes people are genuinely interested in the details, but if that’s the case then they’ll let you know. I’d recommend starting high-level and explaining more if they express interest (and always let them know that you’re willing to talk more about it).

Above all, remember that you’re all in pursuit of the same goals. Hopefully, if someone is asking something of you, it’s in service of building a better product for your users. Remember this as you communicate with the people around you.

### Empathy for your users

<figure class="post-image">
<a href="https://xkcd.com/1172/">
<img src="https://imgs.xkcd.com/comics/workflow_2x.png" alt="XKCD Workflow comic" />
</a>
<cite>XKCD // <a href="https://creativecommons.org/licenses/by-nc/2.5/">CC BY-NC 2.5</a></cite>
</figure>

Last and certainly not least is that you should ideally feel the pain of your users as much as possible. Our users can often be an abstraction to us, hidden away by several layers of communication (e.g. customer service -> product managers -> us). This abstraction makes sense for many reasons — imagine trying to get anything done if customers had a direct line of communication with engineers all the time. However, it’s easy to lose sight of what we’re doing when we are allowed to avoid thinking about our users for too long.

#### Your users are not just metrics

Imagine you deploy a bug that breaks a critical flow, e.g. downloading a spreadsheet of the data in your app, for a tiny fraction of your users, let’s say 2%. If you’re a data-driven company, you and your team might look at the metrics and see that people have stopped being able to complete this flow. You look at usage and you say “oh people weren’t using this very often, just 2% of users. We’ll get around to fixing it sometime soon, but we have other priorities now”. However, this flow might be the thing that allows these 2% of users to do their jobs, and you might have completely ruined their ability to use your product effectively in the meantime.

I know it can be impossible to put the pain of the few before the desires/needs of many, and I’m not suggesting that your team needs to completely change their approach. The point is never to forget that there are human beings behind those screens. Maybe your team’s goals will change as a result, and maybe they won’t, but you’ll be a better engineer if you keep this in mind.

Prioritizing eliminating customer pain isn’t just an abstractly good thing to do — products live and die by advocacy. If you broke this functionality and didn’t care that much, what do you think these users would say if their friends or colleagues ask them what they feel about your product?

#### User experience is empathy

I won’t go into this much because User Experience (UX) is an entire field and job function on its own, but it’s worth mentioning here that cultivating your empathy will also lead to a better product for your users. Our software tends to exist to make our users’ lives easier. We should all strive to make it as simple and intuitive as possible.

Remember also that your users are likely quite different from you. How could you build your product differently as you imagine some of the following scenarios:

1. You’re a user in a developing country that pays for data by the megabyte
2. You’re a sight-disabled user who can’t see color contrast well, or a mobility-constrained user who can only navigate with the keyboard
3. You’re a user who isn’t very tech-savvy and have a hard time navigating complex interactions

It can be exceedingly difficult, if not impossible, to truly put yourself in the shoes of people who are so different from you or anyone you know. That’s why a lot of these issues are often addressed by different fields such as user research and UX design. However, even if you are lucky enough to work with people in these fields, it doesn’t let you off the hook. I guarantee that your product would be better if you take responsibility for these problems as well, rather than just letting your cross-functional partners think about them.

### Conclusion

This post contains just a few examples of how you can express empathy on the job. My encouragement to you, however, is to make it a mindset rather than just behavior. Throughout your day, ask yourself about how people are experiencing your work and your actions. Make a habit of thinking about others, and you’ll do your part in creating better products, a healthy workplace culture, and a rich and fulfilling career for yourself.



Tips on mastering one of the most underrated soft skills you need to succeed in your career

Building empathy as a software developer

<blockquote>
Give me six hours to chop down a tree and I will spend the first four sharpening the axe. 
<footer>
<cite>Abraham Lincoln</cite>
</footer>
</blockquote>

I once stood over my coworker's shoulder as we were working on an issue together and watched him use ssh to log onto our production server, observing that it took a full 2 minutes to connect. I estimated that he used ssh close to 15-20 times per day, so waiting minutes for an operation that should take seconds seemed enormously wasteful. I can't imagine having a non-trivial amount of my work day consisting of waiting for ssh to connect to other machines. It took me about 45 seconds of Googling to come up with a fix for him. When I asked him why he didn't look into it at all, he told me it didn't really bother him.

I was a little shocked by this episode at the time as I never would've put up with that, but over the course of my career, I've gotten the sense that streamlining one's workflow is a relatively uncommon thing to do. I've had many other coworkers who are also willing to tolerate the most horrible inefficiencies. 

<figure class="post-image">
<a href="http://hakanforss.wordpress.com">
<img src="/images/postimgs/too-busy-to-improve.png" alt="Are you too busy to improve? webcomic">
</a>
<figcaption>Don't be these dudes.</figcaption>
<cite>Hakan Forss // <a href="http://creativecommons.org/licenses/by-nc-sa/4.0/legalcode">CC-BY-NC-SA 4.0</a> // <a href="http://hakanforss.wordpress.com">Source</a></cite>
</figure>

As with any job, programming can be quite repetitive at times. You'll find yourself typing the same commands over and over or copying and pasting a bunch of stuff from one place to another. Great news though, because the machine sitting in front of you is actually tremendous at doing menial and repetitive tasks! Leveraging this ability is a fairly underrated but critical part of maximizing your output.

Carefully investing in optimizing your workflow can have a huge payoff over the course of your career. Tiny inefficiencies that manifest over and over again throughout your days and weeks add up, wasting valuable time and keystrokes that you could be putting towards building stuff instead. Having a reputation as a fast web developer can be a major selling point for you in your career, and your teammates will really appreciate your ability to churn out work.

The best part is that unlike many other aspects of programming, being faster than the average developer isn't all that difficult, but you do need to be deliberate about it. Here are a few key things to focus on.

#### 1. Don't multitask

There have been a [lot](http://www.forbes.com/sites/travisbradberry/2014/10/08/multitasking-damages-your-brain-and-career-new-studies-suggest/) [of](http://www.cnn.com/2015/04/09/health/your-brain-multitasking/) [articles](http://www.apa.org/research/action/multitask.aspx) and studies in the past few years about how brutal multitasking is for your brain. I used to attempt to watch TV while I programmed and I noticed a huge improvement in my productivity after I stopped. I would argue that interruptions are especially hard on programmers due to the amount of abstract thinking involved:

<figure class="post-image">
<a href="http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/">
<img src="/images/postimgs/programmer-interrupted.png" alt="Programmer, Interrupted webcomic">
</a>
<figcaption>If you multitask, you do this to yourself dozens of times per day.</figcaption>
<cite>Programmer, Interrupted // <a href="http://creativecommons.org/licenses/by-nc-nd/2.5/legalcode">CC-BY-NC-ND 2.5</a> // <a href="http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/">Source</a></cite>
</figure>

This isn't a self-help blog where you'd normally find this sort of generic life advice, so I'll keep it short and just mention a few things that have particularly helped me in this area.

1. Putting my phone on Do Not Disturb
2. Using noise cancelling headphones
3. Closing all my email/IM tabs
4. Practicing the [Pomodoro Technique](http://pomodorotechnique.com/get-started/)

You'll do yourself a huge favor if you learn how to stay focused and get [in the zone](https://en.wikipedia.org/wiki/Flow_(psychology)). A bonus is that your enjoyment will typically increase right along with your productivity.  

#### 2. Learn your code editor really, really well

What percentage of time do you you spend in your code editor when you're programming? It's pretty high, no? Why not invest some time to learn how to use that time as best as you can? A lot of developers I've seen either use what essentially amounts to a colorful version of Notepad or they use a really powerful editor as if it were a colorful version of Notepad.

I assume you made it this far in this post because you are serious about getting better, so if this describes you, I'd advise you to consider that using a powerful editor really does matter. Imagine you're a carpenter and are passionate about improving your skills. Would you buy the first $10 set of tools that you see at Walmart and stick with that your whole career? Or would you do some research and be willing to invest in the best tools possible for the job?

Good code editors make your life much easier by automating mundane things like indentation, refactoring, autocompletion, and other repetitive tasks. If no one has ever written at least a short book about your editor, you could probably do better. I don't really care which editor in particular you use, just that you choose one that has solid functionality and spend some time into understanding the power user functions. If you're still using a crappy editor, here are a few I'd recommend out of my limited knowledge of the current code editor landscape:

1. [Vim](http://www.vim.org/) – Shameless plug for my editor of choice. I can easily understand that it's not for everyone: none of the buttons do what you think they will and it has the steepest learning curve out of basically any programming-related skill I've developed. When I decided to use it I experienced what I can only describe as a "total loss" of productivity at first. But I love it because of how customizable and lightweight it is, how it makes me _feel_ like a hacker, and the lack of need to move my hand to the mouse for huge chunks of my day. It's also built-in to your terminal, so using it while ssh-ed works just as well as locally, which is not the case for graphical editors. It’s not only free, it’s basically pre-installed on every computer you're going to come in contact with!
2. [Visual Studio Code](https://code.visualstudio.com/) – Open-sourced by Microsoft team, VSCode has become almost a default editor among my peers. With a rich plugin ecosystem that seems particularly suited to the JavaScript community, it’s an attractive option for frontend developers. I’ve even considered switching to it from Vim, which for those who know me personally is saying a lot.
3. [Atom](https://atom.io/) – Built by the GitHub team, Atom is also relatively new. It's similar in functionality, customizability, and style to VSCode. It generated a lot of buzz and a substantial community after its release, but I’ve heard it suffers from performance issues.
4. [Sublime Text](http://www.sublimetext.com/) – Becoming more of a “classic” editor these days as people move on to the newer editors on this list. It's plugin-friendly and extensible, so there is plenty of depth there as well. It's $70 to buy, but most developers I know just ignore the occasional pop-up prompting them to purchase it (support your developers please!).

Your code editor is easily the single most important tool that you use to craft code. Don't neglect it.

#### 3. Embrace the command line

If you use Windows, I'm not sure how much this section applies to you. Feel free to move on to the next!

Your mileage may vary the most with this tip, since it's impossible for me to speak generally about everyone's workflow, but you likely spend at least part of each day on the command line starting task runners, creating and moving files and folders, installing packages and tools, and perhaps dealing with version control. I'll speak generally here and write another post on specifics, but there are two basic things that you can do to make the most of your time on the command line:

##### Know what tools are out there

At my first job, I was tasked with resizing a bunch of images to thumbnail versions. I naively started doing this by hand, before my mentor promptly blew my mind by telling me about [ImageMagick](http://www.imagemagick.org/script/index.php), which allowed me to batch resize an entire directory of images with a single command. It amazed me to learn that there was a command line tool for doing image manipulation.

If you've been avoiding getting too deep into command line because of its obscure syntax and verbose documentation, you might be missing out on a whole host of tools that can make your day-to-day tasks easier. It's hard to come up with generic examples, so I'll offer some specific ones:

1. `curl -I [some-url]` will allow you to see the headers of a webpage, which is particularly useful if you want to see the status code or redirect location for a particular URL. Browsers generally offer this information but it's faster just to see it from the shell rather than opening up your browser, entering the URL in the address bar, opening the DevTools panel, clicking on the correct tab, and parsing the information in the pane to find the headers.
2. If you work with raw data, you can see the sorted data by typing `sort [filename]`, or sort it and look for lines matching a pattern using `sort [filename] | grep [pattern]`. This can be faster than doing something similar in your text editor or some other GUI program.

These are just a few of many things you can do with the shell. I'll discuss a few more of the utilities and ways to combine them that I find useful in my follow-up post, but if you're interested in this topic, [bash cookbook](http://www.amazon.com/bash-Cookbook-Solutions-Examples-Cookbooks/dp/0596526784) is a great resource for understanding what's possible with the command line.

##### Leveraging aliases and custom functions to type less

I use git, so I type `git status` (shows what's changed in a git repository) about a hundred times per day, so it was life-changing when I discovered aliases. This simple line in one of my startup files:

    alias g="git status"

which allows me to just type `g` to mean `git status`, shaves 9 keystrokes off this command. This simple alias saved me hundreds of keystrokes per day and countless keystrokes over the course of my career. And it only took me a one-time investment of 10 seconds to create it!

Using the command line empowers you to create your own shortcuts for things you do often. In my follow-up post, I'll also explain the best way I've found to identify and shorten the commands that you use most. In the meantime, even if your time on the command line is limited, start paying attention to all the repetitive typing you do, and we'll work to eliminate it as much as possible.

#### 4. Always be automating

Commute time is a critical factor when considering where to live, so when my wife and I would look for apartments I would always copy and paste the addresses into Google Maps and get directions to our respective workplaces to see the travel times. This was incredibly annoying to do for the volume of apartments we were looking at. I did a bit of research and wrote a tiny app that takes a few addresses as input and uses the [Google Maps Distance Matrix API](https://developers.google.com/maps/documentation/distance-matrix/intro) to output our travel times from those addresses. I've gotten a ton of mileage (pun intended!) out of this app since I now use it every time I look for housing.

This example was from my personal life but there are many situations in which an automation mindset can come in handy for you at your job. A PM might need you to input a few thousand rows from an Excel document into a database that doesn't have a good upload function. You might need to manipulate a hundred files in a particular way that is too complex for your text editor to handle. If you're attentive to what the non-technical people on your team are up to, you'll find a lot of repetition in their tasks too. Everyone hates menial work, and you will win a LOT of favor with them if you free them from such tasks with your skills.

These automation scripts can be written in basically any popular scripting language, such as Ruby, Python, or Javascript. Learning how to write scripts like this is daunting at first and you might be tempted to resort to doing it manually, but don't give up! Like all things, you’ll improve as you keep doing it, and you'll usually see this effort result in substantial time savings.

It's definitely not advisable to automate every single repetitive task though. You'll naturally learn to analyze the cost-benefit involved for each task. If you're just starting out, I would advise erring on the side of attempting to automate, while still being considerate of your team's needs. You'll develop useful skills and I can guarantee the time invested will not be a waste. But go too far overboard and you'll end up like this:

<figure class="post-image">
<a href="https://xkcd.com/1319/">
<img src="https://imgs.xkcd.com/comics/automation.png" alt="Automation xkcd webcomic">
</a>
<figcaption>My experience is usually more like the top panel, I swear...</figcaption>
<cite>Automation // <a href="http://creativecommons.org/licenses/by-nc/2.5/legalcode">CC BY-NC 2.5</a> // <a href="https://xkcd.com/1319/">Source</a></cite>
</figure>

If there's interest, I'm happy to do a follow-up post on the decision-making and specific skills involved.

#### Conclusion

The most important quality you can develop in pursuing more productivity is mindfulness. Coding is already a huge mental drain, so it takes a lot of energy to be vigilant about your overall process as well, but it's worth it. Think about how to make your computer work for you, and keep in mind the [three virtues](http://threevirtues.com/) of a great programmer espoused by [Larry Wall](https://en.wikipedia.org/wiki/Larry_Wall): laziness, impatience, and hubris. Work hard to build practices that make your job easier so you have more time to focus on building great things.


Tips and tricks on how to maximize your productivity and to be as efficient as you can be

4 tips for increasing your programming productivity

As promised many moons ago, I'll sum up what courses, books, and websites have been most helpful to me, as well as some that I've heard great things about within the web development community.

__A quick note on costs__: I learned how to program on a budget, so I can certainly empathize with people who don't want to break the bank without proof that they can get a job doing this stuff when they're done studying. Most of the resources I list here are relatively cheap and require only a one-time investment. However, there are a few subscription-based resources that can start to add up if you enroll for a few months. If you're like me when I started, you'll look at the overflowing abundance of programming information available and wonder why anyone would ever pay money for any of this stuff.

If you have the means to afford some of the more costly resources, I'd encourage you to drop the mindset that learning should always be free. If the resource is worthwhile, what you're actually paying for is someone to curate it for you and present it in a meaningful way, which is generally well worth the money rather than trying to cobble it all together yourself. I should note here that I'm not in any affiliate programs or trying to sell you anything; everything's only on the list if I think it will help.

__A quick note on languages__: I'll list under each resource which language(s) it targets, but for most good books, I think the language is somewhat incidental. My suggestions are only here because I believe they teach strong language-agnostic programming concepts, but I understand that a book's target language can easily get in the way if you don't know it. Keep this in mind as you decide what interests you from this list.

#### Applicable to total beginners

When you're a beginner you'll need to focus on learning language syntax and general programming concepts (e.g. variables, functions, objects, etc.). I advise you to set your sights on learning just what you need to start building something. Doing too much learning without building something you're interested in can make what should be a pretty fun experience incredibly tedious and dry.

I noticed that I was writing this that these are almost all online resources that feature lessons with related hands-on exercises. I guess that means that I believe lessons and related hands-on exercises are a really good way to learn the basics (and potentially much more than the basics, as I'll explain below)!

<header>
<a href="https://www.codeschool.com/">
<img class="post-thumb" src="/images/postimgs/codeschool.svg" alt="Code School">
</a>
<p class="header-subheader header-subheader-bold">$29/month</p>
<p class="header-subheader">Javascript, Ruby</p>
</header>

I'm really impressed by Code School's quality of presentation. Each course is themed differently to keep it interesting and comprises easy-to-digest short lessons. What really stands out most to me is the range of topics offered. You can find courses on the basics, best practices, and specific libraries/frameworks for both Javascript and Ruby, such as [AngularJS](https://www.codeschool.com/courses/shaping-up-with-angular-js), [EmberJS](https://www.codeschool.com/courses/warming-up-with-ember-js), and [Rails](https://www.codeschool.com/courses/rails-for-zombies-redux). They continually add new courses as well, so even if you don't see the framework you want to learn, there's a chance they will add it at some point. They also offer a Screencasts section with your subscription that offers peeks at new technology, practical advice about building, and mini-courses taught by other screencasters within the dev community. My only criticism is that in the courses I took, I generally felt like the exercises were too easy, and I would've appreciated being stretched a bit more in applying the course material.

They offer a few [free courses](https://www.codeschool.com/free), so you can easily give them a try without any commitment whatsoever. I think they are well-worth the price though: the opportunity to change your career and life for less than the cost of basic cable.

<header>
<a href="https://www.codecademy.com/">
<img class="post-thumb" src="/images/postimgs/codecademy.svg" alt="Codecademy">
</a>
<p class="header-subheader header-subheader-bold">Free</p>
<p class="header-subheader">Javascript, Python, Ruby, Java</p>
</header>

Codecademy got a lot of press a few years ago by convincing many people that [everyone should learn to program](http://business.time.com/2012/06/08/codecademy-founder-why-everyone-should-learn-programming/), and I applaud their very noble effort to make this valuable skill accessible to everyone for free. They offer a slick interface and a number of exercises that apply what you're learning. They feature courses in [Javascript](https://www.codecademy.com/learn/javascript), [Ruby](https://www.codecademy.com/learn/ruby), [Python](https://www.codecademy.com/learn/python), [Java](https://www.codecademy.com/learn/learn-java), and many others.

However, they do draw some criticism from experienced programmers for perhaps presenting their relatively gentle introduction to programming to be more thorough than it is. If you opt to start here, and there are plenty of good reasons to do so, remember that you may only be scratching the surface of whatever language you're learning.

<header>
<a href="https://www.freecodecamp.com/">
<img class="post-thumb" src="/images/postimgs/freecodecamp.svg" alt="FreeCodeCamp">
</a>
<p class="header-subheader header-subheader-bold">Free</p>
<p class="header-subheader">Javascript</p>
</header>

FreeCodeCamp's model of learning seems to involve lessons, implementing those lessons in small pseudo-projects, and then moving on to doing real tech projects for actual non-profits. Apparently their new curriculum (launching next year) totals a whopping 2,080 hours. That's the kind of thoroughness I'd expect from a really solid course. I love the concept of simultaneously teaching people these skill while benefiting non-profits who can't otherwise afford expensive technical services. While I haven't personally used their service, their mission and the number of great things I've heard mentioned about them recently are enough for me to recommend them.

<header>
<h4 class="header-header">
Developer boot camps
</h4>
<p class="header-subheader header-subheader-bold">Tons of money and time</p>
<p class="header-subheader">All languages</p>
</header>

I'm not 100% sure about recommending these since I've never gone through one personally and the price is astronomically high compared to everything else on this list, but I think it's important to mention as an option to those who are able to afford the time and money commitment. These boot camps typically involve going on-site and participating in an intensive schedule of learning and coding full-time for several months. They also typically offer job placement services, working with partner companies to ensure that their alumni are gainfully employed upon completion of the course.

The three big ones that I'm aware of are [Hack Reactor](http://www.hackreactor.com/) (12 weeks, $17,780), [General Assembly](https://generalassemb.ly/) (10 weeks part-time, $3,500), and [Dev Bootcamp](http://devbootcamp.com/) (19 weeks, $12,700-$13,950). This business model is catching on though, and there are a lot of competitor bootcamps that might vary wildly in quality. __You should of course do the kind and amount of research appropriate for a large purchase like this__.

If you have the means and self-paced learning isn't your thing, or if you're anxious to start your new life as a web developer, one of these bootcamps would likely be a great option. The ones I've listed here boast post-program extremely high hiring rates (98+%), and I generally only see good things posted about them by their former students. I'd especially recommend these as an alternative if you are considering just going back to school for formal higher education, as most of the web development curricula I've seen in schools are hopelessly out of date.

#### Applicable to intermediate developers

Once you feel like you have a good handle on the basics of your chosen language, it can help to learn some of the established patterns that experienced coders to make their code clean, readable, and easy-to-maintain. There is enormous depth involved in programming. It's possible (and quite easy) to write code that does exactly what you want it to do but that no one, not even you, will ever want to touch again. Learning how to take code from "working" to "good" is a huge part of becoming a great developer.

Of course, there are many more resources than those listed here, but I listed ones that each touch on a different but important coding topic.

<header>
<h4 class="header-header">
<a href="http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882">
Clean Code: A Handbook of Agile Software Craftsmanship
</a>
</h4>
<p class="header-subheader header-subheader-bold">$33</p>
<p class="header-subheader">Java</p>
</header>

Code is written just once but can be read an unlimited number of times, so we should strive to make our code as easy-to-read as possible. _Clean Code_ is the single best book on code readability I've ever read. There are plenty of rules and guidelines to make your code more pleasant to read for both yourself and your coworkers, complete with corresponding examples.

<header>
<h4 class="header-header">
<a href="http://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-Wesley/dp/0321721330">
Practical Object-Oriented Design in Ruby
</a>
</h4>
<p class="header-subheader header-subheader-bold">$32</p>
<p class="header-subheader">Ruby</p>
</header>

The four languages I mentioned [in my last post](/2015/11/how-you-can-learn-to-program-choosing-a-language) are all [object-oriented](https://en.wikipedia.org/wiki/Object-oriented_programming). Objects are an abstraction in programming used for storing data and for attaching behavior. They are extremely flexible, so it's helpful/necessary to have guidance on how to organize them and how to have them interact with one another. I'd read some material on object-oriented design before but nothing that stuck quite the same way this book did, and I'd highly recommend it to anyone who wants to make their code structure more intuitive and easy to follow.

<header>
<h4 class="header-header">
<a href="http://addyosmani.com/resources/essentialjsdesignpatterns/book/">
Learning JavaScript Design Patterns
</a>
</h4>
<p class="header-subheader header-subheader-bold">Free (online version)</p>
<p class="header-subheader">Javascript</p>
</header>

This book is great introduction to programming paradigms known as [design patterns](https://en.wikipedia.org/wiki/Software_design_pattern). Design patterns are well-established ways for structuring your code to perform common tasks. They are also well-known among experienced developers, providing a common vocabulary for developers to communicate and allowing complex topics to be expressed in just a few words. This book provides examples of both general programming design patterns as well as ones specific to Javascript/frontend, and it's even more awesome that it's free online.

<header>
<h4 class="header-header">
<a href="http://www.amazon.com/Head-First-Software-Development-Pilone/dp/0596527357">
Head First Software Development
</a>
</h4>
<p class="header-subheader header-subheader-bold">$32</p>
<p class="header-subheader">Java</p>
</header>

The Head First series tries to find a creative way to teach concepts and for the most part people enjoy its quirky style (though it's definitely not for everyone). This is one of the more accessible books I've found about the overall process of software development. It deals with topics like understanding what the customer wants, project tracking, testing, working with other developers, etc., basically talking about everything a software developer deals with other than actually writing code. This book may not be applicable for everyone as your ability to implement its advice is very dependent on your company culture, and it's geared towards a project management methodology known as [Agile](https://en.wikipedia.org/wiki/Agile_software_development). Still, there is enough general advice here that I think it's a good introduction to what your life will be like if software becomes your career.

#### Closing thoughts

In spite of the nature of this post, I want to communicate that programming is learned by doing rather than by reading. __Someone who consumes every single one of these resources and never builds their own website or project is likely way worse off than someone who reads nothing and just futzes around with code to figure it out__. These materials should only supplement your education, and your education should be primarily obtained through building and shipping code.

You'll have many questions along the way, so don't hesitate to post on the sites that are built for this. [StackOverflow](http://stackoverflow.com/) is legendary in the programming community, but there are others, like Reddit's [/r/learnprogramming](https://www.reddit.com/r/learnprogramming/) and [Quora](https://www.quora.com/). Programmers can be bullheaded and pedantic, but I've found them also to be exceedingly willing to help one another when asked.

Are there any resources you felt like I made a mistake in leaving off? Have any questions about the process, or need some inspiration? Leave a comment below; I'd love to see what I can do to help. I wish anyone who's embarking on this journey the best of luck. I hope it's as great for you as it has been for me!


A small collection of resources and what I think they can teach you if you're just starting out

How you can learn to program: web development resources

If you've read [my story](/2015/03/how-i-learned-to-program-part-1/), you'll know how much learning how to program has changed my life. I've gone from working at a passionless job to working at one of the most competitive tech companies in the world doing something I greatly enjoy. If you've also been thinking about learning how to program, I'd like to devote a few posts to get you started.

Today's post is about selecting your first programming language to learn. Selecting languages and frameworks can always be a bit of a holy war, so I'll stress that this is a personal choice and these recommendations are based on my opinions and area of expertise, which is web development. If you're interested in mobile app development, games, systems programming, or something else, this post won't be nearly as useful to you.

So here's the thing about choosing a language:

#### It's really not a big deal

It honestly doesn't _really_ matter which language you choose to start, so you shouldn't feel the need to hem and haw about it too much. A large majority of concepts that you learn are going to be applicable to other languages. Languages are also constantly evolving, so even the more specific features of one language may wind up making their way into another language in the future as well. That being said, you still have to pick one, so it's good to get at least a little guidance on how to do so.

#### Factors to consider

I'll elaborate more on all of these in the below section when I start talking about the languages, but here's what I look for when I evaluate a language:

1. __Tools__ &mdash; You shouldn't have to [reinvent the wheel](https://en.wikipedia.org/wiki/Reinventing_the_wheel#In_software_development) when you're writing code. You'll want to choose a language that offers well-tested tools, libraries, and frameworks that people are using on other live sites.
2. __Community__ &mdash; Somewhat related to the above, if no one is using it, no one will be releasing new tools or updating the old ones. Having a strong community also means people to answer your questions on [StackOverflow](http://stackoverflow.com/) or other Q&A sites.
3. __Getting started quickly__ &mdash; There's a lot of magic in being able to go through a short "Getting Started" tutorial and to immediately open your browser and see it render something cool you've created. Learning programming is hard work, and I believe it's important for a lot of people to be able to experience this magic before being sold on going down this path all the way. There are languages that are a real slog to get started in, and it's possible to optimize for this quality when selecting your first language.
4. __Syntax__ &mdash; Maybe a bit trivial compared to the other three factors listed here but I like languages that do a lot with few lines of code and are easy to read.

#### What I'd recommend

Out of all the languages I know and given these factors, here are the languages I'd recommend, in order. Note that it's been awhile since I've heavily worked with some of the non-Javascript languages so parts of what I say may be out of date now. I apologize especially if I've left your favorite framework(s) off these descriptions:

##### Javascript

If all my skills were erased today, and I had to choose how to specialize again, there's no question I would re-up in front-end development. I remember my decision to focus on front-end development was largely influenced by the fact that for now, web apps and websites all require HTML, CSS, and Javascript to render, so it would never be a waste to get super proficient at those three technologies. Now that [Node.js](https://nodejs.org/) exists, Javascript is also available on the [server side](http://programmers.stackexchange.com/questions/171203/what-are-the-differences-between-server-side-and-client-side-programming), so you can build a rich, fully-functional website or web app using only a single language. If you're just starting out, you really can't go wrong with specializing in front-end. The job market for such skills has skyrocketed in the past few years and doesn't show any signs of stopping.

There's no shortage of well-supported tools for Javascript. Javascript has been dominating as the [most commonly-used language on GitHub](https://github.com/blog/2047-language-trends-on-github) for the past few years. On the client side some of the most popular tools are [ReactJS](https://facebook.github.io/react/), [AngularJS](https://facebook.github.io/react/), and [EmberJS](http://emberjs.com/), and on the server side you have [ExpressJS](http://expressjs.com/).

Learning Javascript first is not without its issues, as there are some unique language features and quirks that you won't find in any of the other mainstream [object-oriented](https://en.wikipedia.org/wiki/Object-oriented_programming) languages. Concepts like [prototypal inheritance](https://en.wikipedia.org/wiki/Prototype-based_programming) and [invocation context](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this) don't translate well from similar concepts in any other language. You can make a career out of only knowing Javascript, but I still think there is tremendous value in learning at least one other language at some point as well.

##### Python

Python is commonly thought of as offering a good balance between being explicit and concise. I would say it's the most easy-to-learn language on this list because of how explicit it is about everything it's doing, and its syntax is clean and easy-to-read. These qualities make it the tool of choice for teaching Computer Science many in university courses. The most popular frameworks that I know of are [Django](https://www.djangoproject.com/), [Flask](http://flask.pocoo.org/), and [Pyramid](http://www.pylonsproject.org/).

##### Ruby

I want to put Ruby higher on this list because I like it so much, but I'm not sure I can. Syntactically it resonates the most with me because everything is designed for maximum conciseness. It abstracts away so many details to allow you to write code that resembles plain English. However, the dark magic involved in accomplishing this goal is a double-edged sword, as it can be incredibly difficult to understand what is wrong if something does go wrong. The implication for beginners is that 95% of the time when you do something in Ruby you'll be thinking "wow, that was incredibly easy", but the other 5% of the time you will be questioning all your life decisions. The other main criticism of Ruby is that [it's slow](http://stackoverflow.com/questions/2529852/why-do-people-say-that-ruby-is-slow), and many companies, most notably Twitter, have switched from Ruby to Java after Ruby's slowness could no longer be tolerated.

The framework [Ruby on Rails](http://rubyonrails.org/) dwarfs all other Ruby libraries in popularity (and used to be the frontrunner on GitHub until the Javascript revolution took hold). I don't think I've found a more robust set of tools that allowed me to integrate functionality trivially that it would've taken me weeks or months to implement and test otherwise. The above languages also have a strong set of tools, but the ease of use and the wide availability of the tools on Ruby are, in my opinion, second to none.

##### Java

I hesitated a bit in putting this here, but it earns a spot having been my first language. The reason I wanted to leave it off is because of it's not at all easy to get started using Java. Java is often the language of choice for Enterprise applications, and its reputation as being an extremely [verbose](http://maxgfeller.com/javaclassnamegenerator/) [language](http://projects.haykranen.nl/java/) is well-deserved. The aspect that makes it a good beginner language is that it forces you to learn more about what's going on under the hood, such as [compilation](https://en.wikipedia.org/wiki/Compiled_language), [static typing](http://stackoverflow.com/questions/1517582/what-is-the-difference-between-statically-typed-and-dynamically-typed-languages), and a bit of understanding about memory management. There is so much value in working with statically typed and compiled code that there are now tools in Javascript such as [Typescript](http://www.typescriptlang.org/) that allow developers to write in such a way.

I wouldn't recommend Java as a first language for most people, but if you want to come right out of the gate learning more of a foundational understanding of Computer Science, Java offers a good balance between some high-level abstraction and understanding what your computer is actually doing when you run a piece of code. Another perk is that basically all other languages geared towards web development will seem quite easy by comparison if and when you learn them!

#### Again, it's really not a big deal

Despite how long I spent talking about the pros and cons of the different languages here, I just wanted to stress that the most important thing is just to pick a language and to start creating something awesome. Start with really simple things that would be useful to you. For instance, my very first app was a Java flash card app to help my now-wife study for her GREs. Doing something that matters to you will help keep you motivated to finish your projects. In my next post, I'll sum up some of the resources that have helped me do that and will hopefully help you too.


A non-definitive, totally subjective guide to choosing your first web development language

How you can learn to program: choosing a language

#### Intro to front-end development 
*Note to non-technical people: contains more technical language than the rest of my story*

[When we last left off](/2015/03/how-i-learned-to-program-part-2/), I had ramped up on full-stack web development and was finishing my time at my first web development job. My next job landed me at a bigger startup, doing full-stack development at first. I was shifted around on a few projects before landing as the tech lead for a product developed using [Backbone.js](http://backbonejs.org/) (a Javascript framework) and [Marionette](http://marionettejs.com/) (a library written on top of Backbone). Javascript is the language that runs in your browser, and it’s exploded in popularity in recent years. I haven't mentioned my Javascript experience until now because in my earlier career it mostly consisted of hacking together truly terrible code, and I had never even heard of the concept of using a framework to organize my front-end development.

The system architecture for this app had been set up primarily by a developer who left the company shortly after getting everything in place. He designed it as a [single-page app](http://en.wikipedia.org/wiki/Single-page_application), which means that the website is a page that never refreshes when you click links and submit forms, but instead fetches data and changes layout as needed. None of the other developers I worked with knew much Javascript at all, and they didn't recognize front-end development as a legitimate field, which was an opinion held by many developers at the time (including me!). After the architect left, my remaining teammates attempted to finish his work, shoehorning programming paradigms from other languages into Javascript. However, in working with the app, I discovered that Javascript was very different from what I was used to.

I'll spare you the technical details, but the result of my teammates writing Javascript without truly understanding it was a barely-usable app that locked up constantly, behaved erratically, and was extremely difficult to maintain or change. Fortunately, the app happened to be in the early stages of a total redesign, and I requested the opportunity to rebuild large portions of it. I took the time to dig deep into Backbone.js, reading through the [entire codebase](http://backbonejs.org/docs/backbone.html). I'd highly recommend doing this exact thing if you are starting out in Javascript (maybe if you're beginner/intermediate. Reading the code for a big project like this probably wouldn't be very productive if you're a total newbie). It's thoroughly-commented and relatively short compared to other similar frameworks, and it will give you a solid sense of well-written Javascript code that lots of people rely on.

As we went through the redesign for this site, I appreciated learning about front-end more and more. While Javascript has its fair share of warts, I saw how far web browsers had come in enabling web developers to easily create rich experiences for users, and I enjoyed the idea of building things that would wow people. There were two books that were unequivocally the most helpful to me while learning:

<div class="row">
<div class="half">
<figure>
<a href="http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides/dp/0596805527"><img class="list-image" src="/images/definitiveguide-thumb.jpg"></a>
<figcaption class="left"><a href="http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides/dp/0596805527">JavaScript: The Definitive Guide</a> – An extremely thorough look at Javascript (it's over 1000 pages). It's not easy to get through but well-worth the read.</figcaption>
</figure>
</div>
<div class="half">
<figure>
<a href="http://www.amazon.com/Secrets-JavaScript-Ninja-John-Resig/dp/193398869X"><img class="list-image" src="/images/jsninja-thumb.jpg"></a> 
<figcaption class="left"><a href="http://www.amazon.com/Secrets-JavaScript-Ninja-John-Resig/dp/193398869X">Secrets of the JavaScript Ninja</a> – Probably my favorite programming book. It contains clear and concise writing about the fundamentals of Javascript and lots of information on the quirks of different web browsers (especially IE). It's getting a bit dated now, but I still review it from time to time, especially before I go to technical interviews. You have to look past the fact that it's actually a samurai on the cover and not a ninja though.</figcaption>
</figure>
</div>
</div>

HTML(5) and CSS(3) were also getting more complex at this time too, which also contributed to front-end development being a real thing. I didn't buy any books on these topics, but I managed to cobble together a working knowledge of these technologies after subscribing to a few weekly newsletters on front-end topics:

1. [CSS Weekly](http://css-weekly.com/)
2. [Web Design Weekly](https://web-design-weekly.com/)
3. [JavaScript Weekly](http://javascriptweekly.com/)

These publications are still going strong and are a fantastic way to get curated updates on what's going on in the field.

I was able to use my newfound knowledge to fix a lot of the issues plaguing the old app, and the intermittent locking up issues went away. Even though there are a lot of frameworks now that make development much easier than Backbone.js does, I'm pleased to have started out with it. I feel like other frameworks provide too much abstraction for a beginner to truly understand what they're doing and how they're interacting with Javascript. Learning Backbone.js first was a great balance between learning the language as well and getting an app up and running.

#### Silicon Valley and Google

Having lived in Boston my entire life, and now on my way to becoming a full-fledged web developer, I set my sights on moving out to the Bay Area in the hopes of being surrounded by ambitious people, finding a mentor, and developing my skillset even more. My wife and I found a natural transition when she graduated from grad school, and I started applying to jobs. It was my first time looking at new opportunities since I had decided to specialize in front-end development, and because I'd had virtually no guidance in learning this field, I was anxious to see how I'd perform in interviews.

I'd only worked in startups up to that point, but I'd always set my sights on the idea of working for a big company and enjoying free food and other perks, so I reached out to a friend of a friend at Yahoo, who was able to put in a referral for me. I put a lot of effort into my interview and managed to land a job as a front-end engineer on Yahoo Mail.

My tenure at Yahoo was fairly short, however, as a recruiter from Google reached out to me about 6 months after I started. I had always wanted to apply, even when I was still in Boston, but had never worked up the courage. I know it's not a healthy view, but I was fairly content to be someone who had no idea whether he was good enough for Google rather than someone who knew he wasn't. When this recruiter contacted me, I had no more excuses, so I said I was interested and started on a pretty intense interview process.

The interview started with a coding exercise, for which the recruiter encouraged using Google technologies to do. At the time, Google's Javascript framework [AngularJS](https://angularjs.org/) was becoming the most popular way to write Javascript on the Internet, and I'd been wanting to learn it for awhile. I pulled an all-nighter (not done since college) to learn the framework enough to get the project done within the timeframe allotted.

After that, I went on a bit of an emotional roller coaster ride as I went through several technical interviews with multiple teams over the course of three and a half months. Finally, I got the call that a team had been found for me, and I started a job at Google. And I lived happily ever after&hellip;

#### What's next?

It's been a pretty intense journey so far, and I'm excited to see where it continues to lead me. Although all developers need to keep learning to avoid slipping into irrelevance, the web is constantly changing, and good front-end developers, in particular, need to really stay on top of their game to keep up with all the new features that browsers release. This can be quite tiring, but it's also cool to see how else we can be enabled to serve our users even better. So I'm pretty much in a constant state of being exhausted and excited at the same time.

In my next and last post of this series, I'll offer a few final tips for people who are hoping to make this transition, both from my own experience and also the opportunities that I've seen spring up during my few years of doing this. Thanks for reading so far!


Learning to love front-end development and finding my way out to Silicon Valley

How I learned to program - part 3

[Part 1 here](/posts/how-i-learned-to-program-part-1/)

#### Back to the basics

As I mentioned in my previous post, I was at the point in my career where I needed to go back and start exploring some of the concepts that are second-nature to most Computer Science majors, namely data structures and their algorithms. For the unfamiliar, these are well-established paradigms for dealing with typical programming-related issues such as sorting, storing, and retrieving data.

You can actually go surprisingly far in this industry having only a shallow knowledge of these concepts, and some people I’ve met who have been doing web development for several years actually have no knowledge of it whatsoever. Indeed, most programming languages have built-in solutions for these sorts of problems already, and the ones you’d have to work on yourself only make a big difference when you have tons of data. I can only count a handful of times when deep knowledge of data structures has actually been useful on the job, and even then I would say it wasn’t strictly necessary. There’s been some discussion over the past few years whether engineering candidates (particularly those specializing in front-end) should be required to have a strong knowledge in this area.  However, learning these concepts has helped inform my way of thinking and improved my overall ability as a developer, and furthermore many companies (especially the tech giants) will likely ask questions in this arena during their interviews. It is likely in your best interest to study this area.

I have to admit that knowledge of data structures eluded me for many months. I made many attempts to get this material under my belt, and I struggled to find the right medium for learning this subject. Most books on the topic are quite academic and a bit obtuse, more useful as reference manuals than tutorials.

#### MOOCs to the rescue

Luckily, around this time, Massive Open Online Courses (MOOCs) such as [Coursera](http://coursera.org) and [Udacity](http://udacity.com) were on the rise. The algorithms courses ([part I](https://www.coursera.org/course/algs4partI) and [part II](https://www.coursera.org/course/algs4partII)) taught by professor Robert Sedgewick, a renowned Computer Scientist from Princeton, were the ones that finally made it all click for me. The instruction was clear and straightforward for such a complex topic and the exercises were helpful. I can’t recommend this course enough if you are in software and are looking to fill this particular knowledge gap.

While I was looking to learn data structures, I ended up taking a bunch of other courses in an attempt to solidify my knowledge. A particularly helpful one was Udacity’s [Web Development](https://www.udacity.com/course/cs253) course, taught by Reddit’s co-founder Steve Huffman. While a lot of this turned out to be review of HTML, I got a really great overview of the internals of HTTP, the protocol that the Internet runs on, as well as an introduction to the Python programming language and using [Google App Engine](https://developers.google.com/appengine/?csw=1). The course ended with a glimpse into the technology stack that Reddit employs, and it offered a real look at how a site might handle traffic on the scale that Reddit does.

#### The deep end (systems administration)

After I had been at my first job for a little over a year, my supervisor/mentor announced that he was leaving, and he trained me to take over all the server administration in his stead. I learned quite a bit about the server configurations, proxies, load balancing, and database replication. These topics aren’t nearly as mainstream as most of the others that I’ve talked about, so it can be pretty tricky to learn some of them on your own. If I’m being honest with myself I’d definitely say my knowledge in this area is pretty shaky. My only recommendation as far as a resource to learn this stuff would be &#8220;a mentor.&#8221; It’s rare as a front-end developer (unless you’re the only developer/a CTO) to be in a situation where you will have to work on sysadmin stuff a lot, but in most jobs (even at big companies) there will be many situations in which you’ll find that knowledge of this domain helps you do your job much better.

With my supervisor gone, I was the sole developer for a little while. It was a great challenge for me to maintain the site as both the sole developer, and to be on call for any outages and what-have-yous that the site ran into. However, despite having more responsibility and eventually a few interns as my direct reports, I stagnated. It’s tough to be at a place where you are the most experienced developer with just a year of experience, so I eventually sought out new opportunities.

In case it wasn’t obvious from what I’m writing, I think it’s absolutely crucial to find a good mentor early in your career. Even as I write this, I am amazed when I think about all that I learned during my first year of development. I’m very grateful to have had the opportunity to grow so much when I was just starting out.

My next job was when I started to specialize in front-end development and how I prepared myself further for working at big companies. I’ll talk more about these topics in the next chapter.


Learning data structures and algorithms to uncover the fundamentals of my craft

How I learned to program - part 2

A few people on Twitter have expressed interest in hearing my story about how I went from doing research at a pharmaceutical company to working at Google within the span of 3.5 years. I'm more than happy to relate my experience for anyone else who might want to make a similar leap. However, keep in mind that my experience of learning may be very different from the ideal path now. The rapid growth of web development has led to an enormous proliferation and abundance of learning resources, and these days there are many guides for you to follow that didn't exist when I started. I want instead to tell you my own story, provide some general guidance about the process, and to convince you that now more than ever, anyone can learn to program.

#### In the beginning…

At the time I started learning how to program, the only prior exposure that I had to the subject was a C++ class I took in 7<sup>th</sup> grade at a summer school I attended. As some of you may imagine, programming is a bit intense and obtuse for a typical 7<sup>th</sup> grader, and on top of that C++ isn't as accessible as the vast majority of languages available today. The whole experience was frustrating and managed to convince me for a few decades that programming was just not for me.

I started to explore other options when I became dissatisfied with my career path in biotech research. I talked to a few programmers I knew and figured out that web and application development were diverging fields. I hadn't really figured out which of those I wanted to explore more, so to start somewhere I chose Java. I felt (and still feel) that Java offers the best balance between allowing a new developer to learn the basics about what is going on under the hood while not getting bogged down in the details that made C++ so not fun all those years ago.

I picked up [Head First Java](http://www.amazon.com/Head-First-Java-2nd-Edition/dp/0596009208) and started studying and practicing. Being unhappy with your career really lights a fire under your ass as far as getting started with a new one. I remember coming home from work many days and studying non-stop until I went to sleep, pausing only to eat. For anyone attempting to do this now I'd strongly recommend deciding to build a project and using that goal to guide your learning. I committed to building a flash card app for my wife (then-girlfriend) who was studying for the GREs. Even though the app sucked and was pretty useless for studying, I'm not sure how much would've stuck if I hadn't built something myself using what I learned.

#### My first development job

Around 7-8 months after I had decided to leave my field, I decided that I was also ready to take a shot at finding a real job. I was referred by my friend to a programming internship at a startup. Since this was a web development position, I knew I had to do a blitz to learn HTML and CSS well, so I read [CSS: The Missing Manual](http://www.amazon.com/CSS-Missing-David-Sawyer-McFarland/dp/B00D1GHTIG) and [HTML and CSS web Standards Solutions: A Web Standardista's Approach](http://www.amazon.com/HTML-CSS-Standards-Solutions-Standardistas/dp/1430216069), both amazing resources at the time, but outdated now (already!). I sent the company my resume. However, my credentials were such a terrible match for the job description that the company assumed I must have applied for the wrong role and screened me for a different job instead.

Luckily, I got that sorted out and they scheduled me for an in-person interview. I learned that the company used PHP and not Java, so I bought a copy of [PHP 6 and MySQL 5](http://www.amazon.com/PHP-MySQL-Dynamic-Web-Sites/dp/032152599X) to study for my interview. I saw that the constructs of programming (e.g. if-else statements, loops, variables) are the trickiest parts to learn, and that the particulars of the language are mostly just details, at least for a beginner. However, I did the interview and walked out feeling like I had bombed it, but the interviewer (who would be my supervisor and mentor) saw potential in me somehow and the company still gave me an offer. The only issue was I would have to take a huge pay cut: the job paid basically minimum wage.

I know that some would argue that taking the job for that salary cheapens not only my skills, but also the entire industry. I definitely understand the concern, but I think in the end, you have to decide what makes the most sense for yourself. If you can afford to take a huge pay cut to learn what you have to learn to be marketable in your target industry, I believe in most cases you will find that you got a bargain. The difference between trying to cobble together an education in your evenings vs. being thoroughly entrenched in programming problems 40 hours a week should be fairly obvious.

#### Leveling up

I was one of only two full-time developers at my company, and being a part of such a small team required me to learn a broad range of topics very quickly. I started to learn  concepts I hadn't been exposed to before. I learned about databases and MySQL (partly from that book I bought, but mostly on the job). The tech stack featured [Symfony](http://symfony.com/legacy), a PHP framework, and I finally got a handle on the Model-View-Controller paradigm, a cornerstone concept for organizing your code. I began my journey to learning the command line and the vim text editor, among many other things. It's really difficult to overstate the difference between my time of self-study and my time of learning on the job. My supervisor was an incredible, albeit sarcastic mentor, and through his frequent berating of my work he taught me the difference between working code and good code.

I was taught that much of programming is spent maintaining and modifying existing code as opposed to creating new code. I quickly realized that it was vital for me to learn the best practices in this industry in order to improve as a developer, and I knew I had to improve quickly to impress my company and get out of this minimum wage business. I had enjoyed the Head First Java book, and to study the concept of good, maintainable code more, I picked up [Head First Object-Oriented Analysis and Design](http://www.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678/) and [Head First Design Patterns](http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124). I also bought the classic [The Pragmatic Programmer](http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X). These books all taught me some tried and true ways to design my code to allow future developers to understand my intent and to change my code to suit their new use cases easily. In short, I kept studying in the evenings, almost as urgently as I had before I got my first job.

After six months, my company promoted me from an intern to an actual web developer and I started making a livable wage. However, the pressure wasn't quite off yet. By this time, I had started to read about what big companies like Microsoft, Google, and Amazon look for in their job applicants. It exposed a huge gap in my knowledge, namely in data structures and algorithms, concepts that should be deeply drilled into any Computer Science student's brain. I knew I still had a long way to go. I'll share more about how I filled in this gap, and how I eventually specialized in front-end development in my next post.


How and why I abandoned my degree and took a job that quartered my salary

Hello! I’m Mike Chen, software engineer, father, and recovering big tech company employee. I write about software, business, and crippling self-doubt.

Posts