A concept that I admire is ‘Doing the Hard Thing First’ via Ben Orenstein. Ben described on the Art of Product Podcast Episode 50. Here’s my summary: Choose the hard part of the problem, the part you’re unsure about, the part that success depends on, and solve that first! The Hard Part of the Problem The hard part of the problem will be the most differentiating, and therefore valuable. If it was easy, there would be no opportunity. You’re lucky that Schlep Blindness has failed to hide it from you. It might be impossible, at least the way you’re thinking about it. Solve that problem first before investing any more time in the idea. ...

I’ve been learning a bit of Python this Fall to facilitate conversations with a mentee. In this post, I’m going to share the first Python function I’ve ever written, a solution to the Exercism challenge ‘Raindrops’. Is this good Python code? I don’t know; that’s why I’m posting it here. I’ve read $ python3 -c 'import this' yet am still gloriously ignorant. Below I’ll share the problem, my solution, and a code self-review via praise and criticism. ...

There is a glut of programming information online. You can’t read it all, and you shouldn’t, because much of it is outdated, wrong, or irrelevant to you. So, what is the signal in this noise? I recommend aggregators, blogs, pair programming. And I offer a gentle recommendation against tutorials. Aggregators I’ve summarized this idea before in a Hashrocket blog post called ‘How to Prepare for a Technical Interview’: I advocate a passive approach: whatever watercooler you frequent (Twitter, Medium, RSS, Reddit, email mailing lists, etc.), find the aggregators. These are people who read everything– blog posts, release notes, conference announcements, Twitter fights– and distill it down into a human-sized product. I subscribe to weekly email newsletters for React, JavaScript, Ruby, and Postgres. Each week, I scan the headlines and one or two articles. You build up a picture of the scene pretty quickly. – ‘How to Prepare for a Technical Interview’ ...

I love Vim. Folks who’ve programmed with me, or attended a Vim Meetup when I was an organizer, can attest. When I was learning to code, getting fast at Vim changed everything for me. After almost a decade using this editor, here are my personal configurations. My Vim Configuration My .vimrc is broken up into groups. If you open this file in Vim, you’ll see why: it’s long, and so it’s folded by groups as a default. This is one of many tips I picked up reading Learn VimScript The Hard Way by Steve Losh, and the dotfiles of programmers I admire. ...

Programming is a new and abstract field, and so we place great emphasis on ideas. When I find one that sticks with me, I end up sharing it again and again. These are some of my favorites. Jeff Atwood, The First Rule of Programming: It’s Always Your Fault. I like to answer questions on Stack Overflow, and a decent number of questions on that website have a title like “I Found a Bug in React”, and a question that starts with: “I’m brand new to React.” It’s human to assume there’s a problem with your tools. Especially starting out, it’s more profitable to assume an issue in your code, because your code hasn’t stood up to anything close to the scrutiny of a popular software project. ...

I’ve been working on a development roadmap for my projects, and wanted to share my process. Consider this my recipe to turn an idea into software. The purpose of codifying a workflow like this is to make working with me a predictable and thorough experience. Writing software is pretty hard; it’s much harder when you don’t have a plan. Every item here is à la carte– I wouldn’t typically do more, but I might do less on projects of modest scope. ...

Here’s a familiar scenario: you open a new terminal, and before the prompt appears, you see the following. You have new mail. What’s going on here? Explanation Events in your operating system can send messages to your mail queue. Although it’s tempting to ignore them because they aren’t colored red or filled with hyperbolic language, you should not ignore these messages. In many cases, your operating system is trying to tell you something important. ...

I’m working on a team where we keep a clone of the development branch (the main place where work is done), used to deploy to a QA environment. The benefits of this branching technique are: clone is isolated from work It’s easy to tell what was deployed to QA– clone is the source of truth Instead of merging, we just reset clone to match the development branch. Here’s the technique: ...

Unused dependencies are bad: they increase the size of your project, slow down your processes, require upgrades, and send incorrect messages to fellow developers about what’s important. Make your project better by periodically auditing your dependencies, and removing those that are unused. If a dependency is in your bundle and is not being used right now, get rid of it! Legacy codebases are littered with rainy-day libraries. Rip them out and start again. ...

Here’s my annual professional review covering 2018. Milestones Here are my milestones from 2019. This year, I: 🎉 Ported this blog from Rails to Gatsby.js. I am ecstatic about this change. Writing React and markdown, and deploying with GitHub, makes for an effortless workflow. I also open sourced the codebase. I’d love some PR’s or issues on the repo. Received a challenge coin from Code Platoon for work as a volunteer. Thank you Rod! I love being a part of this community. Created and administered, along with my colleague Suzanne, an internal Developer’s Survey for Hashrocket. We presented our findings (everybody really loves React and TypeScript) at Hashrocket’s Summer MiniConf. Tried out working 100% remotely. I enjoyed the experience. Along the way, I learned the value of a good coworking space. Doubled my Stack Overflow reputation (1,511 points this year, top 3% of the site for 2019). There are a lot of people out there who need help with their code, and I’m happy to give back. I’m coming for you, Jon Skeet! Spoke at Ancient City Ruby 2019 about React.js. My preparation included some of the most challenging source diving I’ve ever done. My slides are here; video forthcoming I hope. I’m averaging one conference presentation a year, which feels right. Thanks for the opportunity to share, ACR. Mentored four Code Platoon veterans. Proud to have been a part of your journey, Ben, Kyle, Christian, and Hal. Good luck out there. Taught SQL three times at Code Platoon with my friend Jack Christensen. Got paid by a client to write Elixir code for the first time. Attended my first RubyConf with coworkers and friends old and new. Spent some one-on-one time with my programming idols. What did I learn? Here are some of my takeaways after another year in the programming trenches. ...