DEV Community

loading...
Cover image for 8 important things I learned as a software developer over a decade.

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

deepu105 profile image Deepu K Sasidharan Originally published at deepu.tech ・6 min read

Originally published at deepu.tech.

Please follow me on Twitter for updates and let me know what can be improved in the post.


I started my IT career, accidentally as I don't have a Computer Science background and instead got an engineering degree in Electrical and Electronics, in March of 2010 and this year marks my 10th anniversary.

Before I start giving out any advice let me try to justify my background. In a decade-long professional software development career, I have worn several hats like Jr./Sr./Principal Developer, Tech Lead, Project Manager, Business Analyst, Pre-sales Engineer, DevOps Engineer, Cloud Engineer, OSS contributor, and finally Developer Advocate. I have also had the pleasure of co-leading an amazing open-source community behind JHipster over the past 5 years. During this period I started out as a Java/JavaScript developer and went on to work with many other languages like Go, Rust, Python, Kotlin, C#, and so on and I now consider myself a polyglot developer. I have built web applications, enterprise apps, Microservices, Cloud Native apps, CLIs, System tools, Libraries, Android and Hybrid mobile apps, and so on. Hence I hope this gives me enough experience to talk about some of the important things I learned and practiced over the last decade.

I hope this is beneficial especially to beginners and junior developers who are starting out their careers.

1. Do not get married to a technology

When you marry a technology you start living with it in a bubble and you miss out on all those smart alternatives out there

This, in my humble opinion, is the most important thing to learn for anyone starting their career. Do not get married to a programming Language, Framework, or Methodology. Getting attached to a programming language or a framework or methodology like OOP/FP will do more harm than good in the long run. Try to be pragmatic and use technology as it was intended, as a tool in your tool belt. Change is the only constant and it fits the IT industry better than others. Languages will die out, Frameworks and methodologies will come and go but the Industry will remain and anyone who is not capable of adapting to the changes may not fare well so be smart and let go of things that are dying out and learn what seems like the future.

2. Avoid being a fanboy/fangirl

Throughout your career, you will encounter technology that is amazing and you will fall in love with some of them. That is perfectly fine but avoid being a fanboy/fangirl and be ready to recognize something better might replace it in the future and when it does accept and move on. Trying to cling on to what you love blindly is not gonna do anyone any good. I still see fanboys of a dying language or framework making the effort to discredit the newer ones on the block, please don't be like them its counterproductive to you and the industry.

3. Learn the basics of programming and become a polyglot developer

A good programmer writes great code in a language. A great programmer is language independent.

When learning a language learn its semantics rather than syntax. Learn programming basics. Learn about objects, collections, memory models, concurrency, and data structures. This knowledge can be applied to almost every language and the concepts around these don't change that often. This will help you to become a true polyglot developer which has its own merits and this will help you follow the above two points as well and trust me it will make you a better developer.

4. Write for humans

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

‒ Martin Fowler

Write simple and clean code and avoid showing off how smart you are in code. I know that it is tempting, especially when you are starting your career, to show off that fancy new language construct or functional magic in your code so that your colleagues can see how smart you are but trust me writing simple and easy to understand code will take you further than writing smart and complex code. Always choose the simplest solution for a problem. The best programmers are those who write the simplest code

5. Write docs, comments, and tests

Never discount the importance of writing good comments, documentation, and tests for your code. I know you might be tired of hearing this but I cannot stress the importance of this enough, not because I always do this but because it's not easy to do always and I end up sacrificing this sometimes and every time I do that I have regretted that in the future. Again this is not easy but you don't have to be 100% perfect you just need to try your best at least

6. There is no perfect code

There is always a better way to do something and someone smarter to figure it out

