Little things matter.

Cover your code in unit tests.

As you refactor your code into smaller and smaller pieces, it becomes easier to cover these shrunken methods with unit tests. The less logic that resides in a method, the less there is to test. This makes it simpler to provide full coverage of the methods that make up a class.

Unit tests are simple things. The only test the logic in the method; outside dependencies are typically mocked out. The methods called within the logic are tested elsewhere. Because they are simple, it is easy for a new person to understand the code and what the tests are trying to do.

One should aim for 100% coverage, where reasonable. Be sure to use a variety of examples including both common and edge cases, so you can test the various branches in the code.

Unit tests are not sufficient to prove the application works; after all, one can assemble the wrong application using perfectly fine building blocks. Integration and behavior tests are still needed. Still, unit tests are highly valuable and simple to add, so should be required part of the application.

Keep out of the loop.

This is a simple database optimization many people overlook.

One of the most common causes of poor application performance is poorly designed database queries. When a software routine accesses a database, it typically has to send a message over the network to another server, which in turn has to access physical disk drives using a large number of operations. Before solid-state drives, this was even slower, involving small mechanical arms and rotating disks.

This problem can become thousands or millions of times worse if database actions are performed inside loops. Many inexperienced programmers make the mistake of collecting data from multiple tables by performing actions in loops. In most cases, however, a well-designed SQL query can join all of the necessary tables in a single, smart query.

So the key thing to remember here is that you should not put database queries, inserts, updates, or deletes in loops. Also make sure your ORM is not inadvertently creating loops, either.

Make this a single database update or request where possible.

Leverage the ORM.

Use relationships to reduce queries.

Relationships are directives to the ORM that describe how one model is related to another. The most common of these is the “has many” and “belongs to” relationships. An author “has many” books, and a book “belongs to” an author. Tying the tables together in this manner creates SQL joins under the covers, making it easy to get related data.

By leveraging the features of the ORM, you can avoid writing prescriptive SQL language and focus on the business issue at hand. After all, “book.author.name” seems rather intuitive and obvious in what it is getting at, without resorting to five lines of SQL.

When a new reader visits the code and sees “book.author.name”, they don’t need to spend any time parsing the code to determine the intent. It’s clearly the name of the author of the book. When you compare this to old Java code with several lines setting up a JDBC connection and concatenating strings to form a SQL query, you realize how much simpler this is.

Hacking is overrated.

Throwing crap together is not a good strategy.

Sometimes a programmer will play fast and loose and try random things to solve some kind of problem. Through various hacks, the system appears to start functioning. The problem is, the system could stop functioning later, or perform improperly under different conditions. Hacks are notoriously unreliable.

As a professional software engineer, you should refuse to hack code that only seems to work. Software should be deliberate, with obvious intent. One should write code that is clearly, obviously correct.

Write tests that will prove the software implementation is correct. When other programmers view the tests, they should easily understand the desired behavior of the system, including how it should perform in the edge cases and under awkward circumstances.

Save the hacking for things that don’t matter, like competitions and personal websites. Hacking can be fun and provide an opportunity to show off clever solutions, but it has no place in professional work.

Accept advice.

Learning from others is vital to self-improvement.

Be coachable. It can be quite challenging to get people to give you advice. So, when you do receive advice, it is important that you are in a position, mentally, to act upon it. If you are the kind of person who ignores advice, then you will soon run out of people willing to advise you.

Learn from feedback. Once you have the advice, take it to heart. It can be difficult enough to receive feedback, so don’t you dare waste it if you are lucky enough to receive it. Some people, unfortunately, rarely get any feedback, living their lives in complete ignorance. Don’t be that guy.

Listen carefully to what others say. Treat their words like precious secret information to be mined for powerful knowledge. With this, you can become a better person.

Use maps.

They’re a good tool for complex queries.

Simple queries can use the basics of ActiveRecord. The model matches the database table, and operations on the model can mimic the queries on the table. For many operations, this is all you need.

In more complicated scenarios, you will need to join data from two tables and return them in a result set. By mapping the results from a complex query into a result set, you can more easily access and manipulate the data in the rest of your application.

Don’t assemble these maps using a for loop. Instead, return the query results straight into the map, so it lands in the result set in one action.

Make data input easy.

Let the user enter information their way.

