“I think I’m having a heart attack”

In 2011, I was part of the Summer class of Y Combinator, working on a startup creating online games, and I was stuck on a problem.

I hadn’t slept well for days. Weeks. I stayed up as long as I could keep my eyelids open each night, powering through work with tons of caffeine. I NEEDED TO FIGURE THIS OUT.

One night, as my hands started to shake, and my heart pounded in my chest, I called my wife and told her:

“I think I’m having a heart attack.”

We’ve all been in situations where we needed to come up with solutions to tough problems. Probably more times than you want to remember. And, I bet, all that thinking sometimes led to some headaches and stress.

But did it lead to a good decision?

In 2009, 4 researchers, Loran Nordgren (Northwestern University) and Ap Dijksterhuis, Maarten Bos, and Rick van Baaren (Radboud University Nijmegen), wanted to find out.

So they gave study participants a decision to make: which car is the best quality (as determined by outside judges) given a set of criteria to read. One group of participants was given simple criteria to determine the quality of those cars, while the other group of participants was given more complex information.

Then, each of those groups of participants were either given time to think consciously about their decision on which cars were higher quality or the participants were distracted by a game so they didn’t have conscious thought available to spend thinking about these cars.

Of the participants who only had to come up with car quality decisions based on simple criteria, they all did well, whether you had to think consciously about it or you were distracted. No big surprise.

But, for the complex car decision, this is where it got interesting.

The people, who spent conscious time just thinking about their decision on which car was the highest quality, only got the decision right 20% of the time. That’s much worse than a coin flip. But of the folks who were distracted by something else, they were right about 60% of the time.

This was just a lab result though. Does it work in the real world?

The researchers came up with another experiment. This time, they went through a bunch of products from a store like IKEA. They had a set of separate judges rank 40 products from simple to complex purchases. Then these researchers went and surveyed people who bought these products. The survey asked participants how much time they thought about making their purchases beforehand. Was it a lot of conscious thought or unconscious?

For complex purchases, it was the people who spent less time thinking about the purchase beforehand who were happier with their purchases weeks later.

Now, this isn’t some black and white strategy. But it sure does lend evidence that “sleep on it” before having to make a complicated decision sounds like pretty good advice.

A few weeks ago, we moved our backend provider for how we store files in Highrise.

It wasn’t going that well.

This is some stuff that’s been running for years. Changing it introduced all sorts of problems in corners of our application that hadn’t been explored in a while. There was plenty of planning and procedures to back out of trouble. But still, on a Thursday morning at 3AM, Michael Dwan, our CTO, and I found ourselves putting out fires.

I was a wreck the next day. Completely useless. I should have just taken the day off.

But… I’ve learned my lesson.

I got to bed early on Thursday. Friday I took the whole afternoon off to just hang out with my kid and my mom. We went to the zoo. Had lunch. It was fantastic and I felt recharged.

Five years ago, when I called my wife about my impending heart attack, I had already been powering through weeks of sleep deprivation with Red Bull and coffee, despite the constant advice from partners at Y Combinator to take care of ourselves. But that night, I decided to try a shot of 5 hour energy just to top things off.

Thank god I was eventually able to calm my breathing and heart rate. Hopefully I haven’t caused myself permanent damage. It’s a lesson that sticks with me deeply today. What was I thinking? That was freaking scary.

For what? What was it all worth? For my startup to succeed? That software I was working on isn’t even around anymore.

And I never did come up with a solution to the thing I was struggling with the most during those caffeinated benders. Maybe I could have, if I had just gotten plenty of sleep.

P.S. You should follow me on YouTube: here, where I share more about how we run our business, do product design, market ourselves, and just get through life. Also if you’ve enjoyed this article, please help it spread by clicking the below.

And if you need a no-hassle system to track leads and manage follow-ups you should try Highrise.

Just starting out? Ditch the “full stack developer” label

The words you use to represent yourself matter — and those words mean nothing.

