I have been working as a software engineer for the last 2 years now. I was lucky enough to land a job in an MNC (Multinational corporation) early on and currently working as a Frontend Engineer in my third job and second startup. During these years, I have been exposed to working on client-sites, in teams of all sizes (3-20 people), and various environments like in-office as well as remote!
While working all these years, I came to a few conclusions to become better at your software development jobs. This is for everyone – people employed as software developers and developers who are preparing to land a job in the next couple of months. So, let’s begin…
Being Pro-Active
There is no point of controlling fire when you could have prevented it in the first place. In other words, be pro-active. Now what that means?
Being a pro-active developer means NOT delaying to convey your fuck-ups. That’s pretty much it. Now, these fuck-ups can be as small as an ugly git merge to as big as wrong estimations on a piece of work. When you are pro-active, it gives your team (and your manager) to put a contingency plan in place.
Pro-active also means to convey the updates on your tasks, without being asked. Always consider your team members and managers to be super-busy and hence, try to convey them as much as you can, when you can. Keeping them in-loop will help you ensure everyone is on the same page. Yes, it will take some extra effort, but believe me, having everyone on the same page prior to a SCRUM Call is a boon.
Over Communication
I am not one of those who think being an affluent speaker in a language like English makes you a superior developer. But, being understood, and conveying your point clearly in a message in one go is a super-power and that indeed makes you a superior developer.
The latter is possible only when:
- You are absolutely clear what you want to convey.
- You know how to frame a message that compliments that clarity of thought
Over-communication is always better than zero or under communication (if that is even a word).
Now, what do I mean by Over Communicating? It means stating the obvious. At times we withhold a piece of information on purpose just because we have a preconceived notion about other developer’s understanding. Refrain from practicing this. When you are working with humans, nothing is “obvious”. Ensure that the message is loud and clear and the fellow developer understood your message.
A tip:
Whenever you are unsure about being on the same page, always request the fellow developer to explain your message to you (like you double-check the order while ordering in a restaurant by asking the waiter to repeat the order). That is how you’ll be 100% sure that your message has been conveyed successfully!
Another domain where over-communicating helps is testing. When you are submitting a module to the testing team, ensure that you attach a list of things to test and explain the functionality/feature you built, saving tester the guess work! This also helps you in hindsight as the tester does not poke you time and again for clarifications.
On the other hand if you are a tester, ensure that while raising a bug you also communicate the steps to reproduce the bug saving developer from treasure hunting the bug!
Clean Code
Everyone knows how important writing clean code is, but most of us ignore the sheer importance of it in the long run. But wait, karma is a bitch, right?
It is highly probable that the shit code you are writing today which is in a “working” condition comes biting you in the ass 3 months down the line. This happened to me, and believe me I am writing this because the scar (from that bite) stays!
Clean code is so important that people have dedicated books on the topic. So a few things that I always follow are:
Indentation - Ensure the entire team has the same indentation settings. 1 Tab = 4 Spaces or 1 Tab = 2 Spaces. Decide and stick to it.
Comments - There are lover letters/snippets to your future self as well as the next developer working on your module.
Missing semi-colon - This is just a noob mistake!
Use TODO - Leave hints/tips and breadcrumbs for yourself and the fellow developer working after you. Complete the TODO before raising the PR.
Debugging messages - Check for all the console.log() messages before submitting your code. And if you are lazy (like me), click here to learn how to remove all console.log() messages in one-go! Also, remove all debuggers as well!
Punctuality
This is one of the most talked about but yet remains the most underrated aspect of working in a team. Even if you are one of the most bad-ass developer, you have to respect everyone’s time. Just because you are good at what you do doesn’t give you “GET-OUT-OF-JAIL” card for free!
So be on the morning SCRUM calls, be punctual with your work commitments and don’t just take an off abruptly on a weekday (I mean too often).
Sometimes your fellow developers are waiting for you to push your code! Don’t be a jerk for keeping them waiting – on purpose!
Be Organized – Google Sheets
This is my Mjölnir. Google Sheets have helped me organize my workday and my work-flow in general. The number of things to keep a track off can hinder your general programming and hence it is important to be on top of it – all the time. Also, the number of things to follow increases significantly when you are working remotely with 20 other people! For example:
Work-From-Home (WFH) checklist
This helps me to make sure I do everything when I start my day and when I end my day. Get the WFH checklist
Sprint Tracker
If you have worked in a product based company and JIRA, the term Sprint will not be alien to you. But for others, a Sprint is a development cycle adhering to a fixed time period, post which the team has a feature implemented. Details here.
The Sprint tracker is something personal and works like a charm for the work-flow being followed at my work-place. It is important to understand that the workflow can be different for different teams and different projects. So, my advice to you will be to develop a Sprint tracker for yourself. Get Sprint Tracker template
Important R&D Links
Now this is “My Thing”. Some of you will definitively think this is just STUPID. But to be honest with you, this has helped me leaps and bounds and have increased my developments speed. One thing that I am sure off is that the problem I solved after 3 hours and if that problem comes again, I don’t want to again go through the agony of finding that 1 StackOverflow answer or that 1 Medium article.
So, every-time I stumble upon something new, I just make a note of it. Now because I work in startup, it also gives me the opportunity of working with a ton of frameworks. So, I have dedicated tabs for them!
Burn Out
Do not work so much that you collapse. You’ll be replaced within 2 days once you aren’t fit to work anymore. Get this thing into your head.
Keep your sanity intact. Do not try to outwork yourself or anyone in your company as a matter of fact! Take your Saturdays and Sundays. Breathe.
In Conclusion…
I’ll be updating this article as I progress with my career as a software developer because improving at your skill and productivity is a continuous process!
Rest, to my fellow experienced software developers, please feel free to suggest your productivity hacks down below in the comments!
Originally published at adityatyagi.com
Top comments (0)