My training is in language education - spoken languages, rather than programming languages. I was teaching mostly German at the university and secondary school levels and found that to teach the way I wanted, I often needed web services that didn’t exist. So I decided to learn how to build them.
I work from my laptop, recently upgraded to a 15-inch 2018 MacBook Pro. His name is Sundance. I rarely use a secondary monitor and don’t own a mechanical keyboard or ergonomic mouse. They’d be wasted on me because I do a lot of my work while traveling, like on the train I’m writing this from.
To help me focus, I use a pair of Bose QC35 II noise-canceling headphones. I’d wanted bluetooth, noise-canceling headphones for years, but found it difficult to justify considering the price and problems I often saw reported. They’re still expensive: half the price of a nice phone, which might seem ridiculous considering all they do is cancel and play sound. The noise-canceling is great though, the connection is always reliable, the battery lasts me several days of heavy use, and they’re so comfortable that I can easily wear them all day.
What really pushed me over the edge though, is the fact that I spend a lot of time in environments noisy enough to slowly but steadily damage my hearing - planes in particular. It used to take me up to several days after a flight to hear normally again, but that’s now a problem of the past.
My primary editor is Visual Studio Code Insiders. It took me a while to customize it to the point where I’m really happy with the experience, so keep that in mind if you try it out.
Two lesser-known extensions I use every day are Code Spell Checker and Git Project Manager. The former checks my spelling, even of camelCased or PascalCased variable names. The latter helps me quickly switch between projects, which I do a lot like an open-source maintainer and consultant.
I used to use Zsh as my terminal shell, but I got tired of people who use Fish telling me that it’s better in every way, so I made the switch. The only disadvantage I’ve found is sometimes having to be familiar with how Bash commands translate to Fish. It works pretty well out of the box, but here are some of my favorite customizations to my config.fish file:
I tend to focus on the frontend, where I prefer to use Vue. You can see more details in my vue-enterprise-boilerplate project.
Limited to the frontend, it’s rare for a greenfield project not to include all of these after the first month of development:
- Vue (framework), Vue Router (routes), and Vuex (state management)
- Cypress (end-to-end tests)
- Jest (unit tests)
- Lodash (utilities)
- Cuid (collision-resistant ids)
I do a lot of enterprise work, where you often don’t have the luxury of choosing every piece of your technology stack. However, whenever I get the chance to work with GraphQL APIs, I love it. I’m really looking forward to the day it overcomes REST as the most common API format.
I also really enjoy working with real-time data over web sockets. UI development becomes so much simpler when you can rely on prefetched data that you know will remain up-to-date as long as the user has an Internet connection. Unfortunately, this too is a rare opportunity.
I’m always learning, but my really heavy learning happens in cycles: I spend a period of time voraciously devouring a new topic, then getting as much practical experience applying what I’ve learned as possible, and finally writing and/or talking about it with others. My biggest learning project right now isn’t actually related to technology, but mental health.
My brain works a little differently than most people’s, which I’ve mostly learned to manage, but it still breaks much more than I’d like. By “breaks”, I mean terrifying panic attacks and periods of (often very deep) depression that can last anywhere between a few days and a few months. I’ve recently entered the practical application stage of my learning cycle, experimenting with new strategies to take better care of my brain.
Honestly, I’m not naturally gifted at anything I do. In my first computer class, the teacher became so frustrated that she just asked me to sit in the corner and read, warning me not to touch another computer. Today, when writing both code and documentation, my first drafts are often pretty terrible. It’s only through obsessive iteration that I end up with a result I like. And in my open source projects, there are so many others who are critical to their development that I’m not sure it makes sense to take much personal pride in them.
However, if I had to identify a skill I’m proud of, rather than a project, it’d be my ability to productively take part in difficult conversations. That can include giving someone feedback on a talk, helping them develop an idea for a new feature, or doing what I can to help them get the support they need during a difficult life transition. I think my investments in people are much more valuable. They tend to live much longer than software and throughout their lives, they have much more potential to improve the world I live in.
Communication skills. Too often in our industry, poor communication leads to insecurity, defensiveness, misunderstanding, and close-mindedness. Effective communication, on the other hand, builds everyone’s capacity and passion for their work.
When we communicate an idea effectively, we’re telling a story. Effective stories start from language that’s already well understood by their audience. When words have multiple meanings, like server or API, it’s important to clearly establish the context - or use a different word. When naming or describing concepts, clarity is more important than brevity. For example, function that returns a function is much more descriptive than higher-order function - and it’s only two syllables longer.
Great stories are also specific. Remember that when you’re tempted to fall back on arguments like, “it won’t be maintainable” - that’s not specific. What does unmaintainable mean in this case? Will it be difficult to troubleshoot specific kinds of bugs? Explain which bugs and why. Describe the specific problems you encountered in the past. Will some sections of code start to feel overwhelming in their complexity? Show an example. Will it be more difficult to build new features? Describe which features and the difficulty in detail.
Similarly, phrases such as best practice, idiomatic, or functional are best avoided when arguing for or against specific patterns. These terms don’t address the why and worse, discourage further questions. Instead, focus on the real, human problems you’d like to avoid and why you think a specific pattern might help address them.
And ultimately, there’s really only one human problem that matters: “How will this make us more excited to come to work tomorrow, a week from now, or a month from now?” When you and your team are excited about your work and eager to keep learning and improving, the product will thrive.
I work with a lot of different organizations, so it’s a wide range. On the Vue team though, one significant challenge is taking advantage of all the newer non-polyfillable features supported in modern browsers, while also maintaining a great experience building applications for legacy browsers lacking these newer features, such as Internet Explorer.
If you enjoy hearing people giggle in delight while they learn more about Vue and its ecosystem, subscribe to the Enjoy the Vue podcast. You can also support my open source work on Patreon and the entire Vue project on our Open Collective.