As coding bootcamps such as Coder Academy and General Assembly churn out more and more software developers, and as more and more people…
Over the past decade or two, both as a software developer and as a manager I have accumulated a few tips for becoming a better software developer.
For context, I've been working as a software developer for more than a decade, mostly in small product-based companies; over the last decade or so I've worked as a team lead or manager in various capacities; and I've moonlighted as a consultant, freelancer and open source contributor in-between. Check out my LinkedIn profile and Github profile if you are interested.
Now, let's break down the tips into three main areas: mindset, technical and people. The goal of this article is to raise awareness of the topics mentioned, if you want to understand more on a particular topic I encourage you to do your own research.
This one hopefully should be obvious, if you haven't heard of it, please read more here.
This one is "new", I've given a talk that includes more details on what it means, check it out here. In essence, it's a mindset that requires you to always consider things around you, and forces you to think beyond your narrowly focused task at hand.
Some people are overly obsessed with the processes of "being agile". In truth, every organisation, every project and every team is different, there is no point to follow a set of processes that might slow you down and not add any value. Discover what being agile means to your team, your project and your organisation is an ongoing effort and should be treated as such.
Some projects and organisations require tech-driven decisions be made upfront, some on the other hand require product-driven decisions instead. Knowing how your organisation operates and what it values plays a key part in understanding how software development should be approached.
Let's be honest, as a software developer we are extremely lucky to be in a high demand field. As a result, many have started building a sense of entitlement - some ex-colleagues of mine even complained about the lack of tissue boxes in the office. Starting and running a business is extremely hard work, let's all appreciate what we have before throwing a tantrum.
Every now and then I see conflicts between people who share different philosophies on what work and career mean to them. We should embrace the different ways people prefer to spend their time and energy on, rather than force our own ideology on them. Discovering and knowing the difference between working at a giant corporation versus working at a small start-up is key to our happiness.
An extension of the 9-5 vs crazy work hours: adjust your expectation based on the effort you put in. You can't have everything, prioritising family life over career building is 100% okay, as long as you know what you are giving up on, vice versa. In my 20s, many of my similarly aged friends and colleagues would go out and have fun after work and on weekends while I was in front of my computer building open source projects, is an example of a conscious trade-off I made.
Internalising the need for speed and the need for quality should always be on our mind. Pursuing only quality or only speed will significantly limit your problem-solving capability as well as your career progression.
It's a balance - don't overthink it, but also don't do without think first. When in doubt, ask more experienced people for advice and guidance.
I've seen Second System Syndrome over and over again throughout my career. Some people always assume a rewrite is a much better approach than alternatives, more often than not though, it is not the case.
There's the age-long debate of monolith vs micro-services architecture, and SOA (Service-Oriented Architecture) has been around for decades. Each has its own pros and cons, don't get bought into the hype because a blog post says so, or a particular product and company found it successful. Use the right tool for the right job.
Just like micro-services, TDD is not the holy grail and should not be treated as much. Chasing the TDD dream without knowing its pros and cons is just as counter-productive as not doing TDD when necessary.
A lot of people treat coding as more of a scientific endeavour: they focus purely on the algorithms and results. Software development to me is a creative endeavour, and I often use white spaces and the general look and feel of the code base to determine how well-organised a project is - deeply nested code and long functions for instance are obvious ways to determine potential code smell.
Don't get me wrong, writing code is important, practice is important, but time and time again I come across developers who clearly have little exposure to established patterns and conventions.
No matter whether you are in a highly specialised field or being a generalist, having exposure to different tech stacks and paradigms is always a good thing - it widens your field of vision and increases the boundary of your technical understanding. Don't be the guy or gal who is known as "a <insert tech stack> developer".
This is strictly speaking a "nice to have", but I lost count of the number of candidates I interviewed who claimed to be a Ruby expert yet cannot explain the Ruby object model and have never heard of eigenclasses, or senior developers who cannot explain the difference between
git merge and
git rebase. Sure, you may not need the deep understanding in order to do your job, but it will certainly help!
If you haven't, read more about it here. Knowing this, and paired with having a growth mindset, you should therefore be encouraged to teach, educate and influence, rather than being defensive and participate in "us vs them".
This is another topic covered in my talk. If you find yourself regularly dissatisfied with the information you receive, ask yourself: what information is and isn't available to you, and are you sure you have the stomach to tolerate the new information?
Some people assume a team's productivity is determined largely by team member's individual capability, some also assume a 10x engineer is a reflection on one's technical capability. It's not. Productivity evolves over time - building rapport with those around you is often the unsung hero in productivity.
This one hopefully is obvious, but I just have to emphasis its importance. Please, if you struggle to work with your team, ask for help! If you have a team mate who is difficult to work with, reach out and help them!
Software development is evolving rapidly, some fundamentals however are always useful and relevant. I hope you find this article useful.
I've mentioned my talk a few times, but if you haven't already, check it out below, it covers a few topics mentioned in this article, and some more. Also check out my tiny Youtube channel for more tech talks I've done in the past.
If you enjoyed this article, checkout my other tips articles: