I started my software engineering journey as a fresh faced web developer, making my first salary by creating websites with PHP. It became my tool of choice. I was a PHP developer, and after a while I became pretty good at it, too.

As part of that process of getting good, I started to see that there were other things that other people were doing, as part of my development team. We had UX experts, and testers. We had systems folks who looked after the servers. We all worked together, and our skills came together to make a better product than we ever could.

But I was the PHP developer, right? I had no business doing the testing. That’s the job for QA. If there was a server problem, I threw the details over to the operations team and assumed it would be fixed.

It was at that point, I started to wonder how I could grow next. What my next move would be. I just would get really good at PHP, and dazzle everyone with what I knew. I mean, really good. So good, and so dazzling, everyone would be complimenting me on my PHP.

What I didn’t know at that time, is there’s more to being a great software engineer than being great at PHP. I knew that a team which works together will make great things: but I didn’t realise that if I knew a little about those other disciplines, I would be a more effective and more useful member of that team.

A useful member of the team not only has the ability to fix the development server when it goes wrong, or gets their hands dirty with some testing when there’s a backlog in the testing column. But they also have the ability to empathise with the other disciplines of the software engineering team. The ability to ask the correct questions, maybe even know the answers themselves. To know why a decision has been made to go one way, rather than the way that’s easier for the developers.

The Covid-19 pandemic has been a world-changing event, suddenly forcing us to come up with some new normals. At least, for a little while. One of the benefits of this is we’ve found ourselves doing more virtual community meetups, which anybody around the world can — if they so desire — join, or even watch a later recording of.

This will almost certainly continue into 2021: and might even bring us a whole raft of virtual, online meetups, continuing far into the future. A future where we can return back to sitting in a room together. But a future where we can do both.

So let’s make the most of this new, virtual future. We have a future where we can join any online meetup in the world, whatever the discipline. There’s so much knowledge out there both within and outwith our primary skill.

And who knows, it might even make us all more useful members of our teams.

When I think back to the things that have helped me in my career, one of the biggest has to be the community.

The chats during local usergroup meetings, the conference hallway track, the Slack groups. All are great ways to get to know other people in the community, learn something new, and even teach somebody else something they didn’t know.

But another way to grow as a developer is by contributing to open source. It may be unpaid work, but being part of the community can provide many benefits.

It lets you tackle something new

Often, trying out some new tech isn’t commercially viable for a day job. It can be hard to justify the cost and the time when a company needs to make money.

In 2017, I plan to get more experience in automated testing. As a member of the joind.in community, I am able to contribute to the automated tests on a real project, and a real website, with real peers. I’ll be working with other people’s code, and I will probably also learn from the other contributors.

You’re giving back

We all make use of open source software as part of our day job, so to be able to give back in some small part helps you grow. You’re not only contributing to the world we all work in, but you’re also contributing to the community. A community that you’ve made that little bit better.

You’re making friends

Among the pull requests, bug tickets, and reviewing of code, you soon start to get to know about your fellow contributors. If there’s a project Slack channel, you might find yourself talking about non-project things.

If you contribute to WordPress or Drupal, you might attend a Wordcamp or Drupalcon — or a local WordPress or Drupal usergroup. You might find yourself eating lunch with someone you’ve been talking to over Slack.

If you ask me, this is the most fruitful of benefits to contributing to open source. I don’t always find time to contribute code to open source projects: often it can be months between my pull requests. But I’m always around, in the community, in the background.

And that’s because I made some friends. Friends who have taught me, and friends who I’ve taught. Friends who I’ve shared both a feature ticket and a laugh with.

My year of open source

A few months ago, I set up a local group where once a month, people can come along and spend some time talking, drinking tea, and contributing to open source. I call it Patch:Manchester.

Next year, in 2017, I want to continue learning and growing, and I will be using open source to do that. I’ll also be using Patch:Manchester to do that.

Why don’t you do the same?