Sometimes we don’t want to do so we practice and sometimes we do want to do and we practice.

Consistency is what makes practice less like practice.

Your experience and feelings cannot be replaced by an LLM, but it can help you find the words to share them.

With all the outrage about AI writing and coding not being “real creativity”, I can’t stop thinking about when sampling became a thing in the 80s.

Musicians taking bits and pieces from other records to create something new.

It was legally messy but creatively fascinating.

Is this what we’re experiencing now?

AI will follow sampling’s playbook: outrage, adoption, amnesia.

Today’s “AI kills creativity” will be tomorrow’s “I’ve always used these tools.”

Creativity when you’re stuck feels like eating when you’re sick. Food loses its appeal even though your body needs it. The spark feels absent even though some part of you knows engaging will help. Sometimes you have to gently force yourself back to the thing that usually brings pleasure.

If AI can write any code, then the real value is in understanding systems well enough to give the right instructions.

Top developers will focus on having great prompt files that explain how they work. The tools they like, the APIs they use. How they want code to be tested and written.

It will be the dot-files of the future. Personal config files that define your entire coding style and follow you from project to project.

Sure, you can copy someone else’s prompt files. But to really benefit, you need to understand and own them, just like traditional dotfiles.

Anyone can ask ChatGPT to write a React component. But not everyone knows how to ask for error handling, team patterns, and optimization for their users.

Just stop waiting to be comfortable. There will never be a time when you’re so comfortable that it’s easy to start. Don’t put expectations on your surroundings before you get started.

Do I need a perfect synthesizer? Do I need to sit in a special chair? Do all the kids need to be in bed and asleep? Do I need a two hour window?

Stop waiting to be comfortable.

I’ve noticed something interesting with tech companies and their websites. They often struggle to keep their own sites updated because they built everything custom from scratch.

It’s rarely about actual technical requirements. There’s this unspoken feeling that using existing tools might make them look less skilled as developers.

The result is predictably frustrating. While others focus on shipping products, these teams struggle to even update their website with new features because their custom CMS has become a maintenance burden that multiple developers have touched over time.

It’s one of those situations where professional pride works against business outcomes.

The connection with people might be the only thing that will set one company apart from another in the near future.

When everyone else focuses on making it easier for ChatGPT to index all their content and hope that it picks theirs.

The only way for people to really get to know your brand will be for them to know how they can find your brand.

I predict a surge in ads talking about domain names in the near future.

I’ve watched several companies try the same clever approach: build a product while running a consultancy. Use downtime to work on the product. Makes sense, right?

The logic is simple. When developers aren’t busy with client work, they focus on building something that could eventually become the main business. Sounds like smart resource utilization.

But here’s where it gets interesting.

The challenge always became prioritization. How do you decide what these “spare time” developers should work on? You can’t give them the most critical features because what if a client project comes up and pulls them away?

So you end up giving them the less important stuff. The nice to have features. The experimental work. Tasks without real deadlines or with artificial ones just to create some focus.

That sounds reasonable. Low risk, low commitment work for uncertain availability.

But then you hit the handoff problem.

Eventually, this side work needs to integrate with the main product. The core team (the one working on actual priorities) has to stop what they’re doing to review, understand and approve the work from the “spare time” team.

That’s when things get messy.

You end up with a priority inversion. Your high-priority work gets deprioritized so you can process the low-priority work you assigned to fill downtime.

The thing you said was most important gets pushed aside to handle the thing you said was least important.

I’ve seen this pattern multiple times now. It always looks smart on paper. Use every available hour. Keep people productive. Build toward the future.

But coordination isn’t free. Context switching isn’t free. Code review isn’t free.

The overhead of managing “spare time” work often costs more than the value it creates. You’re not just losing the output, you’re actively making your core work less efficient.

It’s one of those management ideas that optimizes for the wrong thing. Instead of optimizing for maximum utilization, you should optimize for maximum progress on what actually matters.

There are plenty of valuable things to do with spare time. Code reviews, documentation, experimenting with existing features, learning new skills, hanging out with the support team. The list goes on.

Just don’t pretend you can build your core product features in the margins.

When development teams are organized around services that mostly need maintenance, they often end up reinventing the product instead. Why? Because maintenance work feels boring compared to building something new.