Professional Lessons I’ve Learned In My Twenties

I maintain a Google Doc with a thousand bullet points in it. When I’m feeling inspired or think I’ve just learned something useful, I write it down. I’ve wanted to turn some of these points into blog posts, but that’s a lot of work, so here’s a big list of useful things I’ve learned as an engineer.

20

Themes: Interning in NYC, working on lots of side projects to build a portfolio, being incompetent with any sort of software development.

• Write things down.
• Be noisy when you’re blocked on something at work. It may feel like you’re being a bother, but that’s usually better than wasting a day or two doing nothing at all.
• Don’t get too content, and don’t take yourself too seriously.
• Be okay with failure, or a lackluster response to any work you put out there.

21

Themes: Finishing college, interning in San Francisco.

• Ask more questions. If you’re not sure if the question in your head is well thought-out, ask it anyway.
• Some days you’ll feel like you’re getting nothing done, and that’s okay. Catch up on some conference talks, read some blog posts, or change a few CSS variables. Move forward every day, even if only a little bit.
• Code review can be scary, but you’ll probably learn a lot from it.
• Don’t forget to remind yourself how good you truly have it.
• The folks you idolize are just people: they may have a couple amazing qualities, but they have plenty of flaws just like you.

22

Themes: Landing my first full-time job, lots of 1:1s with John and Marcia.

• Some of the best engineers don’t have time to maintain an awesome GitHub profile full of projects. They do amazing work and go home at 5.
• It’s awkward to ask advice from people you look up to. Do it anyway. Years later you’ll have great notes, and you’ll forget how nervous you were or how silly you sounded.
• When your projects are derailing, don’t take it personally. Many things are out of your control, but one thing you can control is how you communicate your problems. Your colleagues are there to help you, and want you to succeed.
• Don’t write for the experts: write for the people at your level, or the vast majority of people who can benefit from what you’ve learned. You always have an interesting perspective to offer.

23

Themes: Transition to working remote full-time, lots of habit discussions with Steph.

• Working hard and resting are not at odds with each other. Rest so that you can work hard.
• Go. Out. Side.
• Give your habits the freedom to bend without breaking. You can skip a workout and still claim you run every day.
• A backlog implies a queue that you’re going to drain, but you’re probably not going to do that. In fact, draining your backlog of projects would most likely not be the best use of your time. Sort them into categories, or throw them out.
• Print out tweets from your haters and put them on your wall.

24

Themes: Lots of 1:1 mentorship sessions with Andy, productivity, mental health.

• You can’t control your output, but you can control your momentum.
• You may never publish that blog post, but that’s okay. Writing things down is a great way to better understand your thoughts even if no one ends up reading it.
• Getting on the scale every day is not useful: there’s too much noise. Reflect on your progress over time, and don’t fret about all the peaks and valleys in between.
• Often times changes to your work habits are only better because they are different. If you find yourself more productive without music, don’t get bummed out when it stops working a week later. Shake things up.
• Take care of your brain. You wouldn’t keep working with a broken hand, you’d give it time and care to heal.

25

Themes: Quit a job for the first time, did nothing for 7 months, got a new job.

• When a fun idea seems like it may have some potential, write down a list of things you don’t know and things you do know. Your goal is now to move stuff from the first to the second.
• Use your fresh eyes at your new job to fix some stuff, you won’t be new forever.
• No one on that other team is going to ask you to spend time cleaning up abstractions or writing some much-needed unit tests for your code. Carve out time and do it.
• Write a lisp interpreter in lisp — if you want.
• Pair programming is fun, but it’s also really taxing. Consider pairing with someone on code review as a break. It can be your code, or theirs, or maybe some other teammate’s, but you’ll find the knowledge sharing invaluable.
• Share your LEGO.

—

Be sure to follow me on twitter where I post lots of killer one-liners, and plenty of bad jokes.