Subscribe to my email list now at http://jauyeung.net/subscribe/

Follow me on Twitter at https://twitter.com/AuMayeung

Many more articles at https://medium.com/@hohanga

Even more articles at http://thewebdev.info/

To be a good programmer, we should follow some easy to adopt habits to keep our programming career long-lasting.

In this article, we’ll look at some of them and how to adopt them.

Take Responsibility

We should take responsibility for our work. Like with any other task, we make a commitment to ensure that we write software the right way.

We have to accept the responsibility for an outcome that we’re going to produce.

Therefore, we shouldn’t make excuses or blame someone else for anything. It just doesn’t help and make us look bad.

Provide Options

When we run into problems, then we should give the stakeholders a few options on how to move forward.

It’s much better than making one or more crappy excuses that don’t help to solve our problem.

Therefore, finding an alternative way to move forward is much better than making excuses and doing nothing other than that.

Dealing With Software Entropy

The software can turn into a mess real fast if we don’t have much discipline with our code.

Then we’ll run into problems in the future when we work on it.

Entropy is chaos and disorder. And if we don’t plan and commit to making our code clean, then it’ll turn into a mess real fast.

Therefore, we got to minimize entropy so that everyone can enjoying working with the code.

We just got to clean up our code before it turns into a maintainable mess.

If We See Broken Things, Then We Should Fix It

We definitely should find out what’s broken and fix them so that people won’t be frustrated.

We don’t have to take all our time fixing broken things immediately, but we should make note of them or make a quick fix so that we can deal with them in a better way later.

This way, our code won’t turn into a dumpster that no one wants to use or work with.

Remember the Big Picture

We got to make a note of the big picture. Even though we probably won’t get to work on every part of a big system, we should still be able to see the big picture so that we can make things that work well with the rest of the system.

Without the big picture, we would have problems later on when we find out that what we changed doesn’t work with the rest of the system.

Good-Enough Software

Nothing, including software, is going to be perfect. It’s hard to make every perfect and deliver things with a reasonable timeline.

Therefore, we got to think of the trade-offs that we’ll have to make in order to deliver something.

Ideally, everything is delivered incrementally, so that we can make our stuff better and then make them better afterward.

Good enough doesn’t mean sloppy code. It means that we make things that meet users' requirements. However, we deliver what we can within the timeline given.

To outline the requirements clearly, we got to involve stakeholders so that they’re going to be happy with what we deliver.

If we’re working on a different product, then we’ll have different constraints. We got to make sure that we outline those clearly so everyone’s on the same page.

Make Quality a Requirements Issue

Quality is definitely something that we should consider as part of the requirements.

We would never skip quality for any reason because we’ll suffer if we don’t deliver something good to customers.

Also, the code has to be good so we can continue working on it.

Therefore, this is something that we should build into the timeline so that we wouldn't skimp on quality just to release something.

Conclusion

We got to take responsibility for our work and make what’s good in the given amount of time.

The code got to be good, and we need to find a way to move forward given changing requirements.

Also, we should clean up our code and fix issues so that they won’t become a problem for users.

Quality should always be built into our timeline so that we have time to deliver something that’s good for users and developers alike.