Coffee break #43. 6 programming mistakes that prevent you from getting your dream job. How to Contribute to Open Source Software for the First Time

6 programming mistakes that prevent you from getting your dream job

Source: Medium To find a job as a programmer, you need to have a Git repository. This is one of the first things recruiters will look at. For your repository to make a positive impression, it should contain projects with recent changes. Only show projects you're proud of, not every line of code you've ever written. This is the basics of working with a repository. Remember that sooner or later someone will look at your code to see if you're a good fit for the company. This will be a decisive moment for you. After a few minutes, the recruiter will decide whether to invite you for an interview. And here there is both good news and bad. The bad news is that a simple mistake can hurt your chances of getting the job. The good news is that people usually don't want to dig deep into code. They need a general understanding of your code and architecture. So you don't have to be a genius - you just need to be a good programmer. Here are some common mistakes newbies make. Avoid them and your interview chances will increase dramatically.

Outdated comments

Programmers have different opinions about comments. Some love them, others hate them. We cannot come to a common conclusion about whether it is worth commenting the code and in what cases to do it. But everyone is unanimous on one thing: if you have comments, they should match your code. Comments exist to explain the code. When your code is complex or unclear, you need help for readers to understand it. Also you need to change your comment when you change the code. If you don't do this, your comment will no longer be useful. A bad comment is much worse than no comment. To make matters worse, comments are highlighted in the code. Modern IDEs highlight comments in a different color to make them easier to read. By adding a comment, you are placing a “read me” sign in the code. This way, any discrepancy between the comment and the code will be easily detected. Choose your comments wisely and remember to update them along with your code. This way they will serve you well.

Combination of libraries and languages ​​with the same use cases

Before the first interview, I had to solve a recruitment problem. It was a simple web app, so I wrote some code, Googled a few complex questions, and the app was ready. During the interview, the recruiter asked me why I mixed jQuery code with plain JavaScript throughout the code. My answer? “Umm...” To be honest, I pasted a few code snippets from Stack Overflow. I didn't think much about it. The code worked, so I moved on. This error is very common among new developers. We are so focused on solving problems at work that we don't pay attention to how we do it. Don't become one of the newbies who falls into this trap. Examine each line of code and make sure you know why you put it there.

Code repetition

Don't Repeat Yourself (DRY) is a programming dogma. Creating abstractions for repetitive code is the essence of programming. Yes, it can be difficult at first. When you want to solve a problem, you do it in any way possible. Then you move on to other tasks and the repetitive code stays with you. You can get rid of this habit by creating a set of rules for yourself. Every time you refine a feature, read the code again and see if there's anything you can do to change it. Remember that the first version of the code is usually wrong, and you can improve it. When you notice duplicate code, take the time to study it. This way you can figure out the best way to rewrite it (for example, using a loop or creating a new function). If you do this cleaning every time, you will end up with more reliable and elegant code.

Unhandled errors

It is almost impossible to create any meaningful application that will always work flawlessly. Whether you're populating a database or making API calls, errors occur. Unhandled errors can not only stop individual functions from running, but can even cause the entire application to crash. Anticipating possible errors is a sign of a competent programmer. Any time you access or update any external data, you need to be prepared for the worst-case scenario. Flag potential problems in a way that doesn't make the application unwieldy. This will allow readers of your code (and perhaps you) to quickly find errors. It will also show the recruiter that you can write cohesive code.

Lack of consistency

Consistency is the hallmark of quality software. It makes the code easier to read and maintain. Code created in a uniform style is more predictable, and it is easier to evaluate the program's performance. At a higher level of abstraction, consistency is difficult to achieve. It will take years to master it, so you need to start learning this technique as early as possible. Remember to create titles using only one language. It should probably be English, but in personal projects you can name variables and functions in any language as long as it's always the same language. If you're consistent, it doesn't matter whether you use tabs or spaces. Create or choose a style guide and always stick to it. You should also use a tool like Prettier . It really helps to keep the code formatted in a consistent way. Whatever tools and styles you use, use them consistently. Even if you write bad code in a consistent style, it's usually better than inconsistently good code because it's much easier to fix.

Misunderstanding of tools

