Steal like an artist
When asked to talk to students at Broome Community College in upstate New York in the spring of 2011, Austin Kleon wrote a simple list often things he wished he'd heard when he was their age: 'Steal like an artist; Don't wait until you know who you are to start making things; Write the book you want to read; Use your hands; Side projects are important; Do good work and put it where people can see it; Geography is no longer our master; Be nice (the world is a small town.); Be boring (it's the only way to get work done.); and, Creativity is subtraction.' After giving the speech, he posted the text and slides to his popular blog, where it quickly went viral. Now Kleon has expanded his original manifesto into an illustrated guide to the creative life for writers, artists, entrepreneurs, designers, photographers, musicians, and anyone attempting to make things - art, a career, a life - in the digital age. Brief, direct, and visually interactive, the book includes illustrative anecdotes and mini-exercise sections calling out practical actions readers can take to unleash their own creative spirits.
Stats for nerds
18recommend
35mentions
31people
2011–2025years
60% recommend40% neutral
Mentions per year
What Hacker News says
- Cal Newport, So Good They Can't Ignore You. This book convinced me to stop widening my skillset by beginning again, and start doubling down on my strengths.
Gene Kim et al., The Phoenix Project. This book reinvigorated my love for management, which I lost in 2021–2022. I'm still an IC, but I decided to stop refusing management roles.
Kent Beck, Extreme Programming Explained, 2nd Edition. This book lit a fire under my ass to figure out better ways of working. I followed it up with the next one in a book club at work.
James Shore et al., The Art of Agile Software Development, 2nd Edition. This book gave me hope that a productive, humanist, productivity-oriented workflow can work in today's software world. I read it with my teammates in a book club at work, including the software engineers, QA tester, product owners, and UX designer. Unfortunately the rest of my team had little interest in putting it into place where I work.
Robert C. Martin,
Clean Architecture. This book was a delightful read. Uncle Bob weaved practical advice together with stories from his past that served both to illustrate his points and to entertain. While I don't agree with every word in the book (e.g. Screaming Architecture), I still recommend it to every Senior+ Software Engineer.Eric Evans,
Domain-Driven Design: Tackling Complexity in the Heart of Software. Aside from its amazing content, this book has some of the best typesetting I've ever seen. I sought out a font that is a match (or near-match) and reverse-engineered the letter spacing, line height, heading font sizes, etc. Its content was great too, but I was glad to have read Vaughn Vernon's DDDD first.Vaughn Vernon,
Domain-Driven Design Distilled. This book followed up Shore's work in our book club at work. Everybody on the team really liked what they read, but nobody felt like they had actionable insights. So the engineers went on to read Vernon's IDDD, and the non-engineers read Adzic's IM and Patton's USM.Vaughn Vernon,
Implementing Domain-Driven Design. I read this book with a book club at work. While Evans's work was well-grounded in theory and left a lot of interpretation in the patterns behind DDD, Vernon is a practical, nuts-and-bolts DIY guide to one approach to DDD. Luckily, these tactics resonated with my team and our codebase has seen marked improvements in the past few months. I'm looking forward to our process catching up so we can do more than "DDD Lite."Jeff Patton,
User Story Mapping. This book was fun, practical, and completely outside any way I'd ever worked. It also helped me understand exactly why I've failed every time I tried to make my own SaaS startup on nights and weekends.Gojko Adzic,
Impact Mapping. This book was basically a pamphlet. The process seems...good? But since I'm no longer in a role with the influence or authority to recommend product direction, I doubt I'll get much use out of this for a while.Tanya Reilly,
The Staff Engineer's Path. This book wants to follow in the footsteps of Camille Fournier's The Manager's Path, but it seemed less specific and useful as a roadmap. Perhaps that's because of how different "Staff Engineer" is from company to company, at least when compared to the roles covered by Fournier. But it did help me earn my promotion to* Staff Engineer, so it was clearly worth reading.Tamar Rosier, Your Brain's Not Broken. This book was the second I read after I got diagnosed with adult ADHD. I appreciated that it helped me de-stigmatize, because I harbored some bummer feelings when I realized no actually I didn't grow out of it. It also helped me reflect on my habits of action, and see them in a new light. I was surprised to see how much of my anger and frustration in life was a coping mechanism to help me get things done. I've had a much calmer life since recognizing that.
Alexander Tarlinder, Developer Testing. I'm not quite finished with this book, but I'll be done by the end of the year. It's been a great overview of automated testing from the perspective of a programmer. It helped refresh my memory on things I knew but forgot. It filled gaps that I had in my baseline knowledge. It corrected things I "knew" but was slightly incorrect about. I now recommend this to any programmer, whether or not they've got a habit of testing.
Austin Kleon's trilogy: Steal Like An Artist, Show Your Work, Keep Going. These books were cute, full of incredibly quotable passages, and fun to read. I didn't spend enough time on them, though. A lot of the lessons I thought I'd learned left my brain like water through a sieve.
Kent Beck, Tidy First?. This book helped me understand the economics of software through a new light. That was important to me, because during the time I spent as a Director of Software Engineering I was not given a budget and asked to manage the department's expenses.
Antonio Cangiano, Technical Blogging, 2nd Edition. This book convinced me to start a blog. It was going really well, and then I shrank back from it due to fear of vulnerability. Since I got over those fears and started blogging again, it's been a lot of fun again. I incorporated what would've been tweets into the blog (as "quick posts") in addition to my longer-form, less-ephemeral content (as "articles"). Writing has been a great way to solidify what I've learned and distill my opinions. Heck, I should migrate this comment to my blog.
I also read other books (especially on my journey to becoming a magician), but these were the ones I thought Hacker News might be most interested in.
- > software specifically for tracking UX metrics
which UX metrics you’ve personally found the most valuable?
> Copy whatever is already good
it immediately reminded me of Steal Like an Artist. Great advice, and I always forget that sites like Dribbble exist since they’re not usually in my go-to set of tools
- For people wanting to dig into this idea some more, I'd recommend the book by Austin Kleon called "Steal Like An Artist." Also, there is some nuance in the book about copying and stealing, without being a thief.
- When I reread these, I always pick up some details that I missed in the earlier reads:
- On the shortness of life - Traction: How Any Startup Can Achieve Explosive Growth - Show your work and Steal like an artist - Domain modeling made functional
- First I read your title, and told myself, "No, I ain't that", but I clicked anyway to see what others are saying about being a master programmer.
Then I read your definition for this question, and I thought, " sure, I am that. I can program stuff with only google."
How I came here?
I programmed a lot. First, books, tutorials, then small projects.
Coding is not really the harder part. You can go to codewars and begin solving easy problems. And where you don't understand, get help from YouTube. Neetcode is great for Leetcode. This way you learn to solve logical problems. Turn ideas into code.
Ideally learn multiple languages. And then you understand the concepts rather than the syntaxes.
Then you can make minor improvements to existing code. I use and used (before learning to code) a lot of OSS, and, after learning to code, when I saw something that could be improved, I went ahead and created a PR, or fixed a bug. This is lot easier than creating something from scratch.
Before coming here, I fixed some documentation, added translations to readme after learning to use Git and GitHub.
After documentation, and before features/bugs, I fixed minor code errors in tutorials that I watched. Most tutorials nowadays have an open GH repo.
Then comes the harder part, that is planning something. You have to know how to design systems. And here, too, mimic others first. If you want to create games, look for similar OSed games, and learn the structures from them.
Then code your own. Games, websites, apps, whatever.
Tutorials like from freeCodeCamp are important, too, as they not only show you the code, they show you the structure/architecture of things as well. A good starting point from tutorials would be to understand the architecture/function definition and then pause the video and write the code yourself. This is how you start.
Then you start your own project. Design the whole architecture yourself and code it up.
Some Mathematician said that you can't become a Mathematician until and unless you have given yourself a problem that you want to solve. Same goes for programming, in my opinion.
Build something that you need for yourself, that you think should exist.
Write program in the area where you feel genuine interest. For me it was scientific programs like Non-Linear Dynamics, Conway's Game of Life, Machine Learning, Deep Learning, etc. For a friend, it was Electronics circuit simulators. Write stuff that you feel interested in.
This way you begin to see coding as an means to an end, and not the end itself. In my opinion, this is good.
One missing piece in this comment is knowledge of solutions. Immersion is helpful like it is in learning languages. Immerse yourself in an environment buzzing with programmers. It is free with a CS degree or a job writing software. But I started out as a Physics undergrad, and I had to get my immersion from Reddit, Quora, and later HN.
You have to know the names of solutions that exist. Netlify, Ghost, Hugo, DragonRuby, Unity- you must know the names and one line descriptions first, in order to use them as pieces in your software.
I wrote what I know. I hope it helps you. Although Austin Kleon's "Steal Like an Artist" is written for the creator economy, beginner programmers can learn from it. "Don't start with a blank page"- is an important lesson.
May I get the name of the DSA book that your friend read three times?
- > You have to be at your keyboard or lab bench or whatever enough to make things. But if you are there too much your creativity plummets.
I agree, one of the ideas that I started applying from the book "steal like an artist" involved having an analog and a digital desk for work.
You have creative ideas and brainstorm at the analog desk, then document, iterate, and refine your ideas at the digital desk.
