Name your functions well.

A good name describes its returned value.

Function names should not be vague. It should be immediately
obvious what you’re going to get when you call the function.

A function is a method that takes zero or more inputs and returns an output. When the output is an object in the business domain, it’s generally much more helpful than when it returns primary types.

Say you have a function that takes a zip code as an input and returns a list of nearby stores. If you named the function “getLocations()”, it is rather vague. What locations? How do I use them? What kind of object am I getting back?

On the other hand, “getStoresNearZipCode(ZipCode)” gives you the idea that it is returning an array of Store objects. It also points you toward passing a zip code object as the argument.

This type of thing may seem like a trivial issue, but it dramatically increases the speed of development and improves the understanding of the code by others.

Sometimes a class isn’t worth it.

Only some things deserve to be a class.

If you have a class with a few methods but no data elements, you may be better off implementing it as a method in another class. After all, without data, what does it really represent?

Occasionally you’ll see these things, such as a Calculator class, that only consists of complex logic for performing some calculations. But, of course, this begs the question, calculations on what? And as soon as you figure that out, you may wonder how that thing is modeled and whether these calculations should live closer to that object.

Programmers often name these classes after verbs.

In another example, take a class named “Shipper”. Its job is to ship something. Ship what? An order. Ah, it’s an OrderShipper. Or wait, maybe ship() should be a method inside the Order class. So my_order = new Order(”pair of shoes”); my_order.ship(”123 Mockingbird Lane”); and so on.

Have a plan before you code.

Know where you are going and what you are going to do.

Draw out a plan for your code before you start developing software for your next commit. This way, you’ll have a much stronger idea of what tests you need to write, what objects and methods to incorporate, and what services you need to integrate.

Having a plan is called software architecture. Always know where you are going. Coding aimlessly and randomly will lead to trouble, rework, and delays.

It is good to enlist help in designing your plan. If you can easily explain your strategy to another person, you know it is a good plan. On the other hand, if they squint and furrow their brows and can’t follow your line of thought, you need to improve or simplify your plan.

Learn how to give good presentations.

Giving presentations is an essential element of improving your communication skills.

Presentations serve many possible purposes, including:

  • to inform
  •  to educate
  •  to persuade or convince
  •  to activate or stimulate
  •  to entertain
  •  to inspire or motivate

Your presentation may support more than one of these goals.

As you advance in your career, you will be called upon from time to time to make a presentation to your peers. Often, the primary purpose is to educate: to teach your peers something that you have learned. Whenever you can spread your skills amongst others, your value increases significantly. Strong individual contributors are great, but people who make more employees better are a force multiplier.

You don’t need to be in a management role to influence others. And, over time, if your influence benefits others, it could lead to managers considering you for a leadership role—something to think about.

Measure twice, cut once.

It pays to be extra careful.

Always review your epics and your specification documents before writing code. If they are vague, have detailed conversations with your business partners. Never make assumptions.

Making bad assumptions leads to a lot of errors and rework. This will greatly reduce your productivity. Having the right conversations up front saves tons of effort and time later.

Business exceptions are different.

Handle them differently than technical exceptions.

Examples of technical exceptions are the database not responding, a method called with the wrong type of arguments, a library is missing, the system is out of disk space or memory, a firewall rule is preventing a connection, and so on. If you tried to explain these to a business person, you would typically get a blank stare. Instead, they would want to know why you did not do your job correctly.

Business exceptions are different. For example, a purchase order quantity exceeded the available inventory. The bank charged an account negative interest. Someone entered a birthday that is in the future. These are business rule violations.

The system should handle technical exceptions through technical exception handlers. It should notify developers and systems operators so they can repair the system and modify the code to avoid future problems.

The application needs to handle business exceptions through a user-friendly workflow. A user must be able to make alterations to the submitted request and correct the information. It is a much different process.

Avoid excessive switches and flags.

Sometimes it’s better to have something else handle those cases.

When you’re building an API, it can be tempting to add flags and options to increase the flexibility and power of a method. But if you bury an API’s verb with too many switches and flags, you will end up with a confusing mess that’s hard to understand.

Sometimes, moving some of that functionality to a new verb is better. It will make the API more expressive and far more readable. In addition, the API will be more understandable to the consumer.

The more your code reads like language and less like 1990′s PERL, the better off you’ll be.

Always be learning.

In this industry, if you quit learning new things, you are finished.

The best engineers never stop learning. That’s why they know so much more than everyone else. Fortunately for you, it is easy and straightforward to keep learning independently. Unlike the old days, when you had to spend tens of thousands of dollars on a college degree and follow it up with expensive courses and seminars, today’s world offers many excellent opportunities to learn new things at low cost.

Read blogs and books. There are many excellent blogs out there. Follow people you consider experts, and see what they are reading.

Write your own blog. Nothing accelerates your learning like having to explain something to an audience.

Study your framework and libraries. Do not just study the documentation; also closely examine the source code. You can find great examples of better programming styles and techniques in the source because this code is reviewed and improved upon by hundreds of people.

Join a user group. Being able to talk to peers helps you learn more. Give talks occasionally, as this forces you to present your ideas.

Join an open-source project. These projects are great because they often have a list of known bugs, giving you an opportunity to improve the code for thousands of people. Also, help with the documentation. Many open-source projects have weak documentation, so this is an easy way to get involved. Finally, add new features to the project.

Listen to podcasts and webcasts. Podcasts are great for the commute. Webcasts provide good examples of actual code, explained clearly so the presenter can reach a greater audience.

Study your business domain. For example, if you’re working on financial applications, learn more about the financial aspects of the business.

Learn productivity and management skills. You might not be a manager, but these skills are still essential and will help you in many ways.

Finally, whenever you can, teach others. Learn, practice, teach. This is the way to mastery.

Make small incremental changes.

Avoid massive releases.

The larger the release, the more bugs there will be. When you only release software a couple of times a year, you have bugs on top of bugs, under bugs, and hidden by other bugs.

A large release tends to have many different classes changing. It also includes many new dependencies and interconnections. As the development team adds more parts to the release, the complexity and the chance for things to go wrong increases geometrically, not linearly. Thus, several things will always be wrong in a large release.

Another issue with big releases that happen rarely is that the business requirements have probably changed during this time. So what you are delivering may no longer match what the business desires. This divergence reduces your ability to deliver working software and add business value. And if you’re not doing that, then what are you doing?

On the other hand, in a tiny release, sometimes very few lines of code change. And because the difference is small, the code is carefully tested and has a low chance of being wrong.

And with short, rapid releases, you can be much more agile and respond to change instantly. Your business people will love you for that.

Ideally, it would be best if you had a series of frequent, tiny releases. Some organizations can push to production several times a day. To get there, you must master unit testing, integration testing, continuous integration, and continuous deployment.

It would help if you had robots that automated all of the work that goes into a release.

Robots are the future.

Everything should have a code review.

Don’t let it be a rubber stamp.

Code reviews correct mistakes. A second (or third) set of eyes looking over your code may catch some areas of concern you missed. These reviews help prevent defective code from being promoted forward, saving you rework later.

They also provide an excellent way to share knowledge. The developers doing the review can learn from you and the code you wrote. They learn more about the part of the business your code covers. They learn the technical details of the new features and how you have implemented them under the covers. They learn patterns and best practices that you put forth. Observing these things inspires them to write code better.

Code reviews also provide a friendly environment for constructive criticism, which gives you an excellent way to get advice from others on improving your techniques.

Finally, code reviews make coding fun. Through collaboration, we all get better because our friends make us better. This cooperation makes us all more awesome. And who doesn’t want to be more awesome?

Also try: pairing.