Many people want to be involved in this open side of tech, and luckily there are many different ways to contribute.

Still, open source can be scary at first sight. My first official contribution was during Hacktoberfest 2021, and even after that, it took me while to really feel welcome.

The open source community helped a ton, and it's the route I would advise any new techie to take – get involved with the community around a project you care about.

In addition to being a contributor – making updates to open source code bases, updating documentation, and so on – you can also eventually become a project maintainer. Maintainers are responsible for the thrill you experience when your pull requests get merged.

As daunting as it is to become a first time contributor, it is also quite scary becoming a first time maintainer. So in this article, I'll discuss some of the soft skills project maintainers should cultivate to be successful.

A Little Background

After open sourcing a project very close to my heart, I was lucky enough to gain some much needed experience. I also held a Twitter space with some amazing folks, and they had much to share as well. Hence, this article.

I won't say I am an expert, but to successfully scale an open source project, no matter how big or small, there are certain skills you need to have. And some of these I didn't pick up until after I had been a maintainer for a while.

Skills You Need to Maintain an Open Source Project

Develop Good Time Management Skills

On day one of releasing the project, my email was flooded with GitHub notifications.

I was happy people where checking the project out, but it was too much for me to handle. I was putting off work to attend to issues, assigning, labeling, merging pull requests, fixing conflicts... It quickly became too much to manage. I needed to allocate time and set boundaries.

If you are running a big project, notifications are probably nothing new. If you're running the project alone (like I was at that point), it is way worse.

Putting aside specific time to attend to GitHub tasks was the best way out. It could be in the morning before work, or after work, or only on weekends, depending on what works for you and the project.

Be Patient

I hear people advise contributors that they shouldn't spam maintainers if those maintainers can't attend to their issues/pull requests in time. This level of understanding should go both ways.

