Laziness, impatience, and hubris. These are the three virtues of a great programmer written by Larry Wall (the creator of Perl) in his book, "Programming Perl". More specifically, he wrote them as the "Virtues of the Perl Programmer", but they certainly span beyond Perl.

This post is about how being lazy, impatient, and over-confident has improved my efficiency and the quality of my work. More importantly, though, it's about how these virtues allow me to enjoy my job while solving the problems at hand quicker, and how it can do the same for you.

Laziness

I fell in love with programming when I was in high school. I had a fantastic teacher who had more to offer than most college professors I've encountered. I think what made her so effective was that she really focused on teaching the mindset that a programmer should have rather than the syntax of any particular language. One thing that stuck with me more than anything else that she taught was laziness. It's the first of the three virtues of a great programmer. Here's the description of laziness, straight from "Programming Perl":

Laziness sounds like the vice of the same name, but there’s a difference. The vice is about the avoidance of immediate work. The virtue is about the avoidance of future work.

And oh man, did I take that to heart. Laziness has become my core philosophy as a programmer, and it's a key ingredient to doing quality work. After all, it's the job of a programmer to do as much work now as they possibly can to ensure that they will do as little work as they possibly can later. A lazy programmer is a programmer that creates software that scales and source code that's maintainable. A lazy programmer is a magician that makes future problems disappear.

Organization

So many frustrating problems can pop up when working on software. You get bugs, "it worked on my machine" syndrome, and things working when you have no idea how. Hours and hours are spent trying to solve these problems when they could all be prevented in the first place. They all stem from the same problem: a lack of organization.

Take this snippet of a file structure inspired by several projects I've seen before:

.
├── api.go
├── capMon.go
├── health.go
├── kubernetes.go
├── logs/
│   └── output.txt
├── processor.go
├── procMon.go
├── projectBinary
├── send.go
├── sync.go
└── yamlMon.go

All I can say is YIKES.

I'm only kidding, I can say more. I mean what is capMon? Are we playing Pokémon? Where is the main starting point? Turns out the answer is in processor.go, right in the middle of the 1000 line file. What about api.go? That might make sense if it wasn't for the fact that kubernetes.go, health.go, send.go, and sync.go were all part of the API as well. You would never know that without looking through the code, which is buggy and unorganized as well. It's a tar pit - once you get in, you'll struggle, and the more you struggle, the deeper you sink.

There are several other problems with a file structure like this, but I have to stop or I'll go on forever. Months are wasted on code bases like this one, and unfortunately, this is more common than not.

Here's a revised structure for the software:

.
├── api/
│   ├── api.go
│   ├── health.go
│   ├── kubernetes.go
│   ├── send.go
│   └── sync.go
├── cmd/
│   └── program/
│       └── main.go
└── database/
    ├── capability.go
    ├── process.go
    └── yaml.go

The code itself may not be fixed, but even a small change like this can save weeks worth of time, and the best part is that it's not much work at all to do this from the beginning.

This goes beyond software structure, though. I can't count how many times I've tried to help somebody with a problem only to wade through a swamp of scattered files and directories just to find something simple. I get it, we're only human, but the mindset of "I can always fix it later" rarely does anybody any good. Yes, you can fix it later, but it'll be much more of a pain. Once I learned to save myself the pain and do it right from the start, I was surprised with how much time I saved.

Automation

I currently go to an online school, but it wasn't too long ago that I was taking in-person classes on a campus. At that school, I had a particularly terrible class due to a particularly terrible professor. We were made to grade each other's homework, which he claimed was a "learning opportunity", and he had incredibly arbitrary rules that we were required to follow. Par for the course as far as college goes, but his biggest offense was that he had us create his quiz and test questions for him.

We were separated into groups, and every week, for fifteen weeks, each team had to create five multiple choice questions, five short answer questions, and five code snippet questions. Every question we wrote had to be written in a very particular format, and the file's line endings had to be \r\n since it worked in Windows notepad, which he was using. It was a lot of work on top of the work we were already given.

For the first two weeks, we tried to do the work manually. It was a mess. Some of the team was doing work last minute, losing questions, and everybody was forgetting their secondary roles (editing, submitting, etc.). So what did I do to fix the problem? Well, I created an entire website from scratch in two weeks, of course. This is what it looked like:

It was full with an in-built code editor, interactive multiple choice inputs, and progress statistics. Most importantly, it would keep track of who was doing what and format the questions exactly the way the requirements stated. I almost got to the point where the server would automatically email the professor when everybody voted to submit it, but the class ended before I was able to.

The moral of the story is that you won't always be able to prevent frustrating work from presenting itself, as organized and prepared as you may be. Some things will be thrust upon you against you will. But never fret; you can always automate it.

At work, I automate almost everything that takes me over a minute to do and I do often. I no longer set up my machines with my tool set, a script does it for me. I don't deploy my software to a test machine, I have another program that does it for me and live-streams the logs back to me. Automation can be easy, or it can be hard. It can be a simple script, or it can be a complex program. When thinking about automating something, you have to assess how much time it saves you. Will the time to develop the script take longer than it would to do the task manually? Most of the time, you'll find that the answer is no, and you can completely automate those tasks away.

