DEV Community

5 things you should avoid in your dev journey

Alexandra on April 13, 2024

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....
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 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.

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 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.

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.