Contributors also have lives. If a contributor claims an issue, it is important to give them time to actually submit a pull request. Open source is fun (we've agreed on that already, but just for emphasis), but some people can only contribute in their spare time.

If a claimed issue is taking too long to address, a subtle reminder is fine. Constantly reminding a contributor that they need to submit a pull request could be off-putting, and it isn't a good look for you or your project.

On some rather large projects, however, a time frame is given to contributors who claim issues. I've seen cases where a contributor has about seven days to raise a pull request. While this is understandable because of the fast paced nature of these projects, I personally feel that it's too much pressure, especially for new contributors.

Be Empathetic

For me, this is the most important skill. I can remember my first open source contribution. The joy I felt when my pull request got merged and the immense support from the community were wonderful.

Think of this when you merge pull requests. It could be the contributor's first time too. I try to close off pull requests with a message other than just 'LGTM'. It can be as simple as throwing in a bomb emoji, and thanking them.

People come back to a place where they feel welcome.

Be Firm

This can be hard, but it's also important. You won't merge every pull request that is opened, and that's a fact. But abruptly closing off a pull request without justification isn't exactly good practice either.

If a pull request is too big, or it doesn't add to the project like you would've wanted, it is okay to close it. But do not be afraid to kindly explain to the contributor why it can't be merged. Don't leave a pull request open forever because you feel guilty about closing it.

People can be more understanding than you think if you give them simple common courtesy.

Work on Communication Skills

Collaboration is the basic foundation of open source as a whole. And to collaborate effectively, you need to be a good communicator.

Having people come in and work with you on your project is cool and all – but if you can't properly communicate with these people, you'll end up with a closed open source project (if that makes sense).

Collaboration doesn't have to be you spinning up some huge discord server for the project. It could just be you sharing messages in your code reviews.

If the comment sections under your issues are too small, then GitHub has a discussion tab for each repository. This is a great place to spin up new ideas and start some great connections.

You never know whom you might meet!

Listen and Learn

After open sourcing my app, I've probably learnt more React than I would've if I was watching tutorials and building in private.

Smart people will come along and open your eyes to ideas that you couldn't have thought of on your own. My project has improved so much, mainly because I wasn't afraid to try out new things.

The community wants to help – so let them.

Cultivate a Community Spirit

Someone recently reached out to me, saying they wanted to get involved in reviewing pull requests because it was fun. They aren't officially a maintainer, but I would like to think that they enjoy being a part of the project.

Building an open source project is a community effort. And as a maintainer, you will need that community spirit.

You need to be excited with what you do. Collaboration should be fun. You are happy that the contributor added something, but let them also be happy that they contributed.

People love good, honest feedback. And it also helps you build up your little community.

Be Responsible

If the open source project is your idea, then you're the pioneer. If you decide to be the lead maintainer, be the lead maintainer. Be reliable, and most importantly, be present.

Even if you are a supporting maintainer for some big project, it is good to show that you know what you're doing and that you're committed to the project.

Some projects go stale because the maintainers stop responding to issues and pull requests. It's true that life catches up to us sometimes. If you decide to commit to a project, though, it's important to always show that the project is alive.

But how? Well, everything leads back to collaboration. Keep your collaborators involved and they'll help you out.

Be Nice and Welcoming

People are coming from different backgrounds to check out your project. Whoever they are, they won't come back if their first experience was a mean maintainer, whose project had poor documentation.

No matter how easy you make things, expect questions. Be ready to answer these questions. Point people to the right resources, no matter how obvious the solution could be.

If a contributor is having a hard time, check your documentation. Most times, it's not them, it's us (pun intended). The README might've skipped some steps, or a screenshot wasn't clear enough. Instead of telling them off, point them in the right direction and update your docs if need be.

Conclusion

All in all, being a maintainer is hard work. Whether you're going solo on your project, or working with other maintainers, the goal is the same: collaborating to build great products.

Projects with poorly structured management and responses are one of the main reasons some people feel discouraged when it comes to contributing to open source.

The skills I've covered here are mostly based on personal experience, but I hope they help anyone maintaining a project, or thinking of being an open source maintainer.

If you want to check out my open source project, you can do so here.

Do you have what it takes to become a programmer? Chances are, you will base your answer on a bunch of untrue stereotypes and misconceptions. Those are harmful because they stop you from trying out this career path.

Let's take a look at some of the things that you do not need to become a programmer.

Intro

I have always found programming fascinating since I started using the internet in the late 90s. I was enthralled by the amazing things developers could do. And my admiration only grew as new websites and later apps started to radically change the world around us.

And yet, I never tried programming myself. Never even tried to take a look at how it worked. But I am generally a curious person who loves getting into things and learning about them. So what happened there? How was it possible to be fascinated by programming for decades and not even try it out?

The reason, in my case, is what I call the "Hollywood hacker" stereotype. Those of us who did not come into contact with the reality of the field only have media stereotypes to go by. I believed that programming was the activity of an elite, a select few. People who attended exclusive universities and completed very expensive and long degrees. People who had privileged minds who could do superhuman feats of mathematical genius.

I now know this is not true. It's not based on reality. And I wish I had known that earlier.

I eventually understood that this was a much more accessible career path than I had originally thought. I followed a few YouTube tutorials, and got really excited about programming. I got serious about learning, and in 10 months did a career switch from an unrelated field.

It wasn't a walk in the park, it was a lot of hard work. Like any skill that we learn, it takes time and practice. But it doesn't take special powers. Here's the story of how I made that switch.

Now that I'm working as a front-end developer, I want to help others. I want to encourage those who are thinking about programming as a possible career but are not sure if they "have what it takes", or think there are obstacles that aren't actually there.

So let's explore together 10 things you do not need to become a programmer.

Prerequisites

These are the things that are rightly or wrongly connected with our popular image of what it takes to be a programmer. They are the kinds of things that are nice to have, and they can be useful.

Aspiring developers can dedicate time to attaining some of these skills. But none of them is essential to start, to learn, to get a job, or to have a great career in computer programming.

Be a genius. Be a mathematician.

This one is the most important myth to dispel – the myth of the privileged mind. There is no special thing your brain must have to become a programmer.

Programming is a skill like playing the guitar or running a marathon. You get better at it by doing it. By dedicating time and effort. By learning from others. It's a skill that you develop and grow the more you do and the more productive effort you put into it.

If you see a programmer who is capable of doing amazing stuff with a computer, it is always the result of dedicating time and energy into their craft. It's not some innate talent they were born with, or some divine inspiration.

Also, let's talk about math. Even though mathematics is at the heart of programming, you don't need it in your day to day work. The majority of programming languages used today for most jobs are high-level languages. These are closer to human languages than numbers, and don't need any special knowledge in math.

Programming is much more like writing than doing calculus. If you are good with math, it will help you solve certain problems faster. If like me, you didn't fall in love with it at school and never looked back, this won't be a hindrance.

Be a computer wiz

Programming requires you to write programs that run on a computer. You do so using a computer. It's the medium you work in.

But, you don't need to be able to build a computer from scratch by hand to be a programmer. You don't need to be able to understand the inner workings of a computer. Or be that person all your friends come to with their computer problems.

It's one thing if you use a car to do your job, but it's a different thing to actually be a car mechanic. Of course the more you know about your tool the more independent you'll be at tackling up and resolving problems. But you can be an effective programmer without first learning how to fix your aunt's virus-infected machine!

Have an elite university degree. Have a CS degree. Have any university degree.

A university degree is a great thing to have. It teaches you methodologies and investigation. It teaches you about your own learning style.

Being a graduate, if you are lucky enough to have access to a university, is a good thing in general. Being a Computer Science graduate is even better for programming. It gives you great depth and breadth of knowledge. An elite university will open doors and give you contacts.

However, none of the above is actually necessary to be a programmer. The field is packed with brilliant programmers who don't have a CS degree, or any degrees at all. If you put your mind to it, you can become a good programmer without any of it.

There are lots of different paths to becoming a developer nowadays. The traditional university route is only one of them. There are bootcamps that condense the essential knowledge into a few months of intense work. There's a wealth of online resources for those who want to go the self-directed route. This is a great option for people who need to continue holding a job while preparing the career change. And there are plenty of free or cheap options that remove the economic barriers too.

Have a state of the art computer or expensive software

This might be a bit silly. But for many people living in difficult economic situations, it means the difference between taking that first step or not.

I used to imagine that programmers needed the most advanced computer with the highest processing power since they are the ones who write the software and apps that run computers. I imagined that to develop software you needed specialized and expensive software. A bit like the toolkit needed by those doing design or video work.

So I was surprised when I followed my first tutorial and all I needed to build my first website was Windows's built-in Notepad. Notepad!! The humblest and most boring piece of software on any computer. A text editor that is as bland and basic as can be.

Well yes, you can do all the basic stuff on an old machine with no bells and whistles at all. One expects to have a good machine when working professionally. But as a learner, you can go very far with an internet connection and a basic computer that can run a text editor.

And besides, there are free versions of every tool you need to use along the way.

Be fluent in English

As with most of the above, being fluent in English helps. Programming languages were invented and flourished in English speaking countries. So for better or worse English dominates the field.

The words used in programming languages are English. And the majority of documentation, tutorials, articles, and resources about the subject are in English. So it helps a lot if you have a decent level of comprehension.

But, this shouldn't be the barrier that's holding you back from programming. You can learn and become good at it with an intermediate level of English. Many people get by only with being able to read and comprehend English.

Stereotypes

There are a lot of stereotypes associated with programmers in the public imagination. Now let's be clear, I'm not saying these stereotypes aren't sometimes real, or that they are negative in any way. Only that you don't need those to fit in.

Be a nerd. Be a gamer

Let me repeat, nerds are great, gamers are wonderful. But you can be part of a tech team without being either of these things. This is not the 90s – people of every style now work in the industry.

When you are looking for a job for the first time, the team you end up with is one of the biggest factors in your success. So finding a supportive team with a good atmosphere is most important. Far more important than the hobbies you might or might not share with the other programmers.

Be an introvert

Same as above. There is no particular personality type that is well-suited for this profession. Don't go looking for personality traits that might show you whether this is for you or not. Your attitude is far more important.

Being able to deal with frustration and persist is a key ingredient. And that's a learned skill, not part of a fixed personality.

Diversity

The following items are not stereotypes, they are statistics. Looking at the face of the industry as it is now, you might not see yourself represented. This might lead you to think that this is not for "people like you", however you identify yourself.

But our attitude should be the contrary. The lack of representation is all the more reason to get into it and put yourself out there. The industry has become much wiser about the importance of diversity in teams. Many companies and individuals are putting a lot of effort into making the industry more inclusive.

Be young

You do not need to be young to work in tech. You do not need to start young to be a good programmer.

I started learning at 39 and I was 40 when I got my first job. And there are people of every age group who have successfully made the transition.

It's never too late to learn. Never too late to change careers. Besides, a company that only wants to hire young people is probably not a good place to work for anyway. If you need some more inspiration, check out this story about developers who got their first tech jobs in their 30s, 40s, and 50s.

Be a man

This should be clear. But it has to be said. You don't have to be a man to be a programmer. And while men still make up the majority of programmers, this is hopefully rapidly changing.

Any company with insightful leadership has understood the importance of gender-diverse teams. It is not just good for "equality" (which is reason enough), but also gender-diverse teams make better decisions and are less likely to be biased.

Gender is not a factor in how good of a programmer you can be. There is no chromosome or brain configuration that is better suited. Programming is mostly about problem-solving. And we need as many perspectives as possible to solve a problem in the best way.

Be privileged

One of the things I loved the most when I first started learning to program was how democratic, open and inclusive the community is.

The programming world is filled with wonderful people. They dedicate time to help others become better programmers. They create resources and maintain open-source projects that benefit everyone.

Many groups and collectives are still underrepresented. Especially those who have historically been marginalized, or had difficulty accessing opportunity. But the community itself is much more welcoming and inclusive than it might seem from the outside. And it is continuing to change.

You may not see yourself represented in the popular images or the statistics about programmers. But this should not be a factor in being able to become a programmer. Your sexual orientation, your social class, your ethnicity, your disability, whether you don't live in the industrialized world, whether you are poor. These are all factors that are not a hindrance but a benefit. For the same reasons as mentioned above.

The greater the diversity of the team, the better it is at solving problems in a way that transcends biases. And that's always a good thing. And you can be part of the changing image of this industry.

Outro

I hope this article helps you in breaking myths about programmers and removing barriers to entry. I hope that if you are intrigued by programming that you give it a go. And if you find yourself excited by it and interested in pursuing a career that you will try it.

Ignore the self-doubt that comes disguised as one of these barriers that we think are in our way. Programming is complex and requires hard work. But everything about it is made up of skills anyone can learn if they persist.

Life can be tough and can put lots of obstacles in our way. The challenge is to react to these obstacles and find our way around them. So let's at least remove from our path all the clutter that isn't actually real obstacles.

If you know anyone who is thinking about whether programming is for them or have recently started learning, please share this article with them.

How about you? Do you have any other stereotypes and misconceptions about what it takes to become a programmer? Do you see things in the popular imagination about programmers that aren't true? Tweet me your comments, I would love to keep this discussion going on Twitter. Find me on Twitter and say hello.

My name is Syk and I’m a front-end developer based in Madrid. I career-changed into web dev from an unrelated field, so I try to create content for those on a similar journey. My DMs @Syknapse are always open for aspiring web developers in need of some support.

There’s a lot of important topics to learn as a developer. Algorithms, data structures, programming languages, there’s too many to count. That’s before we start on programming languages. Go is trending right now. JavaScript is the most popular language of 2018. 3 billion devices run Java (since the 90’s apparently). It’s hard to pick a language when you don’t know what it’s used for.

This article isn’t about these topics, because these are often taught at computer science schools and similar courses. This article is about the tools and skills that aren’t taught at schools and will make a huge difference when you get your first job. You’ll be able to apply these no matter if you end up being a web developer or a data scientist.

Git

Octocat, Github’s mascot

This is as much of a tool as it is a skill. Doesn’t matter what kind of developer you are or what language you use, you’ll use it almost every day.

Git is a Source Control Manager or SCM for short. In other words, it allows you to work with different versions of your code. Git provides tools that make working with many people on the same project a less painful experience.

If you’re working on a project by yourself it’s a great idea to use Git for many reasons. The obvious one is that you can store your code in the cloud for free. Many companies offer free public repositories, such as Github, Gitlab and Bitbucket. But if you’re working in a team odds are you’ll end up using Git sooner or later, so it’s better to learn it beforehand.

A great way to learn git is by using learngitbranching. The fact that it uses a visual canvas to explain how the commands behave is incredibly helpful. You can learn the basics in less than a day, but you’ll be learning new powerful commands for a long time.

Communication

_Photo: [Unsplash](https://unsplash.com/photos/ASKeuOZqhYU" rel="noopener" target="blank" title="). Pro tip: don’t scream at your colleagues.

A very underrated soft skill is communication. We developers are so focused on the tech aspects of our jobs that we often forget that to achieve great things we must work with other people.

There are many points to improve when talking about communication. I’d say one of the most important ones, for developers, is how to properly describe issues. You’ll ask someone for help eventually, and in order to receive actual help you’ll need to first describe what’s wrong.

Your coworkers are probably just as busy as you are, and probably have a lot going on in their heads. Do not drop questions like bombs at people, instead give context before asking for help.

Let me demonstrate:

DON’T DO THIS

Hey $coworker, the $service isn’t working as expected when I run $command, can you give me a hand?

INSTEAD, DO THIS

Hey $coworker, what’s up? I need some advice. I’m working with $service right now, because of $reason. It’s supposed to do $behavior to achieve $goal but instead it’s doing $wrong_behavior. I read the docs and I couldn’t find the issue. Since you’re more familiar with this topic, could you give me a hand when you’re free? Coffee is on me.

Coworkers are not always familiar with the subject you’re working with. More often than not are working on something unrelated to your specific issue. By being friendly and giving context before asking a question you’ll find that conversations run a lot more smoothly. You’ll get your problems solved faster too.

To improve on this try talking to yourself when you are facing a problem. Try to describe as much as you can about the situation at hand. Unconsciously you’ll do the same when you’re talking to someone else in the future.

Writing

_Photo: [Unsplash](https://unsplash.com/photos/Yi9-QIObQ1o" rel="noopener" target="blank" title=")

Writing code is easy. If your code isn’t working the machine will tell you. Writing for people is the true challenge.

Doesn’t take long when you start working to find that writing is a huge part of your job, I’d say as important as programming. You need it to document changes in your code, to send emails to coworkers, to define technical requirements and even to describe how your code works using comments.

Writing is about transforming your thoughts and emotions into words. When you write something you need to take into account the subject, the audience and the channel you’re using.

If you’re talking to a fellow developer it’s OK to be more technical. When you’re explaining how the system works to the marketing team words like callback and API might make zero sense. You’ll find that when sending a message how you say it is often more important than what you say.

This extends to verbal communication as well, but writing is much harder because when you write for big audiences, instead of a one-on-one conversation, you only have one chance of sending the message right. If someone doesn’t get what you mean at first, they don’t have an opportunity to ask you the same instant.

This is particularly important when you write code documentation and articles (like this one). It’s important to be as clear as possible to the audience you’re working with.

To improve your writing skills my advice is to write as much as you can about things you know and love and to read a lot. Always take some time every day to read about new tech, for example. You’ll not only improve your writing but you’ll learn lots of new things too.

Here’s a great article about this subject.

Conclusion

Developers often think that their jobs are about computers, and that’s as wrong as it can be. A developer job is about people, computers are just our tools. You create solutions that make people’s lives easier and better, and that requires a great amount of empathy.

If you ask me the most important skill to learn as a junior developer I’d say you should learn how to work in a group. All skills in this article help with that goal.

You might change your field of expertise in a few years. You might drop programming for a management position, but you’ll be working with people until you die. And being a team-player is much more desirable to employers than being a rockstar developer.

Thanks for reading my article.

If you liked it give it a few claps and connect with me on my social media.

What are some skills that you wish you had when you first started working?

Vinicius Marchesin
_Vinicius Marchesin — Frontend Developer_vmarches.in