## The Big Idea

LLM tools like ChatGPT, Copilot, and Cursor are great at helping you build, but they are a second brain - not a first one. Used well, they are an intern that speeds up your work. Used poorly, they are a liability. The trick? Give them context, direction, and oversight.

<a href="https://www.paddle.com/resources/mobile-app-monetization-guide?utm_medium=website&utm_source=partner&utm_campaign=core_conversions_fy2025_web_monetization_brand_awareness&utm_content=tiny-improvements" className="text-xs lg:text-xs xl:text-xs">
 Brought to you by Paddle
</a>

---

### AI Works Best When You Steer It

Most AI tools (Cursor, GitHub Copilot, ChatGPT) aren't great at figuring everything out on their own. They do best when you provide them with context. Although this guide is focused on software development with Cursor, the same principles apply to other tools and domains.

I have found that the best way to use LLMs is to treat them like an intern:

1. Tell them the goal. Spell out what you're building.
1. Give them the pieces. Feed them relevant files, not just one at a time.
1. Make a checklist. Break the work into steps you can track.

Here's an example of a recent set of instructions I gave to Cursor, while working on a new feature for Craftwork:

```
take a look at @timesheets_spec.rb - I need to produce an updated version of our timesheets API under the v2 namespace. It should use all of the same patterns as the other endpoints in @v2 do, and should use a new controller namespaced under api::v2 at `controllers/api/v2/timesheets_controller.rb`.

It needs a list view that can be filtered by a craftworker's id, by timesheet state (approved/inprogress/etc), and by production lead id.

The show view should return details for a single timesheet.

The update view should allow me to approve a timesheet, edit values, etc
```

That was enough to get me started working with Cursor, and it helped orient the LLM while building out the new feature. It had enough context for me to ask questions as I worked, and sped things up nicely.

### AI Will Get It Wrong (And That's Fine)

For any instructions you give 'em, LLMs will [confidently spit out answers](https://mikebifulco.com/posts/product-marketing-defy-expectations), regardless of how correct they are.

If you don't understand what they're doing, you're trusting a bad intern to run your company.

That's why you need to:
- Spot bad logic. If something seems off, it probably is.
- Debug iteratively. AI is great for refactoring—ask it to explain itself.
- Know when to take over. Sometimes, the best fix is writing the code yourself.

In the case of the Craftwork timesheets, I was able to spot a few issues, and after making some changes, steered the LLM to the right path (my typoes included -- LLMs actually deal with these really well!):

```
great, now can you llook at the controller and add any helpful missing scopes? You may want to peek at other controllers in the @v2 folder, as well as @timesheets_controller.rb

Alsothe .d.ts type definition declarations you made arne't needed - see @tsconfig.json and @javascript - they're likely in another folder already configured with typescript paths. If the components don't exist they'll need to be created
```

If you've ever onboarded a new teammate to a codebase, this kind of steering is not at all uncommon - you're helping them understand the codebase, and the context of the changes they're making.

### Tests Are More Important Than Ever

If you're letting AI write code, you better be _damn sure_ it works as expected. That means writing great tests before shipping anything.

- Test like a skeptic. Assume AI-generated code is flawed.
- Write failure cases. If AI wrote the function, you should write the test.
- Use AI to help debug. It's great at explaining why tests fail (sometimes).


## The Bottom Line

AI is a force multiplier - but only if you use it right. Treat it like an intern:

- Give it structure.
- Question everything.
- Make sure the work holds up.

Most importantly, remember that your great, big, juicy brain still need to do some work. Don't blindly trust the output of your copilot-of-choice - that's a hell of a lot to ask of an intern.


---

## Tests? What tests?

Most of us (hello, yes, me included) aren't great at writing tests -- but writing software tests is a skillset that is absolutely worth investing in. Here's some resources I've found helpful:

