Being a developer in this market is tough. 🥲 It is a marathon, not a quick run. It comes with many challenges, triumphs, and, inevitably, mistakes. Let's reflect on things we shouldn't do (or better avoid doing) as a developer.
1. Ignoring Documentation
Documentation is the unsung hero of software development. It provides invaluable insights into codebases, libraries, and APIs, serving as a roadmap for developers. However, it's not uncommon for developers to skim over or completely ignore documentation, either due to time constraints or overconfidence in their abilities.
I found myself in this situation many times. No matter how appealing is to jump into code, this can lead to wasted time, frustration, reinventing the wheel and even MANY bugs.
Embracing documentation as a vital resource can streamline your development process and prevent unnecessary headaches down the line. ❤️
2. Overlooking Code Reviews
Writing software is a collaborative journey and code reviews are a big part of it. They provide an opportunity for team members to review each other's code, identify potential issues, and share knowledge and best practices.
Unfortunately, some developers view code reviews as a mere formality or a hindrance to their productivity.
Code reviews serve as a crucial quality assurance mechanism, helping to catch bugs, improve code readability, and ensure adherence to coding standards.
By actively participating in code reviews and embracing feedback from your peers, you can elevate the quality of your code and contribute to a more robust and cohesive development process.
3. Skipping Testing
I have worked in many companies that thought testing was just an obstacle to shipping fast. Testing is a fundamental aspect of software development that should never be overlooked or underestimated. Yet, many developers (including myself) are guilty of skipping or skimping on testing. And honestly it is not the most exciting step in the process.
Skipping testing is a dangerous gamble that can have dire consequences for your project. Without adequate testing, you leave your code vulnerable to bugs, regressions, and unexpected behaviour, undermining its reliability and stability.
Investing time in writing comprehensive unit tests, integration tests, and end-to-end tests can help uncover defects early in the development process and give you confidence in the robustness of your code.
4. Not Asking for Help
Software development is a collaborative endeavour, and no developer is an island. Yet, some developers fall into the trap of believing that asking for help is a sign of weakness or incompetence.
In reality, seeking help is a sign of strength and humility. Whether you're grappling with a particularly difficult problem, struggling to understand a complex concept, or simply looking for feedback on your code, reaching out to your colleagues, mentors, or the broader developer community can provide invaluable insights and support. Don't let pride stand in the way of progress—embrace collaboration and leverage the collective knowledge and expertise of those around you.
5. Forgetting to Refactor
Code is not static; it evolves and is changing requirements all the time. However, some developers neglect to revisit and refactor their code, allowing technical debt to accumulate over time.
Forgetting to refactor is a dangerous oversight that can lead to a host of problems, including decreased code maintainability, increased bug density, and diminished developer productivity. Regularly refactoring your codebase helps keep it clean, organized, and easy to understand, making it easier to implement new features, fix bugs, and onboard new team members. By prioritizing refactoring as an integral part of your development process, you can ensure that your code remains robust, flexible, and scalable in the long run.
Conclusion
In conclusion, while mistakes are inevitable in software development, some mistakes are avoidable. Remember, software development is a journey of continuous learning and improvement, and embracing best practices is key to mastering the craft.
Top comments (16)
Ignoring Documentation is the top cardinal sin I observed a lot in my past 25 years in software.
This is especially true after Agile Manifesto came out which unfortunately signaled to developers to give lip service to documentation.
I have seen the amount of pain that lack of documentation had brought to developers who had to maintain or extend the existing codebase.
Many developers had to quit because they couldn't stand the daily pain of having to browse unproductively in large and obscure code bases.
GenAI might be able to help using a tool like ChatGPT.
Very well said :)
The testing thing is weird to me. I test, sure.. but almost always manually. I've been a professional developer for nearly 30 years and have very rarely used automated testing... and it's never been a problem.
Testing is one of those things that people have strong feelings about but don’t usually think critically enough about.
Testing is testing. Manual testing is still testing. There are things that a good QA engineer will think of that you won’t when writing automated tests.
With manual testing, however, I do think it’s important that the person testing the code isn’t the person who wrote it if at all possible. We as developers tend to test what we know will work.
The primary benefits of automated testing are twofold: reproducibility and verifiability.
They are reproducible in that any time they run they are testing the same thing under the same conditions. A human tester is going to mess up now and then.
They are verifiable in that you can look at the code and see what it does. Every step and assertion is that in black and white. Also when the tests are run they either run or fail loudly. While I’m a fairly trusting person I only have your word for it as another dev or QA engineer that you performed all the manual tests that you claim.
When the system becomes large enough that activity in one part affects another in a way that breaks idempotency, or failures are a possibility, then manual testing becomes much more difficult to do without at least a checklist.
Turning the checklist into automated tests gives you more time to do other things than execute manual tests.
I have been to companies that mindlessly pushed code without even testing their changes :) Manual testing, is still some form of testing.
So you never manage to do it efficiently so it was probably better for you not to do it.
Only because you THINK you did great doesn’t mean you did. I never change the oil of my car and never had a problem: doesn’t mean it was the right decision.
Well said Alexander,
I could not agree more on the points you made. If I were to add a sixth recommendation it would be an extension of point 5, "Manage Technical Debt", don't let it just accumulate. It needs to be prioritised, just like features, and time alloted to address major issues immediately.
If your client/product owner resists it is worth considering how not addressing some issues might adversely impact planned features, and include them as enabling tasks in the scope of the feature.
Recently I had to work on a feature wich the story had few lines, but there was a link to the api documentation, however my tech lead, describe the story, normally we develop the new delivery based on the story written by the techinal leader, but this time I decide do read the api documentation and discover a lot of new things that was not at the story, so... read documentation can be a pain in the ass, but it is really necessary, thanks for the post.
I dont know much about these practices, but yea, now that I've come across this post of your, i will try to inculcate these practices!
Thank you!
All very basic but very valuable insights!
All 5 points are true!
A great tip!
These are handy tips. Testing is something I feel is boring, but I do see the importance.
Thank you for the post.
Thanks for taking the time to write out some tips for us newbies! ❤️
I do find myself skimming documentation a lot, mainly because I don't really understand what any of it means (yet) haha. I know reading it would help me understand but I just felt like I was rabbit holing too much and got way off track of what I was actually doing. 😂
About reading documentation
Great thoughts! Thank you for sharing.