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

How can one know one's own level of technical maturity? #10

Wintermute21 opened this Issue Nov 28, 2018 · 1 comment


2 participants
Copy link

Wintermute21 commented Nov 28, 2018

When I started my career, I hopped around mostly doing contract work, but never really got to stick around in one place long enough to really mature, so, how can I know if I'm truly a mid-level Full Stack dev for example, or if I'm still a junior despite my experience on paper? How should one begin to overcome this?
Thanks in advance.


This comment has been minimized.

Copy link

SeanKilleen commented Dec 25, 2018

Hey @Wintermute21! Thanks for writing in, and sorry it’s taken me a bit to get back to you.

It’s great that you want to genuinely see where you are; I think this sort of continuous self-reflection is critical to improving as anyone in a technical role.

I was thinking about this a bit and I think I can sum it up in a patented* AAAA ™️ approach:

  • Approach
  • Absorb
  • Assess
  • Apply


In this step, you gather all of the content you think could be relevant to the skillset you’re examining. Look up popular books, videos, training courses, blogs, etc. that are relevant to the skills you’re wondering about. This may mean searching by keywords, following folks on twitter, etc. — or asking around. (Feel free to follow up with me if you want any recommendations in certain subjects, by the way). If you can approach this content and it feels relatively comfortable, you’re probably in a reasonably good place. And for the content you’re not familiar with, you can move on to the next step...


Scan through the contents, blog topics, etc. from above, and find something you aren’t familiar with. Dig in.

How was the experience? Do you feel you can grasp it, or did you go down a rabbit hole of concepts you’re unfamiliar with? Either is fine — and in fact that’s one of my favorite things to do sometimes. But, if you’re looking to gauge where you are and this is happening for things that seem to be more fundamental, it may help you understand your current level of understanding.


Once you’ve started to gauge where you are, you may want to take a more formal assessment. This could take the form of a certification (for example I recommend a CSD for fundamental OOP development concepts such as SOLID, TDD, etc.). It could also take the form of a subscription to Pluralsight, which I love and which has both overall assessments for certain groups of skills and assessments after many of its courses when using the appropriate subscription.

Assessments are a great way to see what you know and how you might stack up to others in the industry. I wouldn’t worry about them too much as an end goal, but preparing for them can give you great insight into where your journey might go.


This is my favorite way to attempt to understand a skillset — jump in and build something! Chances are, not only will you understand where you are but you won’t be able to help learning some good stuff along the way. If I want to understand build pipelines, I create one. If I want to check how a thing works, I build a thing that works (...eventually). If I want to test whether I can explain a concept, I write about it or present on it. If I want to see if I understand a library or tool well enough, I’ll see if I can contribute a pull request to it.

It’s important to not get discouraged if the thing you create is ugly or barely functional. It will help you understand where the hurdles are, which is a great way to start exercising to get over them.

Importantly: Remember this is a multi-dimensional thing

You will be a senior at some things, and a junior at others — I sure am, at least. If you can continually level up your skills and you care about doing things well and about the people you work with, you’ll go far.


I hope this has been useful! Feel free to follow up with any additional questions you have.

* totally not patented

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