There's lots of good reasons to get into professional development, but the main one is: to make yourself more valuable. This means more useful/promotable to the company you’re with, or more hireable if it's time for a change. Learning can also get you more excited about a job where you’re otherwise not growing the way you'd like, showing you new ways to work (maybe new processes or tools) to help you, your team, and ultimately the company.
If you've got the resources to do professional development in your off-hours, that could be an option, but don't be afraid to coordinate with your manager to find out how they envision your growth at work. I wrote this article imagining a program where engineers spend one hour learning with a group and one hour learning by themselves every week, but find out what works best for you and your team. Can you start this week?
Sometimes the hardest part is coming up with ideas, so I figured I'd share a few I've seen.
Giving back to some of the projects the world's web developers take for granted is an excellent way to learn new ways of doing things. If you're looking for projects to contribute to, start by looking at what open source projects your team already uses.
Large open source projects often have processes that can inspire you to change how you and your organization work together. You'll also get an opportunity to get experience working with whatever interests you, learning from an existing codebase. Look over some pull requests or previous commits to get a feel for how things work, then take a crack at fixing an issue. Lots of projects have a
CONTRIBUTING.md file to help you get started.
If you have coworkers who are interested in having a fun hour-long micro-challenge competition, come up with an idea for a really simple application like a currency converter or an online survey tool and work in separate teams building it. Compare and contrast what you made afterwards, make it a contest. If other people like, let them pick a winner and participate in next week's challenge.
As you go about your regular work, keep a record of topics you felt unsure about. At the end of the week, share these notes with a larger group to get their input. Alternate weeks, recording questions one week and finding answers the next week. Use your time with the larger group to share what you learned.
Instead of just working on a short challenge, come up with an idea for a more involved project that could span weeks or months and collaborate with your team to make it a real application. Make it a first-rate application with a project homepage, tests, documentation, etc. Let everyone contribute however they like, inside or outside their specialization, so long as it keeps moving the app forward.
Find a course that you and others could benefit from. Spend time each week learning the material and doing the exercises, then talk about the experience as a group. If the course costs money, a deliberate process with check-ins and milestones can help persuade your company to sponsor it. Personally I've found it's a lot more fun spending the group time discussing the previous week's material than trying to watch videos together.
Sit down in a group with peers to individually take on a 30-minute challenge (maybe pair up if you've got a mix of seniors and juniors), then go around in a circle sharing what each person built. For fun, you can take a vote of whose is the best, or everyone can make suggestions for a new challenge next week. The important part is to make it fun and get everyone involved without much overhead.
You might already be doing something like this at sprint reviews, but show something cool you made last week to your teammates. Unlike a regular sprint review, this is a better opportunity to do a deep dive on the technical details of how things work. Let everyone share something they made.
The idea is to walk everyone through something cool and teach them how they could do it themselves (or if the person sharing wants, why not to do it how they did it). Don't let it turn into a live code review (that's what regular code reviews are for) or something everyone dreads each week. Keep it light!
Each week, pick a different command and encourage everyone to use it daily and share their application of it in the group chat. Commands like
grep are great for this since they're powerful but often avoided because they take some practice. This doesn't need to just be bash commands, you could pick a feature in your language of choice. For example, you could focus on how a problem you're solving could use ES6's generators and explain if it'd be appropriate.