I'm not an expert; I'm learning

Although I've been a developer for most of my life, I can't say I'm an expert.

I do have some expertise, but as many things in Tech, they keep evolving, changing, and improving.
The same has to apply to my expertise.

Hence today's topic, being a software developer is a life-long commitment to learning.

In some recent posts, I've talked about Python not because I'm an expert, but because I want to learn about it.
And my way of learning includes writing about it.

In those cases, I love it when people point out other use-cases or alternatives to the examples I sketch.
This doesn't mean my learning is wrong, but there might be room for improvement.

And this, in return, makes one a better developer.

Public learning

You might call this approach public learning, and it doesn't work for everyone.

However, some aspect that might convince you to give public learning a try:

Feedback by peers
Feedback by product owners
Help from community members

For me, those kinds of feedback you typically won't get in school or even in companies.
So pro for getting community help.

But how does one go about this type of learning?
Some ideas to get you started:

Contribute to open source issues
Write down some learnings on a blog
Create a Twitter thread
Open discussions on Reddit/StackOverflow/etc.
Participate in meetups/events

And like mentioned before, don't expect to be the expert, but the learner. It's ok to make mistakes and have people guide you in the right direction.

If everyone knew how to do everything, it would be a very boring world.

Provide feedback and questions

You might have heard me say this before: "Ask questions," and even here, it's valuable.

You might often see a tweet or discussion by me asking for feedback on a certain language, idea, or concept.

This is a valid way to get in touch with people who have done something like this before.

With the information from these people, you will complete your idea on this particular topic and learn from it.

Don't be afraid to ask something you're not sure about, or you question why it's done in that way.
I love it when my PR's are being reviewed and someone questions why I use method x over method y.
Often that's a super good question too, which I either can answer well because of z. Or I refactor it because it didn't have a particular choice to it.