Software development is a fast-changing field. But, you, personally, do you write code now that you wouldn’t have written a year ago? If not, you may be missing out on a lot of career opportunities (as well as a lot of fun).
I’m NOT suggesting you do the tips below in your spare time. I don’t believe in the myth of “You need to have x personal coding projects to show your software development skills”. Indeed, I have a young family and I restrict my working hours (Sounds crazy? Read Why the CEO of Basecamp only allows employees to work 32 hours a week). You should try the tips below while working as you normally do.
Tip 1: Identify a software development task you don’t like (and do it for 30 minutes)
We all have tasks we don’t like doing. We know them, our colleagues know them, our employers know them (or soon will), and they are holding us back. Most often than not, it’s just a silly reluctance: yes, we may never love doing them, but there is no reason to let them stop us from progressing in our career.
As an Android app developer, my pet hate is animations. I always try to talk the designers out of them! And I always find a way to justify my actions (animations are tricky and buggy etc). So, last month, I decided to tackle this area, and, eventually, I discovered Flutter, which led me to learn Dart and learn a different way to layout a UI. As a result, I have expanded both my knowledge and my CV.
List the 5 software development tasks you dislike doing the most. Then, select one, and start a 30 minutes timer to do it. Reward yourself with a coffee, or a chocolate bar at the end of it, if you must.
Tip 2: Spend time crafting your emails and other written communication
Software development is not about writing code. I mean, of course, you need to know how to write code, but the finished piece of software is a collaborative work, involving many people from many teams along the way. More often than not, the main difference between a good project and a bad project is communication.
In a previous job, I had to write code reviews in emails. This sounds crazy – and it was in a way – but it forced me to put a lot of thought into those emails, because it was one of the main ways I had to get the team of Java developers up to speed with Android. I improved my writing skills a lot doing that, and this has helped me in my career ever since.
Analyse your last email thread. Were there some misunderstandings? Did someone wrongly think you criticised something they did? Did someone fail to understand your questions? Could you have phrased something better if you had taken the time to imagine how other parties would understand your sentences?
Tip 3: With pen and paper, think of at least 2 ways to architect your next piece of code
Most software breaks down due to architecture issues. Usually, the detailed code is fine, because your tests catch those issues almost immediately. But software architecture issues are only visible over time, when features are added or amended.
As most Android app developers, I knew of a few UI patterns, such as MVC, MVP, and MVVM. I was also aware of first principles, such as separation of concerns. I did my best to apply the first principles to my code, and it worked (ie my apps were maintainable). But it wasn’t until a tech lead forced me to explain how I would implement MVC, MVP, and MVVM in an existing codebase that I really understood those patterns.
So find an article summarising the main software architecture patterns relevant to your domain area, and grab a pen and paper to figure out how you would apply at least 2 of them to your current project.
Tip 4: Understand why a piece of software is designed a certain way
You may think the server developers are mad to design their functionality the way they did, but, chances are, they aren’t complete idiots. You may disagree with their choices, but you probably aren’t aware of the full constraints they face. Most developers aren’t crazy, they simply do their best given the circumstances.
When working on an app for a large company, we had some backend problems. One API was sending up to date data, while the other sent cached data, so data was inconsistent. Everything went back to the database vendors, and how they charged the company for using the data: one API was deemed “crucial” so used the realtime db, while the other wasn’t. Understanding this enabled us to find the best solution for how to use those APIs in the Android app.
When a piece of software you need to integrate with doesn’t work as you would like it to, ask naive and simple questions to understand why. No judging, no trying to change the way things are (yet!).
What to do next to boost your software development career?
Consider the next work thing you plan to do, and decide which tip(s) you could try out. Write it down somewhere you will see it when you work next.