Today I would like to share some thoughts on ways a software developers can improve their professional skills and become better at their work. The topics raised here are universal and not specific to any technology stack. Most of them are not even specific to IT, for that matter. These are general advice on how to develop your personal traits, improve collaboration with colleagues and clients, and advance your career as a software developer.
Some of the things in this article are subjective and reflect my personal experience, while others have been adopted and successfully used by others.
Understand the Process End to End
A lot of developers think that software development is all about coding, and everything else is just people trying to be annoying and wasting their precious time. This cannot be further away from the truth. Before you get to code a piece of software, it undergoes a process of transformation from a vague idea into a carefully designed solution ready for implementation. And after you pushed your latest changes into Git the software is being tested, deployed, monitored, analyzed and improved on. Coding is just one of the many steps of the process.
So why does this happen? Frequently, especially when working in larger organizations, different phases of the projects are handled by different teams or even departments. It all starts with the business analysts, who gather requirements. The requirements are then handed over to the designers that produce the mockups for developers. The developers code away and give the results to the QA engineers. If everything is OK, the artifact is sent to the operations teams that deliver it to the end users. This process is treated as a set of discrete steps without any feedback. Because of the lack of communication between the departments, their representatives often don’t really understand the goals of others and this leads to misunderstandings and even conflicts.
Try to learn something about everything and everything about something.
By learning something from everybody, you will be able to anticipate their needs, shorten the feedback loop and enable more frequent deliveries. Plus it will earn you a lot of love and respect from everybody else.
Understand Your Client’s Needs
There’s one important thing that you need to understand about your customers: they don’t understand most of the stuff that you’re doing. Agile, functional programming or non-relational databases is all dark wizardry to them. Even the ones that closely follow your work and are genuinely interested are still mostly in the dark. This has a couple of consequences.
Hiring software developers for them requires a certain degree of trust. People often tend to feel uncomfortable about having to pay a lot of money for something they don’t understand. Remember last time you walked into an unfamiliar car repair service and weren’t sure if you could trust them with your ride? Well, your clients have the same feeling. Except there’s no car, there’s just a whole bunch of abstract non-tangible concepts which are supposed to somehow materialize into products and revenue. When working with new clients it’s important to earn their trust. Make sure they understand how you operate and aim to deliver results in smaller but frequent iterations. That way they can see the progress of your work, assess the intermediate results and provide their feedback.
Often clients tend to come up with their own solutions instead of sharing their problems. Since they have little idea of your capabilities, their solutions are often misjudged, under- or overambitious. Remember the old (and maybe fictional) quote by Henry Ford:
If I had asked people what they wanted, they would have said faster horses.
Pick the Right Tools for the Job
Often developers that learn only a single technology rush to apply it to every problem they encounter. Unsurprisingly, this kind of approach leads to sub-optimal results. Instead, when tackling a new problem, pause and think whether the tools at your disposal are really suitable for this kind of work. If you have doubts, investigate a bit and come up with a list of likely superior alternatives. To make it easier, compile a list of questions and assess different options one by one. The questions can be different for each assessment, but it can go along the way of:
- What platforms or devices must it support? - What are the non-functional requirements, such as performance or memory usage? - Is buying a license an option, or do you need something free or open-source? - Does the solution provide everything you need out of the box, or will you need to write something yourself? - Do you have any other limitation, like company policies, legal considerations or a lack of specialists in your team?
Answering these questions should help you structure the options in your head and narrow them down to a shortlist of candidates.
Build on the Shoulders of Giants
IT people often have two common characteristics: we are inventive and we enjoy our work. This sounds like a good thing, but it comes with an awkward side-effect: we tend to come up with our own solutions to problems that have been solved before. So whenever we’re faced with a choice of whether to use a framework, library or service or to implement it on our own, we tend to choose the latter. And this takes us on the futile journey of reinventing the wheel. Some of the common misbeliefs that lead to this are:
- Implementing something yourself is easier than learning a 3rd party solution. While this may be a perfectly valid reason, it’s important not to oversimplify the task at hand. Often, something seems simple in the beginning but turns out to be much more difficult with progress. Eventually, you could end up spending a whole bunch of time handling bugs and edge cases that someone could have handled for you. - This solution does more things than I need. Unless there are specific reasons why this is a bad thing, such as increasing the size of the resulting artifact, adding potential vulnerabilities or considerably slowing down the build, this is not usually a bad thing. You might end up needing it later. On the other hand, adding a whole library to use just one function might be an overkill. - We can do it better. Although there are some successful projects that started with these words, this is not usually the case. Quality third part solutions are maintained by teams that have experience and resources devoted to solving this particular problem. To compete with them you need to be able to invest even more. Most projects have neither the resources nor the need to do that. - Code ownership and long-term maintenance will become a problem. Some people fear that if you go with a third party solution, you risk that the project at some point might become abandoned or unusable for whatever reason. The risk of product lock-in is real, and you should consider a possible mitigation strategy. If it’s an open-source project, would it be possible for you to fork it and maintain by yourself? Or if it’s a proprietary project, how much would it cost to replace it? Based on these inputs you can make a conscious decision on whether it’s worth the risk.
There’s another side to this story. Reimplementing something yourselves is actually a great way to learn. While writing your own framework for a production project is almost always a bad idea, creating it as a learning exercise can be highly valuable. What better way to familiarize yourself with the problems that it solves by taking a crack at the same problems. Don’t go too deep into the rabbit hole, a simplified crude implementation will be enough to give you an understanding of the situation.
While you’re at it, don’t shy away from peeking into the sources of similar projects. Studying the code of open-source projects will allow you to benefit from the experience of more seasoned developers.
Work on How You Work
Strive for improvements not just in technological aspects, but in methodological as well. Just like properly designed and optimized software, a well-established workflow will allow you to work with fewer effort and stress while producing better results. Establishing an effective and efficient work process is not an easy task and there are numerous books and materials available on this topic. But for a start, consider the following areas for improvements:
- Team and project management methodologies. Since most of us work in teams, it’s important to adopt a process that improves collaboration and establishes a common work rhythm for everybody. The agile movement in software development has given birth to a number of widely adopted methodologies, such as Scrum or Kanban. They help organize the overall work structure but don’t cover everything. There are other methodologies that help you make estimates, prioritize issues, improve communication, etc. You’ll need to identify the areas you are struggling with and look for best practices that help address your struggles. - Personal processes. Like an orchestra, an effective team must have the same rhythm, but it doesn’t mean that everybody must work in an identical manner. Each person has their own preferences and should work in a way that makes them more productive. For example, a lot of people don’t like to be disturbed for hours when coding, but I, personally, like to work in short one-two hour bursts with breaks in between (a less strict version of the pomodoro technique). I also don’t like to work at home to avoid household-related distractions and prefer to work from an office or a cafe. Find out what works for you and stick to it, but also make sure that your habits don’t create problems for other team members. - Engineering practices. A lot of practices lie on the border between technology and methodology and focus on improving the actual development process. For example, test-driven development and behavior-driven development help keep your code base well structured and tested. Code reviews help reduce defects in the code and also spread knowledge in the team. Continuous integration and continuous delivery ensure an easier and safer deployment process. Use these practices in combination with other organizational methodologies to achieve maximum results.
Remember, that there’s no process that will work for everybody, you need to trial it in your own environment. Also, make sure that you understand the process completely and implement it correctly. Seek advice from teams that have already gone through the process and benefit from their experience. Don’t neglect the software and material tools that will help you to adopt a process. Get a real Kanban board and a modern platform for continuous delivery. Adopting a new process will require effort and can even lead to a short-term loss of productivity. Give it some time and then do an evaluation of whether things have improved.
A separate thing has to be said on addressing obstacles. It’s a common mistake to neglect small nuisances that might not seem important but can actually have a toxic effect on your work. Is your product designer sitting in a separate room or building? This means that it takes a bit more efforts to come over and have a conversation and some things will not be discussed. Is writing a new test difficult? Then a lot of things will not be tested.
None of these things are particularly dangerous by themselves, but they tend to pile up and cause serious consequences. And the nasty thing is, that you often don’t notice them until it’s already too late. Especially when there are always more serious perils to address. Remember the fable about the boiling frog and the notion of creeping normality.
Stay vigilant and fight these things at their roots before they get to you.
Focus on the Fundamentals
Take some time to familiarize yourself with the classical books on the topics of common patterns in software development such as “Enterprise Integration Patterns” by Gregor Hohpe and Bobby Woolf, the famous “Design Patterns: Elements of Reusable Object-Oriented Software” by the Gang of Four or different works of Martin Fowler. Although some of the things described in books may be outdated, you can use them to learn how the patterns evolved till today.
Secondly, don’t rush to learn about every new thing out there. I understand that it’s tempting to follow every new thing that appears on Hacker News, but a lot of these things are just noise. Rather keep an eye out for things that have been circling in the community for some time now and have matured beyond the hype of initial discussions. Don’t give into FOMO. If you pay at least some attention to what’s going on, no important thing will pass unnoticed.
Often people think that hoarding valuable knowledge will make them indispensable. Having people like this in your team exposes you to the “bus factor” and can put you in a tough spot if such a person were to leave the project. If you are one of these people, consider that in addition to making you indispensable, your expertise also makes you unpromotable and “unvacationable”. You might miss out on other career opportunities in your organization because you are tied up in this role. Instead, share the knowledge with your colleagues, if possible delegate part of your work to them and use this collaboration to build even greater things on top of their work.
I remember a long time ago we had an incident in one project that was by my mistake. We’ve managed to recover from the incident quite quickly and I remember the client telling me:
You don’t judge a team by how they perform when everything goes according to plan, but by how they operate when the shit hits the fan.
No matter how good you are, sometimes things will go wrong and in such moments it’s important to be able to keep your cool and handle the situation with dignity and mutual respect. After the fire is put out, don’t focus on finding the scapegoat. This won’t help you avoid mistakes in the future, but will spear fear and doubt across the company. Instead, come together with the affected parties and do a common post-mortem. Focus on the things that lead to the problem, figure out why it happened and brainstorm on what you can improve your system or workflow to avoid this problem in the future.
Dont be an asshole
The developer community is a funny thing. On one side we see a lot of driven open-minded people that contribute to the community by working on open-source projects, giving speeches at conferences or writing articles. On the other side, we encounter people that troll new ideas, disrespect newcomers and demonstrate rude behavior to everyone around them. Don’t be one of those people. Be nice and spread the love.
Wrapping it up
The best thing about our work is that it doesn’t have a limit. There’s are always new roads to travel and dragons to slay. Whether you’re just at the beginning of your journey or an experienced professional, keep these things in mind. They should help you find your way and become a better developer with each step taken.
Do you have different advice to share with others? Feel free to post it in the comments and start a discussion!