Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore.

15 St Margarets, NY 10033
(+381) 11 123 4567



To My Programmer Self 20 Years Ago: Do These 4 Things More

Twenty years ago, I landed my first gig as a freelance web developer. Twenty years later, I’m still doing it. In hindsight, I see four habits that I wish I had developed in myself earlier rather than later.

1. Automate More

You’ve been so good at being a one-man shop, and you’re able to keep so many details and processes in your head. The deployment for that one client has 15 steps, and you do it every month, so you’ve got it memorized and down to five minutes each run.

You’re going to get into debates with co-workers about this one. With all of the features that need building and all of the bugs to fix, this question will come up again and again:

Is it really worth spending the time to automate something that only takes a few minutes of your time and is only done every once in awhile?

Don’t think about it this way. Instead, think about it this way:

Performing that process manually may only take five minutes of your time, once a month. Building automation for that process will take three hours. That may reduce the time needed to run the process from five minutes down to three minutes.

But here’s the kicker:

With the process automated, it no longer has to be you that runs this process.

The gain for you is not just two minutes a month. Your five minutes can become zero minutes, because now with the process automated, somebody else can spend three minutes to run that process. In fact, it can be anybody else. When it’s crunch time, anybody on the team with three minutes to spare can run this automated process.

You don’t have to do everything. If you automate more, then everybody else can do everything, so that you can focus.

Photo by Battlecreek Coffee Roasters on Unsplah

2. Test More

Because you’re good at keeping everything in your head, you’re good at remembering every little switch and toggle that needs to be jiggled whenever you build a new feature, just to make sure you haven’t broken anything else by adding new code.

But, are you always sure you haven’t forgotten something? And, what about when Charles or Rosa add in their code? Do they have that list of every switch and toggle that needs to be jiggled? They’re going to miss something. So what will probably happen is… you’ll have to do that jiggling for them whenever they integrate new code.

Testing is all about giving yourself confidence — confidence that the new code you’ve added doesn’t break any of the old code; confidence that you can deploy your code without waking up in the middle night, thinking, “Oh shoot, if the user clicks that button after removing their payment method instead of before, they’re going to get a 500. I need to roll everything back right now.”

Yes, it takes time to write tests. And writing tests first is not as gratifying as writing implementation code first. But, it helps you keep your head clear. Test writing lets you focus first on what your code is supposed to do. Then, you can implement the how.

Testing is all about giving yourself some space — space in your brain to focus on refactoring your code and improving it, because you no longer have to keep track of all those switches and toggles you need to jiggle to make sure your refactoring doesn’t break anything. Your tests will do that for you. Now, you have the head space to refactor your code.

Oh, by the way, bonus points if you know how to add:

automate more + test more = automate your tests more

With automated tests, anybody can contribute their code and anybody can run the tests — you, your teammates, your clients. You will build with more confidence, tweak with more confidence, demo with more confidence, and ship with more confidence.

Photo by Markus Winkler on Unsplash

3. Let Others In More

When you did group projects back in college, we all knew that our code was crappy. None of us understood what we were doing. Debugging was really just jiggling lines of code in hopes to un-break something.

As a one-person freelancer, your eyes see 100% of the code. And, chances are, 100% of the code has only been seen by your eyes. And that has you scared and insecure.

That fear and insecurity will make it hard for you to ask others for help, to build a team, to bring others on. That’s because you’ll never feel like the code you’ve written is ready (good enough) for other programmers to be impressed by. In fact, they’ll probably criticize. They’ll see how you used a hack to make that API call, or how you knowingly overlooked that edge case.

That fear and insecurity are going to limit you. Severely. Your opportunities to work with and learn from others. Your opportunities to be a part of projects that require a whole team rather than a one-man shop. Your opportunities to grow.

So instead, make it a habit to let others in more. Ask other programmers to take a look at your code. Accept that your code is crappy, and expect that those reviewers will notice just how crappy your code is. Own it. Then grow from it. (By the way, their code probably has its crappy parts too.)

Oh also, as you get started doing this, you’ll find yourself saying, “Ok, Terry, I want to show you this module I’ve built, but give me… three more days just to clean it up a little first.” Don’t do that. Your code can always be improved, and it will never be perfectly ready for review. You’ll constantly be wanting more time to get it ready. Just own your code — the way it looks today. Then, ask someone to come in and check it out.

By doing this earlier and more often, you’ll find your code start to improve. That’s because you’ll start to anticipate, while you’re writing your code, just what habits or shortcomings you have which make your reviewer cringe or cry. Isn’t accountability wonderful?

Your code will never be perfect. Don’t wait until the day that it is before asking for another set of eyes to review it and give feedback. Otherwise, that day will never come.

Photo by Belinda Fewings on Unsplash

4. Teach More

You’re going to run up against a lot of very specific coding problems, and you’re going to search the web for a solution. You won’t always find a solution that way. Instead, you’re going to muck around in some third-party documentation, play around with different setups, think creatively about the problem you’re trying to solve — and then you’re going to solve your problem.

From there, you could move on to the next problem. But, you’re robbing the world — especially that programmer who is going to face the same problem you just solved — of some hard-fought knowledge. After putting in the time and the work to be an expert on this one little problem, don’t let that expertise go to waste. Teach what you’ve learned to others.

Kent C. Dodds calls it “increasing the impact of your value.” SWYX (Shawn Wang) calls it “learning in public.”

Whether it’s writing a tutorial article or a blog post or an answer on Stack Overflow, you need to capture this. Somebody else will benefit. Don’t rob them of that.

And you’ll benefit too. When you’re preparing to teach something — whether it be an actual presentation, or an article, or a thread post — you’ll learn your solution even better than when you first crafted it. You’ll dive deeper and really understand the problem. You’ll optimize your initial solution. You’ll grow in how you communicate deep, low-level concepts to the uninitiated.

You’re going to discover and craft awesome solutions to difficult problems. That’s what you do for your clients. But that’s also what you do in specific pieces of your code. Take the time to “increase the impact of your value” — share your discoveries in a way that teaches others with the same problem. You’ll make them experts. You’ll become one yourself.


Godspeed on the journey on which you’re about to embark. It’s going to be a zigzag getting here. But if you want to arrive— perhaps not more quickly, but at least more wisely — make a note to self:

  1. Automate more.
  2. Test more.
  3. Let others in more.
  4. Teach more.

Credit: Source link

Previous Next
Test Caption
Test Description goes like this