DEV Community

8 important things I learned as a software developer over a decade.

Deepu K Sasidharan on October 01, 2020

Originally published at deepu.tech. I started my IT career, accidentally as I don't have a Computer Science background and instead got an engineer...

Read full post

Pierre Besson • Oct 1 '20

Thank you @deepu105 for this article. I would add one important point to your list is that you should strive to learn from others and share your knowledge. Never be content with what you are already familiar with or gatekeep what you know/can do from others.

Deepu K Sasidharan • Oct 1 '20

Indeed an excellent point

Alex Lohr • Oct 1 '20

This overlaps rather precisely with my own experience, which is more than 2 decades, the last 15 years in front end - except I studied laws instead of electronics.

Actually, the last point has an exact mirror twin that can be equally bad: "Invented here", which is what happens when you don't see yourself and your colleagues as professional enough to a) decide when it's better writing something in-house and/or b) doing so as good or better than any external dependency that one could otherwise use.

There are a few tell-tale signs of IH:

trying to adapt an external dependency to the issue,
using external dependencies for trivial tasks and
outsourcing complexity to external solutions (so the complexity can be solved by the external implementation instead of the developer thinking the issue through first and finding a less complex solution that can easily be solved without the external dependency).

Deepu K Sasidharan • Oct 2 '20

Yes there are always exclusions and special cases and yes using dependencies for trivial stuff like trip/leftpad etc can lead to bigger issues. The balance between using dependencies and building in-house needs to be decided on a per team per project basis IMHO. My normal take is that use a dependency for non business solutions and for technical stuff. For example use a HTTP library for building APIs rather than building one your self, as the libraries are much more mature and better at those tasks. In such a case adapting your solution to the library is a good thing as you will be following industry standard. But for business solutions and special cases you could always build in-house solutions

Alex Lohr • Oct 2 '20

Maybe I should have rephrased that. The sign was meant to be "trying to adapt an external dependency that is not exactly solving the issue".

Deepu K Sasidharan • Oct 2 '20

Absolutely true

R Z • Oct 1 '20

If you said me about it a decade ago, I would laugh at you loudly. And it's so pity.

Guys, I have a lot of programming experience and I totally agree with @deepu105

The only thing I don't like here is when people call themselves professionals.

Deepu K Sasidharan • Oct 2 '20

Thanks. I don't get your last point. You are a professional when you do something for a living. And engineering is a profession.

R Z • Oct 2 '20

It's just my own preference!
I try my best not to use the word "problem", instead I use the word "task" and try to avoid using the "professional" word, because professionalism has no boundaries. Again, this is my personal view.

Deepu K Sasidharan • Oct 2 '20

Thats fine

Abhijit Hota • Oct 2 '20 • Edited

Glad I'm trying my best to follow these =)

And the 2nd point needs to be voiced more. It's totally true. Being a "fan" of a technology hurts both, the community and the maintainers of the technology. I'm not making this up.

And the sad thing is, most of these fanboys don't even try out other technologies. You're allowed to have opinions about a technology or dislike it when you've tried it yourself. Just because someone on YouTube said so, doesn't mean you have to hate it to be cool.

Maybe I'll write an open letter to all the fanboys out there someday.

Thanks for these tips. Treasuring this article!