The only time “full stack” means something. 😍

The vagueness and confusion around the phrase “full stack developer” has been lingering for years. Google it and you’ll find plenty of discussion about why it’s such a loaded term.

Given that long-standing vagueness, labelling yourself as “full stack” might be doing you more harm than good, especially if you’re just starting out.

🥞 Are you being honest?

“Full stack” basically implies that you can do it all — that you can build front to back effectively and ship.

But can you really do all of that well?

Anyone with some programming experience can learn the basics of something new and cobble a solution together. But that certainly doesn’t make it good software — a goal every good, experienced programmer strives for.

When someone with a few years experience labels themselves as a “full stack developer”, I’m pretty skeptical. Is there really enough experience there to be good at everything? I’m not saying it’s impossible, but it’s certainly not likely.

Not to mention, what’s a “stack” in 2017 anyway? HTML, CSS, Javascript, Rails, Node, PHP, Go, Python, React, Angular, MySQL, Oracle, Swift, Kotlin, Android, iOS, .Net, Java, jQuery, Mongo, Redis…about a thousand other things?

Here’s the important thing to remember — knowing your limitations isn’t a sign of weakness or impostor syndrome. It’s a sign of honesty, and that in itself is a major strength.

Don’t sell yourself short, but don’t be afraid to acknowledge your (current) limitations either. People will respect you for it.

🥞 What matters to you? What’s your focus?

Referring to yourself as “full stack” doesn’t express any opinions or preferences — it’s vague, broad, and bland. It’s the equivalent of saying “I’ll do whatever work, it doesn’t matter to me”.

And if that’s the case, well, stick with that label. But if the work does matter to you (and it certainly should), speak your mind.

If Rails is your favorite technology, say so — be proud of it! If Javascript is your thing, huzzah! Just don’t fall back to labelling yourself with a bullshit buzzword that everyone else uses.

Saying you’ve been “A proud, productive Ruby on Rails programmer for two happy years” sounds a hell of a lot better (and means a lot more) than “full stack developer”.

Along the same lines, don’t overdo it when presenting your skills.

“Full stack developers” are often the same folks who list out the dozens and dozens of skills they have. Whether they have those skills is irrelevant — it gives the appearance of a quantity-over-quality cover story.

When listing out your strengths, be sure to keep the list short and focused. A handful of really strong talking points is far better than a wall-of-text laundry list of skills. It demonstrates clarity in your thinking and a healthy opinion on what matters to you.

The bottom line is this: the words you pick to represent yourself really matter, especially when you’re just starting out. “Full stack” is far too bullshitty to do you any good.

Figure out your limits, be honest, and focus on what you enjoy most. Express those in your work and how you talk about yourself. You’ll have a clearer head and will be positioning yourself for a much happier, long-term programming career.

If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making the various stacks of Basecamp 3 better every day. Check it out!

How I became (and stayed) a successful programmer

3 strategies that have been crucial to the longevity of my programming career

For a while now, interest in programming has been skyrocketing. So there are a lot of beginners out there starting their careers — and that’s a wonderful thing!

If you’re one of those beginners, eventually you may start thinking about the long-term prospects of your new skills: How do I take a new skill like programming, grow it, shape it, and tune it over time so I can achieve longevity in the industry?

I asked myself that same question early on in my career. Now, a mere 15 years into it, I’m hoping I can give you some answers.

Below are a few general strategies that have helped me become (and stay) a successful programmer over the long haul.

1. I surround myself with programmers who are way better than me

Over the course of my career, I’ve always tried to pick work where the people I’d be working with are exceptionally talented. To put it more bluntly, I put myself in the company of programmers who were way better than me.

This is crucial, because the best way to improve (at anything) is to learn from people better than you. It might be a nice ego boost if you know more than everyone around you, but you’re otherwise just flat lining your actual progress.

