Non technical learnings for a software developer

05 Jan 2015

Over the course of my professional career in software development of over three years, I’ve learnt so much to evolve into a better individual contributor. The significant part of this learning fall outside of the technical domain, the importance of which is equal or may be more than its technical counterpart. A couple of months back, I switched to a full-time remote position. While working remotely, I am able to clearly see and appreciate these little non-technical learnings that helps me in managing my responsibilities.

This is my effort to categorise these learnings into practices. Besides sharing my learning with others, this will also help me to proactively improve upon this.

These practices sound so intuitive and simple but the trick lies in making these part of your muscle memory.

1. Communication

Communication refers to all interactions with your peers over any medium, be it email, task management system, slack, skype or any other channel.

1.1 Concise and clear

Always spend extra effort to be as clear, concise and thorough as possible. One habit worth acquiring is to proofread everything. You’ll be surprised at the frequency and the volume of error you can catch using this. Whether it’s a spec discussion with the PM team or explaining something to the QA team, it’s always worth the extra effort spent towards communication.

1.2 Share information with more people

I am pretty sure that I’ve read about this somewhere but can’t point out the source. Almost all of the communication systems are group based. For example, you have different mailing lists for different groups of people. Here is what this rule says. Make your communication accessible to as much people as you can. If you are having a conversation with a set of people, always ask if more people should have access to this.

Infact, golden rule is unless you think this conversation can act like spam to some people, more people should have access to it. Writing a mail to your buddy geeking about some high level git flows, why not send it to the whole dev team. I am pretty sure they’ll be interested. Explaining some component of your codebase to your newest team member over chat, why not move this conversation to the whole dev group. Other people might have something to add or it’ll freshen up their memory. I think you get the idea. More the merrier (but don’t spam).

1.3 Document everything

This is quite similar to automation. If you find yourself explaining something more than once, document that and point to it next time. Documentation can be about a lot of topics e.g. coding guidelines, naming conventions, build process or a test checklist for QA team.

2. Start using calendar

This is to make sure that people can count on you.
Not quite a long time back, I wasn’t a big fan of using calendar and adding reminders. But now it has become a critical component of my work flow.

Start using a calendar - google, iCloud or whichever you prefer. Just remember to integrate it with your primary device, Laptop, iPad or mobile phone. Whenever you have any future commitment, any meeting(ouch!), a PR review or a discussion session with your buddy, just add it to your calendar and forget about it.
Even if you don’t add it to the calendar, you’ll forget about it. Your mind can only manage a limited context and you wouldn’t want to use it for mundane tasks such as reminders.

3. Be proactive in sharing information

This might be a bit hard to put into words. I haven’t encountered any discussions around this before. This is about sharing information as quickly as possible. It can be as simple as sharing updates of tasks assigned to you or a potential delay in your next release. Don’t wait for somebody to ask, just add a quick update about it.

You might come across some information through a more complex route. You are working on a particular feature. You are in the zone. While testing, you encounter some warning/error in some other piece of code. You just can’t afford the context switch to explore more about it. You should take whatever information you have (no need to dig more) and quickly dump it to your bug tracker with the title “potential issue in XYZ”. Don’t copy/paste it locally to act on it in future, just add it directly and be done with it. There can be various similar instances.