The Five Pillars of a Successful Career in Software

Ben Halpern on October 07, 2019

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 ... [Read Full]
markdown guide
 

Awesome list! I would add one more:

  • Humility: I've met many developers who think they already know everything. In my opinion, this is one of the main reasons that lead to being outdated and not growing professionally.
 

A hundred times this :) the best devs I encounter are super humble. Massive egos are a red flag.

 
 

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 have observed something else under the sun. The fastest runner doesn’t always win the race, and the strongest warrior doesn’t always win the battle. The wise sometimes go hungry, and the skillful are not necessarily wealthy. And those who are educated don’t always lead successful lives. It is all decided by chance, by being in the right place at the right time.

 

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.

Vanitatis vanitatum, omnia vanitas

 

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.

 
 

Some of the things my supervisor has told me:

  • Over-communicate. We have deadlines and mulling over an issue affects the team, our deadlines, and our budget
  • Take 5 hours a week for learning/career development.
  • Have an effective task management system. Juggling multiple projects leads to being forgetful if you don't have a system in place to manage all of them. I also have Drafts.app open on my Mac to take quick notes.

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.

 

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.

 

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 ;)

 

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.

 

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'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.

 

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.

code of conduct - report abuse