Originally published at deepu.tech.
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
Top comments (21)
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.
Indeed an excellent point
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:
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
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".
Absolutely true
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.
Thanks. I don't get your last point. You are a professional when you do something for a living. And engineering is a profession.
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.
Thats fine
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!
Thanks you
Thanks for sharing.
welcome
Suggestion for no. 2: /fangirl. Actually stan or superfan is even better since those are gender neutral ;-)
Thanks for the tips!
Thanks. I'll add fangirl as the other terms are not something I have heard of (may be its popular in US)
Cool! Oh interesting, must be a US thing, twitter/instagram slang.
Great article! Thank you for sharing your experience.
Thank you and welcome
Thank you deepu! I would try to follow these things.
Thank you and welcome