We all know that being a competent software developer and achieving career growth is about more than just writing code. Often we talk about "being a good communicator". This is also important, but I also think these are only two of several skills or sub-disciplines involved in being affective at your job and generally having a fulfilling career (possibly with pay increases along the way).
Here are a list of five key concepts I've thought of that can lead to an effective and fulfilling career. If you can think of equally important concepts not touched on here, or feel like I should have arranged things differently, feel free to leave a comment. This is a great discussion point!
Effective Coding Skills
This is the first basic element of software development—coding. This may seem obvious, but in the name of being great at other components of the craft, some folks truly do lose sight of the fundamentals.
Coding skills can be honed by general practice, reading blog posts, and generally hanging around coding sites like this one. Immersion is important for adoption of the nuanced elements of good coding—and is a general theme of this whole post.
One important element in adopting effective coding skills, especially for newbies, is to avoid being sucked into new and exciting domains before you have allowed yourself appropriate opportunity to master some basic concepts in software development.
Unfortunately narrowing on what the basic concepts are is not so straightforward, so everyone's journey is one of personal discovery. However, generally avoiding FOMO and shiny object syndrome is the best way to develop the right skills.
Team Communication Skills
This is that second important concept for software development that is brought up a lot. You must be able to accept guidance, provide guidance where appropriate, and generally become great at communication. Any trope that software developers are inherently not good communicators is patently false. It might be true that our industry attracts a lot of introverts (the truth is we also attract a lot of extraverts and everything in between), but communication skills stretch far beyond personality traits.
In my experience, the best communicators are folks that value communication as an important aspect of their work, and the worst are those that do not. This is not about absolute capacity to communicate, it's about devotion to the concept in general. If you think communication is not important, or perhaps not within your skillset, you will likely become a bad communicator. I believe that is the causational direction here, not the other way around.
Good communicators are folks who believe they are capable of being a good communicator.
Here is a thought-provoking post about communication in software...
Ecosystem Awareness
If you hang out around DEV you will see a lot of posts about the latest GitHub features, VS Code extensions, VIM advice, AWS services, etc.
Software development has always been about staying just plugged in enough to understand what's being released and what might change the way you think about your code—without being so plugged in as to get distracted. This is a delicate balance.
This post is a good example of the kind of post to keep an eye on...
Keep your eyes and ears perked for interesting ecosystem movements in terms of open source and commercial software without being so consumed as to develop the aforementioned shiny object syndrome.
Personal Productivity
Even the most knowledgeable coder in the world can fall prey to productivity traps. Sometimes personal productivity is a matter of life arrangements and distractions, sometimes it is a matter of mental and/or physical health. Sometimes it is a matter of productivity software tools and shortcuts.
Your personal productivity habits will always need refreshing. Learning new things often leads to learning new productivity tricks—especially if you adopt a lot of new things stemming from the "ecosystem awareness" pillar.
Reading about productivity doesn't always need to be an "aha" moment, often it is a nice reminder of something you already do in some capacity.
Article No Longer Available
Don't get into the habit of being set in your current productivity hole. Reflect and refresh often. Take breaks, find ways to socialize outside of tech.
Career Management
If the first four pillars are essentially setting up the pins for an effective software career, this is where you knock them down. Career management is about having good communication with your managers, and when needed, capacity to know your worth and find new managers.
All else equal, I believe in long and fulfilling careers with fewer total companies, but don't pursue this path if it is going to be detrimental—and it often is. Knowing that you have the capacity to leave for the right opportunity is important.
There is a lot of advice around leaving your job and job seeking, so I'd prefer to focus on the effective career management within the job. I think this is about pro-active boundary-setting, not letting important things go unsaid, and generally setting expectations on an ongoing basis.
Here are a couple posts which demonstrate thoughtfulness about one's career...
Top comments (26)
Awesome list! I would add one more:
A hundred times this :) the best devs I encounter are super humble. Massive egos are a red flag.
I couldn't agree with you more!!
That's a very difficult one. It's often a conscious effort for me to take a step back and consider what others have to say about your work. But I do it. While I believe my work is the best, I make myself believe it's a different person who wrote it. There's me, the coder, and me, the reviewer. That make it easier to accept critics.
Good one! In my case, me, the reviewer is always yelling at me, the developer :D
Damn, great point!
The colleagues I respect the most are the ones who are really smart but also humble - whatever
question you ask, they will take time and effort to make sure you've understood it. They're the kind of role models to look up for.
That kind of colleagues are super scarce and valuable!
Pillar 6: Being in the right place at the right time.
As the Bible says, in Ecclesiastes 9:11:
I heard a great corollary to this from Country Joe (of Country Joe and the Fish). He said, "Everyone always says it's about being in the right place at the right time, but what no one tells you is, that means being everywhere, all the time." It's hyperbole, but it's a good reminder that if you really want to make it you're going to have to put yourself out there. A lot.
Ecclesiastes is full of fine advice for a developer.
This could be translated into “Who do you associate with?” Do you surround yourself with people that believe in you? Have positive energy? Are actively pursuing similar goals? Answer these questions with yes your in the right place. Then add some patience...if you have the time.
One more Ben: committing to a process for learning new dev tech. I've "recreated" myself as a developer about 5 times; being able to learn, knowing when to jump ship on a platform, understanding how to differentiate yourself from other developers: these are key developer career skills, IMO.
Nice one Bob
Some of the things my supervisor has told me:
This is a great post and one I'm going to save as a reference,
"Software development has always been about staying just plugged in enough to understand what's being released and what might change the way you think about your code—without being so plugged in as to get distracted. This is a delicate balance."
Damn.
Another thing to add is to understand the business’ goals and purpose. Too often software engineers think their value comes from the code that is produced. Real value comes from the effect of the code, either to generate money, make some progression to the field or industry through innovation or fixing a problem. So to succeed where you are is to also learn the business where you.
Good list. Just 2 remarks:
"It might be true that our industry attracts a lot of introverts": I think a lot of people tend to mix several types: autistic, introvert and shy the three are different though of course some may cumulate ;)
career may be quite different between big corps and startups, you don't know it until you live it ;)
Some solid talking points here.
However I think there aren't that many pillars.
For me, there's only one, knowing what one wants. And this is a process. One can never truly know what they want. It's a shifting target.
We should keep track of our wins and losses, highs and lows and find opportunities which fit our needs and improve upon shortcomings.
It's important for one to find their center and stay on course. Because there's a lot of noise (shiny new objects), and a lot of gate-keeping in this community.
Very true. I feel like you can’t work backwards and establish pillars if you don’t know what you want. Once you know what you want, the pillars will form through trial and error. Of course it’s easy to see the pillars looking backwards but you can’t start from the finish line 😉
Great list! - all very important.
Communication is one that's easy to drop accidentally, and then only you realize the bad effects several weeks later.
It can be difficult to remember that not everyone on your team has had the same conversations, been in the same meetings, etc - and so decisions and actions should be shared (and over shared!)
If I think back to my best and worst contracts - the best have definitely had the most communication, and the worst (by far) had the least communication (written or in person) between the team.
I'll throw one out too, being able to see the big picture of the business and not get stuck in a silo.
The best devs I've worked with understood the business well enough to make nuanced decisions about how they built and using what tools.
Orthography in whatever human language they write, and intellectual ability especially if it's their mother tongue. A person with difficulties to express right, cannot think right and consequently cannot create anything right.
I really like the part in communication and ecosystem awareness.
Since it helps a developer to know where is the technology trending is heading plus being better at communicating with people to create better software.
As soon as I read 5 pillars it made me think of the AWS Well Architected Framework Whitepaper.
Do you think we could get some official Whitepapers for Dev.to?
yuk yuk
A white paper would be something deemed, perhaps, to be a peer-reviewed canonical source, as opposed to the more casual blog post style?
I am missing in this list something like "Business Awareness", otherwise we devs get lost in the passion for developing a beautiful code that is overkill for the feature/problem being tackled.