
<YouTube youTubeId="HX1bMuoZ6II" />

As a part of my work as a DevRel lead for Google Assistant, I did a guest segment on VOICE Talks in August of 2021, talking about why UX research for voice-first experiences is so crucial.


VOICE Talks August 2021: Trust the researchers for voice-first UX


Growing up, I spent a lot of time in the garage with my dad. He's a man of many projects - and hardly a weekend went past where I wasn't helping him work on _something:_ from cars, to household repairs, lawn work or tinkering with electronics. I learned a lot about tools and how to use them, and I learned that the right tool for the job can make all the difference.

Two things that he used to tell me often were:

1. **Power tools are _always_ out to get you.** They may feel like they'll help you get the job done fast, but they're powerful, and they don't care about your fingers. Respect them and act as though they're always trying to hurt you.
2. **There's nothing worse than having to _fix_ your tools.** If you take care of your tools, they'll take care of you. Keep them clean, sharp, and in good working order.

These are both true - and while rule #1 is _less_ applicable to software tools, rule #2 is _absolutely_ something that I've found to be true in my career as a software engineer. The tools we use to get our work done are _incredibly_ important, and taking the time to tune them to work _just right_ can make a huge difference in our productivity and happiness.

## Tuning your tools just feels good

I use Visual Studio Code for nearly all of my coding and writing. I love it because it's quick and customizable, and it just works well. No shade if you're a fan of `vim`; you do you. I dig VS Code, and I've spend some time recently changing up my setup to make it even better.

Here's a few things I've done recently to tune my VS Code experience:

### Houston theme

There's an installable theme for VS Code called [Houston](https://marketplace.visualstudio.com/items?itemName=justusadam.language-houston-theme) which was actually made by the team that makes Astro. If you prefer a dark theme and like some spicy accent colors, you might like Houston.

<Image
  publicId="newsletters/keep-your-tools-sharp/houston-theme"
  alt="Houston theme in VS Code"
  caption="Now that's a delicious-looking theme."
/>

### Zen Mode

