Well, I’m not THAT much a narcissist as the title implies. In fact, I’m not nearly as good as I wish I was. I only have a few years of experience under my sleeve, but I have gathered some helpful insights that help me get better everyday.
I believe that if you follow them you can definitely step up your game. It doesn’t have to be all at once — slowly and steadily adopt some parts of it, in whichever pace fits you.
Always Be Better Than Yesterday
Try to think of the last time you’ve actually done something you learned from. Something that made you better than the day before.
If you can’t recall the last time you’ve read something interesting, or done something out of the ordinary you should be worried. I believe that if you are here, reading my article then you are the type that loves to better themselves, even if not on a daily basis.
There are oh-so-many ways to be better everyday, but the most fundamental is learning new things as often as possible. Medium (and other platforms) are filled with information, guides and walkthroughs to help you do awesome things, whichever technological stack you or your company chose.
Let’s say you’ve heard from a co-worker of yours about that sweet sweet new feature in [Some-Super-Awesome-Framework]. Sadly, most developers I know will go “yeah that sure sounds nice, but I bet it’s complicated so I shouldn’t even try”. Whether it’s from laziness, low self-esteem or lack of time, I can safely say, this statement is wrong more often than not. Most likely the technologies you chose are maintained by responsible teams, or avid communities (and if not, then maybe you should reconsider them), and most features (complicated or not) would have awesome guides to help you through.
Don’t fear the unknown. The worst thing that can happen is that you will fail to implement said feature and learn for the future. I’ve yet to fail without learning anything new. And let’s not forget the happy scenario where you succeed — you got to learn something and made your/your team’s/your company’s code better and more maintainable, and isn’t that what we’re all about?
I think the best thing you can do is adopt a habit of reading at least one article every day. I regularly use Pocket (I’m not affiliated with them in any way) to store articles I find in different sources, so I always have a list of articles waiting for me, and whenever I get the time I open the app and catch up on them. You can choose whichever method that works for you (for example, I’ve also trained my Google feed to show me a lot of tech oriented articles), but make sure you do it, and it should be as easy as possible.
Don’t Focus Only On “Your Code”
To be honest, I hate it when people refer to parts of the code as their own.
“This is my feature, only I am allowed to make changes to it”
and the opposite:
“This is not my feature, so if it breaks it is not my responsibility”
or worse:
“I didn’t write this code, so there’s no reason for me to touch it”
The code doesn’t belong to anyone, and it works both ways. You should know as much as possible about as many aspects of your system as possible. Of course I don’t expect anyone to know by heart every micro-service in a system that contains hundreds of them, with barely a dozen maintained by their team, but that’s what you should aspire to.
You should know how your app is deployed, rather than simply relying on it to work. Get to know your CI/CD pipeline, environments used, scripts used to run your application. If you use some form of logs analyzing tool (and you should), get to know how to query it and how to create dashboards, even if no-one will look at them, as that might be useful in the future. I would also consider in this category some basic things that exist in any application — user authentication, database interactions and so on.
You might even want to get people to explain to you about things they’ve done in the code base, so you don’t have to figure everything out by yourself.
You don’t have to master every aspect of your system, nor should you be a jack-of-all-trades (and master of none). You should have an area of expertise, just make not you don’t neglect other areas. Some people would call this a T shaped person, where the top bar of the T represents the broad but shallow knowledge, and the long “foot” of the letter is your area of expertise.
Don’t Fear Reading Other People’s Code
We read code a lot more than we write. Period.
Usually this line opens a paragraph (or an article) about writing clean code or using some documentation format. While those things are very important, and no application would succeed without close attention to them, I would like to put an emphasis on the reading part, rather than the writing part. Reading other people’s code can do wonders for you — it can open your mind to creative ways to achieve a certain goal or a feature, you can find weak spots in the code base (ones you’d like to fix later, or simply inform your team) and make you a better developer in general.
You should also aspire to review people’s code as often as possible (I know it can be a hassle for some people, but trust me it’s worth it).
At work I was in charge (along with other brilliant people) of the boot camp for new recruits. Over the course of 4 months I was tasked with A LOT of code reviews, meant to make sure that their code meets the standards of the company. Looking at the recruits from the beginning to the end surely showed a massive improvement in their abilities (otherwise it would be a colossal waste of time🙃), but as a side effect I felt like I was getting better as well, even thought I barely had a chance to write code.
I think the main takeaway here is that you shouldn’t be afraid of foreign code. It will exist where ever you choose to work. Embrace it, learn from it, and improve it from time to time.
To sum up, here’s the gist:
- Always be better than yesterday
- Don’t focus only on “your code”
- Don’t fear reading other people’s code
Those are my two cents on how to be a better software developer.
Thank you for reading!