Impatience

This is the second virtue of a great programmer. From the book:

Impatience is that nasty feeling you get when the computer is doing what it wants instead of what you want. Or, more correctly, when the programmer on the other side of the software chose the wrong default settings, made a poor GUI, or doesn’t give you access to this data. You’ve experienced it enough to not inflict the same pain on other programmers, turning your frustration with your wasted time into a benefit for other people.

Any programmer that has had to work with another has faced this problem. It's an innate annoyance of any inefficiency that disrupts the instant gratification we crave. Yet, the problem is common enough that I'm inclined to not believe a programmer who claims they have not dealt with this problem.

But impatience doesn't always apply to working with others. A lot of time time, the one you find most difficult to work with is yourself. This section is about being impatient with yourself, and making it more tolerable for you to work with you.

Using the Right Tools

You shouldn't have to create your own chainsaw from scratch to cut down a tree, yet I see people using vanilla JavaScript to build complex user interfaces instead of a framework all the time. The time and resources that takes to do is ridiculous for the task at hand. Using the right tool for the job can quite literally make you go from taking months to finish a task, to weeks or even days.

The biggest thing that clicked for me was realizing just how inefficiently we write text. Have you ever thought about how much time it takes to copy and paste something with your mouse over and over? Or how long it takes to use the arrow keys to move to another part of your document? All that time adds up, and it's not anything you'd ever notice until you don't do it anymore. And it's all because we use tools designed for ease-of-use, not efficiency. That's fine for the layfolk, but as tech professionals, it's downright unacceptable in my opinion.

This changed for me after I learned Vim. If you're not aware of what Vim is, it's a text editor designed around using shortcuts exclusively. I mean, the mouse is disabled by default. It has a high learning curve, but the amount of time you save yourself in the long-term is unparalleled. After all, most of us write text all day, every day. Take the example of a group of lines that need their prefix changed. Here's how I'd do it in Vim:

What might take the casual copy-paster 15 seconds to do, I've condensed into a maximum of two seconds. Not only that, but it's scalable. While it may not be practical, you can give me 1000 lines and I can do it at the same speed.

Let's look at a more complex example. Say, perhaps, that you have a CSV file full of peoples' names, jobs, and cell phone numbers, and you need to convert it to JSON format. Here's what it looks like in Vim:

That's not something you can do in any other tool I know of. All it needed me to do was teach it how to format the text once (which I didn't include since it takes 15 seconds), and then I simply told it to repeat that work 15 times. I've had to do things similar to this countless times, and each time it comes up, I can't help but appreciate how much time I save. The alternative is to write a whole program that will format it for you, or go line by line and manually copy and paste the text for each one, which is something I see people do a lot.

I focused on Vim a lot here because it's a perfect example of using the right tool for the job, but it's only an example. There are so many things you do on a day to day basis that you're probably using the wrong tool for. As a general rule of thumb: if a task feels like there's a better way to do it than the way you're using, there probably is.

Side Note: Know Your Tools

This might seems self-evident, but even if you are using the right tools, they won't help if you don't know how to use them. I can't count the number of times somebody has told me "I wish tool W did X, Y, and Z", just for me to point out that tool W does, in fact, do X, Y, and Z, if only they read the instructions they'd know about it.

I get it, instructions are boring, but if you are using (and cussing at) a particular tool every day, you ought to know what it does. Take the time to read the five-page manual on what it does. It'll be boring, but it will save you frustration later on.

As a special case, it particularly concerns me how many people are writing software in professional setting when they hardly know the language they're working with; how they download libraries with functionality that is already built into it and incur security risks. There is great value in learning in-depth about a tool such as a programming language that's used to make content for other people. This is a problem that's in more software than you know, and you can find it pretty easily by looking at open-source software on GitHub.

Over-Confidence

Hubris, the last virtue has this description in "Programming Perl":

Hubris is the sense that, with the right tools, you can do just about anything. It’s all a Simple Matter of Programming, right? It’s also the thing that’s likely to make you fly too close to the Sun.

Hubris is the over-confidence a programmer gets from winning and solving problems all the time. It's the yeast that inflates laziness and impatience and makes them relevant. Why be organized if you feel like it won't matter anyway? Why learn your tools if you feel like it won't help? Over-confidence is the thing that makes a programmer move forward even when something seems impossible.

Perhaps it's the hubris in me, but I'm not concerned with flying too close to the sun. In fact, I think it's entirely necessary. Tech is at the forefront of innovation. We are becoming a software-defined world, and somebody needs to test the boundaries. Somebody needs to see how far we can go.

After all that I've learned so far - and I still have a ways to go - anything seems possible. Every problem is simply a matter of difficulty, not possibility, and it's that mindset that drives me to do more; it's that mindset that inspires me to be lazy and impatient so that I can focus on moving forward.

So in conclusion, whether you're young or old, experienced or inexperienced, you should strive to be the laziest, most impatient, most stubborn person you can be. Your co-workers will respect you more for it, and so will you.