
<figure className="reset">
  <video
    autobuffer
    loop
    type="video/mp4"
    playsInline
    controls
    className="full-width"
  >
    <source
      src="https://padilla-media.s3.amazonaws.com/blog/video/DeltaSleepCampAdventureCompressed.mov"
      type="video/mp4"
    />
  </video>
</figure>

[Sick lick](https://www.youtube.com/watch?v=qQfh-umkAcw)! 🦑

[Thanks to Let's Talk About Math Rock](https://www.youtube.com/watch?v=LoAYmxA4lX4) for the tabs and curated licks.


Delta Sleep – Camp Adventure

Punk Solo Snippet


![🌺](https://padilla-media.s3.amazonaws.com/blog/art/sketches-2024-08-24.jpg)

More scenes from our twilight walks at home.


Bindweed Field


My recent projects have involved a fair amount of disposable code. I'll write a component for an A/B test, and then it needs to be ripped out after the experiment closes.

Git has simplified this process beautifully!

I _could_ manually handle the files, deleting line by line myself. But git makes it so that I can run a few commands in the CLI to revert everything.

Here's my workflow for it:

# Modular Commits

I've been guilty of mega commits that look something like this:

```
git commit -m "render revenue data to pie chart AND Connect ID to Dashboard AND move tiers to constants file AND ..."
```

I've recently made the switch to breaking out any instance where I would want to put an "and" in my explanation of the change into its own commit. So now my commits will look more like this:

```
$ git commit -m "render revenue data to pie chart"
$ git commit -m "Connect ID to Dashboard"
$ git commit -m "Move tiers to constants file"
```

There are loads of benefits to this. To anyone reviewing my code, it's far easier to follow the story told by my commits. Isolating a breaking change is much easier.

The best, though, is that it's **WAY** easier to isolate a commit or few that needs to be thrown out later.

# Revert Commits

The word comes back from marketing: The first A/B test was a success, but the second needs taking out.

If a single commit needs changing, it's as easy as this:

```
$ git revert 9425e670e9425e66d61c8201...
```

`git revert` will then create a commit with the inverse of those changes.

Usually, I need to do this with multiple files. The workflow isn't too different:

```
$ git revert --no-commit 820154...
$ git revert --no-commit 425e66...
$ git revert --no-commit 9425e6...
$ git commit -m "the commit message for all of them"``

```

Push and merge from there!


Git Hygiene


I'm thinking a lot about this thread by multi-instrumentalist and composer [Carlos Eiene](https://insaneintherainmusic.com/)

<blockquote class="twitter-tweet" style="margin: 0 auto;"><p lang="en" dir="ltr">People talk about “mastering” an instrument as the final goal, but I don’t think people talk about “fluency” on an instrument enough. You probably haven’t mastered your native language, but you’re probably fluent enough at it to talk about most things with little effort.</p>&mdash; insaneintherainmusic (@insanerainmusic) <a href="https://twitter.com/insanerainmusic/status/1471904710953029634?ref_src=twsrc%5Etfw">December 17, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

For me, this is the key phrase:

> Where is the fluency line with an instrument? ... I think a closer answer is having the necessary abilities to effectively communicate in whatever situation you may be in. And if you're in a vacuum, learning an instrument by yourself without ever playing it for or with others... you don't get the chance to communicate musically.

(Putting aside the whole argument for or against language as an analogy for music here.)

# In Music

This is such a given in music school. You are jamming with musicians all the time, getting feedback, and performing alongside each other all the time.

For me, it's been interesting transitioning musical communities.

The main point of the thread is to deemphasize practicing for the sake of mastery alone. To focus on how you serve musically and how you can still effectively communicate with other musicians.

I'm thinking a **LOT** about the inverse, though. How do you find that same community and immersion in a musical context that's a lot more individualist than, say, being in a concert band or jazz combo? Where does the feedback come from there?

When it comes to writing music, I feel like it's much more in the vein of how I imagine authors write. Or Jazz musicians working on transcriptions, actually. You're not limited by time or space. You are communicating and riffing off of someone's ideas that could be from decades ago. I think a present, accessible community is of course important. But online communities are much more lightweight than when you're in a group that rehearses every week together. And so, filling in the gaps takes working with recordings and materials.

Speaking as an ambivert, this way of connecting musically is pretty amorphous. The buzzword now is that many relationships online are "parasocial." And don't get me wrong, there's beauty to it, too. I love being able to transcribe a Japanese musician's X68000 chip music so easily and readily, there's an interesting kind of intimacy to that engagement with music. The feedback and communication is strange, though. It's not direct communication, and the community, again, is less tangible.

Anyhow — sometimes I miss in person music making. Maybe I shouldn't expect writing music to be the same kind of fulfilling. For me, the lesson is that music is multifaceted. Different acts in music can balance each other out. We write to express individualism. We perform to connect with a larger community.

# In Code

This got me thinking with code languages as well.

There's a spectrum. Folks who are renaissance devs, those who have dipped their toes in many technologies, are fluent in multiple languages and frameworks, etc. And there are folks who are highly specialized.

Namely, in web development, is it worth going broad or focusing in?

(Short answer: go [T Shaped](https://en.wikipedia.org/wiki/T-shaped_skills))

The answer comes from community, or maybe more importantly, what your problems are your clients grappling with?

That, too, is a spectrum. If you're aiming for the big companies, python, data structures, and a CS degree in your back pocket helps. If you're doing client work, breadth wins out. If you're an application developer, it may be a more focused in set of JS centric technologies.

Like music, the field is too large and varied to really say one size fits all.

No matter what, though, mastery isn't necessarily the goal. Here, it _is_ fluency.

Some projects may require that intimate knowledge of JS runtime logic.

Others may only need some familiarity with JQuery.

The interesting thing about this field, in my mind, is that it's a lot less about working towards a specific target for fluency, but using the tools you have to solve a problem for your collaborators.

Learning is a natural part of that process. So there is both a really tight feedback loop _and_ there's natural growth and development built in.

(Again, caveat here to say it's not an excuse to slack on developing your skills. But working towards fluency can keep it so that you are working to master relevant skills vs. simply being virtuosic in an irrelevant way.)

# Back to Music

The difference here is that software solves a direct problem for someone else. It's creativity with a practical outcome. With music, there's more magic. ✨ The outcomes are less clear, the people you serve and communities you entangle with are less defined. The benefits, even, are vague at times.

Except, y'know, your **soul** grows in the process. And simply _being_ creative in the world and sharing that creativity can lead to inspiring others to do the same.


Chris Padilla/Blog

On This Day