[Zen Mode for VS Code](https://code.visualstudio.com/docs/getstarted/userinterface#_zen-mode) is a great way to tune your IDE to be more focused. I use it for writing articles and newsletters. It's _built in_ to VS Code, so you don't need to install anything. Just press `Ctrl + K, Z` to enter Zen Mode, or the `Toggle Zen Mode` command in the command palette.

Straight out of the box, Zen mode is pretty damn minimal - and that's not for everyone (myself included). To customize Zen mode, open up VS Code settings with `Command + ,` and search for `zenMode`. Y

<Image
  publicId="newsletters/keep-your-tools-sharp/zen-mode-settings"
  alt="Zen Mode settings in VS Code"
  caption="I like to use the Center Layout setting for writing articles and newsletters."
/>

### Pieces for VS Code

[Pieces for VS Code](https://marketplace.visualstudio.com/items?itemName=MeshIntelligentTechnologiesInc.pieces-vscode) is... amazing. It's a contextualized note-taking app and code copilot that helps you store, annotate, and generate code snippets in your IDE. Not only is it context aware -- as in, it knows what you're working on as well as the places where you're doing research -- but it also features an _on-device,_ privary first LLM that can generate code snippets and notes _without_ sending your data to the cloud. 🤯

It comes from the lean, mean squad at [_Pieces for Developers_](https://pieces.app/). If Pieces sounds familiar, you probably know about it because of [my interview with their founder Tsavo Knott on Software Engineering Daily](https://softwareengineeringdaily.com/2023/10/25/building-pieces-app-and-the-future-of-developer-productivity-with-tsavo-knott/) a few months back, and definitely not from Scott Hanselman's [recent podcast](https://hanselminutes.com/913/redefining-developer-workflow-with-piecesapps-tsavo-knott) about it. 😅

<Image
  publicId="newsletters/keep-your-tools-sharp/pieces-extension"
  alt="Pieces extension for VS Code"
  caption="Pieces for VS Code is a fantastic use of AI tech."
/>

---

## More from me about whipping VS Code into shape

- Minimalists will appreciate [How to make VS Code load faster with a little bit of housekeeping](https://mikebifulco.com/posts/make-vs-code-load-faster-by-removing-extensions). Spoiler alert: the crux of this one is _getting rid of_ things you don't use.
- If you made the switch from Intel to an M1, M2, or M3 Mac in the past few years, don't miss my article on [Making VS Code Quicker on Apple Silicon Macs](https://mikebifulco.com/posts/make-vs-code-load-faster-mac-apple-silicon). If you're affected by this one, the gains are _huge_.
- This quick tutorial on [using the refactor menu in VS code](https://mikebifulco.com/posts/refactoring-typescript-react-components-vscode) was an awakening for me - I didn't know how much I was missing out on until I started using it!
- If you're a TypeScript dev, there's a couple troubleshooting steps I use to [fix TypeScript errors in VS Code](https://mikebifulco.com/posts/typescript-vscode-error-fix-last-resort) when nothing else seems to work.

---

## Find me online wherever you get your internet

Recently, I've been releasing past newsletters as podcasts - you can find them in your podcatcher under "Tiny Improvements", or if you prefer a direct link, you can subscribe on [Spotify](https://open.spotify.com/show/0H7r0j7q6RXzSie6AbMDwj), [Apple Music](https://podcasts.apple.com/us/podcast/tiny-improvements/id1577037667?uo=4), [Pocket Casts](https://pca.st/itunes/1577037667), and good ol' [RSS](https://feeds.transistor.fm/tiny-improvements).

They're a few minutes long each, and are a ton of fun to make. I hope you enjoy them!

I'm also releasing occasional videos (both short- and long-form) to [my YouTube Channel @mikebifulco](https://youtube.com/@mikebifulco?sub_confirmation=1). I'd love it if you'd subscribe and let me know what you think of the content.

---

## Hey though, how are _you_ doing?

I hope you're doing well. As always, I'd love to know what you're working on, what you think of Tiny Improvements, and what you'd like to see more of. Hit reply and let me know - I do my best to respond to every email I get.

Keep up the good work, and I'll see you in the next one.


Keep your tools sharp

More from me about whipping VS Code into shape

Find me online wherever you get your internet


Recently, I've been asking developers what they think of no-code tools. Friends, I'm here to tell you - some of the responses I've gotten are extremely frustrating.

They range from discouraging to straight up disparaging, especially for newbies who are excited about the prospect of building something for the first time.

"no-code tools?" I had one developer tell me. "What are those? Another bubble that's going to burst?"

"I wouldn't trust any tool that makes it easy for people with no coding experience to make a website," said another. "It's only a matter of time before something goes wrong and we'll have to rebuild it the right way."

"no-code is just a fad," said a third. "Real developers code. That's what separates the wheat from the chaff."

Ouch. I get it. I really do.

Maybe these developers have put in their 10,000 hours (or more) and they've honed their skills to become masters of their craft. They've seen "no-code" come into the spotlight, and they're rightfully skeptical.

But here's the thing: I'm not asking for your permission. I'm not asking for your blessing. I'm not even asking for your approval. I am imploring you to give these tools a serious look. They can save you time, and they're going to go a long way to build the next generation of software developers - whether you're ready or not, no-code tools will be a big part of the future.

## Devs are often insecure about using no-code tools

For some, mentioning the use of no-code tools can induce fear around job security, the validity of use cases for no-code tools, and some future need to “rebuild it later the right way”. This is understandable, but also wrong. Devs are not insecure about no-code because it is no-code. We are insecure about it because of what it represents. no-code is a new way of building things that is not as intuitive for them (yet). It represents a shift in the way things are done that may even threaten their jobs. But the thing is, this shift is inevitable.

The world is moving towards more no-code and less handwritten code. This is a trend that is only going to accelerate.
So, instead of being insecure about it, devs should embrace it. We should learn how to use no-code tools in harmony with hand-coded software, and strive to become no-code experts. This way, there is an opportunity to stay relevant in a no-code world and become the experts that companies will need to build the next generation of no-code products.

## I use no-code tools all the time

Any time I can take advantage of no-code tools, I do. It saves me time, lowers complexity, and results in that many fewer things needing my attention to be maintained in the long run. Some quick examples for you:

- I use an automated “sign up for my newsletter!” embed on [my personal website](https://mikebifulco.com) to interrupt readers at just the right time and ask for their email address. I configured [Polite Pop](https://politepop.com/) entirely on their website, and embedded it in my next.js site with a simple copy/paste
- For [APIs You Won't Hate](https://apisyouwonthate.com), we have several Zapier automations set up to populate an Airtable when someone submits a contact form. The process is different for sponsors vs. general contact - and I can change it any time without redeploying the site.
- I have uptime monitors on all of my web properties - I get a handy text from [Fathom](https://usefathom.com) any time a site goes down for more than 60 seconds
- I use [Google Home](https://home.google.com/welcome/) (shout out to my former team @ Google!) to automate my morning routine - the lights in my bedroom come up like an artificial sunrise, and by the time I get down to my kitchen, there's soft music playing, and my espresso machine is warm and ready to pull a shot.
- I use [Shortcuts for iOS](https://support.apple.com/guide/shortcuts/welcome/ios) on my iPhone for all sorts of things - turning off lights and making sure the doors are locked in my home at night, sending an automated text with my location to tell someone I'm headed their way, you name it.
- I use a [Stream Deck](https://www.elgato.com/en/stream-deck) to swap between camera views during livestreams, to toggle lights and set the temperature in my home office, and to hang up zoom calls or toggle my microphone without having to switch apps on my computer.

To be perfectly honest, I'm probably using many more that I've already forgotten about. I'm willing to bet that this short list probably spurred some recognition for you, too - you're probably already using no-code!

## You're probably already using no-code

Even in your dev work, you're probably already using a variety of no-code tools, whether you realize it or not. I certainly am! Vercel, Netlify, Cloudflare Pages, and GitHub Pages are great hosting options that require little-to-no-code to set up. Configuring web servers used to be a full-time job for every large project. Airtable is a great no-code alternative for gathering and storing data in a database. Chat widget tools like Intercom, Drift, and Front can be dropped onto any website by including one script and provide a massive superpower for messaging users and responding to customer support issues. Even everyday analytics tools like Google Analytics, Fathom, and Plausible are essentially no-code integrations that replace what used to be heaps of code for building telemetry into an app.

Stripe is investing in no-code tools to help business owners get things done more quickly. From Payment Links to Customer Portal to Pricing Tables, we're helping business owners and platform builders, because at the end of the day, your time is best spent doing things that add value to your products and services - and our no-code integrations give you more time to do just that.

If you've read this far and you find yourself thinking "these aren't no-code tools" because they can't be used to build an entire web app, I'd encourage you to rethink what "no-code" means. no-code tools are simply tools that allow you to get things done without writing code. They don't have to be a replacement for all of your code; think of them as an incredibly powerful complement to it.

## No-code doesn't mean low quality

No-code tools are often more reliable because they're built by teams of developers who are focused on a specific problem. They also tend to be more secure because they're not as complex as an entire web app, so there are fewer opportunities for bad actors to exploit vulnerabilities.

## No-code doesn't mean no extensibility

No-code tools also don't mean you have to compromise on features or customization. Many no-code tools offer APIs or other ways to extend their functionality. If you do find yourself needing more, you can always use a no-code tool as a starting point and then add custom code on top. They are a powerful way to get things done quickly and without having to write a lot of code.

There exists a dev subculture that hypes up building software in the most steampunky way (see: vim, mechanical keyboards, etc). It glorifies "make it look like I'm doing something super difficult and specialized" in a way that makes it hard to get started. This culture gets promoted for a variety of reasons - many of which are innocuous. For example, many developers are introverts, and so they express their personality through the things they use and build. We also tend to be tuned into the latest news on bleeding-edge tech, and because of that, many of us like to collect and show off our gear.

With that said, I don't think this kind of enthusiasm is entirely a bad thing.

I think it's great that there are people out there who love their keyboards, and their vim customizations, and who are willing to share that with the world. I also think it's great that there are people who are passionate about using those tools to build amazing things.

Things become problematic when they're used as a form of gatekeeping.

It's important to consider that this may deter new developers who are just getting started. Just remember that at the end of the day, it's all just a bunch of tools - and you can use whatever tools you want to build whatever you want.

## How to turn yourself into a no-code cheerleader

If you're a traditional developer, you may have already decided that no-code is not for you. You may think that it is “taking the easy way out”, and that it can't possibly work for anything more than the most basic apps. I'm here to tell you that you're wrong. no-code tools are powerful. They're flexible. They're easy to use. And they're getting better all the time. If you're a traditional developer, I challenge you to give no-code a try. Spend a few hours with one of the many no-code platforms out there and see what you can build. I think you'll be surprised.

## Go ahead, give no-code a try

Ready to dive in? There's plenty of great resources online for taking advantage of no-code tools.

- [Apps Without Code](https://www.appswithoutcode.com/)
- [Automate All the Things](https://www.aatt.io/)
- [r/nocode](https://redditcom/r/nocode)

If you're not using no-code already, give some of these tools a try. And if you are using them, showcase your efforts whenever possible - especially to your dev friends who may be skeptical.

- [If This, then That (IFTTT)](https://ifttt.com)
- [N8n](https://n8n.io/)
- [Zapier](https://zapier.com/)

As I mentioned earlier, [Stripe has a growing portfolio of no-code tools](https://stripe.com/docs/payments/no-code). These are a few that I'd recommend to anyone looking to dip their toes into the cool, refreshing waters of having to write less code:

### Payment Links

[Payment Links](https://stripe.com/docs/payments/no-code#send-a-payment-link) are a quick and easy way to share a URL for a specific product with your customers. You can create as many payment links as you need, and they can be used anywhere you might share a link. [Check out the docs](https://stripe.com/docs/payments/no-code#send-a-payment-link) for more information on getting started with payment links. You may also want to check out my other post, [No-code payments: How to use Stripe with customized NFC tags](https://dev.to/stripe/no-code-payments-how-to-use-stripe-with-customized-nfc-tags-3c1o).

### Pricing Table

You can use the Stripe Dashboard to configure a [Pricing Table](https://stripe.com/docs/payments/checkout/pricing-table) UI component, and embed it on your website. This will allow your customers to see pricing information and be taken to checkout without any custom code. The pricing table is designed to be flexible and fully responsive, and uses recommended practices for selling subscription-based products online.

### Customer Portal

The [Stripe Customer Portal](https://stripe.com/docs/customer-management/activate-no-code-customer-portal) is a Stripe-hosted solution for customer self-serve management of subscriptions. This allows your customers to change and cancel their subscriptions as needed, and includes a complete checkout workflow for collecting and updating their payment information.

## Wrapping up

So, what do you think? Have I made a compelling case for using no-code tools? I'd love to hear about the no-code and low code integrations you're using - drop me a comment below to show off your stuff, or track me down on twitter [@irreverentmike](https://twitter.com/irreverentmike).

If you've made it this far, thanks for reading. I think there's a better world out there for all of us if we embrace no-code, and extend an olive branch to our less technical friends who are interested in building apps with no-code tools.

<Aside type="note">

Author's note: This post was originally written as part of my work as a
Developer Advocate at [Stripe](https://stripe.com). As of November 2022, I no
longer work at Stripe, but I'm still a big fan of their products and the work
they do.

</Aside>

<small>

_Stripe fam: If you want to re-host this article on a stripe-owned URL, [get in touch!](mailto:hello@mikebifulco.com)_

</small>


Devs: It's okay to use no-code tools

Devs are often insecure about using no-code tools

How to turn yourself into a no-code cheerleader


<Aside type="note">
  _This article was written during my time at Stripe as a Deveoper Advocate, and was co-authored by my inimitable teammate, [Charlie Gerard](https://charliegerard.dev/)._

I do not speak for Stripe, and this article is not official company policy, etc. and so on. It's just my experience with friction logs from my time at Stripe.

</Aside>

## What is a friction log?

Friction logging is a practice that can be used by engineering teams building products to track and improve upon issues that users experience while using a product. The goal of friction logging is to make a given product better for everyone involved. End users and developers get a product that delivers value more directly, the team building the product gets a more attached, happier user base, and salespeople have an easier time showing value to potential customers.

At [Stripe](https://stripe.com), we use Friction logs to share feedback with product teams about the products we build. This is at least part of the mission of our DevRel team. Our goal is to be the voice for devs who use Stripe's products to build their own. We often serve as the liaisons between these worlds: the devs using our products, and the engineering teams building them.

Stripe also encourages all employees to actively participate in giving feedback. During onboarding, every new Stripe is given training on how to give feedback on products, and the process for creating friction logs.

## Parts of a friction log

<Image
  publicId="posts/how-stripe-uses-friction-logs/parts-of-a-friction-log"
  alt="Parts of a friction log"
/>

### Context

The context describes the persona of the person reviewing the feature, as well as what they were trying to accomplish. For example, if you are reviewing a new API endpoint and this is your first time using the feature, it is important to mention this as part of your persona. You can try to write the context by answering the following questions:

- How experienced are you with the feature?
- What were you trying to build?
- Which parts of the feature is this friction log about?

Below is an example of context for a friction log about setting up a new printer:

<Image
  publicId="posts/how-stripe-uses-friction-logs/example-context"
  alt="Example context for a friction log about setting up a new printer"
/>

### Pros and cons

Once you've written the context, you can move on to summarizing the pros and cons you've experienced.

This part should be a list of bullet points clearly stating the parts of the feature or experience that you enjoyed or thought were useful, and the ones that you think could be better or did not match your expectation of how the feature should work.

<Image
  publicId="posts/how-stripe-uses-friction-logs/example-pros-and-cons"
  alt="Example pros and cons for a friction log about setting up a new printer"
/>

### Detailed stream of consciousness

Finally, the detailed stream of consciousness is the part where you should be giving feedback without necessarily following a specific structure. You should write it as you are going through your experience trying to use the feature. It can include anything you think could be useful to the team, no matter how small. Feel free to add screenshots, GIFs showing your interaction with the tool, links, etc.

We are all different in how we use tools, our level of knowledge and expertise, the applications we're trying to build, so any piece of feedback is valuable to help improve a product.

To give you an idea, here's an example of how this part of the friction log might look:

<Image
  publicId="posts/how-stripe-uses-friction-logs/example-stream-of-consciousness"
  alt="Stream of consciousness example for a friction log about setting up a new printer"
/>

## Framework for a great Friction log

### Share size (S/M/L) up front

**Small** - The friction log is small and manageable. It can be completed in a reasonable amount of time without feeling like a burden.

**Medium** - The friction log is of a moderate size. It may take some time to read, but it is not excessively long.

**Large** - The friction log is large and may take some time to consume. These likely capture larger user journeys, and show a holistic view of a process, as opposed to a small bit of confusion with a single feature.

### Make the journey clear

The friction log should make it clear what journey the user is taking, and what steps they are taking along the way, as well as context on their persona ("I'm brand new to collecting payments on the web", or "This is the 3rd major release of my product, but we need to add support for taking payments in Canada"). Additionally, The log should be easy to follow so that the intended audience can understand it -- whenever possible, use language that your product teams and stakeholders will understand without having to go do research of their own.

### Highlight both joy & frustration

While it is critical to share opportunities for improvement in a product, it is also extremely valuable to share what is going well. This helps to build trust with your engineering team, and can be a good reminder that you all share the same goal: making the product as good as it possibly can be.

### Be illustrative

Wherever it may be helpful, provide screenshots, videos, or other visuals to help explain the process you've undertaken, and the real experiences you've had. This may take the form of a link to a developer screencast for longer friction logs.

### Describe issues objectively

This is where emotional intelligence is critical. Avoid using emotionally loaded language, and instead describe the issues objectively. Something like "I got confused between steps 6 and 7, and went back to this docs page to look for what I missed" is far more helpful than "I wasted 2 hours on this, it's so bad!".

### Share your feedback broadly

At Stripe, when a friction log is completed, it is shared to an email list that includes the entire company, as well as with the specific team working on the feature or product being highlighted. This takes advantage of the network effect: when everyone can see your feedback, it's more likely that you'll start a conversation with a broad audience of affected parties.

You may find that there are people who actively disagree with your perspective - don't fret, this is usually a good thing! Exposing your friction log to people with a diversity of experience and background means that any suggested changes to your product will be more considerate of a larger userbase.

### Follow-up!

It's also good practice to follow up directly with people who may be tasked with coming up with fixes related to your friction log. Keeping an open dialog is important - it helps ensure that feedback is given and received in good faith, and that the outcome of your work is a meaningful solution (even if it isn't implemented right away).

**This is where the magic happens.** All your work in crafting a great friction log is worthless if you don't follow through and make sure that it has an impact on the product your company is building. Making sure that your log results in the creation of new feature requests and bugs is a good starting point - do your best to be a steward for these tickets after their creation, so that they are prioritized thoughtfully in your team's backlog.

The last bit of follow up comes after the implementation and release of updates to the product: tell the world! Update docs and release notes with the new changes, and follow up directly with affected users wherever possible. This is your opportunity to show them that your team is working hard to make things better for them. Let them know that you built something because of them, and that you're always open to more feedback. This creates attachment and loyalty, and is the virtuous cycle that great product teams strive for.

## On giving feedback

A friction log is essentially a detailed piece of feedback, so to ensure that it is helpful and received well, there are a few important points you need to keep in mind.

### Emotional intelligence is important

Emotional intelligence encompasses self-awareness, social awareness, empathy and relationship management. Writing a friction log focuses on your personal experience with a feature or product, however, you have to keep in mind that it will be read by people who have put a lot of time and effort into building what you are using.

Try to put yourself in their shoes and avoid using language that isn't very considerate. For example, instead of saying something like “This is by far the worst API I've ever used”, which is not only rude but also unhelpful, you could change it to “I've struggled using this API because X, Y, Z”. This way, your feedback changes from a general comment to one more focused on your personal experience, and it is more helpful to explain what you struggled with so the team can take action to make improvements. Additionally, try not to use the pronoun “you” to address your feedback. Instead of saying “the API endpoint you implemented isn't clear”, you could say “This API endpoint was a bit unclear to me”. This focuses your comments on the feature itself, instead of whoever implemented it.

### Trust is a critical ingredient

When giving any kind of feedback, trust is very important. In general, your teammates want you to do well and you should have a common goal of making the experience better for your users so, when receiving feedback, you should know it comes from a place of care. However, if your company doesn't have a great collaboration culture or if you only recently joined, it can be difficult to have this sense of trust. Before you try to implement friction logs as part of your process, make sure that you get to know your team members. If necessary, schedule calls to go through your friction logs with people so they can understand the state of mind you were in when you wrote your feedback.

### Giving feedback is hard; receiving it is even harder

A bit earlier in this post, I talked about emotional intelligence and how you should put yourself in other people's shoes when writing your friction log. This can be a difficult process when the feedback you need to give is not the most positive. However, remember that receiving feedback is even harder. If you're on the receiving side, try to detach yourself from what you are reading and remember that this is an opportunity to improve. If this is not something you are used to doing, it can be a bit difficult at first and might take a few tries to get comfortable with. Hopefully, the more you do it, the more you'll realize how beneficial it is, not only on a personal level but for all your users.

### Summary

If you're not already using friction logging as part of your product development process, you should definitely consider adopting it. Here's why:

- It can help you identify opportunities for improvement in your product, by highlighting bottlenecks and weaknesses.
  Showing that you listen to users and actively make changes to your product based on their feedback builds user trust and loyalty
- Friction Logging can help to build a culture of trust and feedback, and incentivize emotional intelligence in communication between your colleagues
- In the long run, friction logging can help you save time and money by ensuring that your product is constantly improving.
  Get our friction logging templates
- We've created a [friction logging toolkit](https://github.com/mikeb-stripe/friction-logging-toolkit) for you to use if you're interested in getting started with Friction Logging at your company
- You may also want to check out [frictionlog.com](https://frictionlog.com) - they provide lots of great articles, examples, and resources on Friction logging.

## About my co-author

<center>

![Charlie Gerard headshot](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qrn3697iitskc063b8y8.png)

</center>

Charlie Gerard is a Developer Advocate at Stripe, a [creative technologist](https://charliegerard.dev/) and [Google Developer Expert](https://developers.google.com/community/experts). She loves researching and [experimenting with technologies](https://charliegerard.dev/). When she's not coding, she enjoys spending time outdoors, trying new beers and reading.


How Stripe Uses Friction Logs to Improve their Products

Giving feedback is hard; receiving it is even harder

#devrel: 4 posts tagged

Keep your tools sharp