In a typical project, you will probably have to use some external library. Many programmers install libraries almost automatically because they are used in every project. External libraries are great because they are a proven way to solve recurring problems. However, new developers often don't understand which libraries they are using and end up adding one library on top of another or re-implementing some existing functionality. Every time you install a library in your project, read or at least view the documentation. Check the methods and properties you can use and make sure you understand which problems the library should solve and which require using a different tool. This way you can choose the right tools for the job and explain your choices.

How to Contribute to Open Source Software for the First Time

Source: Jamestucker.dev The other day I saw a tweet from Evan Yu (creator of Vue.js ) about a new repository he was working on and it got me interested. I decided I wanted to contribute to it! The catch is that I've never contributed to open source projects before and didn't know where to start. But it can't be that difficult, right? Once I got into the repository, I immediately froze. “What the hell should I do?” I thought to myself. If I make a PR (pull request, merge request), specialists will probably tear my code to pieces. I will always be known in the development world as the guy who doesn't know how to work with open source properly. And my career will end. Fortunately, I read an article (I don't remember where) the author of which advised that your first contribution to someone else's repository should be as discreet as possible. This could be something as simple as correcting a typo. And so I did. I read the repository documentation, found a few typos, opened a PR, and lo and behold, Evan approved my changes. I'm officially a Vue contributor! Maybe I should put this in my Twitter bio?

"That's great, but how do I get started?"

Okay, let's get started: I'll show you steps you can take to make a difference.

1. Find a project

For inspiration, think about your favorite technology or tool. Let's say you work with JavaScript and use Gatsby a lot ? Check out their repository ! You can also contribute to one of my repositories. Here is a list of my frontend projects. If you have something you love or find useful, I'd love for you to add it! Finally, Awesome First PR Opportunities is a giant repository of open source projects for beginners. There are projects in 22 different languages!

2. Decide how you can contribute

Check out the project. Read the Readme. Scan different folders and files. Gain an understanding of the structure of the codebase. By doing this, you can easily find and correct the typo! Once you've done that, take a look at the Issues section of the project. There you will find a list of previously found bugs or suggested features. Fortunately, many projects involve problems that are geared toward beginners. I think your first contribution should be as subtle as possible, but if you want to gain recognition quickly, it's up to you. Once you find something that you can add to the project, you will need to fork it.

3. Creating a fork of the project

A fork (fork of a project) creates an exact copy of it in your own Github repository.

4. Clone the project locally

Then clone the project to a local folder using the project URL.

git clone <project-url>

Here you will find the URL. Now that the project is on your computer, open it in an editor. If you think changes will take time, be sure to sync a copy of the project with the original so you are always aware of the changes. You can find the exact Git commands for this here .

5. Create a new branch for your changes

It's time to make your changes/corrections! Create a new branch where your changes will take effect.

git branch <branch-name>

You can call it whatever you want, but in my experience you will be able to see a pattern for naming branches in the original project. In this case, I recommend following the existing template. A good branch name to fix the typo would be patch/typo-fix . You can switch to this branch using git checkout <branch-name> . Now make your changes!

6. Open a PR (Merge Request)

So you've fixed a glaring typo or updated a broken link. You take pride in your work. You want the whole world to know that you're one of those mythical developers who can code, erase, and watch Netflix all at the same time. Push your changes to a branched Github repository using git push -u origin <branch-name> . Go to your forked Github repository and open a PR (pull request). Note: If you've never done a pull request before, watch this video by Kent Dodds to learn how to do it. Make sure your branch points to the master branch of the source repository. Now you're ready to add details to your PR. Make sure your headline clearly conveys the content of the PR. Add a description: If you're fixing an existing problem, be sure to include a link to it. Once you're done with your description, submit your PR for review. Whoever has the authority to approve PR will likely review your application within a few days and do one of the following:

1. Will merge changes immediately.
2. It will ask you to make changes.
3. Will close your PR.

Please be patient as the repository creator may be busy with a full-time job or other projects.

You did it!

You are now a contributor to the open source project! How does it feel? Ready to build your own Node.js competitor? I hope that by making a simple contribution, the prospects for future open source work will become less daunting. For more information on open source contributions, check out the open source guides .