- (React) [Testing Library](https://testing-library.com/) provides documentation and set of tools for testing web applications, in a variety of frameworks. Whether you're a fan of react or svelte or vue or solidjs, this is a great resource.

- One of my favorite things about building with Ruby on Rails is the framework's first-class support for great testing. There are _so_ many thoughtful features for writing great tests for rails apps. Even if you're not a rails developer, it's worth giving their docs a look: [Rails Testing Guide](https://guides.rubyonrails.org/testing.html)

---

## Stop paying the app store tax.

Sell your app on the web with lower fees and full control. As a merchant of record, Paddle handles payments, taxes, and compliance — so you can focus on what matters: building your app.

Paddle acts as the reseller of your app, offering a solution similar to the App Store or Google Play Store but optimized for successfully selling your mobile app on the web, with significantly lower fees.

[Start selling smarter with Paddle.](https://www.paddle.com/resources/mobile-app-monetization-guide?utm_medium=website&utm_source=partner&utm_campaign=core_conversions_fy2025_web_monetization_brand_awareness&utm_content=tiny-improvements)

---

## Thinking about automation

I've spent a bunch of time working on small scripts to automate manual tasks lately - and I'm working on a couple quick video tutorial showing how you might use tools like Puppeteer, Faker, Skyvern and your copilot-of-choice to get things done more quickly than ever before.

If that sounds interesting, go chase me down on youtube at [@mikebifulco](https://www.youtube.com/@mikebifulco?sub_confirmation=1).

AI is your intern (not your boss)


## The Big Idea

Talking to AI is a lot like talking to people... except for all the ways that it isn't. It's a skill worth honing, and not a replacement for thinking.

---

From 2020 to 2022, I worked at Google.

I was on the Google Assistant team, in an era where "hey alexa" and "hey google" weren't new ideas. ChatGPT had not been released yet, and in general, the public was not aware of AI; "LLM" was far from a household term.

Funny enough, the dev product that my team was promoting was called "conversational actions" -- back then, "conversations" were predetermined - whether you realized it or not, you were following a scripted series of questions, and Google Assistant was a clever way to trigger actions.

In that time before LLMs took over, I noticed a funny pattern: people would talk to their assistant *like* a robot. They'd slow down, speak in weird, clipped phrases, almost like they were trying to sound like the assistant itself. It reminded me of how people adjust their speech when talking to someone who doesn't speak their language.

Fast forward to today: people are speaking to LLMs much more naturally. _Conversations_ with AI feel more convincing, but the reality is that the LLM is still just a tool. It's up to you to do the thinking.

Of course, LLMs are getting better all the time, and the tools will continue to get better. There's still a real skill in knowing *how* to talk to your LLM. Done well, it can be a powerful extension of your thinking. Done poorly, it's a waste of time.

After a bit of reflection, here's the pattern I've adopted for working with AI tools:

---

## Provide Context (More is Better)

Once upon a time — like, two years ago — LLMs had tiny context windows. They were only able to process a few paragraphs of information at a time. Now there's *loads* more headroom. Most modern models can handle essays, transcripts, full articles, and more. The more context you provide, the better the results.

Here's how I set mine up for success:

- **Tell it who you are.** Your background, goals, and what expertise you expect from it.
- **Define the task.** Are you brainstorming? Writing? Editing? Summarizing?
- **Give it sources.** If it can read the web, provide links. Otherwise, copy/paste key quotes or references.
- **Set guardrails.** Be explicit about what you *do* and *don't* want. Examples:
  - "Be concise."
  - "Avoid jargon."
  - "Don't mention XYZ."
  - "Your audience is nontechnical."

---

## Iterate and Customize

You'll get better results if you tweak your prompts while working, and you should save what works, and refine it over time.

- **Save what works.** If you get a great response, refine it into a reusable prompt.
- **Use different prompts for different goals.** You wouldn't write a social post the same way as an executive summary. You may want to have separate prompts for copywriting for social media, writing execustive summaries, or brainstorming on SEO keywords, for example.
- **Redo / Retry / Resubmit.** LLMs aren't deterministic: if you submit the same set of instructions multiple times, you'll get different results. If it misses the mark, tweak the input and try again.

I think it's also a good idea to regularly try different models and tools - what does Claude do better than Gemini? You'll never know if you don't experiment with the tools. Don't get lazy, and don't blind yourself to what's out there - it's all changing very quickly right now.

---

## Don't Get Lazy

An LLM is a tool — not a replacement for thinking.

I'll admit, I go into a bit of an existential spiral when I think about the future of communication - do we want to winnow down our existence to LLMs talking to each other? I certainly hope not. All the same, these tools are really useful for brainstorming, editing, and revising your writing, and they're not going away.

You're still the expert (ideally). It's your job to check facts, refine tone, and ensure the final product *sounds like you*. In my opinion, a big part of that work means that you should treat your LLMs like an assistant, not a crutch.

Edit the output - make it sound like you!

---

## TL;DR

1. More context = better output.
2. Experiment, tweak, and refine your prompts.
3. Never stop thinking —  you're still the one with the expertise.


---

## Your inbox shouldn't slow you down.

Superhuman's AI-powered features—Instant Summarize, Smart Replies, and Ask AI—help you fly through email, reclaiming at least 4 hours every week.

That's 4 extra hours to build, think, and focus on what actually matters.


📩 **Tiny Improvements readers get their [first month free](https://superhuman.com/ti?utm_medium=sponsor-callout&utm_source=mikebifulco-com).**

---

## Stick these in your brain's context

I'm a firm believer that we should always be learning. Don't rely on AI to do all your thinking. Here's a couple things I found this week that you might enjoy:

- [Ranking Paradoxes](https://www.youtube.com/watch?v=1vJsWKg2o1w) is a YouTube video from Chalk Talk, which goes discusses the complexity and counterintuitivity of philosophical and mathematical paradoxes.

- I'm still very much into 3D printing nerdery - and this recent video from Make Anything on [multi-texture prints](https://www.youtube.com/watch?v=zmZCA9jqGiI) shares a really cool new technique for making prints more visually interesting.


How I (Think I) Talk to AI

## The Big idea

The right tools don't just save time—they amplify your focus and flow, making it easier to do your best work. This is what I'm using to stay productive in 2025.

<a href="https://superhuman.com/ti?utm_medium=brought-to-you-by&utm_source=email" className="text-xs lg:text-xs xl:text-xs">
 Brought to you by Superhuman
</a>

## This is how I get things done

My work as an engineer and founder is split between two main activities:

1. Building products and features
2. Building the systems and processes that allow me to build products and features (I spend more time here each day)

I tend to stick with tools that amplify my productivity, help me get stay organized, and ones which don't get in the way when I'm finding flow state.

The best tools find their way into my workflow without much hassle.

## Princples for choosing tools

While I never consciously set hard rules for choosing the tools I use, I have found some consistent principles of what I look for in a tool:

1. **Simplicity:** I prefer tools that are simple to use and understand. I don't want to spend time learning how to use a tool - I want to spend time getting things done.
2. **Portability:** I prefer tools that are easy to set up and move between devices. This means that cloud sync is a huge plus for me - if my work laptop ever gets launched into the sun, it should be easy to set up a new machine and get back to work.
3. **Reduced key ~man~ tool risk**: Developers are notorious for customizing the hell out of their tools, often to a fault. I don't ever want to feel like I _can't_ get things done on someone else's computer. My team does lots of pair programming - and I never want to feel lost on someone else's machine because without _my dotfiles_.

---

## These are the tools I use in 2025

Alright, let's get into it. This is the tech stack I'm using in 2025:

### Hardware

- **Laptop: Macbook Pro 14"** - Up until a few weeks ago, I was using a 14" 2021 M1 Macbook Pro. I recently swapped to a 2023 variant with an M3 chip. These computers have been, without a doubt, the best I've ever used. I've switched between Windows and MacOS over the years - we're in an era where hardware is what makes the difference. These MFs are fast, and the battery life is incredible.

- **Phone: Pixel 9 Pro** - Hot take: I'm not a huge fan of some of the UX on IOS. My Pixel takes _stunning_ photos, and integrates with all the things I love for home, work, and play. Even still, I switch between Android and IOS every few years, because I believe it's helpful to know and understand what both options are like. It's a great way to keep learning and stay informed.

### Tools

- **Note-taking: Logseq** [LogSeq](https://logseq.com/) is a fantastically simple, privacy-first, markdown-based note taking app for building knowledge graphs. I switched to LogSeq last year from RoamResearch, and have been very happy with the experience. If you've tried Notion and haven't quite gotten along with it, I'd recommend giving LogSeq a try.

- **Email: Superhuman** - [Superhuman](https://superhuman.com/ti?utm_medium=body-rec) is a stunningly email client designed with efficiency in mind. It works _with_ my Gmail accounts, and lets me triage, filter, and respond to emails confidently - and without distraction. Their design team has done an incredible job of creating a product that's both beautiful and functional.

- **Swiss-army knife:Raycast** - [Raycast](https://www.raycast.com/) integrates with MacOS as a replacement for Spotlight (the little window that pops up when you hit command + Space on most Macs). It's more than just a launcher - I use it for launching apps, translating english &harr; spanish, checking fligth statuses, and countless other utilities during my workday.

### Devtools

- **IDE: Cursor** - [https://www.cursor.com/] is a fork of VS Code that is highly customized for AI-assisted coding. I have it customized with a set of prompts for each of my projects, and to index docs for libraries I use. While it's not a replacement for _thinking_ - it's like having a _very good_ pair programmer at your side all day. An instant productivity boost.

- **HTTP Client: Bruno** - I started using [Bruno](https://www.usebruno.com/) last year for testing and integrating with APIs. It's similar to Postman, open-source, and includes some really cool features, like a native git integration, so you can share your API specs with your team.

- **Design: Figma** - I've been using Figma for years, and over the past year have started using their layout tools to prototype interfaces as I build (shout out to my pal [Drucial](https://drew-white.dev/) for getting me up to speed on autolayout!). I believe design is a _critical_ skill for any engineer, and right now, Figma is the best tool for the job.

- **Project Management: Linear** - [Linear](https://linear.app/) is _the_ project management tool that we use at Craftwork for keeping our ever-changing backlog in order. It's like Jira, but with all of the garbage ripped out and replaced. If you haven't used it before, give it a try.


..and more. There's _definitely_ more that I use day to day - I'll share a follow-up post soon with details about the stack I use for _building_ products - the frameworks, libraries, and SaaS products I use to build Craftwork, this site, and APIs You Won't Hate.


### Your tools should work as hard as you do.

Superhuman keeps your inbox in check, so you can focus on building. Stay productive in 2025: prioritize, reply, and save 4+ hours a week. Thanks to Superhuman for giving Tiny Improvements readers their [first month free](https://superhuman.com/ti?utm_medium=sponsor-callout&utm_source=mikebifulco-com).

---

## What did I miss?

Is your favorite tool missing from the list? Did I miss something that's critical to your workflow? The best way for me to find out is by sharing - slap the reply button and let me know what I'm missing.

My 2025 Developer Tech Stack

Your tools should work as hard as you do.

## The Big Idea
When you carve out focused time for your work, you're making a statement. This week, let's harness that power and explore how to stay on task with purpose.


## Focus Mode for the Defiant

Founders who actually _build_ things are a special type. You are making a statement: you've found a problem worth solving, and you're using some of your limited time on this earth to solve it.

Everyone's time is limited, and the act of building something is a display of your priorities -- so don't waste it on distractions.

When you focus your time and energy on creating, you're asserting your free will in the most powerful way possible. This week, let's talk about how to stay on task and bring your boldest ideas to life.

Let's talk about _focus mode._

## Practical Tips for focusing

A funny thing about my role at [Craftwork](https://craftwork.com) is that the more we grow, the _less_ time I have to do "typical" work - my days lately are spent focused on strategy, hiring, scaling, and unblocking my teammates.

This means I get precious little time to _write code_ - which makes it all the more important that I make the most of the time I do have.

I use a few strategies to carve out focus time, to eliminate distractions, and to make use of the limited time I have to be productive each day.

- **Scheduling Focus Blocks:** I set aside 90-180 minute blocks each week for deep work. These uninterrupted periods are when I do my best thinking.
- **Notification Detox:** I turn off non-essential notifications -- all the time, 24/7. This helps me stay in control of my time and attention. Rather than get sidetracked by an email coming in, I check email when it's productive for _me_ to do so.
- **Do Not Disturb Mode:** To further manage notifications, I flip on _Do not Disturb_ on my laptop and my phone - this further cinches down notifications, and helps me stay focused. I usually do this with a set end time, so that I can focus on the task at hand.
- **A literal, physical timer:** When working through tasks that are mentally taxing, I use a minimalist desk timer from [TIME TIMER](https://amzn.to/3PPRKBT) as a visual reminder to keep me on track.

## The Importance of Focus

It is _extremely_ easy to waste away your days with notifications, social media apps, and other distractions. Founders who _get things done_ are the ones who have learned to focus. It is a skill, and it requires practice.

Moving the needle every day is the difference between a _wantrepreneur_ and a _founder_.

Don't let distractions get in the way of your focus.

<SponsoredSection
 imagePublicId="sponsors/superhuman/new-year-new-habits"
 sponsorName="Superhuman"
 CTAtext="Get started today"
 href="https://superhuman.com/ti"
>

 As a founder, your inbox is chaos—but it doesn't have to be. Superhuman cuts through the noise, prioritizes what matters, and drafts replies before you even open a message. Every action takes seconds, not minutes.

 Start 2025 with clarity, focus, and 4+ hours saved every week. **Your first month is free.** What's stopping you?

</SponsoredSection>

## Focused learning for existential awareness

- What if maps were made to show the _time it takes_ to travel between points? YouTuber [Vaclav Volhejn explores this idea](https://www.youtube.com/watch?v=rC2VQ-oyDG0) with a fascinating visualization built in TypeScript.

- Creator of Million.js, Aiden Bai has been producing an incredible series of videos about how browsers work - his recent entry on [how browsers "paint" HTML](https://www.youtube.com/watch?v=yBkFjlPWpZ8) goes far deeper into browser rendering than I ever thought about.


## The Spinal Column 🩻
_Because staying informed is an excellent use of vertebrae._

_This is a new segment for Tiny Improvements. I thought it would be helpful to share _one_ link related to current events that I've found interesting, educational, or poignant. I'd love to hear what you think - hit reply and let me know._

On a recent episode of the podcast Opening Arguments, the hosts dive into a sobering truth: the US president is now above the law. We're in uncharted territory, facing a challenging four years ahead.

Listen to it here: [We (Disrespectfully) Dissent](https://open.spotify.com/episode/5DD95dTspKjSOyKUPzZhpT?si=4544c33d9fe04f6a)

Thanks for tuning in. Keep pushing boundaries - and give 'em hell!

Focus Mode for the Defiant

Focused learning for existential awareness

## The Big Idea

Building products and teams successfully relies on your ability to build meaningful relationships; making a habit of introducing interesting people to each other is a great way to seed serendipity.

## Build Meaningful Relationships

Building a network and introducing people is an important skill that takes honing. I've learned from my most successful founder friends that it's something worth doing—offering to introduce people feels great, and it occasionally pays itself back in unexpected ways.

Here are three simple ways to do it right:

### Give them a heads up

Before you connect people, shoot them both a quick message to let them know why you think they should meet. A little heads-up goes a long way in keeping things smooth and avoiding surprises. This is where the _real_ introduction happens. If it's done well, both parties will be excited to meet.

### Be quick and thoughtful

Keep your introduction emails short and actionable. Highlight why the connection makes sense and how the parties might benefit from knowing each other. A concise, well-thought-out message shows respect for everyone's time - they're rarely longer than a couple sentences.

### Trust your gut

Not every intro needs a big reason. Sometimes, just putting two cool people together can lead to amazing, unexpected stuff. Be the spark that gets things rolling—you never know what might happen.

When done right, introductions are more than just emails — they're opportunities to foster creativity, collaboration, and growth. Start small, but start today.

<SponsoredSection
 imagePublicId="sponsors/superhuman/new-year-new-habits"
 sponsorName="Superhuman"
 CTAtext="Get started today"
 href="https://superhuman.com/ti"
>

As a founder, your inbox is chaos—but it doesn't have to be. Superhuman cuts through the noise, prioritizes what matters, and drafts replies before you even open a message. Every action takes seconds, not minutes.

Start 2025 with clarity, focus, and 4+ hours saved every week. **Your first month is free.** What's stopping you?

</SponsoredSection>


### A sample introduction email

Many of the introductions I send and receive look something like this:

> Subject: Mike, meet Sarah
> Hey gang -
> Sending over a quick note to connect you. You both have context, but think it would be great for you to meet! Will let you take it from here.
> T.

Brief, informative, and to the point. It gets the job done!

---

## From around the internet

I've come across a great deal of creative inspiration online this week - and I thought you'd appreciate these:

[Lofted Goods](https://thangs.com/designer/LoftedGoods) is a designer who creates simple, elegant, and functional 3d prints for use around the home. Their aesthetic really speaks to me, and I love the addition of thoughtful features, like an insert for wall-hung decor that makes it dead easy to decide where to drill holes for screws and wall anchors. Best of all? You can download the files for free and print them yourself.

My god do I love a good typeface. I recently came across [Taylor Penton's hand-drawn fonts](https://www.taylorpenton.com/fonts), and fell in love straight away. I've even hopped onboard as a paying member of their Type Club. I may even incorporate some of [Taylor's webfonts on my site](https://github.com/mbifulco/blog/pull/945) before long...

## What about you, friend?

As always, I'd love to hear what you're working on. Read something interesting recently? Launching your product soon? Hit reply and let me know. I do my best to respond to each and every one.




Note: Cover photo for this newsletter is from [MJ S](https://unsplash.com/@mjseka?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash) on Unsplash.

Superfounder Superpowers: Sending Introductions

## The Big Idea

Your inbox is a tool—learn to use it to stay focused, organized, and in control of your time.


## Did you get my email?

Staying organized and on task is an absolutely _foundational_ skill to master for founders.

Building a product is a complex task that will have you busier than you might imagine. For many of us, one of the first things to go is our inbox.

Without looking, what's the count of unread emails in your inbox? Is that little notification bubble straining to fit all the count of unread emails?

Friends, **it's time to take control.**

A clean inbox isn't just about aesthetics; it is a critical tool for staying focused and on task, being responsive to your network, and staying productive.



<SponsoredSection
 imagePublicId="sponsors/superhuman/new-year-new-habits"
 sponsorName="Superhuman"
 CTAtext="Get started today"
 href="https://superhuman.com/ti"
>

In the life of a founder, the inbox is both a necessity and a challenge. Every deal, opportunity, and conversation is buried under a flood of noise. Superhuman is designed to change that.

Imagine an inbox that knows what's most important and drafts replies to messages before you look at them — and every action takes seconds instead of minutes. Superhuman transforms email into a tool for clarity, focus, and action.

This January, start your year with a platform built to help leaders like you get more done and save 4+ hours every single week.

With your **first month free**, there's nothing holding you back.

</SponsoredSection>


### Your inbox is a tool, not a bottomless pit

Whether you use gmail, apple mail, Superhuman (shout out for sponsoring!), or Outlook, your inbox is a tool, and knowing how to use it is a game changer.

Treat your inbox like you would your favorite IDE or design tool—it's only as good as how you use it.

My approach:

- Only emails I need to respond to or act on live in my inbox.
- Labels and folders keep everything else neatly organized.
- Snoozing helps prioritize tasks for later without cluttering the present.

Think of your inbox as a task manager for important things, not a dumping ground for everything.

### Turn Off Notifications and Regain Your Focus

Real productivity happens when you're focused - and for me, sporadic email notifications are an unpredictable distraction.

**My tip**: Turn off email notifications entirely.

Seriously -- I turned 'em off. On my phone, in my browser, and in my email client.

This lets me check and triage messages in my inbox when I choose, ensuring I stay in the zone while working.

This practice eliminates the randomization of being distracted by notification bubbles. Being intentional about when and how you engage with your inbox keeps it from controlling you.

### A Clean Inbox = A Clear Mind

The value of an organized inbox goes beyond email:

- New, important emails are less likely to slip through the cracks
- Less notification spam is a free productivity boost
- It makes the _unread count_ on your email app's notification bubble _useful._ Imagine that!

### This sounds great, but I have 493287 unread emails

If you're sitting on hundreds of unread emails, it may be time to declare email bankruptcy.

Sometimes, the backlog becomes unmanageable — and that's okay.

Email bankruptcy isn't about giving up; it's about clearing your slate:

- Archive everything older than a certain date and triage the rest.
- Notify key contacts if they're waiting on something and ask them to resend anything crucial.

It's the fastest way to regain clarity and focus without drowning in old noise.

Use this reset as a chance to make email a tool that works for you—not against you.


## Start the new year fresh

Your inbox, like any great tool, works best when you know how to use it. A clean start at the beginning of the year can help you reclaim your time, focus on what matters, and build habits that last all year long.

Take control of your inbox, and you'll find yourself in control of your time, your focus, and your productivity.

---

## Who I'm learning from this week

By now, you know that I love functional 3D Prints. For me, the magic in this tech is in creating useful, customized tools to make your life better. It's a challenging process to master, which is why I really liked seeing this video on [designing 3D printed mods for a vintage Toyota](https://www.youtube.com/watch?v=hpxAcJaAXgk) on the _Fat Lip Collective_ YouTube channel. Even if you have no interest in old cars - there's lots to learn from the process used to develop a custom part.

If you haven't heard already, **you should uninstall the Honey extension from your browser** pronto. YouTuber [MagaLag created an exposé](https://www.youtube.com/watch?v=vc4yL3YTwWk&pp=ygUSaG9uZXkgc2NhbSBleHBvc2Vk) on the many ways the extension has been abusing creators and consumers, and it's a must-watch.

[Folklore (Kyle's version)](https://pca.st/0iqmt7xe) is the most recent episode of the podcast Hyperfixed, from Alex Goldman. This episode goes deep on something that at first glance seems trivial, but eventually touches on verbal tradition, craftsmanship, and some fundamental truths of the physical universe. A fantastic listen.

The Great Inbox Reset

Your inbox is a tool, not a bottomless pit

Turn Off Notifications and Regain Your Focus

This sounds great, but I have 493287 unread emails


I spent the last week spinning up tools for a new startup I'm working on. Although I've built several products in the past few years, they have all been solo-efforts, so I haven't had to think about setting up collaboration tools. I haven't started from scratch with a new team since somewhere around 2017, and I was surprised at how much has changed.

Here's what I learned:

### The basics - the best got better

The first few tools I set up have been constants in my work life for a while - we're using [Google Workspace](https://workspace.google.com) for email, access to GSuite, and Google Drive, [Slack](https://slack.com) for team communication.

Notably, onboarding for both of these has gotten _much_ better - both for administration _and_ end users. I was able to get both of these set up in a few minutes, and adding new teammates was flawless.

I also set up [GitHub](https://github.com) for code collaboration, [Google Search Console](https://search.google.com/search-console/about) to keep an eye on SEO, and [Cloudflare](https://cloudflare.com) for managing DNS and protecting our web properties from abuse. These are tools I've used for years, and I'm happy to see that they've continued to improve -- and they all have generous free tiers, which is helpful if you're in the early days of bootstrapped products.

### First time tools for me

Believe it or not, I haven't used [Notion](https://notion.so) before. I've been using [RoamResearch](https://roamresearch.com) for personal note-taking years, and GSuite / Google Docs for authoring and collaboration since about 2014. I'm definitely a bit set-in-my-ways when it comes to collaborating - having worked at Google for a couple years, I got to see how the best-in-the-biz use Gmail and Google Docs to get things done.

_With that being said,_ I'm already really impressed by Notion. They've got an incredible set of templates for all sorts of use cases, and the ability to embed all sorts of content makes it easy to get started. To boot, my teammates have used it extensively, so I'm looking forward to learning from them as well.

We're using [Rippling](https://rippling.com) for Workforce Management -- in other words, for things like HR and payroll. Although I didn't set up Rippling, I have been plugging other tools into it - and I've been delighted by the automations they've built in for provisioning and deprovisioning services. This makes it easy to spin up services for new teammates - when they're added to Rippling, they're automatically added to the tools we use (and just as well, when they one day leave the company, Rippling makes revoking access a breeze).

Somewhere in the past few years, I started using [Figma](https://figma.com) as a design tool alongside my longtime staple [Sketch](https://sketch.com/). At this point, Figma is definitely better suited for collaboration, and I'll be using it with my new team to design our product UI and design language. I still use Sketch for design assets for mikebifulco.com, as well as many quick operations -- but I'm looking forward to using Figma for the bulk of my design work.

I'm sure we'll end up adding plenty of other services as time marches on - and I'm really interested in the things you use to get work done. If you've got a favorite tool that I missed, reply to this message and let me know. I'd love to check it out!

---

## Top tip: Browser profiles keep your work and personal lives separate

If you use Chrome (or any Chromium-based browser like Brave or Edge), and you're setting up a Google account that will live alongside your personal one, it's a good idea to set up different [browser profiles](https://support.google.com/chrome/answer/2364824) for each. This means your personal and work browsing histories will be separate, and you'll be able to install different extensions for each profile. I also tend to set up a third profile which I use for testing.

## Resources for fluorishing developers

These are a few of the things that have been occupying my brainmatter lately. I think you might like them, too!

- 🖇️ Growing on LinkedIn - now that I'm no longer using twitter, I've been working on strategies for increasing my area of influence in places like [Mastodon](https://hachyderm.io/@irreverentmike) and [LinkedIn](https://linkedin.com/in/mbifulco). My friends at Taplio (who previously sponsored Tiny Improvements) are currently hosting their [LinkedIn Growth Challenge](https://taplio.com/linkedin-growth-challenge-2023), where they're sharing their best tips for growing your network on LinkedIn. I'm participating, and looking forward to figuring out what catches peoples' attention on LinkedIn.

- 💼 Are you building a portfolio? [Victor Eke (@Evavic44) on GitHub](https://github.com/Evavic44/portfolio-ideas) has a great list of portfolios built developers, which is a great place to start if you're looking for inspiration for your own portfolio. I was flattered to find my site featured in the list alongside many others I admire.

- 🎥 I talk a lot about [Design for Developers](https://mikebifulco.com/newsletter/design-rules-everyone-should-know). I have a strong belief that most developers would benefit from learning just a few design basics. This week I came across [The missing guide to grids](https://www.youtube.com/watch?v=wIabVp0Hh8U) on YouTube. Whether you've used a grid system before or not, this video is a great introduction to the basics of grids, and how they can help you build better layouts.


Tools for building a new company

Top tip: Browser profiles keep your work and personal lives separate

I recently finished reading _Working in Public: The Making and Maintenance of Open Source Software_ by [Nadia Eghbal](https://nadiaeghbal.com/), thanks to a book club organized by [Chris Traganos](https://twitter.com/chris_trag) at [Stripe](https://press.stripe.com/). While I can't say this is a book I would have found my way to own my own, I found myself tearing through it far more quickly than I would have guessed. I'd fully recommend giving it a read - you can pick it up on [Amazon](https://smile.amazon.com/Working-Public-Making-Maintenance-Software/dp/0578675862).

Below is a pretty raw copy/paste of my notes on _Working in Public_, which I take in Roam Research as I read. If you'd like to discuss any of this with me, drop me a line on [twitter @irreverentmike](https://twitter.com/irreverentmike).

**Notes on _Working in Public_**

# Part 1

## Chapter 2: The Structure of an Open Source Project

- &#8203;
 <Highlight>
 Developers don't contribute to open source for lack of technical ability,
 but rather due to fear of committing a faux pas
 </Highlight>
 - There's a huge hurdle to get over here, particularly for new contributors.
 Even sending a very small PR or opening an issue has a mental tax associated
 with it that can prevent progress, community from being built
- &#8203;

 <Highlight>
 The process of getting a change approved depends, among other things, on the
 **complexity** of the change (and the complexity of the project), as well as
 one's **reputation** among those with the ability to approve the change.
 </Highlight>

 - Reputation is a tricky currency, particularly when some folks build clout by
 being funny / sarcastic to gain viral notoriety. This doesn't necessarily equate
 to value to the community or trustworthiness, but often can be parlayed into exactly
 that.

- &#8203;

 <Highlight>
 If a project's contributor base is growing rapidly, and there is enough work
 to hand off, maintainers may start to distribute work more widely. In a
 **distributed** state, maintainers actively recruit more contributors to
 pitch in, with the goal of retaining them in the project.
 </Highlight>

 - At some point, the success of a project causes a requirement for a shift in operations
 - from building the thing to **supporting** it, and recruiting community members
 to help get things done on either end of that. Teams' ability to make that pivot
 is critical to success.

- &#8203;

 <Highlight>Healthy open source (re: node.js contribution policy)</Highlight>

 - Design a contribution policy and code of conduct which entices contributors **and** retains them. Based on my experience, this is the magic in getting something over the hump from being fledgling to more broadly successful.

## Chapter 3: Roles, incentives, and relationships

- Open source developers were frequently characterized as "hobby" devlopers
 - Hm! TIL.
- A theory of the commons
 - In the last half of the 1900s, economist Elinor Ostrom came up with an 8-part theory to what makes up a successful "Commons", or resource that is owned, used, and managed by a community. These rules outline the basic tenets of what makes a successful commons, and apply directly to successful OSS in many ways.
 - Making sure members are biased toward **working together** is a key to success. This may mean distributing knowledge and capability so that everyone has value and meaning, and no one person can hold up the process. Obviously encouraging collaboration is a valuable outcome here, too - so empowering folks to use each other as a resource is extremely helpful.
- <Highlight>
 Intrinsic motivation makes it easier for people to self-organize to achieve
 the same outcome.
 </Highlight>

- The newcomer effect
 - <Highlight>
 "Because newcomers have not yet developed commitment to the group and have
 not yet learned how the group operates, it is rational for established
 group members to distrust them"
 </Highlight>
 - This happens all the time in OSS - many projects have core maintainers who
 do all the work, and a significant amount of gatekeeping by way of bluntly shutting
 down PRs or issues when they're disinterested in them. It's fair to say that
 for the contributors getting shut down, a steady and consistent participation
 in the project will help them get notice, but it can feel like an unfair hurdle,
 too. What might be a more equitable solution to this? Not empowering code owners
 as much? Adding an objective, third party moderator to make some decisions?
- All Contributors
 - https://allcontributors.org/
 - Recognize All Contributors Including those that don't push code
- On Contributors...
 - Again, I'm reminded of the madness of Hacktoberfest 2020 - lots of garbage contributions from people just trying to get a free t-shirt does not make for good OSS, good community, or good contributions.
 - &#8203;<Highlight>Bus Factor</Highlight> is the number of contributors in a project
 who would need to be hit by a bus for it to be in jeopardy. lol

# Part 2: How People Maintain

## Chapter 4: The Work Required by Software

- Software, once written is never really finished. Chasing the feeling of a "finished" app/program/site is something that took me FOREVER to get over. I never felt like I had done anything, because nothing ever got to the finish line. It turns out that the finish line doesn't exist, and a decade+ of building "incomplete" things was the catalyst that I needed to figure that out. As such, <Highlight>greenfield</Highlight> projects are "coveted" because they're a blank canvas, enabling us to chase that feeling of a fresh _starting line_ to point us to a goal that is always just past the horizon. It's a feeling of hope - and thankfully a beneficial one, as rebuilding software from scratch is often inherently beneficial. Neat.
- <Highlight>Free as in speech, not as in beer</Highlight> vs <Highlight>
 free as in puppy
 </Highlight> is a brilliant analogy
- <Highlight>
 By focusing too much on iterating upon their incumbent product, companies
 risk missing major opportunities for so-called "disruptive innovation,"
 which eventually replaces existing products. - Clayton Christensen in Book:
 The Innovator's Dilemma
 </Highlight>

- The anecdote about Sophie Alpert being offered $600 to **open a PR on someone's project** because it would draw positive attention is mind-blowing.
 - "Is this what it feels like to be an influencer?" - Sophie
- <Highlight>
 We can think of a creator's reputation as a "battery," or store of value,
 for attention. More followers mean more attention in the bank, but when
 people follow a creator they do so because they expect to receive more
 content. If creators don't produce anything new, their followers will
 eventually get bored and leave. Reputation, like software, requires
 maintenance over time.
 </Highlight>

## Chapter 5: Managing the Costs of Production

- Absolutely mind-blowing that at one point, cryptographic code was treated the same as munitions by the US government. Early developers of OpenSSL <Highlight>had to become licensed arms dealers to be able to write and "export" (i.e., distribute) their code.</Highlight>
 - This is an implicit declaration that certain types of technical solutions can be weaponized, and perhaps just as importantly that sometime in the past, some of our legislators had a reasonable understanding of this. In the US, at least, it's apparent that this is no longer the case. Don't believe me? Pull up a congressional hearing with Tim Cook, Zuckerberg, etc
 - Relatedly, it is asymptotically difficult for lawmakers to keep up with the changing pace of technology. There's a decent argument to be made for a citizen-run, or commons-run governing body for technical regulation, rather that trusting some crusty old white men from flyover states whose pre-government professional lives weren't the least bit technical.
- <Highlight>
 When software is in static state, **what if there is no free-rider
 problem?** When code is non-rivalrous, it only has first-copy costs, which
 the creator is intrinsically motivated to provide -- so the problem doesn't
 seem to lie in how many people **consume** it. For this reason, I'm
 skeptical of attempts to charge for access to information, whether it's
 newspaper articles or open source software.
 </Highlight>

- This hints at one of the most fascinating things about content creators online. Virtually all of the really, truly successful creators are driven by an enjoyment of creating and sharing -- and might not typically start creating as a business. Often times it takes hundreds of youtube videos, or dozens of podcast episodes, blog posts, etc to get any kind of sizeable following. It's those with the fortitude and perseverance to continue without an audience that find success. Perhaps the audience is their reward, or perhaps the audience is a natural byproduct of the law of large numbers: create enough of something, and put it out into the world, and **some size** of audience will find you.
- <Highlight>
 At a high level, it's also possible that throwing away projects and starting
 fresh is the most cos-effective approach: rebuilding the whole system, piece
 by piece.
 </Highlight>

- There are many companies that operate like this - occasionally dropping an existing product for a **completely new** rewrite. This has been done with projects as small as weather apps and as large as Windows and MacOS, and is often a good decision. It strikes me that this is often only possible due to a luxury of funding, time, and resources. Imagine telling a scrappy startup that their best bet is to ditch their entire source library, and start anew. It wouldn't work! Many fledgling companies fall apart because of early and inflexible assumptions made, or technical debt built up to save time. The luckiest of them find success despite this debt, and carry on to be successful. I'd imagine this success often brings about an effort to rebuild the plane while it's flying, in a modern Ship of Theseus paradox.
- Automation! This section rang true with me to the core. When building [smpl](https://www.crunchbase.com/organization/smpl-llc), our biggest superpower was automation. It made our engineering team of 2 feel much larger than it was, and helped us to execute successfully and dependably. To this day I think that process automation is the closest thing I have to a superpower.
- It's interesting that a book about OSS has me thinking about work, content, and contributions outside of software so often. So much of what's discussed here has interesting implications politically, socially, and in content creation of any sort for public consumption (art, blogs, youtube, instagram, etc)
- I didn't know about [dear-github](https://github.com/dear-github/dear-github) or its relatives [dear-github2](https://github.com/drop-ice/dear-github-2.0) and [isaacs/github](https://github.com/isaacs/github). It'll be interesting to give these a read. As of this writing, `dear-github2` has had activity as recently as 2 weeks ago

### The role of Money in OSS

- Companies pay for access, attention, and feature proposals. This can often have adverse effects: companies are essentially skipping the line to pay for attention, and as a result aren't vetted by the same processes as other OSS Contributors (particularly those who request fixes and features). This can be a governance nightmare, and can cause mistrust in a project if done incorrectly.
- Advertising in OSS projects has real untapped potential, but often gets shot down. There was a product called Code Fund by Eric Berry which aimed to put ads into the readmes of OSS repos on github. It rose to $24k/mo revenue in 4 months before GitHub shut it down as a violation of their ToS.
- Trivago appears as a sponsor on Webpack, and this has helped them to recruit JavaScript developers, who see them as a good company to work for as a result of their support.
- An interesting difference in funding projects comes by way of GitHub's sponsors feature (and other services like Pateron), whose goals are more oriented towards having individuals back a **contributor** (rather than a project) on a monthly basis. The subscription is seen as a vote of confidence in the person, rather than slippery backing for a single project.

Book notes: Working In Public

Chapter 2: The Structure of an Open Source Project

Chapter 3: Roles, incentives, and relationships

Chapter 5: Managing the Costs of Production

## Earlier today, we had a problem at [Gymnasium](https://thegymnasium.com).

We released a [new 5 minute tutorial on Making Headings and Lists more Accessible](https://thegymnasium.com/courses/take5/making-headings-and-lists-more-accessible) - which is great news! If you build things for the web, and you've got 5 minutes to spare in your day (you do), you should give it a look.

After the course was made public, our marketing wizard did her magic and started posting to our various social media pages: [Facebook](https://www.facebook.com/aquentgymnasium), [Twitter](https://twitter.com/AquentGymnasium), and [LinkedIn](https://www.linkedin.com/school/gymnasium/).

It was immediately apparent that something was off. During our course release process, we missed the fact that Open Graph metadata for that course page wasn't correctly included. Unfortunately, that meant that _none_ of our posts on social media had the beautiful image previews that we'd expect to see (and by extension would likely see far less engagement).

<Aside>
 Open Graph metadata tells other services what kind of information is
 shown when a URL loads, so that they can create a preview of the URL that
 makes sense. Read more at{' '}
 <a href="https://ogp.me" target="_blank" rel="noopener noreferrer">
 ogp.me
 </a>
 .
</Aside>

Fast forward a short while, and we updated our CMS with the necessary metadata for Open Graph Shares to work correctly. Newly shared links in our team Slack now looked great!

<Image
 publicId="posts/open-graph-cache-reset/slack-after"
 alt="screenshot of a post in slack"
 caption="Screenshot from slack after the fix - our new course was shared with the correct image"
/>
.

## Social networks cache link previews

Rather than redownload the preview image and metadata for a given link every time it's shared, your entire open graph preview is often cached. Depending on the site, that cache may be cleared regularly throughout the day.

Because we had _already_ posted links to our courses, every site we had shared to had cached our shared links with the bare defaults. The result was relatively plain, and not relevant to the content on the page - something like:

`Free online courses on design and web development | Gymnasium`

With Gymnasium's logo beside it. Just defaults! Not a great look.

Because we were working on a concerted marketing push to announce our new courses, these extremely plain previews were bad news. We've seen from experience that having an attractive (and differentiated) share image helps gain traction during the initial publicity of new content.

## _You_ can trigger a cache reset on each of these sites!

After some brief research, we found that there are tools to reset the cache on each of the major social networking sites. They're each extremely easy to use - paste your URL in a box, click a button, and reset the cache if necessary. Here's the ones we found to be useful:

### Use these links

- **Facebook Sharing Debugger**: [https://developers.facebook.com/tools/debug/](https://developers.facebook.com/tools/debug/)
- **LinkedIn Post Inspector**: [https://www.linkedin.com/post-inspector/](https://www.linkedin.com/post-inspector/)
- **Twitter Card Validator**: [https://cards-dev.twitter.com/validator](https://cards-dev.twitter.com/validator)

That's all there is to it! Hit reset, re-share your link, and you should see your latest Open Graph preview shared. Phew! 😅

How to reset your Open Graph embed on LinkedIn, Twitter, and Facebook

Earlier today, we had a problem at [Gymnasium](https://thegymnasium.com).

_You_ can trigger a cache reset on each of these sites!

Put simply, [gitignore.io](https://gitignore.io) is a tool that is so profoundly helpful that I've _forgotten what life was like without it._

Its purpose is simple: for any project you're working on, it'll generate a valid [`.gitignore`](https://docs.github.com/en/rest/reference/gitignore) file for you. All you need to do is use the autocomplete box provided to describe the type of project you're working on:

<Image
 publicId="gitignore-fill-in-the-blanks"
 alt="Screenshot of the web interface for gitignore"
 border="2px solid #888"
 borderRadius="1rem"
/>

<Aside type="note">
 A .gitignore file is used to tell git to exclude files from
 being added to a given repo. Each line of the file represents a filename,
 directory, or pattern. When git looks for changes in your working directory,
 it will automatically ignore any file that matches an entry in your .gitignore
 file.
</Aside>

From there, you'll hit the `Create` button, which will bring you to a page that displays nothing but the raw text which you'll need to add to your project's `.gitignore`. If you selected just `react`, for example this is what you'd see on the next page:

```
 # Created by https://www.toptal.com/developers/gitignore/api/react
 # Edit at https://www.toptal.com/developers/gitignore?templates=react

 ### react ###
 .DS_*
 *.log
 logs
 **/*.backup.*
 **/*.back.*

 node_modules
 bower_components

 *.sublime*

 psd
 thumb
 sketch

 # End of https://www.toptal.com/developers/gitignore/api/react
```

That's all there is to it, too! I use it on the vast majority of projects I work on, new and old, and as far as I can tell, it hasn't let me down in any meaningful way.

## It's Open Source!

One of the reasons I like this tool so much is that it gets better the more people use it. Is it missing support for a project type that you work with? Go ahead and submit a [Pull Request](https://github.com/toptal/gitignore.io), and it may be integrated into the product one day. Or, if you're not quite comfortable with a full-on PR, you can start the discussion in an issue on the repo. Maybe something isn't working like you'd expect -- and it's worth pitching in your two cents in the discussion on an open issue. _All of that_ is contributing to Open Source -- don't forget!

As I understand it, it was created by [@joeblau](https://twitter.com/joeblau), and quickly gained momentum with developers. As I write this post, there are [**135** contributors](https://github.com/toptal/gitignore.io/graphs/contributors) on the project.

[Gitignore.io](https://gitignore.io) is a great example of a successful Open Source tool born out of the desire for an improved developer workflow. It currently appears to be operated by [TopTal](https://www.toptal.com/), a company that helps freelancers find work.

<Aside type="info">
 
 (note for transparency: I have no connection to TopTal, and this is not a
 sponsored post. I <strike>do</strike> (update: 11/2020) used to{' '}
 work for{' '}
 <a
 href="https://aquent.com?utm_campaign=mikebifulco&utm_source=mikebifulco.com&utm_content=gitignore-io-is-great"
 target="_blank"
 rel="noopener noreferrer"
 >
 Aquent
 </a>
 , which is a creative staffing agency. If you're looking for work, give{' '}
 <strike>us</strike> them a look!).
 
</Aside>

## There's a CLI

If you prefer it, there's a [CLI](https://docs.gitignore.io/install/command-line) which will help you generate gitignore files, powered by this same project. I can't say I've used it, but I know some of you will want to give it a go, so it's worth mentioning

## There's other options, too

If you don't find gitignore.io particularly appealing, there's always other ways to cretae your `.gitignore` file. You can write it by hand, or grab one from another project you work on. [GitHub also maintains a repo](https://github.com/github/gitignore) of popular gitignore files, which seems to be updated quite frequently as well.

### Was this helpful?

If you found this useful, I'd love it if you subscribed to my mailing list. Details are below!

gitignore.io is great

_Note: I updated some names and links in this post. Dev.to's product became
**Forem** when it went open source_



So, like all good things, the idea for this post comes from a tweet:

<Tweet tweetLink="irreverentmike/status/1141169316273897536" align="center" />

This is something I've been ruminating on for a bit. I've even tried to build it - a few times! I keep starting in on the work and getting lost in the millions of directions I could take it.

Here's what I'd like: When I publish a new post to [my gatsby site](https://mikebifulco.com) (you're on it now!), I'd like for that post to appear on [dev.to](https://dev.to) automatically.

## It should:

- recreate my post verbatim, from its original markdown source
- use the `canonical_url` frontmatter field to make sure I retain SEO goodness on my post
- happen without my intervention
- be agnostic of where my posts are coming from. At the time of writing this article, I use [takeshape.io](https://www.takeshape.io) as a headless CMS for my site, so my individual posts aren't in source control
- only take posts from my `master` branch, since I use feature branches for draft posts from time to time
- use the [dev.to API](https://developers.forem.com/api) (update: now called the _Forem API_), of course

## Nice to have:

- maybe posts should be set to `published: false` at first, so I can preview/review/update them as needed for dev.to?

## Possible approaches for this:

1. Tap into GitHub's webhooks somehow, and fire off a post here
1. Come from a job kicked off after CI, maybe? I use CircleCI, but would like this feature to be fairly implementation agnostic.
1. Use a [GitHub App](https://developer.github.com/v3/apps/)?
1. ...or a [GitHub Action](https://github.com/mbifulco/thepraticaldev-crosspost-action)?
1. Perhaps just a lamba function deployed to AWS or [Netlify Functions](https://functions.netlify.com/).

So - here's where I ask for your help. Surely there's a simple approach here I haven't thought of, or maybe it's a matter of collecting a few scenarios and building something based on 80/20.

What else am I missing here? I'd love your help. What use cases would you have for a cross-poster from your gatsby site? How would you implement it? How can we help each other?

Do you have your own Gatsby site? Let's brainstorm a dev.to cross-poster

**Update (2021, pt.2): Do you want to know how to run Dependabot locally?**

I wrote a follow-up to this article based on a question I've been getting fairly regularly: How do you run dependabot locally? You asked, I answered - check it out here: How to [run dependabot locally](https://mikebifulco.com/posts/run-dependabot-locally) on your projects

**Update (2021)** Dependabot has been Acquired by GitHub, and many of the links from this post stopped working once they took down the original site (dependabot dot com). I've updated URLs here to point to more relevant links within GitHub's docs.

[Dependabot](https://github.com/dependabot) is an automation service that will automatically create PRs to keep your projects' dependencies up to date, and it is really powerful.

<Image
 publicId="posts/i-have-to-tell-you-about-dependabot/dependabot-settings"
 alt="Screenshot of the settings interface for a project on the former Dependabot.com"
 caption="Setup for Dependabot is flexible, quick, and straightforward."
/>

In just a few, sweet, wonderful minutes, you can install and configure it to automatically keep an eye on your project dependencies, and set a daily or weekly schedule to submit updates and changes. Automation at its finest - dependabot is like having a super mindful teammate who keeps an eye on npm (or pip or rubygems or one of [many other languages](https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates#supported-repositories-and-ecosystems)) - you'll automatically get great, well-formed PRs for each dependency version bump, which you can test locally, or have sent up to your CI toolchain of choice.

After you run through the setup process, dependabot will monitor your repo and submit PRs to update individual dependencies on a daily or weekly rhythm (your choice!). If the PR contains an important security update, it will be assigned a label of Security, too.

<Image
 publicId="posts/i-have-to-tell-you-about-dependabot/dependabot-pr"
 alt="An example PR from dependabot"
 caption="Automatically created PRs are simple and to the point."
/>

Honestly, for me, it's like adding a member to my team. I love automation, and I love making my life simpler. Until now, for all of my projects, myself or another teammate would regularly run through all the dependencies in a given repo, and manually update them one at a time, testing and pushing them to GitHub to be run through CI and then eventually merged by the team. The honest truth is that this process can take quite a while, and can be forgotten, and isn't mindful of important security updates at all. That's all over now.

<Image
 publicId="posts/i-have-to-tell-you-about-dependabot/merge"
 alt="An example PR from dependabot"
 caption="Dependabot will merge this PR once CI is done, thanks to the @dependabot merge command"
/>

## What else?

There are a _ton_ of other features available to you the moment you install dependabot. It responds to a wide variety of commands by way of GitHub comment. In the screenshot above, I've approved a PR and asked dependabot to merge it as soon as CI has passed. Now I don't have to babysit the repo in order to merge updates! Sweet!

If your repo contains multiple languages, Dependabot can handle that. If you've got a complex monorepo with multiple files representing your dependencies (for example, a node project set up with Lerna), dependabot can monitor each dependency file individually, with different rules for each.

<Image
 publicId="posts/i-have-to-tell-you-about-dependabot/github"
 alt="Dependabot's announcement that they were acquired by GitHub"
 caption="Dependabot was acquired by GitHub"
/>

This was the final kicker for me. Dependabot was [just acquired by GitHub](https://github.blog/2019-07-25-one-million-dependabot-pull-requests-merged/), and is now available completely free for use. That's incredible! There's no reason for you not to give it a shot. Go check it out now, post haste!

Go install [Dependabot](https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates)!

## For more reading

- Check out my follow-up post: How to [run dependabot locally](https://mikebifulco.com/posts/run-dependabot-locally)

_Note: the cover photo for this article comes from one of my favorite photographers, [Alex Knight](https://twitter.com/agkdesign), and was made available un [Unsplash](https://unsplash.com/search/photos/robot?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText). Thank you Alex for your work!_

I have to tell you about Dependabot 🤖

## I really don't like my laptop.

I've been using a 2017 Macbook Pro for the past couple years.  As I'm sure you've heard, it is a fiercely disappointing device largely due to its courageous lack of ports, flawed keyboard design, and astonishing sticker price.  My personal machine is a 13" version, with 16GB of memory, _no_ touchbar, and a 256GB SSD. When I bought it, upgrading to 16GB of memory seemed far more important splurging on processor speed or disk space.  That's probably still true - but I've found myself endlessly frustrated by the tiny capacity of the SSD in my day to day work.

Roughly once every 6 weeks, my machine grinds to a halt as I run out of disk space, so I have to suffer through all the usual suspects for clearing up some room:

- empty the trash
- delete unused applications
- make sure all my photos are moved to my NAS, cloud storage, and offsite archives
- remove old virtualbox VM images

## A new kind of purge

Last week, however, I came across a surprising new way to free up some disk space: clearing out `node_modules` directories.

Curiosity hit me, and I searched my mac for folders named `node_modules`. This is what I found:

- My machine has `7,731` _total_  `node_modules` folders.  Wow!
- Under `~/src/**`, where I keep all of my dev projects, I had a grand total of 7,719 `node_modules`
- These folders contain _hundreds of thousands of files_ (which should be no surprise), and took up nearly **10GB** of disk space!

## Turtles all the way down 🐢🐢🐢

That last number was a bit of a revelation to me at first.  If you're unfamiliar, `node_modules` contains a copy of each of the [npm packages](https://www.npmjs.com) which you add to your project (with `npm install` or `yarn add`, etc) on projects which use node.  Each of them are pinned to a specific version, which is typically specified in `package.json`.

Somewhat logically, each of the dependencies in your project's `node_modules` directory may also have a `node_modules` directory, containing their dependencies, each pinned to a specific version (again, defined in the `package.json` file of that dependency).

This is where file and disk space bloat happen - the libraries you add to your project may each contain dozens of dependencies, each of which have dozens more, etc etc, all the way down to super basic node and C libraries which make up the fundamental building blocks of node.

(Mind you - This is oversimplifying things a bit - depending on how you set up `npm` or `yarn` , there is _some_ optimization done here. If one version of a given npm module is required more than once by your dependency tree, it may only appear once.)

## The fix

Actually, this was pretty easy to fix.  I did a search for all of the `node_modules` folders under `~/src/**`, and deleted all of them, right from finder (sorry, terminal apologists).  I then emptied the trash on my mac, and I was 10GB richer.

<Image
 publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/disk-space"
 alt="Screenshot of MacOS folder info for a node_modules search"
 caption="10 GB of space, just for node_modules!"
/>

## What did it break?

It's been a week since I've done this. So far the only inkling of a downside is that when I revisit projects I'm actively working on, I need to run `yarn install` to recreate the `node_modules` directory there. I switch between a good handful of projects, and I'm back to a fair few directories, but at least these are just the ones I'm currently using. I'm good with that.

<Image
 publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/terminal"
 alt="Terminal search for directories called node_modules"
 caption="A week later, I'm back up to 1209 node\_modules directories"
/>

## Can we do better?

There is an alternative to `npm` and `yarn` called [`pnpm`](https://pnpm.io/), which claims to be a "Fast, disk space efficient package manager".  Its primary feature looks promising:

<Image
 publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/pnpm"
 alt="pnpm's value prop - one version of each package saved to disk"
 caption="One version of each module sounds great"
/>

I haven't tried it yet, but will certainly be giving it a shot.

## Epilogue 

I think it's fair to say that this is a problem that the folks at npm and Facebook (who maintain yarn) are also looking closely at. My guess is that some healthy competition will improve this disk space nightmare... hopefully before I'm forced to buy a laptop with 1TB of storage. 🥳

---

### More reading

I'm certainly not the first one to write about this.  Some more great reading for you to check out, if you're interested:

- [The node_modules problem](https://dev.to/leoat12/the-nodemodules-problem-29dc)
- [What Happened When I Peeked Into My Node_Modules Directory](https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558) (this is the infamous tongue-in-cheek Guy Fieri article)
- [What’s really wrong with node_modules and why this is your fault](https://hackernoon.com/whats-really-wrong-with-node-modules-and-why-this-is-your-fault-8ac9fa893823?gi=1ff87c0f83ba)

#tools: 13 posts tagged