10 Lessons From Steal Like an Artist That Transformed My Creativity

The title itself is provocative: Steal Like an Artist. Stealing is bad. But “like an artist”?

Does it mean all artists steal? The whole point of stealing is not getting caught. Then what are artists doing to steal differently? Those are questions I asked just by reading this book’s title.

After sitting on my desk for a while, I finally read it. Here are 10 lessons I learned:

#1. Learning is copying. First learn who to copy, then learn what to copy. Once you’ve chosen who to copy, trace their influences too.

#2. If you copy from one person, it’s stealing. But if you copy multiple, it’s inspiration. Creativity is using inspiration to come up with something that doesn’t look stolen.

#3. “There’s nothing under the sun.” This is the author quoting a passage from the Bible. If there wasn’t any new 2,000 years ago, that feels like permission to copy.

If you think it’s new, it’s because you don’t know the original source.

#4. Creativity is subtraction. Creativity isn’t only inventing. It’s also remixing existing ideas and leaving things out to make them new. This reminds me of Idea Calculus from Skip the Line.

#5. Hands first, then computer. With a computer, the line between writing and editing is blurry. A computer wakes up the perfectionist inside us. Go analog to separate creating from critiquing.

In my own writing, I’m adopting this idea for my next books: outline first with index cards, then write on a computer, and then print out the draft to edit on paper.

#6. Use a calendar and deadlines. Work expands to the time available. Use deadlines to focus and to avoid procrastination and perfectionism. Done is better than perfect, perpetually unfinished.

#7. “You’re as good as your last post.” This is an invitation to keep working on your creative side. Don’t be a one-hit wonder.

I was about to write “keep showing up,” but I remember I ditched that line.

#8. Have a victories folder. Every time anything good happens with your art, take a screenshot, and save it for later. I screenshot comments, hit posts, follower count, dashboard with sales…Anything inspiring. This comes in handy when you feel like giving up or facing haters.

#9. Routine over time. The other day, I watched an interview of Steven Pressfield in the Huberman Lab. Steven said he only writes for ~2 hours a day. If a pro writer only writes 2 hours, you don’t need to quit your day job. Build discipline and a routine first.

#10. Keep your day job. It takes time to live off your art. Have something that doesn’t deplete your energy to pay the bills. The time to quit will come later.

This book made me rethink creativity. But it also made me rethink the concept of a book. Steal Like an Artist isn’t a 50,000-word volume on creativity. It’s a collection of 10 big ideas, presented with clear examples and eye-grabbing doodles and visuals. That already feels like permission to steal, remix, and create today.

Friday Links: Worms, Amazon, and Agile

Hey there.

Hope your week’s been good. Here’s what caught my eye lately:

#1. Around this day in computing history, the Morris worm infected 10% of the Internet. A prank that got out of control. Thank goodness that worm is trapped in a floppy disk now. Do you still remember floppy disks?

#2. Amazon has been in the headlines: outages, layoffs, and users leaving its cloud. Maybe the could wasn’t such a great idea after all (20min). And I don’t need to worry about the fear of missing the cloud hype.

#3. I don’t miss Scrum and its “ceremonies” from the corporate world. The whole Agile movement has become a performance theater (6min). We get stuck in rituals instead of real work. Arrggg!

#4. As a coder, I’m grateful for free and open-source software (FOSS). But it rarely beats the convenience of most closed software. Often FOSS scares “normal” people (3min).

Also on my blog this past week, I share about AI’s hidden gift (2min) and the real problem with AI writing all our code (3min).

(Bzzz…Radio voice) This email was brought to you by… My new book, Street-Smart Coding: 30 Ways to Get Better at Coding. Inside, you’ll find 30 lessons, from Googling to clear communication, designed to help you grow from junior/mid-level to senior and build real-world coding skills.

If you’ve ever felt like you don’t know how to level up as a dev, this is the roadmap I wish I had

Grab your copy here. During launch, pay what you want (even $1 or $2).

See you next time,

Cesar

Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.

The Scariest Lines of Code I've Ever Written

I don’t remember if it was rainy or sunny outside. It was more than five years ago. I was still becoming a senior coder.

I’ve written hundreds of thousands of lines of code. But I still remember this one. As part of my routine, I wrote this query in a stored procedure,

SELECT * FROM dbo.HugeTableWithoutIndexes
WHERE DATEDIFF(DAY, ADateColumn, @InputDate) = 0

I was working with an email system built with Amazon SES. I needed to show all email activity: delivered, opened, bounced, and so on. I wrapped a column in a function. A deadly sin!

The table had millions of records and no indexes. My query forced a full scan of the table. The next thing I knew the server was on fire. Not literally, of course.

Those days I refused to learn SQL, convinced ORMs and NoSQL were enough. I couldn’t have been more wrong. Relational databases and SQL still reign.

Eventually I learned about indexing, scans vs seeks, and SQL Server internals. Shout out to Brent Ozar’s courses.

A painful lesson I will never forget. That’s why learning SQL found its way into my new book, Street-Smart Coding. It isn’t a textbook. It’s a roadmap with 30 proven lessons to help you code like a pro. It’s the guide I wish I had starting out.

Want to avoid painful mistakes like mine? Grab your copy of Street-Smart Coding here

Dead Tech Will Outlive Today's Stacks

Every single job I’ve had has involved migrating a legacy app.

