I was in a similar position for the first half of my career.
1) Start contributing heavily to a popular open source project you're familiar with and use. Try to make your PRs as high quality as possible. You'll get free code reviews from some of the best engineers in the world doing this. That'll be a million times better than ChatGPT code reviews and you'll be able to learn a ton from it while also getting your code into production at thousands to millions of companies in the world that depend on the open source project/s you choose to contribute to.
2) Fill holes in your knowledge base. If you feel weak in a particular area like networking or DSA then study and practice with it until you no longer feel weak in that area. If you were on my team I would try to assign tasks to you to help you naturally build out knowledge and confidence in your weak areas but without someone to do that for you, you'll need to try to figure out your own weaknesses.
3) Always try to do your best when working professionally. This is all any of us can ever do and if you actively practice it then it'll become a habit that will guide you toward success in any environment.
1) Is this really the case? I mean some of the popular open source project are kind of mature. So you would get some feedback, regarding some specifics of the frameworks. For sure you would learn a bit. On the other hand they are kind of "done" software, so you would not really learn how to build something new from scratch.
You learn so much by looking at how mature succesful software looks under the hood, which you will have to do as a condition for writing a good PR.
But, sure, don't send PR's for things that don't matter just to send PR's, that's just annoying.
But if you send a 3-line PR to fix a bug, that required 15 hours of study of the code to diagnose and figure out the right 3-lines, that is HUGELY educational.
Working on immature or even poorly written software can be super educational too, nothing wrong with that too.
But if you only ever look at hacky not-yet-mature not-yet-proven software, how would you ever learn to write high-quality software, or even know the difference? You have to study known good code. The way programmers study something with a natural goal instead of just artificially, is in the course of trying to alter it "correctly", the study you must do to figure that out.
(I know some programmers who have literally never worked on anything but over-engineered architecture-switched-every-month-for-years barely-holding-together technical debt bankrupt software... and I think sometimes some of them literally don't know anything else is possible! Looking at mature respected code is crucial, if you don't even know what it looks like how could you possibly try to get there?)
One of my best contributions was a 1 line fix in one of Microsoft's repos. It took me a day or two to understand the code and what it was doing but it was well worth it.
Mature projects are probably the best to work on - they have built a good foundation to study.
As the other poster pointed out, heavily contribute implies the project still could use some major new features and there is plenty to do. Even porting something KDE to QT6 would be a major effort and teach a lot even if you don't write any new code. There are projects that are complete as well and so there isn't much to do.
'some of the popular open source projects are kind of mature', so find popular projects that aren't mature, or 'done'? There are countless.
I wouldn't say you'd only learn specifics of the frameworks. Maybe if you only submitted 2 or 3 PRs, but that's not what parent is suggesting: 'start contributing heavily'.
Not so sure about 3. Wouldn't it be more sensible to be flexible in terms if what you optimize? Some projects need best work, some need a friendly face, some should just die quickly.
Determining what a project needs and doing your best to deliver those needs is what "doing your best" means. If you spend months working on a solution that needs to be and can be deployed in a week, because you want to make it shiny and such, you aren't doing a great job on that work.
This is hindsight in my case, but I will say that a lot of the resilience and experience I've developed in my career has come from putting best effort into less-than-ideal or even failing projects (in my defense, in most cases I didn't know they were failing or in a bad state).
Suggestion 1 is a great idea. In particular, consider contributing to one of Airflow’s provider packages if you use Airflow and have any steps in your data pipeline that aren’t ultra-specific to your company not covered by existing providers.
1) Start contributing heavily to a popular open source project you're familiar with and use. Try to make your PRs as high quality as possible. You'll get free code reviews from some of the best engineers in the world doing this. That'll be a million times better than ChatGPT code reviews and you'll be able to learn a ton from it while also getting your code into production at thousands to millions of companies in the world that depend on the open source project/s you choose to contribute to.
2) Fill holes in your knowledge base. If you feel weak in a particular area like networking or DSA then study and practice with it until you no longer feel weak in that area. If you were on my team I would try to assign tasks to you to help you naturally build out knowledge and confidence in your weak areas but without someone to do that for you, you'll need to try to figure out your own weaknesses.
3) Always try to do your best when working professionally. This is all any of us can ever do and if you actively practice it then it'll become a habit that will guide you toward success in any environment.