We do a lot of programming at RoboSource. In fact, it’s our entire job. Everyone in our company is dedicated to producing high-quality software that solves problems and makes life better. Our software developers do that by writing really good computer code.

I am not a software developer by any stretch (I prefer to contribute to the process in other ways…), so I’ve been surprised to find that the way RoboSource software developers write really good code doesn’t involve secret geek sauce. In fact, the principles our devs use to write good code are the same principles we all should be using to make our work better—whether we’re coding, marketing, baking, or candlestick making.

(All of these concepts have their origin in The Pragmatic Programmer—a book for, well, pragmatic programmers.)

Provide options, not lame excuses

It’s not uncommon for a client to ask us to accomplish a task that seems like a total impossibility. I.e. “please solve the traveling salesman problem for me.” We have some exceptional minds in this company, but there are some problems that probably can’t feasibly be solved given the constraints of time, money, and the human need for sleep. So what do we do?  We go back to the client and say, “Sorry, we can’t solve your problem because we would rather sleep.”

No. We do not.

When we get a question or a task like this—one that seems impossible to solve—we get out the whiteboard. We talk about what the question is. Sometimes the solution is as simple as asking the same question a different way. Then the answer presents itself. Sometimes it means understanding the goal of the task and then finding an alternative solution to the one that seems impossible. Other times we find that the task is indeed unsolvable in its present state. So we come up with the best alternatives we possibly can, and we take those to the client for them to consider.

We always prefer explanations and options to lame excuses.

Invest regularly in your knowledge portfolio

“A mind stretched by a new idea never shrinks back to its original proportions.” – Oliver Wendell Holmes

When I hear the word “portfolio,” I think of stocks. A stock portfolio should expand over time and include a reasonable amount of diversity to be considered successful. It should be worth more today than it was five years ago. And it should be trending up.

Your knowledge portfolio is no different. You should always be expanding it and diversifying. At RoboSource, we encourage our employees to learn a lot about coding. Right now, most of our programmers are reading Clean Code together and discussing it in book club. Our programmers need to be cutting edge in their knowledge of their field. But they need to know more than the best method to call an API, or the best way to store a procedure. We believe in whole-person development at RoboSource. We want our software developers—and our quality assurance testers and our marketing professionals and our project managers—to be awesome humans with a full body of knowledge about life and the world. We want them to be great at leading other people and operating within a business structure and interacting with each other. So we encourage a lot more than reading Clean Code.

One of our apprentices is meeting with a full-time employee right now to discuss a book he just finished on leadership disciplines. Many of us make it a priority to keep up with current events and trends in the world and in technology. RoboSource offers a weekly class for employees that covers a lot of technology topics, and a lot of other topics, like how to communicate effectively with each other, how to think about brand management in a company, and how to follow through on commitments.

Invest. Expand. Diversify! Your mind will be better for it.

Here are a few resources we like right now at RoboSource:

The Hustle (for news about things that you normally wouldn’t notice.)

The Pragmatic Programmer (for definitive advice on how to program pragmatically.)

Clean Code (for a slightly sarcastic approach to coding. Cleanly.)

All of the TED Talks (for brain-stretching information on every topic under the sun, and not under the sun.)

Don’t live with broken windows

This idea comes from the real world, where researchers realized that the beginning of the end for a building (and sometimes an entire area of town) was one broken window. Once one window broke, it was only a matter of time before the whole building became dilapidated. Why? Because people stopped caring. A building with a broken window looks abandoned. It becomes easier to treat it as abandoned. Pretty soon, it really is an abandoned building beyond saving. Bring in the demolition crew

It’s the same way with computer code. We call it “software rot.” Once you make one mistake and don’t fix it, it’s easier to make more and not fix them. Eventually, your software is riddled with broken windows and graffiti and the roof is falling in… it’s not worth fixing. You might as well start over as try to fix everything that’s wrong.

This is secretly the law of entropy—things always get more chaotic, not less, when left to themselves. It’s obviously not just in software development. You could just as easily have legal brief rot or blueprint rot or a host of other types of broken windows. The solution is to be vigilant in your work. When you see a problem, fix it. Don’t be sloppy. At RoboSource we sometimes call this going slow to go fast—you might spend some extra time in the middle to solve issues as they come up, but you’ll save a whole lot of time at the end if you don’t have to try and fix a whole building with a roof that’s caving in.

Fix the problem not the blame

This is just plain old hard. In software development and everything else. Writing software isn’t just typing a bunch of letters and numbers—it’s a highly creative problem-solving process that often results in artistic solutions. These guys sit at their computers and sweat over brick-wall problems, sometimes waking up at 3am with off-the-wall ideas that somehow break through the barrier.

All of that to say, it’s personal. Creating always is. So when you tell devs there’s a problem with their code, it can be a little offensive. It’s like telling Picasso you think choosing red was a horrible decision. But the truth remains: we can’t have bugs in the code, personal or not. The problem has to be fixed, and getting offended and trying to shift blame doesn’t help anyone.

We have a saying at RoboSource, “No pride in authorship.” What we mean when we say that is, “don’t take it personally when your stuff gets critiqued. No one is better than anyone else, and no one is trying to be mean. We can all make each other better if we’re humble enough to listen to each other.”

It’s hard, and not just in software development. I’m a writer—a people-pleasing, perfectionistic writer. When I find out there are problems in my work, my gut reaction is to shift blame or offer excuses. But the truth is that no one is perfect. Humans will make mistakes. We’re better off fixing them and learning from them instead of trying to make sure they weren’t our fault.

Sign your work

“Anonymity, especially on large projects, can provide a breeding ground for sloppiness, mistakes, sloth, and bad code. It becomes too easy to see yourself as just a cog in the wheel, producing lame excuses in endless status reports instead of good code.” – The Pragmatic Programmer

Have you ever watched Antiques Road Show? “Oh, this is a So-and-So, circa 1825.” Whatever the hopeful local brings in automatically gets flipped over and searched for the signature—it offers context and often helps determine value.

It’s no different with your work product or mine. It’s not so much about getting credit for the work (no pride in authorship, remember?), but it is about taking responsibility. Maybe the signature is the company’s name and not yours, but regardless, you should be taking pride in your work as a job well done. You should be willing to stand behind it. “Yes, I made that. It’s good.” If it’s not good enough for you to stand behind, as a member of your company or with your own name, you should probably fix it so you can.


Yes, computer programming is a highly specialized field. It requires a lot of very focused knowledge on a certain subject. But the core principles? Those are universal.