When I’m around these talented programmers, I constantly keep my eyes and ears open for nuggets of wisdom. I watch how my fellow programmers carry themselves, how they breakdown a problem, how they talk to each other. I look at their code for patterns and style choices that I can mimic. I remind myself to talk less and to listen more.

Unless you’re the Michael Jordan (or dare I say the LeBron) of your respective field, there should always be someone better than you — this is a good thing!

You have nothing to lose and everything to gain in such a situation. Take advantage of it. 🚀

2. I occasionally leave my comfort zone

I’ve found it beneficial to leave my programming comfort zone once in a while. It helps me think differently by challenging a bunch of established ideas I already have.

For sure, you don’t want to do this constantly because it can be hard to get into a rhythm with your normal area of work. But in moderation it can really open your mind to new ways of thinking.

For example, my comfort zone is Java and Android. But over the last year, I’ve taken on stuff well outside that zone:

  • I helped build an open-source framework. Turbolinks Android was the first time I’d ever worked seriously with Turbolinks (new tech to me), it was my first open-source project ever (new process for me), and it was a cornerstone for Basecamp 3 for Android (a new product for the company). It was one of the hardest projects of my career!
  • I started writing Kotlin instead of Java. I’d been writing Java for over a decade, so picking up a new langauge was no trivial task. Not to mention I’d never written a single line of Kotlin previously! But before I knew it I jumped in head first and am now writing Kotlin most of the time. (Incidentally, I’m completely in love with the language!)
  • I’m learning the underpinnings of our open source rich text editor. By learning the ins and outs of Trix, our Android team will be able to better utilize its capabilities now and in the future. But as someone who isn’t totally up to speed on advanced Coffeescript and DOM manipulation, this has more or less melted my brain. But I shall prevail!

Here’s what’s important to remember — none of this stuff was particularly easy or comfortable for me. In fact much of it was downright uncomfortable, nerve-wracking, and filled with doubt. At times I literally felt like I had no idea what I was doing.

But as challenging as they were, I did them anyway because I knew how valuable those experiences would be . They gave me the opportunity to work with a variety of the programmers, let me reacquaint myself with technologies I’d fallen behind with, and let me learn brand new stuff that few others in the company got to. All of that made me a better programmer.

So find a programming task that takes you out of your comfort zone and make it your next project. Then watch it pay off in spades. 💰

3. I value being independent

When you’re just starting out, you’re going to have a lot of questions. That’s OK!

What’s most important is how you choose to find the answers to your questions.

One philosophy that’s always served me well is to be independent. Usually this means that I’ll try to do most things myself first, and only when I really get stuck, I’ll ask for help.

Being independent has tons of benefits, but to name just a few…

  • You learn how to be resourceful. Finding answers may just be one Google result away, or it might take a dozen different queries. You might have to patch together 5 different solutions that you’ve found to work together. Who knows. Finding the answers you need on your own is a skill that’ll serve you well for years.
  • You earn respect by being courteous of other people’s time and work. When you prioritize your independence, working with other programmers is easier. They’ll appreciate that you’ve done a lot on your own and have taken it as far as you can before asking for help. By respecting other people’s time and work, you’ll earn respect back. And mutual respect is the cornerstone for trust and solid teamwork.
  • You start developing your creativity. When you need to come up with answers, you’ll find yourself coming up with creative solutions you hadn’t considered. You’ll try things that seem crazy and out of the realm of possibility. Some will work and some won’t, but you’ll begin to develop a palette of creative solutions that you can draw from many times down the road.

The next time you have a burning question, see if you can answer it yourself, even if it takes a little longer than asking someone. It’ll be worth it.🔥❓✔️

Becoming a successful programmer is, like anything worthwhile, hard work. But these strategies have always served me well in the long run — after all, I ended up getting my dream job working at Basecamp. I hope they can help you get to where you want to be, too. 😀

I hope this article was helpful to you! If so, please do hit the heart button below and let me know on Twitter.

We’ve been working really hard to make the all-new Basecamp 3 and its Android app as great as they can be. Check ’em out, we hope you love them.