DEV Community

Alexandra
Alexandra

Posted on

5 things you should avoid in your dev journey

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 progressembrace 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)

Collapse
 
bklau2006 profile image
BK Lau

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.

Collapse
 
ale3oula profile image
Alexandra

Very well said :)

Collapse
 
jonrandy profile image
Jon Randy 儭 • Edited

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.

Collapse
 
ludamillion profile image
Luke Inglis

Testing is one of those things that people have strong feelings about but dont 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 wont when writing automated tests.

With manual testing, however, I do think its important that the person testing the code isnt 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 Im 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.

Collapse
 
drjasonharrison profile image
Jason Harrison

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.

Collapse
 
ale3oula profile image
Alexandra

I have been to companies that mindlessly pushed code without even testing their changes :) Manual testing, is still some form of testing.

Collapse
 
mathieu_hamel_219329d40a7 profile image
mathieu hamel

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 doesnt mean you did. I never change the oil of my car and never had a problem: doesnt mean it was the right decision.

Collapse
 
tracygjg profile image
Tracy Gilmore

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.

Collapse
 
sehgalspandan profile image
Spandan Sehgal

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!

Collapse
 
thiagoanjos profile image
Thiago

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.

Collapse
 
kasinathcr profile image
Kasinath Conjeevaram Ravi

All very basic but very valuable insights!

Collapse
 
turtlewake profile image
Sean Davis

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.

Collapse
 
gadrawingz profile image
Gad Iradufasha

All 5 points are true!
A great tip!

Collapse
 
grooms_nicholas profile image
Zack Grooms

These are handy tips. Testing is something I feel is boring, but I do see the importance.
Thank you for the post.

Collapse
 
pinotattari profile image
Riccardo Bernardini

About reading documentation

Remember: two days of debug can save you one hour of documentation reading

Collapse
 
emmabase profile image
Emmanuel Eneche

Great thoughts! Thank you for sharing.