Don’t (only) focus on the code

4 minute read

Every developer aspires to create great things, but often the most important issue is not just the quality of your code, but many other and obscure things that are setting you back from achieving your and your company’s goals.

You should write good, well tested code, which doesn’t have to be perfect, but merely good enough. I know that some of the purists will get mad but that is often the case. As the saying goes, Perfect is the enemy of good enough. I won’t go into the quality of the code anymore, because I believe you, as most of the programmers do, write good enough code. What you should focus on is something completely different.

There are three things that you can do while working for a company or consulting for a client:

  • Create value
  • Reduce expenses
  • Both of the above

Ultimately I want you to always think of the ROI (Return On Investment), for either your employer, your client, or yourself in the end. If you steer away from that focal point, and start procrastinating on delivering the product, because the code, design, or copy is not perfect, you will never ship it. Also, if you are not embarrassed by your first release, you have shipped too late.

Now, think long and hard, what situations call for further improving the quality of your code to stick them in the three categories mentioned above? Testing and refactoring bad code will improve future maintainability, which reduces expenses in the long run. Optimising for performance and making the application faster can bring you more clients and earn more money. Optimising workflows will cut the time needed for the end-user to finish a unit of work faster, which reduces expenses per unit of work, allowing them to do more in the same amount of time, or to work less.

Automation is a nice thing to have, but unnecessary in the beginning. If the product that you are creating succeeds, and you start spending a lot of time on processes that should be automated, please automate them, and delegate the execution to someone else. But don’t do it before it really starts to hurt, because you are wasting your (and the company’s) precious time.

Understanding how and why the software does what it does should be the main thing for you to learn about. I agree that you can be some level III programmer in an enterprise behemoth, really detached from the process, being fed with your daily or weekly tasks through some project planning tool and not really knowing how the sausage is made. Maybe you are one of the Dark Matter Programmers, and aren’t really ambitious to move up, and that is also OK. I know people that are in the same situation as you are, happy with the work they are doing. Although I consider this approach highly insecure and uncertain for the long run, it is practical for the present, for them.

If you are focusing on the process, and eliminating the obstacles to reach one of the three points mentioned above (create value, cut expenses, both of them), then your software will be better in the long run. In that process you stop being just a programmer that is easily replaceable, and start being a true business consultant, with a unique set of skills.

As an example, there is a process that each end user has to do to make one widget. It includes going through 10 different screens, and entering a dozen parameters on each screen to produce the widget. Creating any type of widget generally takes 10 minutes Although the company makes different types of widgets, let’s say that one widget accounts for 80% of the sales, and all others for only 20%. Optimising the code in this situation does nothing, because the code has to produce a variety of widgets, and unless it’s really messed up, you should leave it alone.

Optimising the process on the other hand is something completely different. Especially if we have a situation like I mentioned above. I really love the Pareto principle, and try to use it all the time, applying it to any situation will allow you to focus on the stuff that really maters and ignore/drop the stuff that doesn’t.

How do we apply it to the above example? Let’s call the widget that accounts for 80% of the sales The Golden Goose. All widgets have around 100 properties you can set while creating them, but 95 of them are the same for each Golden Goose. So why bother entering and checking each one for a process that happens 80% of the time. Optimising the process from 10 screens and 100 parameters that takes at least 10 minutes and allows for a lot of human error, to one screen and 5 parameters, which reduces the widget preparation time to only one minute will drastically increase the user productivity, allow them to push out more widgets in the same time.

By focusing on the business and not only on the task at hand, you will stand out among your peers. There is no difference whether you are an employee, a freelancer or a consultant, your customers will generally have more respect for someone who looks at the bigger picture, and speaks their language. You can do yourself a big favour and read a couple of business books. It is a very big chance that you work for one, so why not invest a couple of hours in understanding how businesses work. It is a very small chance that those hours are spent in vain. If you don’t know there to start, The Personal MBA by Josh Kaufman is really great, and I can’t recommend it more.

Comments