Don’t modify input parameters.

It will lead to unexpected results later.

When a long routine has input parameters, they carry a certain meaning. The variable boxWeight is expected to represent the weight of the box.

If a new developer is editing the code and is working towards the end of the routine, they expect boxWeight to still represent the weight of the box.

The problem here is that if the input parameters are modified at some point in the routine, they will no longer represent their original values. Then, developers who come later may be operating under some false assumptions. This then leads to severe bugs in logic, that aren’t easily caught.

So don’t modify input parameters. Instead, use local variables.

newWeight = boxWeight * 1.1;

This way the original parameter retains its value throughout the scope.

Write shorter routines.

Studies have shown that longer and more complex routines are subject to error and more expensive to maintain.

To avoid these problems, your routines should be simpler and shorter. One way to look at this is to find a tool that measures your code’s cyclomatic complexity. Every function call, every for loop, every if statement and other branching conditionals increase the cyclomatic complexity.

The longer a routine is, the more logic it contains and the harder it is to easily grasp what all it can do. Also, an error can occur at any of the different points, so the more logic it contains, the more error-prone it becomes. A routine with 20 points of logic is needlessly complex, and would require a ton of tests to fully cover.

Refactor your routines to be smaller, so there’s less things to go wrong and the tests are easier to assemble. Also, when new readers examine the code, they’ll be more likely to fully comprehend all of the logic points if there simply aren’t many present.

Some people like to use 10 lines as a guide. Try to keep your routines under ten lines. Comments don’t count as lines in this, so feel free to add comments, as long as they explain why the logic does what it does. Don’t add needless comments that simply echo the code itself.

In some languages, like Ruby on Rails, the convention is to keep routines under five lines. Ideally, a routine should be responsible for doing only one thing. If you follow that ideal, you’ll naturally have shorter routines.

Be on time.

There are many benefits to being on schedule.

Maybe you’re not the best programmer, the best systems architect, or the smartest person in the room. If you’re a person who can be relied on to stay on schedule, you will still be extremely valuable to people. Sticking to a schedule is a very rare thing in business. If you can pull it off, you’ll have a very rare and valuable trait, indeed.

Punctuality makes you appear more reliable to other people. Obviously, you can’t end on time if you don’t start on time. Take the initiative to be the person who always starts on time.

“80 percent of success is just showing up.” — Woody Allen.

Really, you would be amazed at how much you can help things just by being there. The person who habitually comes to work late? Unreliable. The person who multitasks during meetings? Unfocused. The person who skips meetings because he’s too good for them? Disengaged.

Being there is also key to being lucky. See, luck is simply preparation meets opportunity. You don’t get opportunities if you’re not there.

You can’t succeed without starting. Don’t be afraid to tackle the big projects. Often just getting a big project started is the hardest part.

Why, why, why, why, why?

Keep asking why to get at all of the underlying assumptions.

When acting in the role of a business analyst and gathering requirements for the next great feature, it is crucial to understand not only the request, but all of the underlying assumptions and motivations that went into the request. This is because it is quite possible that the business is asking for the wrong thing in the mistaken hope of getting what they want.

For example, maybe they want to increase client conversions on an application form, so they want all of the fields to fit on one page. Then further think that the page needs to have three columns to fit all of the fields on one screen. Of course to accomplish this, they want to use a tinier font.

So a request comes in to use a tiny font and three columns. The developers are puzzled by this as they believe this will hurt conversions. A bad business analyst will say, “Well, that’s the business requirement, go implement it. We need to give them what they want.” The developers do their job and switch the layout to three columns and a tiny font and it’s a disaster.

A better business analyst will look at the tiny font request and ask “Why?” To fit in the three columns, they reply. “Well, why do you want to do that?” So a one-page form will fit on a screen. “Why does it need to fit on a screen? All browsers support scrolling.” Because they don’t want users to have to scroll, they say. “Why not have separate pages like before?” Because we want to increase conversions by avoiding page transitions.

Now the analyst can keep asking questions, learning about the desire to increase sales and the concerns about losing sales when people abandon applications in the middle of the process.

Through serious conversation the business can learn that having tiny font would not improve conversions. This might lead to better research towards what would actually improve conversions.

So keep on digging and asking why.

When to rebase.

Git rebase is a powerful tool, but there’s a right and a wrong time to use it.

So the main rule of rebasing is to never rebase a branch once other people have seen it.

Only rebase your code before the first code review. It’s good to rebase your code before sharing it with others because it will flatten out all the various commits into something that’s a lot easier to examine.

Once others start reviewing your code, you shouldn’t rebase. Other people may be writing new commits on your code, and if you rebase it, you’ll be changing the history and their commits won’t work with your changes.

So follow this simple rule and you’ll avoid trouble.

Learn from everyone.

