To my programming ear 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 still do. In hindsight, I see four habits that I wish I had developed in myself sooner rather than later.

1. Automate more

You have been so good at being a one-man shop and you manage to keep so many details and processes in mind. The implementation for one client has 15 steps and you do it every month so you have it remembered and down to five minutes each run.

You’ll get into debates with colleagues about this. With all the features to build and all the bugs to fix, this question will come up again and again:

Is it really worth spending time automating something that only takes a few minutes of your time and is only done once in a while?

Do not think about it this way. Instead, think of these as actions that you must take on a regular basis.

Performing this process manually may only take five minutes of your time once a month. Building automation for that process will take three hours. It can reduce the time it takes to run the process from five minutes down to three minutes.

But here’s the kicker:

With the process automated, you no longer have to run this process.

The payoff for you is not just two minutes a month. Your five minutes can stay zero minutes, for now with the process automated, another can spend three minutes running that process. In fact, it could be anyone else. When it’s crunchy time, anyone on the team with three minutes left can run this automated process.

You do not have to do everything. If you automate more, then everyone else can do everything so you can focus.

Photo of Battlecreek Coffee Roasters at Unsplah

2. Test more

Because you’re good at keeping everything in mind, you’re good at remembering every little switch and shift that needs to be made when building a new feature, just to make sure you have not ruined anything else by add new code.

But are you always sure that you have not forgotten anything? And what about when Charles or Rosa add their code? Do they have the list of each switch and toggle to be moved? They’re going to miss something. So what’s likely to happen is … you’ll have to tamper with them every time they integrate new code.

Testing is about giving yourself confidence – trust that the new code you added does not break any of the old code; trust that you can implement your code without waking up in the middle of the night and thinking, “Oh, if the user clicks that button after remove their payment method instead of before, they will get 500. I have to roll everything back right now. ”

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

Testing is about giving yourself some space Space in your brain to focus on refactoring your code and improve it because you no longer have to keep track of all the switches and toggles you need to jiggle to ensure that your refactoring does not ruin anything. Your tests will do it for you. Now you have the main place to refactorize 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, anyone can contribute their code, and anyone can run the tests – you, your teammates, your customers. You will build with more confidence, adjust with more confidence, demo with more confidence and post with more confidence.

Photo by Markus Winkler on Unsplash

Let others in more

When you did group projects back in college, we all knew our code was bad. None of us understood what we were doing. Debugging was, in fact, just moving code lines in hopes of breaking something up.

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 it makes you scared and insecure.

That fear and insecurity will make it difficult for you to ask others for help, to build a team, to bring others forward. It’s because you want to never feel that the code you entered is ready (good enough) for other programmers to be impressed. In fact, they will probably criticize. They will see how you used a hack to make that API call, or how you deliberately overlooked that edge case.

That fear and insecurity is going to limit you. Seriously. Your opportunities to work with and learn from others. Your opportunities to be a part of projects that require an entire team rather than a one-man store. 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 bad, and expect these reviewers to notice how bad your code is. Own it. So grow from it. (By the way, their code probably has its crazy parts, too.)

Oh well, when you get started doing this, you will find yourself saying, “Okay, Terry, I want to show you this module I’ve built, but give me … three more days just to to clean up a bit first. “Do not. Your code can always be improved and it will never be completely ready for review. You will always have more time to get it ready. Just own your code – as it looks today. Then ask someone to come in and check it out.

By doing this earlier and more often, you will find that your code is starting to get better. This is because you will begin to anticipate as you type your code exactly what habits or deficiencies you have that will cause your reviewer to shake or cry. Isn’t responsibility wonderful?

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

Photo by Belinda Fewings on Unsplash

4. Learn more

You will encounter a lot of very specific coding problems and you will search the web for a solution. You will not always find a solution that way. Instead, you will be rummaging through some third-party documentation, playing with different setups, thinking creatively about the problem you are trying to solve – and then you have to solve your problem.

From there, you could move on to the next issue. But you are depriving the world – especially the programmer who is going to face the same problem that you just solved – of some hard-fought knowledge. After spending time and effort being an expert on this one little problem, do not let that expertise go to waste. Teach others what you have learned.

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 a response to Stack Overflow, you are need to capture this. Another will benefit. Do not rob them of it.

And you also benefit from it. When you are preparing to teach something – whether it is an actual presentation, or an article or a thread post – you learn your solution even better than when you first made it. You will dive deeper and really understand the problem. You optimize your first solution. You will grow in how to communicate deep concepts at a low level to the uninitiated.

You will discover and create amazing solutions to difficult problems. That’s what you do for your customers. But it’s also what you do in certain parts of your code. Take time to “increase the impact of your value” – share your discoveries in a way that teaches others with the same problem. You want to make them experts. You become it yourself.


Good speed on the journey you are going on. It’s going to be a zigzag to get here. But if you want to arrive – maybe not faster, but at least smarter – then note yourself:

  1. Automate more.
  2. Test more.
  3. Let others come in more.
  4. Learn more.


Leave a Comment