You may quibble with my choice of percentage, but I don’t think the underlying idea that things other than technical ability is particularly controversial. Even if they bitterly dismiss such things as “politics” most developers are aware that their careers are impacted by things that go beyond their ability to write algorithms. What I haven’t seen much of however, are attempts to catalogue what these soft skills are, and how somebody might get better at them. The second part is outside of the scope of a single post, though I will attempt to list resources here. But the first is achievable, and that is what I will attempt to do here.
The following is not an exhaustive list, but it covers 10 “soft skills” that I’ve seen have a clear impact on my career in software and those of others. The best part? These are things you can grow in that will have an impact in your life outside of work, and in any career you might transition into in the future.
While I’m making bold statements: A developer’s ability to communicate clearly is the single most important skill in determining the trajectory of their career. Poor communicators are forced to rely on others to interpret their work, even when it is brilliant. They will often create problems for others through miscommunications or lead teams to make suboptimal decisions because they were not able to explain the technical considerations involved in a situation.
Great communicators on the other hand, enlighten. They help teams understand what is really going on so that non-technical team members can make good decisions, and technical folk can work with confidence. Great communicators cut through misunderstandings, expose ambiguity and poor assumptions, and can translate for team members who are having trouble making themselves heard.
Communication skills are important for those on a management track, but they are just as important for those on a technical trajectory. Architects, Principal Engineers and Tech Leads must coordinate with many teams, teach less experienced developers, explain technical tradeoffs and document decisions and code. Those are core parts of a senior technical employee’s job, and all of them come down to communication.
This one is more commonly referred to as “time management”, but I agree with this recent NYT Op-Ed: the mechanics of how we organize our time is less important than whether we end up spending it on the most important things. This broadly encompasses the ability to prioritize, to prevent distractions from wreaking havoc on productivity, and the ability to find ways to get back on track when things go wrong or priorities change.
This was a weakness for me early in my career: I got things done but often did them haphazardly or inefficiently. One of my biggest sources of growth in the last few years has been finding ways to structure and prioritize my time better, while cutting out distractions. This has been necessary due to life changes: I’m now a parent and have people reporting to me at work. I wouldn’t be able to meet my current responsibilities with the habits I had as a 25 year old. For me this has been largely about focusing in on a small amount of essential things and actively removing less important things from my life. For others it may be more about establishing patterns and limits. Either way, this requires planning and introspection first to be effective.
If you see an opportunity or a problem, do you do something about it? I’ve been reading a good amount of “manager books” recently, and in many of them a surprising amount of focus is dedicated to the question of how we create conditions when people are “empowered” to act. And there certainly is an environmental factor here. People are more likely to take initiative and risks when they’re not afraid of being punished for it. But the individual also controls a lot here. Developers who are willing to step up and take initiative in a situation can make an outsize impact.
Do you have a piece of code or process on your team that everybody acknowledges is a bit wonky, but nobody has ever taken the time to fix even though it is slowly taking a toll on the team over time? Are there simple things that you know could make your product better, but nobody has quite taken the time to get to them? Those are the opportunities that initiative can turn into value.
There is no meaningful software product that has been created in isolation. One person may have written the code (though that is quite rare for software with any scale of impact), and maybe even didn’t collaborate with anyone to handle distribution / hosting etc, but if that software is used by others there is always support, training and marketing to consider. You can create a todo app for yourself without talking to anyone. But nobody makes a career in this business without talking to other humans.
The thing about us humans; we work well with people who we trust, and who we perceive as caring about us. We also are for the most part exceptionally good at discerning when somebody is faking it. So if we can’t get away from humans, and we can’t be fake, what can we do? We are left with, in the words of Dale Carnegie “becoming genuinely interested in other people”. If you’re currently filled with red-faced frustration at your annoying co-worker or manipulative boss, this may seem like asking for a miracle. And arguably any time we look outside ourselves it is a miracle. But regardless of your philosophical outlook on such things, there are definitely ways we can improve in how we work with and care for the people around us. And it starts with trying to empathize and seeing the people around us as human beings and not obstacles or tools.
You may not think that Software Engineering involves much negotiation. But that is only true if you use a shallow definition of negotiation. Every time a team debates implementation strategies for a feature, which tickets should end up in a sprint, and how much time to spend chasing a difficult to reproduce bug, they are engaging in negotiation, and team members are attempting to persuade. And there is a wealth of knowledge out there describing how to improve on these skills.
A word of caution here; unlike some of the other things on this list, these skills can often be dangerous when they’re improved in isolation. When developers complain about politics trumping technical ability, they’re often experiencing decisions being made based on the ability of some employees to persuade and negotiate. When those employees are not actually providing the best ideas this is suboptimal. For the technically skilled employees, the answer is to learn to persuade better. But for those who can negotiate we always need to make sure that we’re persuading for good. Just like the loudest voices shouldn’t always win, when you can communicate well, make sure to stay humble and boost other’s good ideas when you see them.
Were you paying attention in high school physics when they taught about the difference between distance, velocity, and acceleration? Distance is the amount an object has traveled. Velocity is the speed at which it is currently moving in a given direction. Acceleration is the rate at which the object’s velocity is changing. If you want to know where an object is right now, distance is the only thing that matters. But as time progresses, velocity starts to matter more, and in the very long term any difference in acceleration will be the only thing that matters.
The same ideas play out when acquiring skills. If you need to evaluate your career potential for the next few months, the skills and accomplishments you’ve acquired so far (distance) are the only things that matter. But if you want to think about your career potential over the next 30 years, the new skills you’re acquiring (velocity) and even more importantly your ability to get better at learning new things (acceleration) will matter much much more. Learning is a skill unto itself, and the earlier you invest in it the more dividends it will pay over time.
Another lesson that I’ve learned the hard way in my career is the reality of my own mortality. None of us are indestructible, and our bodies are not perpetual energy machines. They require care and maintenance. Our souls too are not meant to run on work alone, and we can burn out hard without sufficient rest. This is all aside from deeper issues of disease and mental health that can change our lives in even more profound and difficult ways.
Self care is a career skill because frankly we are great at deluding ourselves into thinking we’re functioning normally while we’ve compromised ourselves. Research shows that we are horrible judges of whether our judgement and creativity are compromised by lack of sleep. Because we can’t run controlled studies on ourselves, we don’t really know whether our lack of exercise or 60 hour workweek induced burnout are hurting our creativity. But research suggests it is for pretty much everybody.
Healthy socialization, sleeping, eating and exercise ultimately lead to better emotional stability, ability to focus, and creativity. But even aside from the career benefits, when we’re devouring our bodies and minds for work, it leads to a question of what we’re doing this for in the first place.
Do you know what your company actually does? Do you understand why the features you’re building are important, and the relative priority of them? Can you explain the business tradeoffs involved when you’re making an software architecture decision between performance and security?
In companies larger than a few people it’s not ultimately developers’ jobs to make business decisions. But understanding the context for those decisions helps us better prioritize our time, make good tradeoffs, and call attention to inefficiencies or counterproductive behavior in our products. In addition, nobody wants to spend time working on things that don’t matter. But when we try to innovate without understanding the broader business, we often end up doing just that.
Marketing is a dirty word in engineering circles. Many take the attitude of the Dilbert comics that marketing is a synonym for exaggeration lying, and fraud. But at it’s core marketing is just making sure that the people who could benefit from your services are aware of those services. This has several applications to developers. In the job market, finding ways to let employers know who you are and what you’re capable of is important. But in medium to large companies it also is important to do some level of internal marketing; to make sure you’re credited for the work you’ve done and that people understand it’s values. Developers who consider themselves above this or dismiss it as politics do so at their own peril.
The final item here is in some ways an oddball. While the other 9 things on this list are skills that you can work on, character is something deeper. Questions of what good character is and how you develop it are way outside the scope of this post. And I would personally consider any attempt to improve your character for solely utilitarian career reasons to be ultimately hollow. But character is undeniably important in your career.
Do the people around you trust you? Do they believe that you’re trying to do the right thing? If the answers are no, you may find obstacles in the most unexpected places. If the answers are yes, you will eventually find help from people you would never have looked to.
In addition, as an industry, technology has the power to shape the world, and as practitioners we all get the chance to impact our little corners of the world. It’s worth considering not just whether we’re “succeeding in our career”, but what impact we’re having on the world around us.