At my last full-time job, it was a WebForms app to manage hotels. First, they tried to modernize it by embedding modules powered by Bootstrap and Knockout.js into the main app. Then, React applications powered by ASP.NET Core API, still hosted within the main WebForms app. Management daydreamed of ditching the old WebForms app. But nah! Mission impossible. It had too much old code entangled with the new code. A zombie that refused to die.

Currently, I’m working on a WebForm app migration from VB.NET to Blazor. We fear Microsoft will deprecate Blazor before we finish the migration. Most likely, WebForms and VB.NET will still be around, seeing dozens of other languages and tools die.

Here I’m talking about WebForms applications. But it’s the same story with jQuery, PHP, and more “dead” languages and tools.

They’re dead depending on who you ask. The StackOverflow developer survey in 2025 registered 23.4% of respondents still using jQuery and ~8% using VBA/VB.NET. That doesn’t seem dead at all.

A business can’t wait for a new application

It’s tempting to rewrite legacy applications. We rebuild all the context, business rules, and constraints, which makes us confident in the code we’re writing.

Often, rewriting isn’t an option. Legacy code runs “successful” businesses. A business can’t stop while the new system is built. And paying off technical debt doesn’t guarantee more money.

Sylwia Laskowska puts it clearly on jQuery Will Outlive Half of Today’s JavaScript Frameworks:

You don’t get paid to build shiny new things. You get paid to keep existing things alive without breaking production.

Legacy code is code that simply works.

New coders don’t dream of working with “dead” languages and tools. I know! I thought I was going to work only with brand-new tools. But legacy code taught me more than any coding course, like navigating large codebases without any documentation or anyone to ask. That’s why it’s in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.

Grab your copy of Street-Smart Coding here. That’s the roadmap I wish I had when I was starting out.

Senior C# Dev Reacts to Reddit's /csharp (Hot Takes Only)

I didn’t have writer’s block today. Naaah! I was just scrolling down the /csharp subreddit for inspiration.

Scrolling through, I realized I had answers and reactions. And to follow the popular YouTube format, here I go reacting/roasting/responding to the front page of /csharp:

#1. I wrote a cross-platform TUI podcast player in .NET 9 (mpv / VLC / native engine fallback) Source

Great! Put it on your portfolio.

#2. Best approach for background or async tasks Source

Mmm. Probably that’s Hangfire.

Hi. In my last project, I had: 1 Api for backoffice 1 Api for app mobile 1 Worker Service for all the background tasks … So now I’m in new project, but I’m not sure if is necessary use Masstransit with RabbitMQ? Maybe channels? I mean, I want to keep it simple, but I don’t like put consumers or jobs in the same API, I always prefer to have a worker service dedicated to all asynchronous tasks.

Hangfire?! That’s definitely Hangfire. I don’t need to read more. And you don’t need to look for anything else.

#3. Is conciseness always preferred? (Linq vs Loops) Source

Not that I have a course about it, but LINQ is the best of all C# features. Yes, write a LINQ query first. Then, if you’re working on a high-performance scenario, go with loops.

#4. Can you explain result of this code? Source

Nah! I have a post to write. Ask ChatGPT or Copilot. It’s free.

But seriously, it’s a good exercise. Try debugging it yourself before asking.

#5. Let’s Talk About the Helper Classes: Smell or Solution? Source

Definitely a smell. Helper classes attract plenty of methods. “Where do I put this new method? Oh there’s a Helper class over there! I’m putting it there…”

If you’re tempted to write a Helper class, hold your horses.

#6. In general is it normal to have more than 2k lines in a file? Source

You shouldn’t have one. But yes, it’s normal.

Scroll…scroll…

Nah! Boring! Scroll…scroll…

#7. After seeing that LOC post, can anyone beat this? Source

Really?! Like, c’mon. We’re seeing who has a larger file?!

The other day, I shared that you know you’re in trouble when you try to open a file on GitHub and it says “(Sorry about that, but we can’t show files that are this big right now.)” Spoiler alert: The file has 69,923 and it’s called GlobalFunctions.vb.

You see? Helpers!

#8. Is C# good for beginners? Source

Hell, yes!

#9. Why is this issue only popping up at the 30 line? Source

Dunno! See #4.

#10. Career Guidance: .NET Backend Developer Role and Future Tech Stack Transition Source

“Blah…blah…blah… I’ve accepted the offer, but I sometimes question whether choosing the .NET path was the right decision. I’d like to understand the current job market for .NET developers.”

Hey, buddy! We’re in a bubble that is popping (or about to pop) now. In 2020-2021, “Software Engineer” on LinkedIn meant a line of recruiters with “life-changing opportunities.”

These days? Just look at the headlines. Amazon just “let go” thousands of employees in the past weeks. And that was right after an outage that took down pretty much every client. That’s for every stack, unless you have “AI” anywhere in your title.

OK, let’s call it a day! That’s enough roasting for today. I should be writing a YouTube script, but I don’t have a channel. Just a blog…and a book. Speaking of which…

This post is brought to you by… Check out my latest book, Street-Smart Coding: 30 Ways to Get Better at Coding. It’s not a C# textbook. It’s the roadmap I wish I had on my journey from junior/mid-level to senior. Some lessons are conventional. Others not so much. From Googling to debugging to clear communication.

Get your copy of Street-Smart Coding here

PS: In case you didn’t notice, this was half-joking. And yes, I’m promoting my book.