It’s that time of year where people often start thinking about new year’s resolutions. I want to lose 10 lbs, I want to read more books, I want to x, y, and z. Often, it’s just a fantasy. They’re not actually going to lose 10 lbs or they might order some more books but never read them. But at least there’s a spark of hope there. A fundamental faith that they could become a better them. I think that’s tremendously admirable.
The trouble with a lot of these aspirations, though, is that they require the formation of new habits and carving out new chunks of time in an already busy day. That’s not impossible, of course, but it’s hard.
But the one activity most people already have a huge block of the day carved out is at work. That’s a solid eight hours for the majority of people with a regular job. Forty hours a week. About two thousand a year. Imagine if you spent just 10% of that dedicated to actually getting better at what you do.
When I think back over my career, this is where the bulk of the advancement happened. Through a commitment to getting better, smarter, faster at what it is I already spend eight hours a day doing, during that time.
For me, that’s mostly programming, writing, marketing, and management. Every single one of those disciplines hold the promise for improved effectiveness through increased competence. So spending a healthy chunk of the day in deliberate practice and refinement seems like an easy investment to justify.
So what does that actually look like? Let’s take programming. I write a lot of code that’s just meant to solve some problem or implement some feature. There’s usually a quick way to do that by following the path and patterns I already know. That’s the dividend of experience. You’ve done something before, so you can do it again. But it’s also a potential trap.
See, experience will give you a leg up on doing the same things you’ve done before in the same way. But it’ll also raise the price of trying something new, since that might take longer. This is why so many of the big paradigm shifts that happen across disciplines often come from outsiders or even novices. Once you’ve been cooked in experience for too long, the cost of trying something new can seem prohibitive. But spend you must, if you aren’t to stagnate.
So with programming, I try to make it a point of frequently taking the longer route. First, I don’t just want the thing I’m working on to merely work. I mean, that’s step one, but we can’t stop there. As the saying goes: make it work, make it right, make it fast. And then, let me add one more: Make it beautiful.
This focus on aesthetics is a form a deliberate practice. When the bar isn’t just a completed task but a delightful solution, you’re frequently forced to find novel solutions in the wilderness of unfamiliar techniques. There’s so much learning in there. But it requires you to take a breath, look around, and actively search for the hidden flowers of new competency.
It’s the old slow is smooth, smooth is fast again. You take another 15 minutes here, or even 2 hours there, and you don’t just get it right, but you reach two steps further by making it beautiful.
(I’m not going to go into a whole dissertation of what is beauty. If you work professionally within any area of competency, you need to develop that eye first. Even if you can’t explain exactly what makes a beautiful piece of code, design, or prose, you ought to be able to recognize it. Without this ability to recognize excellence, you’re never going to be able to get that. But let’s assume you have this basic, junior appreciation already in place.)
I find that it’s in this search for aesthetic satisfaction that so many of the best lessons are found. I’m not talking about ornamentation or bells and whistles. I’m taking about the beauty of the four Cs: Clarity, cohesion, consistency, and conciseness. If you have the eye, you’ll recognize them easily (even if getting there isn’t quite so easy).
The most practical way I know how to put this principle into action is by reading and rewriting the draft. Everything has a draft, even decisions about management. Step one is not to overthink the initial inspiration. Just get it out of your head and down on paper. Now you have something you can work with, something you can mold.
With programming, that’s the pull request. Some people might see that primarily as a tool of collaboration with others, but I see it as a tool of collaboration with myself first. It’s where the complete body of work, across multiple code commits, is stationed before it enters the codebase. It’s the ideal place to study by zooming out so you can see the whole solution and question its proportions.
That’s why I’m a big fan of large, long-running pull requests. The size isn’t nearly as important as the cohesion of the scope. You have to be able to see the total sum of changes to evaluate the design.
If there’s anything I see juniors often miss, it’s this. Careful, repeated, hell, even obsessive, study of their own work. For programmers that means poring over that pull request of theirs over and over again until it’s as aesthetically pleasing as it is functionally correct. To the level of every line break, every new domain word, every expansion of existing classes or methods.
“But I don’t have time!”, is what I often hear. Or, even worse, “it doesn’t matter, just ship it!”. But it does matter. Because your career, and even your business, is not a single sprint. It’s an intellectual iron man repeated until you’re in the ground. Whatever time you take to refine your technique now will be paid back to you for the next 20-40-60 years of your career. Getting your posture right early is how you reap those dividends of good form.
It’s the same thing with writing. Not just for public consumption, like this, but for internal communication as well. Every comment, every proposal, every bug report is an opportunity to become a little better, a little clearer, and a little more persuasive. But you have to work on it, it doesn’t just happen.
I love that loop. Write, revise, write, revise. It’s like doing reps in a gym. You can’t expect that 10 pull-ups will add any discernible new muscle. But 30 pull-ups, across three sets, done thrice a week, for a year? Yeah, you’re going to notice the cumulative results of that.
But you have to decide that this matters. The incremental but relentless pursuit of betterment. Taking two beats to get it right, not just getting it working. To slow down, so that you can do it smoothly, so that you can eventually become quicker than you ever imagined.
It’s all possible. Work offers endless opportunities and plenty of time. The main blocker is your will to see it so. Try moving that blocker out of the way for 2024. You’ll be amazed what a year can move if you make it count.
The trouble with a lot of these aspirations, though, is that they require the formation of new habits and carving out new chunks of time in an already busy day. That’s not impossible, of course, but it’s hard.
But the one activity most people already have a huge block of the day carved out is at work. That’s a solid eight hours for the majority of people with a regular job. Forty hours a week. About two thousand a year. Imagine if you spent just 10% of that dedicated to actually getting better at what you do.
When I think back over my career, this is where the bulk of the advancement happened. Through a commitment to getting better, smarter, faster at what it is I already spend eight hours a day doing, during that time.
For me, that’s mostly programming, writing, marketing, and management. Every single one of those disciplines hold the promise for improved effectiveness through increased competence. So spending a healthy chunk of the day in deliberate practice and refinement seems like an easy investment to justify.
So what does that actually look like? Let’s take programming. I write a lot of code that’s just meant to solve some problem or implement some feature. There’s usually a quick way to do that by following the path and patterns I already know. That’s the dividend of experience. You’ve done something before, so you can do it again. But it’s also a potential trap.
See, experience will give you a leg up on doing the same things you’ve done before in the same way. But it’ll also raise the price of trying something new, since that might take longer. This is why so many of the big paradigm shifts that happen across disciplines often come from outsiders or even novices. Once you’ve been cooked in experience for too long, the cost of trying something new can seem prohibitive. But spend you must, if you aren’t to stagnate.
So with programming, I try to make it a point of frequently taking the longer route. First, I don’t just want the thing I’m working on to merely work. I mean, that’s step one, but we can’t stop there. As the saying goes: make it work, make it right, make it fast. And then, let me add one more: Make it beautiful.
This focus on aesthetics is a form a deliberate practice. When the bar isn’t just a completed task but a delightful solution, you’re frequently forced to find novel solutions in the wilderness of unfamiliar techniques. There’s so much learning in there. But it requires you to take a breath, look around, and actively search for the hidden flowers of new competency.
It’s the old slow is smooth, smooth is fast again. You take another 15 minutes here, or even 2 hours there, and you don’t just get it right, but you reach two steps further by making it beautiful.
(I’m not going to go into a whole dissertation of what is beauty. If you work professionally within any area of competency, you need to develop that eye first. Even if you can’t explain exactly what makes a beautiful piece of code, design, or prose, you ought to be able to recognize it. Without this ability to recognize excellence, you’re never going to be able to get that. But let’s assume you have this basic, junior appreciation already in place.)
I find that it’s in this search for aesthetic satisfaction that so many of the best lessons are found. I’m not talking about ornamentation or bells and whistles. I’m taking about the beauty of the four Cs: Clarity, cohesion, consistency, and conciseness. If you have the eye, you’ll recognize them easily (even if getting there isn’t quite so easy).
The most practical way I know how to put this principle into action is by reading and rewriting the draft. Everything has a draft, even decisions about management. Step one is not to overthink the initial inspiration. Just get it out of your head and down on paper. Now you have something you can work with, something you can mold.
With programming, that’s the pull request. Some people might see that primarily as a tool of collaboration with others, but I see it as a tool of collaboration with myself first. It’s where the complete body of work, across multiple code commits, is stationed before it enters the codebase. It’s the ideal place to study by zooming out so you can see the whole solution and question its proportions.
That’s why I’m a big fan of large, long-running pull requests. The size isn’t nearly as important as the cohesion of the scope. You have to be able to see the total sum of changes to evaluate the design.
If there’s anything I see juniors often miss, it’s this. Careful, repeated, hell, even obsessive, study of their own work. For programmers that means poring over that pull request of theirs over and over again until it’s as aesthetically pleasing as it is functionally correct. To the level of every line break, every new domain word, every expansion of existing classes or methods.
“But I don’t have time!”, is what I often hear. Or, even worse, “it doesn’t matter, just ship it!”. But it does matter. Because your career, and even your business, is not a single sprint. It’s an intellectual iron man repeated until you’re in the ground. Whatever time you take to refine your technique now will be paid back to you for the next 20-40-60 years of your career. Getting your posture right early is how you reap those dividends of good form.
It’s the same thing with writing. Not just for public consumption, like this, but for internal communication as well. Every comment, every proposal, every bug report is an opportunity to become a little better, a little clearer, and a little more persuasive. But you have to work on it, it doesn’t just happen.
I love that loop. Write, revise, write, revise. It’s like doing reps in a gym. You can’t expect that 10 pull-ups will add any discernible new muscle. But 30 pull-ups, across three sets, done thrice a week, for a year? Yeah, you’re going to notice the cumulative results of that.
But you have to decide that this matters. The incremental but relentless pursuit of betterment. Taking two beats to get it right, not just getting it working. To slow down, so that you can do it smoothly, so that you can eventually become quicker than you ever imagined.
It’s all possible. Work offers endless opportunities and plenty of time. The main blocker is your will to see it so. Try moving that blocker out of the way for 2024. You’ll be amazed what a year can move if you make it count.