DEV Community: Steph

How to explain the benefits of code reviews to non-technical people?

Steph — Fri, 15 Jul 2022 10:54:44 +0000

One of the most powerful ways to improve or maintain code quality is proper code reviews.

But many teams face challenges from outside of Engineering to protect the time to do code reviews well.

Here’s how we would explain to a non-technical colleague why code reviews are essential.

First, you will lose engineers without a culture of mentorship and learning.

Engineers are among the most in-demand positions for all companies across the globe. COVID and Work From Home sped up the globalization of the talent market for engineers. As a result, companies need to invest in their Engineers aggressively. If you’re not actively building a great place to work, you’re on the losing end of the war for talent.

One of the ways to build a great place for engineers to work is to shape an environment that supports mentorship. Learning and exploring on the job is no longer a “perk” but a requirement. Engineers are deeply curious, and code reviews are a great way to facilitate a learning culture.

‍

Second, you will fast-track the effectiveness and productivity of new engineers.

If you hire new engineers or bring in third-party development shops and freelancers, you want to ramp them up as quickly as possible. Code reviews fast-track the onboarding process.

The difference between an effective and ineffective onboarding is six months or more of lost productivity. Unproductive onboarding means wasted financial resources and time, slower time to market, and ultimately, losing pace with your competitors.

‍

Third, engineering effectiveness and velocity will be lower without code reviews.

Your CEO will undoubtedly have heard the concept of “10X developers,” rare developers who are significantly more productive than everyone else. Whether or not that’s true, the idea of the 10X developer is informed by a substantial uplift in skillset – and so they are better able to contribute to the code and the team.

Think of code reviews as a means to 10X not one developer but many. It’s a great way – in our view, perhaps the best way – to continuously improve the quality of the entire team, not just an individual. This is because coding is fundamentally a craft, not a competition– a rigorous skilled activity that requires learning from more experienced experts and one that requires deep knowledge and concentration. The greater the investment in growth and learning, the higher their effectiveness will be.

‍Gartner says the productivity difference between low and high-performing engineering teams is 53%. To us, that estimate merely scratches the surface.

‍

How can the rest of the organization's non-tech employees, such as Product and Sales, assist in making code reviews more effective?

Trust the process

It can feel so urgent that a feature be added right now, or a piece of code pushed to production by the close of business. We get that.

But skipping the step of a code review almost always makes things worse later – and sometimes, not all that much later.

Trust us: no user is happier with a buggy version of the code than with a more complete version in the next release.

‍

Protect review time

The most essential thing that the rest of the organization can do is understand that code reviews are part of coding and time should be set aside in sprint planning and other kinds of work estimation.

As discussed above, code review “return on investment” is extremely high, and so organizations need to protect that time.

Organizations who estimate and plan engineering activities should include a buffer of 10% to 50% for code reviews beyond code writing, depending on the complexity of the code being written, the coder’s skill level, and the reviewer’s skill level.

‍

Cement its importance

The point above about formal recognition and or “consequence management,” is as true for the rest of the organization as it is for the Engineering team.

If the CEO celebrates feature completion, does the CEO also celebrate code quality, developer mentorship, and code reviews? Does the annual performance process reflect reviews too?

Remember, an ounce of prevention is worth a pound of cure. Investing sooner in code reviews through celebration and recognition means avoiding more expensive outcomes later like technical debt and developer attrition.

Tips for Code Authors for Better Code Reviews

Steph — Tue, 05 Jul 2022 10:21:06 +0000

Keep pull requests small

Try to keep the pull requests as small as possible. When a pull request requires more than three comments— and especially once it reaches five — it is usually a sign that the pull request should have been broken up into smaller pull requests.

‍

Be open to feedback

Remember, it can be just as stressful to give feedback as it is to receive it. Coding is a craft and it is hard to point out ways that someone else's hard work could be improved.

If you feel frustrated by the feedback you received, pause before responding – perhaps put it aside and go for a walk/sleep on it and come back to it the next day. Is there some truth to the feedback that was shared?