The path to greater wisdom is paved by the knowledge of others.

One way to learn things is to go through a lot of personal experiences. You try things, experiment. Some things succeed, most things fail. You keep trying, and over time you get better at things. It happens almost by accident.

It’s an extremely inefficient way to learn new things.

Furthermore, when you learn from your own experiences, you are very limited in the things you can learn. Try as you might, you will only the gain wisdom of one person’s experience.

Real wisdom requires learning from the experiences of thousands of other people. You can learn something useful from every person, as they have a lifetime of experiences to share. So to achieve the most wisdom, you need to always be open to thoughts and knowledge of others.

Some people feel they are better than others and remain closed-minded much of the time. Over the long run, such people fail to learn from others’ experiences, and thus their own wisdom is limited. So, be smart, and realize that you learn things from anyone.

Obviously, other people aren’t always right, and you need to be aware of this. The important thing is to learn from others’ experiences so that you’re not only learning from your own.

Don’t put test scripts in production.

They don’t belong there.

Test scripts are very important, and should be in version control and treated as software. But they should not be installed on production systems. Make sure your scripts that deploy code to production systems does not deploy the test scripts.

You may think there’s no harm in having scripts that sit there doing nothing, but the problem is that sooner or later, one of those scripts will get executed by accident. And what do test scripts do? They truncate data, drop databases, fill tables with fake elements. Any of which could cause major issues with the production systems, possibly leading to loss of customer data and system outages.

Be smart. Keep that stuff out.

Don’t over-engineer.

This is a widespread problem that seems to most teams at some time.

Overengineering wastes precious time, does not deliver added business value, and is dangerous to the system and your career.

Any time you spend building components and elements that are not necessary is time you are taking away from more important projects. Consider two solutions to a requested feature. In one, the developer builds the simplest system he can, and it works. In another, the developer decides to add queueing, triggers, notification systems, piles of interfaces, introduces new languages, and adds all latest trendy technologies. Because there is a learning curve with each of these, it takes much longer to build. Because there many more components, the system now has many more points of failure. Because of all of the new technology, the DevOps department is very slow to set up deployment processes. Clearly, the second developer has built a Rube Goldberg nightmare machine. Overengineering has struck again.

Don’t be that guy.

The business certainly will not appreciate it.

In a related note, delivering features that are not requested by the business will often backfire. Only implement the stories requested. If you think they missed something, then talk to them about it, and make them request the additional feature. You may think adding in extras is “showing initiative” but more often than not, it upsets the business by giving them an unexpected (and perhaps unwelcome) surprise.

Believe me, the business does not like surprises.

Estimates, targets, and commitments are not the same thing.

Know the difference.

It’s really important that you understand the difference between an estimate, a target, and a commitment.

An estimate is a rough measure of how long it will take to complete a task in the future. When you give estimates, you are predicting the future. You don’t know what kind of obstacles you will run into. There may be unexpected delays. Or things may take less time than expected. You never know. Because estimates are highly speculative, they are prone to a lot of variance. “We can deliver that feature after three weeks of work,” is an estimate. You’re well aware that it may actually take two weeks or four.

A target is a goal. “We should have that finished by the end of the month,” is a target. It may not take the whole month, and in fact you may working on several other things in the month. But your goal is to have it done by then. It might not happen, though.

A commitment is more of a promise. “We will have that released by the end of the month.” Now you are committed. If it turns out it will take longer, you’ll need to cut back on other tasks, work overtime, or do other things. A failure to deliver on time shows you can’t meet your commitments.

Unfortunately, many business people can’t tell the difference between an estimate, a target, and a commitment. They hear an estimate and they take it to be a commitment. Thus you should generally try to avoid giving estimates to these kind of people until you have them trained on appreciating the difference.

Don’t let people turn your estimates into commitments. Estimates are frequently wrong. If you gain a reputation for being frequently wrong, you will lose trust. Things only go downhill from there.

Beware shiny things.

Buzzwords don’t make things useful.

It is very easy to get caught up in a new fad. It may be a new framework, a new development pattern, a new tool, or whatever. A new version of Angular. The atom editor. The repository pattern. Machine learning. Internet of Things. There are countless examples.

Just remember, being popular in the press and on websites and blogs does not mean that the current hotness is the best tool for every job you have in front of you. Frequently, these are new things generating a lot of buzz, because they appeared to solve a specific problem in a cool new way, giving someone a huge advantage in a particular job.

Next thing you know, everyone wants to copy it. Uber for strawberry picking. Airbnb of skateboard rental. Snapchat for trainspotting. Blockchain for Slurpees. And so on.

Soon people realize that just because it worked in one case doesn’t mean it will be the best tool for their job. Then the fad passes and people are on to the next new hotness.

The best tools prove themselves over time. So watch out when people dog pile onto the latest fad. It might not last.