Last week I created my first pull request for Akka.NET fixing a small bug that caused an exception when you concatenated two byte strings. Nothing major, but I felt a huge sense of accomplishment. Here's why.

You get to see the developer culture of a different team

When I wrote the fix for the problem with the byte strings in Akka.NET I got a feel
for the culture in the team that works on this product.

The Akka.NET doesn't have a very strict policy on contributions. Their guide is very compact,
it basically tells you to write unit-tests and make sure you follow some very basic coding rules.
They made it easy for me, when you use Resharper the coding guideline is configured in the editor
in Visual Studio. Resharper will automatically point out any problems in your code, so you don't have
to compare your code to the guideline created by the team.

This makes for a great experience when you try to contribute. For the team it is easier, because
they don't have to work very hard on pull requests. The code looks good almost instantly.
It also makes things easier for me as a developer. I absolutely hate to make multiple roundtrips
to get a pull request accepted. So the automatic guideline thing is a huge timesaver for me as well.

The Akka.NET team is a team that clearly focuses on getting from source to working builds.
They like to get out of the way of developers and let them do their thing. This is something that I
would love to have on my next team. Use the proper tools and get out of the way!

I had my pull request accepted and merged in minutes. They are really on to this sort of thing.
This makes me feel invited to do more for them. I think that if you can get this kind of sense of welcomeness on your team
you are on your way to a great agile development team.

The fact that they accepted my pull request in such a short time with only a single comment
invited me to do more.

You learn a lot by writing tests

I actually signed up to write a few tests for the Akka.NET team. They needed help with porting
some of the test cases that verify mailbox behavior in Akka to their code base so I jumped in and wrote
those tests for them.

After using Akka for quite a while I think that I know a few things about this framework. But while writing
tests for Akka.NET I discovered that I don't. Not that I felt stupid, but it turns out that there's a quite a few things
to go into working with a single actor.

I learned that you have a choice between different kinds of mailboxes that have a different effect on how your application
handles messages for a particular Actor. I didn't know this before, but now I do. And I also know very well what mailboxes
are supported by Akka.NET (which aren't many, but more are planned for a future release).

You learn quite a few things about a product when you try to write tests for them. Not only do you learn how to use a product,
but you also learn a lot about other people's code styles. For example, I learned how you can check for exceptions during a
test in Akka/Akka.NET. I haven't done a whole lot with testing in Akka and Akka.NET, so this will definitely help me get more out of it.

You get to feel important

Writing tests for a project is almost never fun. I used to say never, but I have to get back to this. Because it is important
for the people that use the product. I now know that the mailboxes that are available today can be properly configured in Akka.NET
through a config file, code and mailbox semantics.

The tests I have written give the team more confidence that they have a working product. Which makes my work a little bit important to them.
At least that is how I feel about it.

Try it out, you'll love it

So, if you haven't tried building something for an open-source project before, this is your chance!
Go ahead, open up your browser and go to Next pick a project and issue to work on.
Place a comment that you want to give it a shot and away you go!