The more open and appreciative you can be with feedback, the more ideas you will get from others, and the more you will grow.

‍

Respond quickly – if you can

If you have a negative emotional reaction to the review, best to step away. As Oasis so eloquently sang, Don’t Write Back to a Code Review in Anger… or at least that’s how we remember it.

If you don’t have a negative reaction, deal with the review as fast as possible– answer the questions, make the changes, and ask follow-up questions.

Context switching is a killer for coding flow. The goal is to minimize the time spent for you and the Reviewer thinking about this review vs. other coding work. If you can reply to the review just after the Reviewer completes it, you avoid the mental effort later for both of you to get back up to speed.

‍

Switch to synchronous communication for any follow-up

Code reviews are usually asynchronous and can be completed thousands of miles apart.

In the Olden Days, when Dinosaurs kept using up the copier toner with jokes that really weren’t all that funny, a Coder could ask a question or a colleague by walking over to their desk.

Now we have many other tools, which are helpful up to a point.

Now it’s time for the sixth and final Golden Rule of Code Reviews (you didn’t think we’d forget, did you? If the code Author has a follow-up question to a code review, do it synchronously in real-time, not asynchronously. Pick up the phone, start a huddle, and walk over.

‍

The reason is context switching. At this point, there will be three moments of focused attention on the code:

1- Author writing

2- Reviewer reviewing

3- Author internalizing the review

‍

Asking clarifying questions about the review automatically means there will be a fourth moment:

4-Reviewer responding.

‍

The goal of synchronous communication here is to avoid requiring a fifth, sixth, seventh, etc. moment of attention.

How to Set Up a Team's Systems and Culture for Strong Code Reviews

Steph — Tue, 14 Jun 2022 08:20:54 +0000

Six tips for setting up a culture and system for strong code reviews on a team.

‍

Match the level of the Code Reviews to the context of your team and project

All software companies must take an intentional and structured approach to code reviews. Still, there is no "one-size-fits-all" approach for code reviews; it varies depending on the codebase, the company's size, and the team's preferences.

When a company is starting out, code reviews should look different than during rapid growth, or product maturity.

Here’s a quick guide to figuring it out for your team and development stage:

If a product is just starting to be built, at the earliest stages, such as during a hackathon or simplest minimum viable product, then code reviews are not necessary. At this stage, they only get in the way. The team should just figure out what functionality should be created and do their best.
After that stage, code reviews ramp up in importance. Early-stage companies might want to pick one person on the team to do all of the code reviews. This has the benefit of simplicity and speed but comes at the expense of a shared and varied learning experience.
As a company grows, more people should be performing code reviews. As a rule of thumb, all senior engineers should do code reviews when a company is in the rapid growth phase. In this phase, we are assuming that speed is still essential.
As the company matures, and as there is more capacity, code reviews should be carried out by seniors and mid-level engineers.
Finally, as the codebase becomes mature, and the team has more capacity, all engineers including junior engineers should participate in the code review process. Note that the juniors will not only need training, but their reviews will also likely need a second evaluation by someone more experienced. Here, a major goal of code reviews is as a teaching tool for junior engineers.
‍

Clear coding standards, readily available

Next, if your organization has documentation about coding guidelines or content specific to your code, make sure it is readily available and accessible to the code reviewers so that they don't have to search everywhere for what to include. See a discussion of linters, below.

‍

Give code reviews gravity

Make sure that code review work is as valued as coding — both activities should have equal weightage and visibility.

There are many ways to do this: from celebrating engineers who have done a lot of code reviews, to discussing code reviews at informal check-ins, to including contributions to code reviews as part of the annual performance process.

If code reviews are not important based on recognition, rewards, and other consequences, it doesn’t matter what is said on paper.

Do you have a “great developer” who refuses to do code reviews or refuses to act on feedback from others? What happens to them? That’s one of the clearest signals to the rest of the organization about how much code reviews actually matter.

‍

Psychological safety

Psychological safety is about colleagues feeling safe and trusted, knowing there is room for mistakes and that bad news can be shared, and generally feeling confident that the organization has your back. Studies at Google and elsewhere have demonstrated that psychological safety is one of the most important factors to make teams successful.

It makes sense– if you are constantly worrying about whether someone’s out to get you, you are going to be investing significant time and emotional energy in protecting yourself, rather than creating. And you’ll be suggesting far fewer ideas, or taking far fewer risks, that could advance the team.

Everything you are doing to work towards greater psychological safety in general at your organization and your team has applicability to code reviews, too:

Reduce the negative consequences of delivering code that needs to be fixed. We can’t say “eliminate” the negative consequences; after all, teams are here to build great code that meets requirements. But framing cost reviews as teaching moments, not judgment moments, make it
Regularly canvas the team, especially junior developers and others who might be worried they have less standing, to understand how the code reviews are making them feel.
Review a sampling of code reviews regularly across all reviewer-coder pairings, to look for positive or worrisome trends based on their tone and conclusions.
Offer training and support, not judgment, to colleagues who may need more training and support in creating code reviews that protect psychological safety.
Finally, we recommend that continuous violators of psychological safety, in code reviews and elsewhere, should be asked to leave the team. We don’t believe that any single coder or colleague is more important than making sure that everyone feels enabled to do their best work.
‍

Clear process

Make sure that the process for code reviews is articulated, clear, codified, taught, followed, and reinforced.

Especially while teams are dispersed, it might be helpful to have a “cheat sheet” of the basics of your code review process easily available – such as, pinned to the development Slack channel.

On top of that, the organization should be clear about when code reviews should be done and who should do them – see below.

‍

Fast turnaround

Code reviews are a responsibility that should always be taken seriously — and take first priority. Someone's first task is always to review other people's code before writing one's own.

The reason for that is that unblocking someone else's work makes others on the team more effective. If you are working on your code, instead of reviewing someone else's, then it becomes a blocker. If you review their code, then work on your own code, you are unlocking your team’s potential. Remember — it’s a craft, not a competition!

15 Steps to using Open Source to Advance your Career as an Early Tenure Developer

Steph — Tue, 07 Jun 2022 11:12:20 +0000

Pick the language you are the best at. If you're not at least an advanced beginner in a language work on tutorials until you get there.
Search for an Open Source project in that language - good places to look are https://github.com/stars/bdougie/lists/open-source-friday / or https://summerofcode.withgoogle.com/programs/2022/organizations
Pick 2 or 3 projects.
Watch all 2-3 projects for 1-2 weeks. See how people contribute, how they talk to each other. and read all of the documentation.
Based on that investigation, pick the one that seems most welcoming to you. Only pick one.
Introduce yourself in the proper channels. Follow the introduction instructions!
Read all of the open issues. Pick the one that you are most likely to do well. Work on that issue.
Meanwhile, if you see someone else ask a question that you know the answer to based on reading ALL of the documentation, answer those questions. "I think the answer is this [and add link]. Community, please redirect me if I'm wrong. *** helping in Open Source is more than coding, and this is a great way to ease the burden on the very busy Maintainers. ***
When you finish the issue, follow the protocol to get a code reviewer. Also, ask the appropriate channel for a Maintainer to double-check that you are following the correct process.
Repeat steps 7-9 at least 5 times, preferably 10.
Ask in a public channel, not privately, for an experienced Contributor or Maintainer to review your initial contributions to see what you are doing well and how you can improve.
Now that you've worked on 10 issues, work on 20, then 30, then 40.
Recommended: start reviewing others’ pull requests. Make sure you get advice from someone more experienced after your first one.
Recommended: along the way, keep a weekly list of what you did, and what you learned. here's a guide: https://www.semasoftware.com/blog/how-to-build-an-accomplishment-journal-brag-book
After at least 25 hours of contribution, but preferably 50, update your resume (that's what #14 is for), and ask on a general or career channel if folks would give advice on your job search. "I've been working on Community AA for the last BB weeks and have done XX issues, YY pull requests, ZZ code reviews. Would someone be willing to share tips on my resume and or organizations you know who might be looking for an Engineer with these skills ”

What do Open Source Maintainers want you to know about contributing to Open Source projects?

Steph — Wed, 25 May 2022 10:02:42 +0000

Focus

Pick a small number of Open Source communities to be a part of and make a real contribution. That’s way better than joining a lot of communities and not helping.

One Maintainer: “And remember everyone, while you can belong to multiple communities, I don’t recommend joining 100. I highly recommend joining two or three because you get different things from different communities. But don’t try and join 10 or 20, or 30, it just doesn’t work. It’s not beneficial to the community, and it’s not beneficial to yourself.”

‍

Read the documentation

Maintainers are doing their best to build documentation to make it easier to be an effective Contributor from the start. A quick way to earn trust is to read that documentation before asking a question. Maintainers are so busy that it is much better for them to work on things that help the many, not the one– and documentation is a great example.

Pro tip: Particularly like the documentation? Say thank you to the Maintainer(s), and explain why. It is always the right time to give a specific, positive, compliment.

‍

Learn in public

Learning in public means asking your questions to many people rather than one, privately.

The benefit for the Community is that your question might help other Contributors. And it saves time for the busy Maintainers, by letting them help many people at once.

Another Maintainer: “If you ask me a question, I’m going to have the same conversation with the next person. And so when you comment publicly, you’re literally helping those people as well. That’s why it’s so important to ask in public. It’s not just for you, but maybe 100 other individuals that are literally faced with the exact same problem. I guarantee you, if you’re having a problem, someone else has had the exact same problem. And by commenting about it publicly, you’re helping everyone.

“That’s why Stack Overflow exists. Do you think it exists for that one person’s problem that nobody else needs? No, we all find that same question to answer because we have the same problem. It’s the same exact concept here. Trust me on this.”

Pro tip: worried that your question might be too silly, or obvious, and you’re concerned how you might look? Ask it in public anyway and see what happens.

If members of this community are disrespectful, well, you have learned something valuable about their values– and it’s likely time to find a new community. I promise there are many great Open Source communities out there that would be thrilled to have your help and have you ask questions in public.

‍

Pick a community that is welcoming to new Contributors

Some Communities are better set up for newcomers. If you are just getting started, it makes a lot more sense to start with a community that is prepared to help you have a great experience.

Of course, I highly recommend EddieHub as one such community.

Other ways to tell? Go to another community and just jump in and start approving pull requests and asking random questions.

OK… that was a test to see if you read the previous sections. Never do that. ;0

The other ways to tell if an Open Source community is set up for newcomers is to read the Documentation, to see how understandable they are, and the issue list, to see if stories are clearly indicated that they are suitable for newcomers. If you love the topic of the code but it’s not clear how you can help, start helping somewhere else and then come back when you are more ready.

There are many exceptions, but in general, I recommend the Goldilocks rule. Beginner-friendly projects are likely not too big (like React) or too small (with only one Maintainer and a few contributors), but have a “just right” level of Contributors and Maintainers.

Pro tip: I recommend watching a community for at least a week to understand the flow of contributions and conversations — after you’ve read all the documentation — before you try to contribute. You want to start off on the right foot.

‍

If you are contributing code, create small pull requests

Each version control system (GitHub, GitLab, Bitbucket) uses different terminology for code reviews. For example, in GitHub, coders create a pull request once their code is ready for review. They may also identify one or more people to review the code, or a manager could select people to serve as code reviewers, or anyone can volunteer.

A code reviewer leaves feedback either for the pull request as a whole, or individually through comments. A single pull request can have 1–100+ code review comments but less is definitely more here.

It’s highly recommended to create pull requests small enough to only need 1–3 comments. This makes it easier for the Community and reduces the likelihood of blockers.

Another Maintainer: “As a maintainer, if you get a large pull request, is a lot of work. And larger pull requests do often get resulted in getting reviewed later, and maybe by fewer people. And that way, they end up with more conflicts, and it takes longer for them to get merged in.

“It’s really OK to think, ‘actually, I don’t have to add more lines to this pull request. If it’s two lines, but it adds value, then perfect. That can that can get merged in and then some other features and changes and fixes and improvements can all come in another pull request.”

‍

Remember there are more ways to help than just coding or code reviewing

I know when I started getting involved in Open Source, I thought it was only about contributing code.

But then I realized it can be so much more than that.

Here are some Maintainers’ tips on ways you can help that aren’t coding:

“But I think the easiest way to support people is if you see a question on any platform, answer it. Or even if you can’t answer it, point the person to someone who can answer it.”

“Just being available to other people is a great way of supporting it can be answering questions, it could be pointing out resources, it could be connecting others to each other as the small way of supporting people.”

“Documentation is a great way to help. There’s so much documentation and it’s so helpful to get help with keeping it up to date. It’s even helpful to volunteer to translate documentation into multiple languages.”

‍

Just make sure you are actually helping

There are many reasons you might choose to help with an Open Source community– for learning, for career advancement, to give back. Any of those reasons, and others, are good ones.

But you owe it to the community you are a part of to make sure your work is actually useful. Much better to make a smaller number of contributions that matter (see Focus, above) than spread yourself too thin.

And especially please avoid contributing for contributing’s sake– not only does it not help the community, but it can slow them down. And it doesn’t serve you well either.

Again, the Maintainer point of view: “One thing I’ll just caution people is don’t just try and make activity on your profile, because it creates a lot of noise for everyone else in the project and the maintainers. Writing “great” on everything, without even actually reviewing it, actually has a negative effect for your own GitHub profile, and the community as well. So just make sure what you’re doing is adding value.”

“Please don’t go approve a pull request that’s already been merged. It makes absolutely no sense. You’re adding value there. It’s merged. It’s been approved enough to get merged. And it just creates noise, not only for the maintainers. But for everybody involved in that discussion.”

Pro tip 1: spending a week watching the community before you try to contribute is a good way to calibrate what’s really helpful.

Pro tip 2: imagine one of the Maintainers is standing in front of you and you are explaining the contribution you made. Can you look that person in the eye and explain why your contribution is good for the community, and not just an activity metric for you? If yes, great. If not, find a better way have.

How can you be an effective Open Source Maintainer?

Steph — Thu, 12 May 2022 10:32:26 +0000

Now let’s talk about tips to be an effective Maintainer. There are seven tips here too. I promise that was a coincidence.

‍

Be ready for a lot of notifications

This is a great tip for first-time maintainers: you will get a lot of messages.

“Be prepared for lots of notifications. It can be a bit of a shock, especially if like a really enthusiastic person comes across your repository and makes a lot of issues or pull requests at one time. This is a good thing and it means that people are learning all the time. So go with it.”

‍

Make it easy for newcomers to get started

Writing clear and detailed documentation and having issues identified that are suitable for newbies make your community more welcoming– and save time for Maintainers, too.

Here are Maintainers on how to do this well:

“At EddieHub, we have a ‘good first issue’ channel, where people can pick up good first issues to get started. However, for people who are posting those links, just make sure they are good first issues, make sure they have steps for people to understand how they need to get going.”

“Make sure that your Readme has a really good quickstart guide so people can get started. It’s not just about how you clone a repo, there are many official sources for that. Make sure that you also cover the specific parts about your project in your repo rather than the stuff that people are going to find on finding the official documentation.”

‍

Be clear on documentation. Be really clear

It is almost impossible to make your documentation clear enough.

One maintainer: “Make sure you have like a really clear contributor files, saying like, if you want people to, for example, write the pull requests in a specific way, have it clearly explained in the contributor file so that people know how to contribute. And then there’ll be less back and forth.”

Pro Tip 1: Read your documentation out loud. Is it something you would say to another person? If not, change it to how you would say it.

Pro Tip 2: a great project suitable for new contributors is to have them pressure test your documentation. Have multiple newcomers read the documentation and see what questions they have. Then update the documentation to reflect answers to those questions.

‍

Be kind to contributors

Remember that these contributors are volunteers, who have chosen to spend their time helping improve your project. Repay their contributions with thoughtfulness.

This does NOT mean that you will always agree with their contributions– after all, a reason to contribute to Open Source is to get feedback to become a better coder or technologist — but share feedback through code reviews or other methods with a spirit of generosity.

Another maintainer: “Be kind to the people that want to contribute to your repository. Even if they do something wrong, it’s not out of ill will, they’re there because they want to contribute. Many of them are young, try to help them learn. And just try to be as kind as you possibly can. Because it’s easy to take things the wrong way in like a written message when you write back to someone in an issue or a pull request.”

‍

Encourage multiple code reviews per pull request

Code reviews are a magic method to help improve the code and help improve coders’ skill and knowledge. It’s not just about the code author, either– code reviewers frequently learn by reviewing.

And while one code review is good, two or three code reviewers can be even better.

One maintainer: “It’s always great to have multiple reviews. Pull requests with two or three reviews means there was a great (asynchronous) conversation and coordination, which helps the project.”

‍

Automate processes

The more that can be done to improve the code and core processes, the less work it is for the maintainers and contributors, and the more they can focus on what they can contribute.

One maintainer: “I would say automate as much as possible. So have if you’ve got linters, run them on GitHub actions. Not to take away from the collaboration or communication that you’re gonna do with the community, but focus that collaboration and communication on what matters more. There’s no point are we saying you’re missing a semicolon, your indentation is incorrect, you want to have that automated, and then you can discuss the more interesting and fun things.”

Pro tip: helping automate tooling for a community is another great way to contribute, whether that’s in the codebase or in the communication channels.

‍

Set clear expectations on time commitments and update them accordingly

This is the flip side of “Focus” for the Contributors. If you are a Maintainer, be realistic about what time commitment you can actually make, and meet that commitment. If the situation changes and you have to reduce the time, be upfront about that too.

As a Maintainer, people are now relying on you, and it’s much better to underpromise and overdeliver than having people wonder where you went.

One maintainer: “Don’t stress yourself out by thinking I have to dedicate many, many hours to this every week, because I’ve volunteered to be a maintainer. If you’re looking to be a maintainer on a certain site, and you don’t feel like you’re going to have the time, discuss that with the person that owns the repo in that case, just so that you don’t feel stressed yourself.”

Basics of Open Source

Steph — Wed, 04 May 2022 08:56:31 +0000

What is Open Source?

Open Source code is code that is accessible to everyone, and (almost always) is created and maintained at least in part by members of the public.

“Accessible to everyone” means a viewer only needs to create a user account on a version control system like GitHub, Once they do that, they can see Open Source projects.

The opposite of Open Source code is private code. To access private code, not only do you need a version control system account, but you also need an invitation to that private repository (code is stored in repositories, one or more repositories make up an application).

“Created and maintained at least in part by members of the public” means that not only can viewers view the code, but they can also make suggested changes such as features or bug fixes, and can review others’ code.

The Maintainers of the Open Source project– the leadership of one or more repositories– set out guidelines for Contributors of the code on how to write, propose and review code. There are almost always fewer Maintainers than Contributors.

Again by contrast, private code relies on a private group to maintain the code. Typically these private groups are employees of companies, government agencies, or non-profit organizations.

‍

Say more about what Open Source Maintainers do.
Open Source Maintainers are responsible for organizing Open Source projects.

This includes organizing the work of Contributors, including the processes for recommending improvements, adding proposed code, and approving that code. Maintainers can approve code (in GitHub, via reviewing pull requests), and Contributors can too, depending on the project’s guidelines.

But Maintainers do a lot more than that, too. To quote a few of the Maintainers who spoke:

“Being a Maintainer is not just about coding, it’s about finding issues that are really good, especially for first-time contributors to the repository. I try to sit down and go through the code and see if I can find good first issues on a fairly regular basis, so that I can help new people to get involved with our code.”

“Being a Maintainer often involves walking people through how to get started, or matching them to an issue.”

“I do a lot of code review as a Maintainer. I really like it because it helps me to learn how to code better as well, and helps me become a better communicator.”

Importantly, being a Maintainer can be more about working directly with the code:

“So, to me, being an Open Source Maintainer is very little about the code and very much about the community– creating a space where people feel encouraged to contribute, especially new contributors. It’s very important tome to lower the barrier to entry and create spaces where the community can support each other, you know, as a, as a maintainer.”

‍

What are examples of Open Source?
A neat example of Open Source code comes from NASA.

Here’s the link to NASA’s Open Source code: https://github.com/nasa

NASA has published 413 Open Source projects, some of which are combined to create applications.

One of the applications is Cumulus, which is used to collect information about the Earth’s atmosphere.

Pro Tip: it is incredible what code is available for exploration via Open Source. Go take a look!

You can that Cumulus is actively under development — there are changes made within minutes of this screenshot.

From here you can dig in and see that one repository within Cumulus, also named Cumulus, has 2810 finalized or rejected changes (closed Pull Requests) and 10 changes that haven’t been accepted yet (open Pull Requests).

From here you could jump right in and start code reviews or tackling issues…

… but you shouldn’t.

It’s always, always a good idea to fully familiarize yourself first with the project, to be respectful of the hard work of the Maintainers and Contributors who came before you.

For example, you should always read the How to Contribute Guides first, like this one:

How big is Open Source?
It’s huge, and it’s growing every day.

One estimate is that there are 180,000 Open Source projects.

And Open Source code is incorporated into many other projects. One recent estimate found that 96% of all applications included some Open Source code.

GitHub estimates that 19% of code contributions went to Open Source projects:

Open Source contributors and maintainers can come from all walks of life and are around the globe. 80% of Open Source contributors in 2019 came from outside the US.

Employees at RedHat/IBM, Google, and Microsoft are among the major contributors from companies.

What about the actual number of Open Source contributors? Answers vary, it’s not as easy to tell as you might think, A 2019 study estimated there are 7 million developers who are not paid for their work– not all of them are working on Open Source projects, AND many developers who are compensated for coding are also working on Open Source. So let’s agree it’s a very big number.

‍

Can anyone use Open Source code once it’s created?
Sort of.

It is technically possible to take any Open Source project and make a copy of it– that’s part of what it means to be Open Source.

If you want to learn and explore, it can make sense to make a copy of the repository and get to know it.

It is also technically possible to reference or use that Open Source code in another project, whether it’s Open Source or private.

Those are the technical answers.

However, there are also important legal– and in my view, ethical– considerations.

First, the legal ones.

All Open Source code comes with a license, which lays out how you are allowed to that code. Private code has licenses too.

These licenses vary substantially.

Some licenses are quite permissive– you can do whatever you want with the code.

Other licenses are commercial– you can only use the Open Source project if you pay for it.

Finally, some licenses have very particular requirements: if you use the code and share it, you are required to give away any code you create for free as well. This is called a “CopyLeft” license. Violations of CopyLeft can be a big deal for companies– such as lawsuits.

What does that mean for you?

First, know that there is no way to tell what kind of license it is just based on having access to it– you have to read the license.

Good news, if you are exploring the code to learn from it, there’s nothing to worry about.

If you are using the code personally– not just exploring it, but putting the code to work– then you need to read the license file. If it’s a commercial license, do the right thing and pay for it.

Pro tip: If you are at a company or organization that is using Open Source code, please check with your colleagues about setting up a proper approach to organize and vet the usage. Send your colleagues, or your company’s lawyer, this article. There is great software that can help.

Those are the legal issues. Let’s talk about the ethical issues.

Open Source code is only based on the community of millions of coders who make it possible.

Even if the license type is permissive, I believe all Open Source users, whether individuals or teams, have an obligation to give back to the communities who’ve created the code.

From my Scouting days there is an expression– leave a campfire better than you found it. This can apply to codebases generally, but it also applies to Open Source: if you use Open Source code, you should help make that Open Source code or other Open Source code better.

Thankfully there are many ways to give back to Open Source, and not just by coding.

As an individual, become a Contributor or a Maintainer to the code
As an individual, become a Contributor or a Maintainer for the community
As an organization, donate to Open Source projects that your company uses
As an organization, donate goods or services (such as your company’s software) to Open Source projects

OK, now that I’ve covered some of the basics, let’s turn back the discussion from the EddieHub sessions about Open Source.

The 5 Golden Rules of Code Reviews

Steph — Wed, 27 Apr 2022 09:27:24 +0000

Code Reviews have such a key role in the development process. In addition to saving valuable time and money, they also give a human-centric value to development teams. They are also a great tool for teaching and mentoring new recruits and an overall good practice big companies swear by.

But of course because of tight deadlines, sales expectations, and organizational pressures, some teams and companies are passing up opportunities to increase code quality.

Regardless of where your company falls on the spectrum of code reviews fandom, this piece will cover how you can (and should) use code reviews to help the development process and other aspects of the organization’s culture, and most importantly, give more value to your developers

Here are the 5 Golden Rules of Code Reviews:

There are five Golden Rules of Code Reviews. Some of them might sound familiar if you've been involved in training. And that's exactly right – code reviews are just one specific format of giving feedback in a particular domain.

‍

Always remember - it’s a human being on the other end of the review

The first Golden Rule of Code Reviews is simple: Review other people’s code like you’d like your code to be reviewed.

Code reviews should:

- Be kind– even if there’s room for improvement, the message can be delivered with empathy
- Be clear– make it easy for the reviewer to understand what you are saying. Importantly, if you have constructive feedback to give, be direct about it. Avoid a “crap sandwich” that starts with positive feedback about the code, even if it’s genuine, before getting to your suggestion for improvement.
- Be specific – The more granular your feedback can be, the more helpful it is to the Author.
That can be hard to do when so many of us work remotely or hundreds or thousands of miles away from each other.
To make sure you are communicating correctly, read your code review to yourself out loud and ask yourself, is this something I would want to be said to me? If not, think about changing the tone or content.

‍

Give clear suggestions or recommendations

Never tell someone that the code needs to be fixed without giving suggestions or recommendations on what to fix or how to fix it.

Not sure why? Imagine someone came to your home and said, “I don’t like your decor. Fix it.”

It is incredibly annoying.

It is never a good idea to write “Fix this” without giving more explanation. Why does it need to be fixed? What suggestions do you have to fix it? How might someone figure it out?

On behalf of the Code Review powers, we will personally come to your home to rap your knuckles if you ever leave a code review that only says “Fix this” or “Do better.”

‍

Always assume good intent.

Code may not be written how you would write it. Let’s say that more clearly: code is rarely written the same way by two different people. After all, code is a craft, not a task on an assembly line.

Tap into a sense of curiosity and appreciation while reviewing – curiosity to understand what the reviewer had in mind and gratitude for what the Coder did or tried to do.

‍

Clarify the action and the level of importance.

If you are making an optional suggestion, for example, a “nit” that isn't necessary before the code is approved for production, say so clearly.

If you wonder why the person made a particular choice, but it doesn’t affect whether the code should make it to production, say so clearly.

If you are confident that the code needs to be fixed before it is ready for production, say so clearly.

Pro tip: When writing, we frequently think that our intent is clear. After all, we know what we are trying to say. But remember that our writing may not always be as clear to the reader as it is to us, and make sure that your most fundamental guidance is plain and straightforward.

‍

Don't forget that code feedback – and all feedback – includes praise.

It goes without saying that the key benefit of doing code reviews is to make the code better and fix issues.

But that's only half of it. On the flip side, code reviews present an excellent opportunity to thank you and appreciate your colleagues' work.

If someone has written particularly elegant or maintainable code or has made a great decision about using a library, let them know!

At Sema, we say it is always the right time to give positive, specific feedback. But, of course, we walk the talk when it comes to code reviews too.

Find out more about the ins and outs of code reviews and their impact on company culture in our whitepaper: www.semasoftware.com/blog/code-reviews-101-the-basics