DEV Community

John Au-Yeung
John Au-Yeung

Posted on

Top Mistakes That Developers Make

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.

Trusting User’s Input

We should never trust users’ input into any software. Instead, we should assume that they’ll enter invalid data.

Letting them enter invalid data will contribute to corrupted data in our systems and we’ll run into problems later on.

Therefore, we should never trust them and validate any data that are entered by users.

This includes both client-side and server-side validation. Client-side validation is used to tell users that what they entered is invalid. But we also need server-side validation to prevent bad data from being saved to our systems since bad data can be entered easily.

Manual Tests

Manual tests should be minimized since they take so much time. It’s just annoying to test all features of our apps manually.

It takes a long time and it’s boring and repetitive. Computers are good at doing repetitive tasks. Therefore, we should let them do it.

We should write unit tests to test small parts of a system like functions and classes.

Also, we should write some end-to-end tests to test the behavior of the full system to see if they work well.

Skipping Documentation

Without documentation, no one would know how to do anything. We have to write documentation so that people will know how to do things like setting up a project locally.

Also, we need documentation for our product so that people know what it’s supposed to do.

More importantly, we should make sure that documentation is up to date so people won’t be misled by outdated documentation.

Skipping Logging

We got to log activities that are done by our systems so that we know what it’s doing and we can find out what things are causing issues when things go wrong.

With error logging, we can check for recurring errors and fix them faster.

Also, we need an audit trail so that we know what users are doing is what we expect and no malicious activity is going.

Being Careless as a Privileged User

Any privileged user has more power to do things. An admin makes have the power to mess up databases by modifying or deleting data.

Therefore, we should always think twice before doing that. Even if we have backups, it’ll be a pain to fix issues with data after we screw them up.

Also, we should be careful with any server operations. Even though many apps are hosted in sandboxed containers, we may still mess things up if we aren’t careful or if we don’t know what we’re doing.

Scattered Configuration

Configuration files should be in one centralized location so that we don’t have to look for them everywhere.

This way, we can find them easily and keep track of them easily. Making changes will also be easier if they’re in one place.

It’s also easier to safeguard things if there’s only one place to safeguard our configuration.

Hard Coding Values

We shouldn't hard code values that are constants. So we shouldn’t have values written in our code as magic numbers.

Instead, we should put them in as constants so that we know what they’re for.

Photo by Ricardo Gomez Angel on Unsplash

Burnout

To prevent burnout, we should always take breaks. Taking breaks lets us recharge and think about things in a different way.

We always need a vacation and they’ll be more productive than working nonstop since it’s easy to screw up if we work too long.

Not Learning More

Computer and software change all the time. We should learn more things so that we can use them later.

Sooner or later, we’ll have to learn them so we should just take the plunge now. Learning it fast will be a lot harder and more stressful since there’re probably deadlines.

Without deadlines, learning things is more comfortable, since we can learn at our own pace.

Conclusion

We shouldn’t make mistakes about when developers. If we’re too fixated at our jobs, then we’ll make these mistakes fast.

They’ll stifle our success since they’ll affect us negatively in one way or another. For instance, messing up user’s data is definitely bad and we can’t let that happen.

Letting our skills get outdated is also bad since we may become unemployable in the future.

Oldest comments (11)

Collapse
 
190245 profile image
Dave

Not so sure I agree with your comments on documentation. Sure, documentation should exist, and someone has to write it - but it probably shouldn't be a developer.

Juniors - probably don't understand the business domain enough to write good user documentation etc.
Seniors - probably write in too much technical detail for end users to be able to follow etc.

Both, should be writing code, and the time spent on documentation (and it's approvals process) detracts from what developers are paid for doing.

There is the argument for a "self documenting system" too of course - the UX should be clear enough that users don't need documentation. Who has read the user guide for "How to Google?" The backend should be fault tolerant enough that when a user gets something wrong, it's caught, and they're guided the right way. The code itself should be self-documenting, such that any junior knows what's happening just by reading it.

If you don't have a self documenting system, various types of documentation are needed - but in my opinion, it shouldn't be a developer writing them.

Collapse
 
oddward profile image
Mugtaba G

Good input. In a company/large team environment you're probably right, but if it's a solo project or a small team of mainly developers it's a good lesson not to skip out on I think. It also helps people who might join the team get a hang of things quicker.

If it's a bigger project, yeah, interns & juniors are often tasked with similar things if there's no one better lol.

Collapse
 
aumayeung profile image
John Au-Yeung

I think tests are pretty good for documentation, so at least those can be written.

Collapse
 
190245 profile image
Dave

No tests, no release.

That's what CI/CD is for. :)

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao

Nice compilation of things we need to do especially on both the doing manual testing and documentation is something I hate someone tell me they don't have much time. In writing test cases and incrementally update their documentation from scratch to save time and effort to support, maintain and upgrade a system,

I more to add on is that you might miss out is talking in technical jargons to people. As if they know how what it means. Following the "Keep It Simple Stupid" is what one should do when explaining it to a no-technical or technical person is the right way to go.

Collapse
 
aumayeung profile image
John Au-Yeung

I think we can combine them with automated tests.

They serve as good documentation and reduce the burden of testing manually.

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao • Edited

I think there still has to have some form of documentation. Definitely having automated tests helps a lot in reducing the manual testing away.

I had an ex-colleague who swears to use manual testing and he gave me the reason. That he will forget it or unable to fix it if it runs into an error. Which I just shrugged it aside as him being stuck to his ways of thinking that can be a very slippy slope.

Thread Thread
 
aumayeung profile image
John Au-Yeung

Yea. Once he tries it, pretty sure he can't go back to testing everything manually.

Collapse
 
sarafian profile image
Alex Sarafian

In my opinion, the biggest mistake developers and not only do, is not knowing, understanding or caring where the code executes. Failing to consider those is the trademark cause for failed software.

Collapse
 
aumayeung profile image
John Au-Yeung

Agreed. Never write or use code that we don't understand.

It just leads to problems later on even if it works now.

Collapse
 
sarafian profile image
Alex Sarafian

Also such a bad feeling and reading experience with the massive self promotion at the beginning.