It can be very frustrating when you try to enter data into a website, and it returns an error, not because you entered the wrong number, but because you didn’t use the right combination of dashes, spaces, parentheses, or other non-numeric symbols. This syntactic sugar is not necessary and can be easily stripped out with a straightforward regular expression. Still, some developers feel it’s necessary to impose their will upon their users and make them add the symbols. This annoys the user and sometimes will cause them to abandon the form. After all, there are cat videos to see on YouTube. If you don’t value your customer’s time, they may soon get distracted and go elsewhere.

There are many ways to enter a date, for example. You might use slashes, or dashes, or spaces, or slashes and spaces, or periods, or some other thing. You might spell out the month completely, or use a three-letter abbreviation. You might use two digits or four digits for the year. It’s really not that hard to allow the user to enter a date their way. If you’re concerned that the value may be wrong, you can reformat the input after the focus leaves the field and display it back to the user.

Similarly, there are many ways to enter a phone number. Parentheses, dashes, dots, spaces, or some combination. Instead of forcing the user to enter it your way, let them enter it their way. You can reformat it afterward.

The same thing goes for social security numbers. Should the user have to enter the dashes? Or worse, did you divide this up into three separate fields, forcing multiple mouse actions to enter a number? Don’t make this hard.

If you make it easier to for your user to input data, they are more likely to finish filling out your form. Conversion rates are low for many reasons, and lousy user experience is high on the list. Be kind to your users.

Uncover the user’s true intention.

Find out what the really want.

When gathering requirements from the business, it can be challenging to bridge the communication gap between what the user would like to see and the vision that gets explained to you. It’s imperative that you get the requirements right because making corrections later will be quite expensive. Here are three tips for getting better information.

First, restate the problem in different words. It may be that the person you’re talking to chose the wrong words in the first place, or struggled to explain what they really meant. When they hear the explanation echoed back to them in different terms, it may reveal some of the flaws in the assumptions.

Second, keep asking “what if” and “why”. Just keep digging for explanations and possible alternative outcomes. It may be that the actual requirement is hidden under a bunch of other assumptions. Sometimes people ask for one thing because they believe it will get them something else. That “something else” may be the actual requirement.

Third, use visual aids. Get some colorful markers and attack the whiteboard. If a picture is worth a thousand words, then it’s certainly worth several attempts at sketches. Map the workflow, create a process diagram, visualize the various states of the desired system. When you get to an agreement with the results, take pictures of the board and add it to the requirements documentation.

People rarely spend a lot of time on requirements, and more time is almost always warranted. The business person wants to rush through the process and assumes you’re reading his mind. More ignorant ones assume making changes later will not cost much. Try to avoid that situation.

These are software too.

Your build and test scripts deserve first class treatment.

Some people treat the build and test scripts as second-hand citizens, which is a mistake. These scripts are a critical part of the process that builds your product. They may not be a part of the finished product that is seen by the customer, but they are still vital to delivering a high-quality product.

Maintain these scripts in version control. You’ll want to be able to revert to earlier versions if something goes wrong, or if recent changes don’t give you the results you want.

Similarly, track changes. Just as you would open a ticket in your issue tracking system for software enhancement, you should also open tickets for changes to build and test scripts.

Follow best practices when writing your scripts. This means choosing your names carefully, adding proper documentation, separating concerns, and avoiding copypasta code.

In other words, don’t do things in your scripts that wouldn’t do in your source code. They’re just as important.

Look under the hood.

It’s great to learn how things work.

Originally, this idea applied to cars. If you were going to own and maintain a car, you should look under the hood and learn what all the parts are. Learn what each component’s function is. This way, when the car breaks, you will know what’s wrong with it, and possibly be able to fix it. And if not, you’ll be better informed when visiting a mechanic.

The same idea applied to personal computers. Any time a new PC was purchased, I would encourage people to open it up and look inside. What kind of memory, CPU, motherboard, and video card did it have? If one had to upgrade the memory or install a new card, where would it go? Later when it was time to repair or upgrade the computer, you would be prepared.

Today, this concept works great on open-source software. Some people take the functions for granted and just want to use the components. It is a much better practice to actually open up the source code and understand how it was all put together. You can learn more about the features this way, especially if the documentation is weak. Open-source software can also be a great example of well-written code, because of the hundreds of code reviewers. You may learn some new techniques by studying the source code.

And if you don’t have access to your new tool’s source code? Read the manuals and know your APIs. Even if the software isn’t open-source, you should still learn everything you can about it. There can be very useful features hidden in the far corners of the documentation. Seek out the gems.