I present to you a list of a few common mistakes new devs (and sometimes even experienced) usually do. I believe that learning from these mistakes would be of some help to you. So, here is my pick of the Top 10 mistakes.
10. Trusting user’s input
Never trust the inputs provided by the end user. Also don’t blame them, mostly they do it unintentionally. We all make mistake mistakes. This might not be of great concern to them but a piece of bad data could potentially bring down the application or cause compliance related issues. Apart from naive non-technical users we also have users with a certain level of technical know-how which they could potentially use to circumvent the system and get their work done. These are the users who pose a threat to your application and application needs to be safeguarded against the malicious activities.
The only option to save from landing into trouble at a later stage is to build a strong validation with self-explanatory and human understandable error messages. Cryptic messages hardly help the naïve user accomplish any task. Validation should be done in both user interface and database level just to be sure that even if by some means front end validation was turned off the application still does not accept trash values.
9. Manual unit tests
Code changes that you do, needs to undergo unit testing and further rounds of Quality Assurance testing. All tests or at least a few minimum number of tests needs to be done to ensure that the changes you made in one unit of code do not have side effects on the others. This is a necessary evil. Having automated unit tests and integration tests save you a lot of manual efforts in validating side effects of the changes.
8. Skipping documentation
The evilest thing that you can do is skipping documentation. Off course you can read the source code and try to understand the functionality. Reverse engineering the functionality from the code is a daunting task. This is good enough for a tiny functionality but definitely not a go for the entire application.
"Requirement changes, code changes and more frequent - members of development team change."
Knowledge about the application might not be transferred 100%. Sometimes people just forget. You need not create dozens of documents, create only a few like requirement specification and technical document and make sure to keep them updated, this should be a part of a stringent process which needs to be followed at any cost and must be accommodated in the project planning. This would help at later stages when the application is in support/maintenance phase.
7. Forgetting about Audit and Error logging
Not all end user/stakeholder would be bothered about cross cutting concerns like audit logs and error logging. A stakeholder would simply come with a one liner requirement which you would have to drill down till it becomes good enough to work on and deliver a solution addressing the stakeholder’s problem.
Data change audit and error logging might never be a part of user’s requirement but is implicit that it needs to be maintained. One fine day user would simply approach support team and ask them to provide data related to access and roles or some business critical data required for compliance or audit purpose and then you would have nothing to share.
Error logging is also crucial, you might do defensive coding but you never know what might fail in such cases effective error logging comes in handy. Monitoring error logs and trying to work on resolving recurring error would help in making your application more stable.
6. Careless use of privileged access
First and foremost, full control and access should never be provided. The system cannot protect itself from malicious activities if you leak the superuser or privileged account passwords. Risks involved in the reckless usage of privileged access should be a part of learning for inexperienced new members of development or support team. There might be times when you would have to make a modification to production database and having privileged access can lead to many issues.
“With great power comes great responsibility”
I remember once unintentionally deleting data from the master table and the query was auto-committed. I went cold but soon realized I had taken backup of the data, phew! It is always good to provide limited access for data modification via an interface which keeps data backup. One should also note that this tool should also be capable of doing bulk operations, else you will find yourself doing manual updates for a very long time.
5. Configuration menace
Scattered configurations in different files and database is a menace. Change in a configuration which affects multiple applications would have to be replicated in many files and databases. This probably is not much of an issue if you have a handful of applications but would soon become an overwhelming task when you have hundreds of application in an enterprise environment. Moreover, naked passwords in config files are yet another threat. If configurations are database driven then it reduces the later hazels also safeguards sensitive configuration entries.
4. Hard-coded time bomb
Hard coding values in the program are definitely a bad practice. Strange issues could occur because of the hardcoded value which silently sits there in your source code. One such incident is when you make use of hard-coded values for some maximum number, assuming that the maximum will not be hit. Such cases could take months or years to raise an error. Combined with no error logging and you will be in a very bad situation. Try to avoid hard-coded values. Move them to configuration variables if needed or try to completely avoid situations which would require them.
3. Prevent Burnouts
Working continuously without any breaks will just lead to burnouts. You should always take breaks at regular intervals. When you are overworked even doing simple things take a whole lot of time.
Set small achievable milestones for yourself and don’t forget to reward yourself for it. Chocolates, cakes, quick games just about anything that makes you happy and feel free. Learning how to prevent burnouts will make you more productive.
2. Code / Suggest for building resume
Having a strong resume with a listing of all new technologies is great but don’t just do it for inflating the resume. Learn them but use them only if you see the benefit and high maintainability over the existing things. Sometimes adding new tech options would not even be required.
Increasing the complexity should at least pay off in providing ease of maintainability. So I strongly believe that when you suggest some solution, check if it makes the application easy to maintain and makes everybody’s life easy.
1. Finding comfort zone in just one technology
Being a ninja in one technology is awesome and is always beneficial. But don’t stay limited to one technology. Try to expand your knowledge, sure there is a learning curve but challenging yourself helps you become a better technologist – a person who uses various technologies as effective tools and provides business enabling solution.
Times change, technology may become obsolete but your learning should never stop. Always try to explore new technologies and try weighing the pros and cons before using it as a solution for solving a problem.
I would like to hear about your views on these points. If you have any experiences to share, go ahead and post a comment. Remember…
The only real mistake is the one from which we learn nothing. ~ John Powell
This article was originally published on SkillHive Blog
Top comments (16)
Very good points. Two stand out most for me.
On #3. Burnout is real. It's a horrible place to be in. Work hard for yourself (your brand/company/side project), not for a company or employer. BTW, there is more to life (and being a developer) than just writing code.
On #1. This has been my biggest mistake. And I see it happening too often with young and veteran devs. We get religious and tend to believe our language, library, framework, OS rocks and everything else sucks. We lie to ourselves because we are afraid. We are awesomesauce here, and we are noobsauce over there.
Advice:
TL; DR:
11.: If you get 2 months to get a project done, don't rush off and start coding immediately. Take some time, a few days, a week or some more to think through what you are going to build, do some research, write down ideas and start to work out some strategy/plan – and only then, you may start coding.
This is all incredibly valuable advice. Thanks a lot for the contribution Charanraj! 🙌
Hope more people find it helpful. Looking forward to writing better articles 🙌
Couldn't agree more with these. Great advise, thanks!
Happy that you liked it. Hoping to write better and more helpful posts.
Great advices 1st one is the best of all in my opinion.
This is a great list, I throughly enjoyed reading it.
Much thanks!
Thanks for sharing 👍
I have published my points based on the same niche as here,
rsagames.com/blog/2019/10/13/commo...
Please comment your thoughts.
Great article Charanraj. Burn outs!! Avoid it all costs. It tolls your body as well as mind.
Thanks 4 share. at last advice i will add when the developer wants test new technology in every project
Experimenting is good but first, try doing some sample projects to get good hands on. One should not directly jump into using it with very little knowledge. You might run into issues and delay the project.