New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not great after 10 years; what to do? #4

SeanKilleen opened this Issue Nov 16, 2017 · 1 comment


1 participant
Copy link

SeanKilleen commented Nov 16, 2017


Hey @sjkilleen, what do you do if you've been coding for 10+ years, are still not great at it, but feel like it's too late to make a change?


This comment has been minimized.

Copy link

SeanKilleen commented May 30, 2018

Hey! Sorry this took a bit -- I've been noodling over it for a while.

It's never too late, if you want it.

If your skills aren't where you want them to be, and you want to invest in your skillset and are able to make the time / training investment, then it's never too late to make a change, especially if you're already recognizing that things could be better.

The amount of time you've been doing it doesn't matter -- there's no cutoff period period for growth. I'm really advanced in several areas, but in some areas I've got a ton of growth to accomplish.

What do you mean by "not great"?

Some people don't give themselves enough credit, I think. So as part of this exercise, I'd encourage you to understand what you mean by "not great". Compared to what? Compared to your colleagues around you, or compared to some rockstar-ninja-whatever-bs-term engineer you look up to?

Remember that you've been doing it for 10 years -- assuming you're not getting fired all the time, you're probably not doing it too terrible.

Experience & Mistakes are the best tools in your toolbox

You'll hear a lot of senior or high-profile people talking about how it's not that they're great, it's just that they've made all the mistakes.

There is some serious truth to this.

What mistakes have you made, and what are the lessons you've learned? Catalog those and you'll realize you probably already have a bit of learning under your belt.

The Honest Assessment

It sounds like you've detected some areas you'd like to improve.

List them. What are the things that are out of your grasp? Things that seem murky? Things that you feel like you stumble around? Places where it seems like it's easier for other people?

Now, rank them in order of pain or embarrassment or the amount they've been holding you back.

This is your checklist. Break it down & start, one thing at a time. Find training resources & start putting in the time.

Find a way to apply things

It's by no means required, but a side project -- even some rinky-dink thing that you never intend to see the light of day -- can be a huge confidence booster.

A personal example: I'd never used ElasticSearch. But it was the right tool for the job on a project. I felt way in over my head, but dove in, made a bunch of mistakes, and learned a lot. Now I have confidence to use that tool (knowing I survived) and I've turned those mistakes into lessons that I provide to others in the form of talks.

Not everyone has time for a legit side project, and I'm definitely not in the camp of "everyone should have a side hustle". But, even if it's just to tinker, having some tiny demo codebase you can mess with can help you apply things and level up.

Software Development First Principles

There are some topics that will increase confidence in your development skillset & take you pretty far -- I've deemed this "Software Development First Principles". Topics include:

  • Unit / integration testing & TDD: Knowledge gained in this area will have ripple effects throughout your code & codebase.
  • SOLID Principles: If you're working in an object-oriented language, these are worth looking into and understanding.
  • Code Smells: Learn about them, because it will help you learn to spot your own.
  • Build processes: Knowing how software gets out into the world eludes a lot of developers and can hold people back. Explore a build system & how software goes from code to published with minimal human intervention.
  • Refactoring: Knowing how to change code without breaking its functionality. This is especially useful when combined with TDD, because you become more able to refactor your code to a better testable state.

Get out in the community

It's not always easy to do, but I've found that when possible, attending meetups & get-togethers with other folks in your industry can be a great way to relieve this pressure & learn. We're all learning, and we're all trying to improve, and none of us have a handle on everything. Seeing other human beings dealing with similar issues could be helpful.

It's not just you, I promise.

You may want to consider following blogs. I use Feedly and regularly skim through hundreds of articles, though I of course never read 100 of them. If I want to read something later, I send it to Pocket, and then I catch up on them when I have time.

Following people you admire or who are senior software developers & then following them in places like Twitter & GitHub can be helpful too. They often retweet relevant articles & lead to other great people to follow I also love it because Twitter is an equalizer; it allows you to ask questions.

Which brings me to my next point...

Ask Questions!

If you have a question, chances are 100 other people do too. Asking a question of someone who may know the answer, especially if you do so publicly, could benefit not just you but others as well.

A lot of times, they'll have additional resources and I think you'll be surprised at how often people are willing to help.

A few resources that could Get you started

  • I've got Rob Conery's The Imposter's Handbook on my reading list -- and there's a whole second edition planned that looks like it's going to be awesome.
  • Pluralsight has a ton of tutorials -- search around and see if they cover your topics
  • Lynda is also pretty popular, though I haven't used it personally.
  • The Art of Unit Testing is a fantastic book I think, and taught me a lot about how to think about tests. The examples are in C# but it should be helpful for almost any OO language.

Wanting to improve is a valuable motivation. With that motivation, a little bit of self-credit for where you are already, a plan, and the willingness to say it's OK to improve over time, I think you'll go a long way.

And if you have any more questions, that's what this AMA is for! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment