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