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/

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.

In this article, we’ll look at mistakes that developers make.

Being a One Trick Pony

Being a one-trick pony if definitely a bad idea. If we only know one thing, then we’re only useful at doing one thing.

That’s just not good since computer and software changes so fast, our skills will be useless in no time.

Therefore, we should learn whatever is popular if we want to continue to work as a developer.

It’s easy to learn new things if we build on our skills.

Trusting Customers to Know What They Want

Not all customers know what they really want. Therefore, we should get more feedback than from a single customer before adding, changing or removing any feature from our product.

Communication is essential to implement a feature that people use. We should also implement it in small pieces and test them with customers along the way so that we can make sure that customers actually like it.

It’s much better than working hard for a long time and having something that no one wants.

Requirements change all the time, so we should prepare for that. Being defensive is no good even though some developers do take that stance. We should help make our products better.

Winging It

We shouldn’t wing it as a developer. That means we should only do things if we know what we’re doing and why we’re doing them.

For instance, we shouldn’t try random things until something works to fix a bug without knowing why we’re trying something. We should know how the code works before trying something.

Also, we should think about all the ways that something can break. This includes edge cases, invalid inputs, bad formatting, etc.

We should have useful unit tests, version control systems, good methodology, and maintainable code.

Unit tests are useful for catching regressions. Version control systems let us revert our code if we messed them up.

A good development methodology will prevent us from doing useless things.

Maintainable code will be easier to change and fix in the future. The code should be built with clear architecture planned before it.

Wrong Person in the Wrong Team

Being in a team that fits us is important. Working in a team that doesn’t fit our skillset or personality is going to be unpleasant.

With respect to skills, we should make sure that we can actually do what’s required in the team so that we can actually produce something.

Also, team fit is also important. Fit reduces conflict and having people with similar personality make other teammates understand us better. This means more empathy.

Frustration, anxiety, and depression may result. This will make anyone’s life miserable. Therefore, we should find a team that fits our skills and personality.

Not Backing Up

Backing up is very important. We should always be prepared to use our backups to recover data.

Cloud systems and our own hardware are all fragile, so we should always be prepared for the worst.

This means having backups in multiple places so that we’ll always have them somewhere.

Ar least one backup should be in a remote location and some should be within our reach.

Also, we should make sure that data that’s backed up is only available to authorized parties.

Not Testing Our Code

Skipping testing is a bad idea since our stuff often doesn’t work out the way we expect.

This is especially apparent with code. We should prepare for code to fail.

Testing can be automated to take the burden off our backs, so we should also do that. However, that’s mainly good for regression tests.

If we’re writing new stuff then we’ve to test them ourselves and write the test to test for regression.

Trusting Other Developers’ Code

Trusting other people’s code may be a bad idea. Everyone can be careless, so we probably shouldn’t trust them too much,

That means we should always review other people’s code and solutions to check if there’re any issues with it.

Duplicating Features

If there’s already a feature available in our code that we can use. We should use it instead of reinventing the wheel.

It’s better to use time-tested code than writing new code that does the same thing but may have more bugs.

Conclusion

We should only write code when we know what we’re doing and why we’re writing it.

Also, reviewing other people’s solutions to check them for flaws. In addition, we shouldn’t duplicate features and use time-tested code.