I used to spend a lot of time polishing my code and rewriting stuff to make it perfect, but over years I started realizing that there is nothing called perfect code, there is always a better way to do something and there is always someone smarter than you who will figure it out. I lost count of times when someone has suggested better solutions to code that I thought was perfect. Hence solve the problem at hand and avoid premature optimizations and over-engineering. One good thing about our industry is that the source code is ever-evolving and there is always tomorrow to improve it if needed. Don't get me wrong, I'm not saying you should write sub-par code, when I say solve the problem at hand, I mean writing code that solves the issue along with all edge cases that could be thrown at it and code that is secure and with acceptable performance. I still polish my code when I feel something can be improved but I do not obsess about it or lose my sleep over it. I first get the problem solved and then if there is spare time and if an improvement helps to simplify the code or increase performance I do it. But mostly its when the polish makes code simpler.

7. Don't fall for trends

We are all guilty of this, especially in our junior years. We see a hype or a trend and we get on that bandwagon without thinking through. For example, if you have React or Angular app, there is no justifiable reason IMO to switch to Vue. The same goes for many such choices which are purely based on trends, hype, or personal preferences. Don't do something just because it's hyped or is trendy, do what makes sense for your problem and remember something that works for a specific team need not work for another. Most companies build fancy frameworks to solve their own problem and doesn't mean you have to blindly adapt it for no reason.

8. Do not reinvent the wheel without a good reason

Not invented here (NIH) syndrome is common in IT companies and it does more harm than good

Last but not the least make use of the collective wisdom from the industry, make use of OSS frameworks and libraries instead of building everything from scratch. There is an abundance of OSS libraries, frameworks, and tools out there for your language/platform of choice so make use of them for complex problems. Sometimes it's better to slightly change your approach to fit a library than developing a huge library in-house just to fit your minor deviation in solution. Having said that there is also a time when you should avoid using a library, for example, it's better to just write few lines of code as util rather than using a library for simple stuff like left pad or trim. If you want to use utils from a library go for a util library like Lodash which provides multiple utilities.

Conclusion

There are many other things I learned over the years that have helped me but these are the important ones. Some are more common sense but its hard to recognize them especially in your initial years. The root idea is being pragmatic and using the right tools for the right job.


If you like this article, please leave a like or a comment.

You can follow me on Twitter and LinkedIn.

Cover image credit: Photo by Martin Katler on Unsplash

Discussion

pic
Editor guide
Collapse
pierrebesson profile image
Pierre Besson

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.

Collapse
deepu105 profile image
Deepu K Sasidharan Author

Indeed an excellent point

Collapse
lexlohr profile image
Alex Lohr

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).
Collapse
deepu105 profile image
Deepu K Sasidharan Author

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

Collapse
lexlohr profile image
Alex Lohr

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

Thread Thread
deepu105 profile image
Collapse
futureistaken profile image
R Z

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.

Collapse
deepu105 profile image
Deepu K Sasidharan Author

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

Collapse
futureistaken profile image
R Z

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.

Thread Thread
deepu105 profile image
Collapse
kretaceous profile image
Abhijit Hota

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!

Collapse
deepu105 profile image
Collapse
tiwariaditya profile image
Aditya Tiwari

Thank you deepu! I would try to follow these things.

Collapse
deepu105 profile image
Deepu K Sasidharan Author

Thank you and welcome

Collapse
debbiswasgit profile image
debbiswas

Thanks for sharing.

Collapse
deepu105 profile image
Collapse
kirstenlund profile image
Kirsten Lund

Suggestion for no. 2: /fangirl. Actually stan or superfan is even better since those are gender neutral ;-)
Thanks for the tips!

Collapse
deepu105 profile image
Deepu K Sasidharan Author

Thanks. I'll add fangirl as the other terms are not something I have heard of (may be its popular in US)

Collapse
kirstenlund profile image
Kirsten Lund

Cool! Oh interesting, must be a US thing, twitter/instagram slang.

Collapse
killianfrappartdev profile image
Killian Frappart

Great article! Thank you for sharing your experience.

Collapse
deepu105 profile image
Deepu K Sasidharan Author

Thank you and welcome