DEV Community: Markus Hatvan

How I Raised My Hourly Rate by 78% in My First Year as a Web Development Freelancer

Markus Hatvan — Sat, 20 Nov 2021 09:08:37 +0000

Many freelancers struggle with the question of how to raise their hourly rate. One of the main reasons why self-employed workers are hesitant to increase their rates is because they are afraid that they will scare away potential clients. This fear often comes from a lack of confidence in themselves and being able to articulate what sets them apart from other skilled freelancers. As the freelance market is getting more competitive, it is becoming harder for freelancers to ask for higher rates without providing good reasons to do so.

An important question to start with is “are you charging enough for your services?”.

There are many great ways of how you can begin building your confidence and showing your clients why they should pay you a higher hourly wage. This can be done by making small improvements in your workflow. Since COVID-19 massively sped up the digitization process for companies, currently there is an abundance of businesses who are looking for web development professionals, no matter the experience level.

If you are just starting out in your freelance career like I did at the beginning of 2021, the rest of this article will share some of my best advice on how I was able to raise my hourly rate by 78% in one year:

Generate multiple sources for incoming project offers

When you start out as a complete newbie in the freelance industry without any business connections, it is most important to find a variety of channels that can provide you with project leads. This is crucial because once you have multiple interesting project offers available to choose from, you will automatically learn how to bid for jobs more effectively and stay relaxed during the interview process.

To find potential clients, I researched and found websites where companies in my target market (Switzerland, Northern Europe, USA) were looking for freelance workers. Nowadays, it is easy to find remote positions across the globe, so you are not restricted to the country you live in. Think globally!

I talked about my process of winning new clients in detail in my previous article about How To Win Your First Clients as a Freelance Web Developer, and I can tell you, it was a lot of upfront effort that luckily paid off in the end.

Keep talking to recruiters even when you are fully booked

Although it is better to sign a deal with a company directly, you will usually have to go through some intermediary like a recruitment agency or freelancing platform. Many of the bigger and more prestigious companies completely outsource the recruitment (and billing) for independent contractors, so you wouldn't have a chance to get in contact with them anyway except through these third party agencies. The recruiters usually cooperate with many companies in parallel, so it makes sense to stay in contact and respond when you are receiving calls or emails from them.

Whenever I was contacted if I was available for a project, I would ask for basic information like the projected duration of the project, hourly rate, tech stack and more, even though I was already busy with a project and didn't plan on taking on a new one. By regularly staying in touch with the recruiters, you can get a better feel for the most in-demand skills in your area and which companies are offering to pay for it.

Update your online freelance profiles regularly

This is probably one of the key aspects to keep in mind when trying to achieve a higher hourly rate. Whenever I had a bit of time available, I made sure to go over all the freelance platforms where I registered and update them regularly. It is tedious at first because you never know if someone will actually discover your profile, but it is definitely worth it in the long run.

In my case, I was lucky enough to get contacted by the co-founder of a new invite-only freelance platform who found me through Remote OK. I didn't even know that they existed, so that provided me with a great source for high value project offers.

Showcase your passion through an active GitHub profile

It is not a hard requirement to work on web development projects outside of your work, but it definitely helps to be able to showcase a GitHub profile with reasonable activity. Opening issues, fixing bugs and adding new features to open source libraries shows that you are passionate about web development and that your code contributions are of high quality to others. The social proof of having contributed to well-known companies will improve your intrinsic value as a freelancer immensely, and you will be able to ask for better rates.

Lifelong learning and training is the way to go to be highly successful.

Move on to the next project regularly

As you can see in the graph above, I have switched between projects quite a bit. This was an important factor for raising my hourly rate quickly, since it was unclear at the beginning how to estimate the value of my services without any prior clients. I recommend setting the initial hourly rate based on the median rate that is common in your area.

It might sound a bit harsh at first, but as a full-time freelancer you are not a permanent employee and therefore a long-lasting cooperation with the company is also not expected from you in the first place. Don't make the mistake of relying on a single client and then sticking around with them for years. It can be quite comfortable to have a client that provides you with a steady income, but whenever you receive a better project offer than your current one, brainstorm if it would be worth the hassle of switching.

You will definitely have an easier time increasing your hourly rate if you decide to choose a new project rather than asking for a raise at the current one. As a rule of thumb, I like to pick a new project every few months, but this is entirely up to you and your desired growth rate as well as relationship, satisfaction and success with a client.

Note that since you are part of the external workforce of a business, you should also be aware of the fact that you could get kicked out of a project at any time as well, so this can go both ways.

Pick a project that can advance your skill set

You might disagree with me on this one, but I believe that it is better to offer a broader skill set in the market of web development rather than to become highly specialized in one topic. Whenever I decide on a new project, I take a good look at the tech stack that is used and other facts, rather than the hourly rate alone.

With this in mind, I have recently been able to add modern and in-demand technologies like Next.js, Playwright and Electron to my skill set, which improves my value to potential clients, and it is also always great fun to learn new skills.

I started bidding on jobs that were at a higher level than what I was comfortable with and slowly increased the complexity of the projects that I took on. In the end, I was always able to keep up with the pace. In the worst case, I would need to learn a bit in my free time to be able to get up to speed with the project.

Try to move on from every client with a positive impression

Once you've made a successful pitch, make sure you do everything you can to make your client happy. If they are satisfied, they will be more likely to hire you again for any future projects. You never know which business connections can come in handy at a later stage in your career.

Oftentimes, it is not simply about having great skills in your freelance position as a software developer, but clients also want to cooperate with a freelancer who is reliable, feels connected with the project at hand and has a good eye for design and user experience. Specifically small businesses use word-of-mouth advertising and could provide you with an unexpected follow-up client.

Conclusion

We should all negotiate for higher rates in our careers as freelance business owners whenever possible, or we will find ourselves working for lower rates than we deserve. With a decent annual income, we can improve our work-life balance as well as spend newly-found free time with friends and family or focus on other productive tasks.

The market demand for freelance services is there, so build up the confidence, go ahead and make the most of it! I hope that you can take my advice to heart and apply it! Let me know if there are any open questions left or explanations to add.

How To Win Your First Clients as a Freelance Web Developer

Markus Hatvan — Tue, 19 Jan 2021 13:41:09 +0000

After working as an employee for different companies during the last four years, I am finally doing it and becoming my own boss!

It is certainly a challenging adventure to switch from the secure and predictable path as a member of a company working at a full-time job to running your own business with all of its complexities and requirements.

As a newbie web development freelancer, you will often have to ask yourself this one most daunting question in the beginning:

How Do I Even Find a Promising Client if No One Knows About Me?

Although I didn't start as a freelancer officially until January 2021, I was already able to establish myself on the market and win multiple international clients two months prior my start as a sole proprietor. As the cherry on top of this, all these projects were built on a modern tech stack and included fun and challenging tasks throughout.

Instead of relying on a single source for fresh freelance project leads, I tried out various possible ways of finding new work opportunities, some of which work efficiently and others that don't. As a successful freelance web developer, it is especially important to spend most of the time doing actual paid work and to avoid unpaid side tasks like looking for a new client.

In this article, I want to show you what I learned so far about promising ways to find potential clients for your freelance web development business.

Talk to Your Network of Peers, Friends and Family

Before searching for project offers in any other way, try to leverage your network and reach out to your connections. Interesting leads and project offers that you receive through word-of-mouth have one big advantage: the prospective clients are introduced to you through social proof and are more likely to consider you than if you had contacted them through cold outreach.

Always ask the client for follow-up projects or referrals to other potential clients to keep the flow of projects going whenever you finish a project. The social proof of getting recommended can work in your favor again. Additionally, don't forget to demand a testimonial from a happy client that you can put up on your website to improve your credibility and market value.

Receive Inbound Offers From Recruiters on LinkedIn

You might think like me that social media is a waste of time, but there is one exception: LinkedIn works like a charm for potential offers and work-related connections. You can create a good profile for yourself, put the "open for work" label on it, then lean back and wait for the offers to come rolling in to your message inbox. There were certain days where I got five offers in 24 hours, and I am not even updating my profile or posting much content for improved visibility.

Unfortunately, a lot of times recruiters will just spam their standard phrases and send you offers for permanent positions. It might be annoying to you and your first intuition is to not respond to them, but I highly recommend you to do so! I usually thank them for their nice offer and tell them that freelancers are only interested in project-based offers, but if they ever have something that could be relevant to me, they should get back at me. Because as a matter of fact, most recruiters and software agencies have both jobs and freelance projects to offer. It happened more than once that the recruiter sent me a different offer or invited me to sign up for a freelance developer talent pool at a company. You can also shortcut the process and go to the company website of the recruiter, check for project offers that are relevant, and bookmark them for later use.

Get Approved on Curated Freelancing Platforms

There are a lot of them out there, and it's not easy to separate the good ones from the bad ones, but two of the freelance platforms that I use most are ExpertLead and Gun.io.
Expertlead requires an initial get-to-know interview, a short project showcase, and a coding interview with a peer freelancer to become a member. On Gun.io, you will have to set up a nice profile, including a short video introduction, and pass a test of three different algorithm coding challenges. After you get accepted, both can deliver interesting and relevant projects on a regular basis for you.

One of the most well-known freelance platform that I haven't applied to yet is Toptal. Their time-consuming multi-step process and the strict vetting of allowing "only 3% of top talent" in - according to their marketing - kept me from trying to get accepted so far. Still, Toptal has a very good reputation in the industry and will be able to provide you with a steady stream of high-value clients.

Browse Job Boards the Old School Way

If you decide to search for freelancer offers on job platforms, you have the advantage that you can cut out the middleman in a lot of cases. This could be a recruiter cashing in on a successful hire or platform fees like Upwork or Fiverr have, which might result in a lower hourly rate.

The job boards that I found especially helpful in regard to finding freelance offers were Glassdoor, We Work Remotely, Stack Overflow, LinkedIn and AngelList.

One issue that I found with a lot of job platforms is that they are lacking useful filtering options to easily discover project-based work. Additionally, it is hard to tell from a lot of job descriptions if they are supposed to be for a person looking for a permanent position or a freelance contract.

Use Lesser-Known Ways of Finding Qualified Leads

It can be a hit or miss, but holding a presentation at a meetup or conference can lead to unexpected offers and connections. Especially after the presentation of the talk, it can be the perfect opportunity to mingle with the crowd and to get into contact with prospective clients who saw you on stage.

Another way to find potential clients is to simply search on a messaging services like Twitter for a term like "freelancer wanted", and you will get a long list of past posts by users.

The same trick works for Facebook: there is a huge selection of worldwide Facebook groups for job seekers and freelancers. Try to keep away from the ones with large numbers of members though, because they tend to get spammed with low-quality content and they have too much international competition.

If you don't want to lift a finger to find freelance jobs, simply lean back and enjoy the service of a website like RemoteLeads, which scrapes thousands of sources and delivers the best matching projects right into your mailbox. It works like a charm. If you know of any similar services, let me know.

Another rather underground source for projects is the website HN Hiring, which aggregates all posts from the monthly Hacker News thread "Ask HN: Freelancer? Seeking freelancer?" into a useful listicle.

If you like to work with startups and smaller businesses, you can take a look at job-related groups on Indie Hackers or join Slack groups for freelancers.

In case you are passionate about a certain programming language or software tool, some of them have Discord channels which have a distinct #jobs channel for offers.

You have to get a bit creative with your thinking but there are a myriad of ways to find business owners who desperately need your services.

So How Did I Find My First Clients?

With my four-plus years of experience in web development, code contributions in well-known open source projects, and technical articles released on big web development publications, I would say that many recruiters and HR departments of companies would be interested to get me on board.

Since I made sure to collect all project offers in bookmarks, I can provide you with an exact breakdown of the numbers and how the customer acquisition funnel worked in my case.

Between October 2020 and January 2021, I spent endless hours searching for clients:

I bookmarked ~65 different websites as sources for finding freelance offers.
I applied to ~45 projects found on websites like HN Hiring, We Work Remotely, Computer Futures, Freelancermap, Gun.io, GitHub Jobs, LinkedIn, and many more.
I received a response from approximately 20 projects regarding a cooperation.
I had a total of 11 project interviews through remote calls.
I ended up with four international customers which will provide me with projects regularly.

Although I have such a large amount of different websites and sources for finding clients, in the end, it turned out that:

I found two of my clients through the Svelte Discord #jobs channel
One client found me through the Austrian job center database and approached me per mail
Another one re-engaged me due to a Issuehunt bounty that I solved a while ago.

Wrapping Up

No matter how good your skills, your portfolio or your references are, there will be a lot of unanswered emails, turned-down offers and disappointing client decisions until you will be able to secure your first customer. After all, it's a numbers game, and landing clients without prior connections can be hard. But it doesn't have to be.

When you start looking for your first project, use the great variety of sources and tools out there, from word-of-mouth advertising to inbound project newsletters. Try to think out-of-the-box and you might discover new ideas about finding businesses in need. My experience was that there are a huge amount of freelance web development projects out there; they are just hard to find.

Make sure to set useful bookmarks on websites, with the correct filters applied, to save you time. You can find a sub-selection of websites that I bookmarked with freelance filters enabled throughout the article.

With the right steps, you will find a company to work for in no time. Always remember: one long-term client can be enough to bring in enough money for the whole year and make you a successful freelancer!

Reclaim Your Data Privacy From Big Tech With the Best Privacy-Focused Alternatives

Markus Hatvan — Thu, 14 Jan 2021 10:48:15 +0000

The frequent data leak scandals caused by big corporate companies is a real reason to be concerned about misuse of personal information through illegal (and legal!) data collection practices. These scandals are leading users away from using mainstream products to finding safer alternatives.

Have you ever worried about your data privacy? Are you wondering if there are any alternatives to the Big Tech services out there?

Luckily there are great alternatives available that can allow you to take your data privacy back into your own hands. Although there are many, finding viable replacements to mitigate your privacy risk without much hassle is a time-consuming effort. I will explain how I switched different services myself so you don't have to start your research from scratch.

Why should you care about online privacy?

The most obvious reason is clearly to avoid being tracked and to keep your personal information safe.

Additionally, you probably don't want to maintain and encourage the status quo that only a few tech companies have a monopoly over the entire software market. It is much more rewarding to support multiple, smaller companies with ethical practices in mind and to help them flourish.

Supporting smaller and more underdog tools has another useful advantage: You will more likely be heard whe you request a new feature. Many of these are also open source, which means that the program has its source code available to be examined by the public. This is usually a good sign that the company is transparent and trustworthy.

Privacy hardliners will always find something in recommendations like the ones below to critique, and many will even know how you can be even more secure on the web. But the choices below include stable, mature, and free-to-use services that I’ve found to offer an acceptable trade-off between user experience, privacy, and convenience.

Google Search alternatives

This is probably the hardest switch you will have to make - at least it was for me. The search results and meta information (store opening times, movie ratings, weather forecasts, and more) that you receive through Google Search are often unbeatable.

I tried privacy-friendly search engines like DuckDuckGo, Qwant and Ecosia for a while, but they often didn't give me the results that I was looking for. Especially when querying for programming-related search terms, I often found myself receiving unrelated search results. When you are getting paid per hour as a freelancer, that is impractical as the additional time required to search more precisely can add up quickly.

Fortunately, I found out about StartPage which I have been using for about six months now. According to the privacy policy of StartPage this is how they operate: "When you search, your query is automatically stripped of unnecessary metadata including your IP address and other identifying information. We send the anonymized search query to Google and return the search results to you. We don’t log your searches."

So when using StartPage, you basically use the capability of great search results from Google without getting tracked. I don't really like the fact that I am still using Google under the hood, but this is the best solution available for me for now as I am receiving good quality search results again. I sometimes do still miss the meta results that Google provides like store opening times, movie ratings and weather forecasts, but usually, it just requires an additional click on a search result in StartPage, which is manageable.

My recommendation: If you need to dig deep into a certain topic, use StartPage to get the best results or fallback to Google Search - otherwise, you can get great results by using Qwant as your default search engine as well.

Google Chrome alternatives

According to statcounter, Google Chrome is used by approximately 66% of the population worldwide as of October 2020! Although I don't disagree with the well-deserved popularity of the browser due to constant and innovative updates by Google, it's always scary when a corporate company has such a monopoly and lack of competition in a business sector as Google Chrome does.

If you look for a privacy-focused browser alternative, I can recommend Brave Web Browser. Brave has a built-in ad blocker, automatic HTTPS upgrade, and it blocks autoplay, and you can support content creators through its own built-in BAT cryptocurrency. When I decided I would like to switch to Brave, there were some issues with syncing extensions and bookmarks across devices which kept me from using it for a while. Since then, they have fixed these issues and now it's a flawless and enjoyable experience.

Another great alternative would be Mozilla Firefox, I personally don't use it because I prefer the look and feel of a Chromium-based browser.

If you decide for a browser that comes without a built-in tracker and ad blocker, make sure to install a browser extension like uBlock Origin to do the blocking for you.

Google Maps alternatives

Your location data is very precious and you shouldn't have it exposed and possibly let it get into the wrong people's hands.

Getting rid of Google Maps is really hard and it took a lot of research to find reasonable alternatives. Most of the time, similar navigation applications only support some forms of transportation, but not all of them. There are only a few privacy-focused options that support bicycle, public transportation and on-the-go navigation, which are relevant to me. Finally, I ended up using a combination of multiple services.

For all means of transportation, HERE WeGo is a solid choice for desktop and phone. It was originally developed by Nokia and is now owned by a handful of German automotive companies, which does worry me a bit, but I haven't found any bad press on it so far. Alternatively, I also liked Sygic Maps. The interface looks very user-friendly and displays places of interest in your area.

For commuting per bicycle - which is my main form of transportation - I am using Bikemap on my desktop and phone. Since the application is specialized on bike navigation, it gives me the fastest routes.

Other alternatives for desktop that I tried and might work for you include Qwant Maps, OpenStreetMap, OpenRouteService, and BenMaps.

On your phone, you could take a look at apps like OsmAnd and Transportr.

Microsoft Office Suite alternatives

Switching from Microsoft Office Suite to LibreOffice is quite easy in my opinion. As long as you don't need any fancy advanced functionality, you should be fine.

LibreOffice works with the .odt file extension by default - but don't worry, it also has compatibility with .docx files in case you are opening a file created by a Microsoft Office user. I have been LibreOffice Writer and LibreOffice Calc on a daily basis for multiple years and don't feel limited in any way.

Google Gmail alternatives

Using another service than Gmail shouldn't be that hard. I personally never liked the user interface of Gmail and I guess I am not the only one.

As a solid alternative, Thunderbird is a reliable and mature email client that has worked flawlessly for me for a long time. Unfortunately, there is no app for Android or iOS, so I am using Spark for that on my phone.

If both email clients don't seem like the optimal choice for you, you could also take a look into ProtonMail, which is an end-to-end encrypted email service located in Switzerland and therefore adheres to strict privacy laws.

Services that I still want to switch

Since the needs of the modern world require so many different software tools, I am also still using some services from big corporations that don't have data protection high up on their priority list.

Google Calendar is deeply embedded in my everyday life. With a total of 8 different calendars and ongoing collaboration with multiple other people on calendar entries, it is very hard to find a worthy replacement for this application.

I also wasn't able to find any useful YouTube alternatives that worked well. Other video platforms like Vimeo or BitChute just can't compete with the amount of content that you can find and enjoy on YouTube. If you know a real competitor let me know; I would love to try it.

My personal website currently uses Google Analytics simply because it was fast to set up. Shame on me. There are plenty of viable privacy-focused alternatives like Matomo, Plausible or Umami out there that I plan on investigating at some point.

Facebook had its fair share of bad press in the past like the Cambridge Analytica data scandal, for example. Notorious for its invasion of privacy and data misuse, I still can't let it go due to its amazing groups and events features.

I would love to switch from WhatsApp to a more secure chat application like Signal or Telegram entirely, but that would require every one of my friends and family to use these platforms too, which is not the case. Improving your data privacy is usually inconvenient, so I don't expect that to happen anytime soon.

Conclusion

Moving away from popular and well-established services by the likes of Google and Microsoft is very difficult. The ease of use and the quality of their applications are simply superior to most other choices out there. Since they always come with a free tier, we are paying with our user data at the expense of our individual privacy.

With plenty of privacy-focused tools and alternatives like LibreOffice, Thunderbird, or StartPage on the market, you can take a step in the right direction of combating tech monoculture and increasing your user privacy.

If you liked the small selection of tools that I mentioned above, you can find a more comprehensive list of carefully picked services on my dedicated recommendations page. For a huge list of alternatives, you can also check PrivacyTools or degoogle, which continuously update their lists when company acquisitions occur or privacy policies change. I am sure you can find great services that you weren't aware of before to expand your current choice of software tools.

Thank you for reading! I hope this article has been helpful to you, let me know if there are any open questions left or explanations to add.

Helpful resources

8 Common Web Development Mistakes And How To Avoid Them

Markus Hatvan — Thu, 19 Nov 2020 15:40:46 +0000

I recently joined a small startup where I helped create and deliver a web application for an important clinical study which focuses on COVID-19. The only problem was: the deadline for the project was in two weeks time! That alone already sounded scary and stressful, but I decided to accept the challenge!

On top of the looming deadline, the junior developer who was mainly responsible for leading the project, was understandably overwhelmed with the enormous workload. As a result, the code output was rushed and was a complete mess. The scope of the project was simply unrealistic for a team of two developers to manage in such a short time span.

In the end, the minimal viable product was deployed and working with minor hiccups, but it now requires a major overhaul and refactoring effort due to the messy way the code was written. It’s a daunting task that will require a lot of time but won’t lead to any additional revenue for the company.

This could have easily been avoided from the beginning if the project had been set up correctly and used some best practices.

After working on many diverse projects, I have created my own list of “must-haves” to ensure a successful project and great developer experience.

To save you valuable time on your web development projects in the future, make sure to avoid these eight common web development mistakes:

1. Not enabling code quality tools right away

This should always be one of the first tasks on your to-do list when you begin working on a new project. Make sure code quality tools are in place based on the project’s needs, you will be grateful for it later.

When I joined the aforementioned project, nothing was set up and the code was inconsistent with mixed up usage of quotes, missing .catch() blocks and various formatting issues.

ESLint will save you from producing errors like these, which could have been prevented in the first place. After running a lint script on the project for the first time with an opinionated configuration, there were 200+ warnings and errors waiting to be fixed. Fun.

I know, I know, it can be hard to make the configuration work exactly as you need it to. Additionally, the project owner wants to see actual results and doesn’t care about you spending precious time configuring development tools. But it is such a worthy time investment in the long run and shouldn’t be delayed. In the end it will make you even more productive when you have a project that is clean and error free, which is beneficial for everyone.

I recommend using all or some of these packages for your configuration depending on your needs:

eslint or @typescript-eslint for a base rule setup
eslint-plugin-import for clean and ordered imports
eslint-plugin-jest for writing better and stricter unit tests
eslint-plugin-node for backend development and supported node version feature checks
eslint-plugin-promise for avoiding missing .catch() blocks and other bad practices when working with asynchronous code
eslint-plugin-jsx-a11y for writing accessible code in case you use React
eslint-plugin-unicorn for miscellaneous helpful rules

On top of the recommended configs that give you a base rule setup, I add additional rules like: eqeqeq, prefer-template, prefer-const and no-var, which are not included in the recommended config out of the box.

Apart from avoiding nasty bugs and writing bad code, you can also gain an incredible amount of knowledge by simply following lint suggestions and looking through the ESLint documentation on why a specific rule exists and why it is necessary.

On the other hand, Prettier will make sure that the whole team conforms to the same stylistic code formatting guidelines and the achieved readability will save you time as well. The default configuration settings provided by Prettier out of the box are great, so I usually only have to do minor tweaks. This is a minimal .prettierrc.json configuration file that I tend to start with:

{
  "printWidth": 100, // default is 80
  "singleQuote": true, // default is false
  "trailingComma": "all" // default is "es5"
}

After setting up ESLint and Prettier, you have a solid baseline of code quality tools in place which will greatly improve your developer experience.

2. Using outdated dependencies

Various packages of your project are multiple major versions behind. The package.json dependencies haven't been upgraded for more than a year. You could delay upgrading and hope you never have to. But believe me, you will as soon as support for that old Node.js version drops or when there are new code vulnerabilities discovered in the old dependencies that you are using. Additionally, you would love to use the latest features of a library, but you can't because you are stuck with an old dependency version. Sound familiar?

Whenever I create a new project or join an existing one, one of the first things I do is check the package.json for outdated dependencies. Make sure that the dependencies are at least somewhat up to date to have potential bugs and security vulnerabilities in your 3rd party libraries fixed. For existing projects, ask the main responsible developer if there is a good reason why the dependencies are not up to date.

I personally create a dedicated package.md file in projects that I work on that looks like this:

# Dependency upgrade issues

## "postcss-cli": "^7.1.2"

Major version 8 requires postcss as peer dependency, leads to breakage when running development

## "sapper": "0.28.0"

Keep locked until missing CSS issues are fixed in v0.28.1

This way every collaborator of the project will be informed about known dependency upgrade issues.

Always keep this file up to date when you run into dependency issues or resolve some. Ideally the file stays empty and everything can be upgraded as expected.

3. Writing variable names and comments in a language other than English

Easy rule of thumb: if you or others reading your code need to spin up "Google Translate" to understand what is happening in the code, it is a waste of precious development time. Translating code should not be a part of being a web developer.

In the MVP project, the entities that were coming from MongoDB through a Node.js backend had some fields named in German and others in English while the frontend was mostly using English. This required a lot of unnecessary mapping from one naming convention to the other. It was not possible to use object shorthand and it was easy to forget which field is which. Additionally, any developer that might join the team that is not a German native speaker would have problems understanding the usage of each field.

Stick to keeping the whole code base in English. Apart from variable names looking weird in other languages like German, you exclude international developers from understanding what is going on in the code. Whenever you need to have words displayed in another language than English in your user interface, you can use libraries like Format.js to handle internationalization needs.

4. Different naming conventions throughout the whole project

Try to avoid mixing up different naming conventions for HTML, CSS and JavaScript code. Don't use kebab-case, snake_case and camelCase all over the code base or you will get confused quickly and lose productivity.

Learn about the different naming conventions and why they exist. I recommend you stick to the coding conventions of the language that you are using. Native JavaScript methods like .toLowerCase() are written in camelCase, so why would you write your variables with any different casing? While JavaScript uses camelCase, remember to use kebab-case for your HTML markup and CSS styles.

5. Using meaningless variable names

I am sure you have seen code similar to this before:

const x = 'Gabriel';

const stuff = x.map((y) => `Hello, ${y}!`);

What values are stored here? Is Gabriel the first name or last name of a person? What is x that gets mapped over? Is it even an array? What does the variable stuff hold?

You should not have to waste valuable cognitive energy on deciphering what you and others wrote, but focus on bug fixes and new feature implementations instead.

You might think that it is cool to write short and cryptic variable names and expressions, but it's not. Coding is not about writing the least amount of characters but about producing business logic that is easy to understand, valuable and doesn't need a refactoring right after writing it.

Let's take a look at a good example:

// The variable name `firstName` clearly shows the intent of the stored value
const firstName = 'Gabriel';

/**
 * The variable `students` is in plural, so it is probably an array.
 * The value `student` is most likely an object that we are
 * mapping over.
 * We seem to collect `greetings` of `students` here as a result.
 */
const greetings = students.map((student) => `Hello, ${student.firstName}!`);

Here we can assume a lot more based on good variable naming and clarity which means lesser cognitive overhead for the developer.

Your future self and your co-workers will be thankful when they still understand what each line of code is doing - even a year later.

6. Leaving console.logs and to-dos scattered all over the code

This is bad for the developer and user experience at the same time.

console.log('Hello from indexing function');

console.log('Result', result.data);

// TODO: Why does this even work?

// TODO: Add error handling

It can be embarrassing and unprofessional to leave console.log() messages in the dev tools for every user to read. On the developer side, it can be distracting and discouraging to find to-dos of what needs to be changed without detailed information and console.log() which might be needed or not.

I recommend using the no-console ESLint rule and to configure it as needed. I tend to mark console.log() as an error and use it in conjunction with lint-staged pre-commit hooks to disallow commits which fail on lint mistakes. When you want to keep logging information you could either use console.info() to show the specific intent of requiring outputting information at that point.

If you cannot give up your console logs in the code, you could opt-in for a plugin like babel-plugin-transform-remove-console or terser-webpack-plugin to strip out console messages for you based on the environment.

To-dos are preferably put into separate issues on your repository management tool. Make sure to provide enough information for another developer to start working on it without having to sync up with you first. Additionally, when putting to-dos into issues, every developer will be aware of them rather than stumbling over random to-do comments in the code base.

7. Mixing up async/await, promises and callback syntax

Producing mistakes in asynchronous code can lead to bugs which are very hard to detect, so make sure to stick to one paradigm at a time.

Let's take a look at a real-world example from the MVP project:

export const saveLogAuthToken = async (token) => {
  const jwtToken = jwt.verify(token, JWT_SECRET);

  if (!jwtToken) return false;

  const logoutToken = new logAuthToken({ token, expires: jwtToken.exp });

  await logoutToken.save().catch((err) => {
    console.log(err);
  });

  return true;
};

Even for me with more than 4 years of professional experience, I have a hard time figuring out how the code would flow here based on different outcomes.

The code example above shows missing knowledge about how async/await works.
The code starts with usages of async/await which is great for writing readable and concise code, but then it becomes unclear:

When does the function return true?
What does it return when we run into the .catch() block of the logoutToken.save() method?

With a few simple changes, we can drastically improve the code flow:

The code should be wrapped in a try/catch block to avoid the well-known UnhandledPromiseRejectionWarning message in Node.js
Remove the .catch() block on logoutToken.save() since errors are caught in the catch statement of try/catch
Stick to either using async/await or the Promises syntax. It could also be a good idea to consider not only returning false when jwt.verify() fails, but to explicitly throw an error instead.

These code design mistakes can be deadly - especially when there are no tests written for this piece of code.

8. No unit or end-to-end tests for complex business logic

This is so common that it is a running joke amongst the web development community. I still remember working at my first job and there were zero unit tests written for the project. When I asked about it, everyone said: "It would be great to have test coverage, but there is not enough time."

Since unit or end-to-end tests don't bring added value for the customer, they are often skipped and neglected. A common phrase is: "We will do it in the future when we have time," and then guess what? It never happens.

At the second company that I worked for, there were also almost no unit tests written for the front-end part of the project. By then, I was more experienced as a developer and motivated to do my team and myself a favor, so I started to implement unit tests here and there whenever a task was finished earlier than expected.

For one task that I had to work on, there were so many potential edge cases, so I started using "Test-driven development" (TDD) and wrote the tests before the actual code. Although I had to write the unit tests in addition to the business logic, I ended up finishing the issue around 30% faster due to having the "safety belt" of the unit tests catching all potential errors and edge cases. The test coverage will prevent you from looking for a bug in the wrong place as well.

Bottom line: write unit tests when possible, especially for complex snippets of code and use end-to-end tests at least for the critical parts of an application.

Wrapping Up

Although I understand that time pressure alone can be the reason for some developers to throw code quality standards overboard, I highly advise pushing through while still doing your best at delivering clean code.

The minimal amount of time that you save just by duplicating code snippets and hacking away until it works will then start to pile up as technical debt, and it will take you even longer to fix afterward.

It will not always be possible to write the cleanest code, but don't let that discourage you. After all, we are just human beings and make mistakes.

Have you made any of these or similar mistakes before? Leave a comment below!

Why You Should Start Contributing to Open Source Software Right Now

Markus Hatvan — Sat, 14 Nov 2020 12:07:59 +0000

You might not be aware of it, but you use some form of open source software every single day.

Every time you start an app on your phone or launch a program on your computer, you profit from the code that someone has written for free.

WordPress, the largest and most well-known content management system, is used by 38% of all websites worldwide. It is open source and free to use.

Linux is powering 30% of all websites globally. It is open source and free to use.

These are just two examples out of a myriad of projects which were created to solve a problem or serve a use case.

These projects became highly popular as communities formed around them. They tried to deliver the best product possible in terms of user experience, stability, security, and more.

But not only the usage of open source projects is rising. The participation in the open source movement as a whole is growing as well.

According to the State of the Octoverse report by GitHub, out of more than 40 million developers on GitHub, 10 million new users joined in 2019 alone!

The open source movement is growing quickly and you should become a part of it too.

Whenever I see a new update for my operating system or new software releases of tools that I actively use every day, it makes me smile. I enjoy the thought of products continuously getting better and more sophisticated.

Do you feel the same way?

Here is why I am convinced that you should start contributing to open source software right now.

You can learn a lot from the source code

Since the source code in open source projects is available for anyone to read, that means that a large number of developers can battle-test and improve a project.

Developers point out privacy or security issues, update the documentation, and improve source code to the newest web development standards all the time.

Especially when you go through the code of projects with hundreds or even thousands of contributors, you can gain immense knowledge about best practices and code quality.

Not only is reviewing the code itself a learning experience, but also the structure and folder hierarchy in larger projects is well thought-out and works well in the long run.

You will work with the smartest people

Compared to a company that has a limited number of employees to work on feature requests and bug fixes, you have the brightest minds working in open source development.

In my imagination, I see it as swarm intelligence, which can solve every problem that arises.

The more people that join a community, the better a project can scale. It can be like a buzzing beehive, where you could have pull requests to a codebase from users all around the world 24/7, non-stop.

A good example is the well-known code editor Visual Studio Code which got very popular with a total of 1,200+ contributors on GitHub.

You won’t see a single day without any pull requests on GitHub and the monthly release cycles always bring out new amazing features.

When you participate in a project and submit a pull request, you will receive extremely helpful feedback from highly experienced maintainers. You can then implement that feedback to grow as a developer.

Your own code could be used globally

Since some software development projects are used by millions of users daily, it can be very rewarding to see your own code helping so many people.

I wrote lint rules for the JavaScript projects called eslint-plugin-unicorn and svelte. It’s a great feeling knowing that my pull request will improve the code quality of many developers all around the world.

From my personal experience, it is also motivating to get positive feedback in the form of a thankful comment.

Open source projects are inclusive

A great advantage of free open source software is that no one is excluded from using the product because they can’t afford it.

While some open source projects cost money to use, most do not.

Also, when you’re contributing to a project on GitHub, many of the bigger repositories have a code of conduct. These make sure that every contributor feels welcome and accepted in a project.

Projects are starting to become sustainable

The main goal of a company is to become profitable - which often leads to questionable decisions. But open source software focuses on solving the needs of its users as the highest priority.

Most projects are entirely volunteer-supported, and project maintainers will unfortunately never see any financial reward. But there are great ways nowadays that you can help make these projects sustainable.

With websites like OpenCollective or GitHub Sponsors, you can donate to speed up the development of projects that you like.

Personally, I think that it would be great if every company donated at least a small sum to open source software projects because they profit from these tools daily. Such support would reduce the stress for a lot of maintainers and some could even take up the work full-time.

How to contribute to open source

Contributing to open source development sounds more scary than it really is. There are plenty of projects out there on GitHub which encourage first time contributors and newbies to take action by labeling issues as “Good first issue”, “Beginner friendly” or “Help wanted”.

Don’t know where to start?

Ask yourself: what is an application that you enjoy using every day and where you would want to give back?

It can be as simple as searching for that application on GitHub and looking through the open issues.

It doesn’t have to be a code contribution, either - you can also help out by creating a pull request to update the documentation, fix typos that you find, or by doing a thorough code review.

The README.md file of a project usually includes a passage of how to contribute.

If you decide to contribute to a project, I recommend reading my article about Contributing To Open Source Projects The Right Way. It’s a detailed step-by-step guide about the contribution workflow.

I wrote it to be very beginner friendly, so don’t worry about becoming overwhelmed. You will be able to find your first project and submit a contribution in no time!

Wrapping up

It always impressed me that everyone in the world can join an open source software project and work on it.

And open source software only works as a collaborative effort. The goal is to produce the best product or service without compromising on important factors like stability, security, or user privacy.

I hope you understand the importance of open source software and that you value its benefits. No matter what your reasons are for giving back to the open source community, just know that you are highly appreciated!

Many projects can only thrive with support and contributions from developers like you.

Helpful resources

10 Reasons Why I Recommend Svelte To Every New Web Developer

Markus Hatvan — Wed, 11 Nov 2020 08:27:09 +0000

Although the initial release of Svelte was back in November 2016, it's still more of an underdog amongst the JavaScript front end frameworks and just recently started to get its well deserved attention by the community.

After working with various JavaScript frameworks over the years including Angular, React and Vue.js, I think I have a good overall impression about how writing code can be enjoyable and how it can be frustrating.

A couple of years ago, writing code with jQuery felt like a revelation when coming from pure JavaScript. Then at my first job, I started working with Angular 2, and all of a sudden jQuery felt like a drag. Now, React is the cool kid on the block and Angular feels so complicated in comparison. You can probably see where this is going!

For me, Svelte is the next evolutionary step in the rapidly changing ecosystem of JavaScript frameworks.It feels so easy to write the Svelte way and you can tell that its creator Rich Harris was tired of all the annoying abstractions and the necessary boilerplate code that the existing frameworks require you to learn.

Now you might be asking yourself the question:

What makes Svelte different?

You might have heard about Svelte appearing here and there in articles like A RealWorld Comparison of Front-End Frameworks and developer surveys like the State of JS Survey as one of the best ranking frameworks when it comes to bundle size, performance, lines of code and most important developer satisfaction.

Compared to the popular React and Vue.js libraries, which do the bulk work during runtime and are using a technique called "virtual DOM diffing" for detecting changes, Svelte is compiled into framework-less vanilla JavaScript as a build step and can therefore benefit from a lot of code optimizations.

Naturally hesitant, I dismissed Svelte at first as "just another JavaScript framework" and didn't bother looking into it. After hearing about it a second time, I wondered: is Svelte just hyped or could it really be that good? I decided to battle-test it and use it on a personal project of mine.

Now after a few months, I can give you a definitive answer:

Svelte is simple, powerful and elegant and you will love it!

Without further ado, these are the top 10 reasons why I recommend Svelte to every new web developer who is starting to learn programming:

1. Svelte components are easy to understand

If you have never seen the Svelte syntax before, this is how a simple example would look like:

Compared to other frontend frameworks which introduce a lot of abstract concepts that take a while to learn and understand, it's really refreshing to see that Svelte just uses plain old HTML, CSS and JavaScript side by side. You can see and easily recognize what is happening here with its beginner-friendly syntax.

2. Simply write concise code

As you can see in the code example above, the business logic that you write is simple and easily readable at the same time. After all, the less code you write, the fewer bugs it can have, right?

Rich Harris, the genius creator of Svelte provided some good comparisons with React and Vue.js in his article called Write less code. According to his check up on characters needed to write the logic for a simple addition of two numbers, a React component is typically around 40% larger than its Svelte equivalent!

3. Reactivity with labeled statements

Whenever you want your variable values to update and recompute based on other variables, you can use reactive declarations. Just put a dollar sign in front of the variable that you want to be reactive and you're good to go!

Any time the button is clicked, count will increase by 1 and doubled will know that the value of count changed and update accordingly. It's really fascinating to think in terms of reactivity and it feels good to write.

4. Easy global state management out of the box

No need for any complicated third-party state management tools like Redux or Vuex.

You just define a variable as a writable/readable store and use it in any .svelte file prefixed with a $ sign.

In this example, we check the current environment, which exists as a value in our store and use it to decide if the cookie notice should be displayed or not. Simple, isn't it?

With Svelte stores, you also never have to worry about memory leaks, because store variables prefixed with a $ sign act as auto-subscriptions and unsubscribe automatically.

5. Built-in accessibility and unused CSS checks

Svelte wants to make the internet a better place and helps you out with useful hints in the code.

Whenever you forget to put the alt attribute on an <img> tag, Svelte will display a A11y: <img> element should have an alt attribute reminder for you. There is a long list of accessibility checks that are implemented in Svelte, and they hint at you without ever becoming a nuisance.

To keep the code as concise as possible and to avoid snippets of left over code, Svelte also flags unused CSS selectors for you whenever there is no respective markup to be found in a component.

6. Components are exported automatically

Whenever you would want to use component A in component B, you would usually need to write code to export component A first, so it can get imported by component B. With Svelte, you don't ever need to worry about forgetting to export, a .svelte component is always default exported for you automatically and ready to be imported by any other component.

7. Styling is scoped by default

Similar to CSS-in-JS libraries, Svelte styles are scoped by default which means that a svelte-<unique-hash> class name will be attached to your styles, so they don't leak and influence any other components styling. Of course, you have the option for styles to be applied globally by simply prefixing them with the :global() modifier or just using a .css file if you want to.

8. #await blocks

With most web applications, you will need to handle asynchronous data to display useful stats to your users.

The advantage of {#await} blocks is that you don't have to define an extra state for you resolved/rejected promises, you can just define variables inline in your template.

9. Shorthand attributes for passing props

In case there's a prop name that is the same as a variable name, we can pass it to the component as a shorthand attribute like {message} below. There is no advantage over using message="{message}", but it's more concise.

Above you can see the class:round attribute getting applied to the button based on if round is true or false. This could easily become a reusable component where you pass the value of round from the outside to decide the styling of the component conditionally.

10. Built-in effects and animations

Svelte comes prepacked with powerful effect modules:

svelte/motion effects like tweened and spring
svelte/transition effects like fade, blur, fly, slide, scale, draw
svelte/animate effects like flip
svelte/easing effects like bounce, cubic, elastic, and many more

There are a few examples in the official Svelte tutorial, but I like this progress bar example the most because of its simplicity.

Animations is an area of web development where you usually look for an external dependency to handle it for you, so it's great that you can use these right out of the box.

Fair reasons not to adopt Svelte

To avoid making this article sound like one long fanboy post, these are the cons that I experienced with Svelte so far:

`.svelte` files cannot export multiple components

On one hand, we profit from .svelte files being default exported automatically, but this also means that we cannot export multiple components from a single file. I don't think that this is such a big deal since it forces you to follow best practices writing your application with many small isolated components, which keeps them easy to understand and unit test.

Template syntax in general

For displaying conditional logic, Svelte uses a syntax that resembles the well-known Handlebars templating syntax.

I didn't encounter any issues with this way of writing logic, but I would prefer a more concise syntax.

Receiving props in a child component with `export let`

When you want to pass values from the parent to the child component, you need to pass a value as an attribute and receive it by using export let with a matching variable name.

In modern JavaScript, export is usually used as a keyword for exporting a module and let to declare a block-scoped variable, so I feel that the syntax is misusing existing keywords, but I got used to it and it works well.

Development speed

This is not directly related to the development experience with Svelte, but you should definitely be aware that Svelte can't compete (yet) with bigger and sponsored open source projects like React, Angular, Vue.js and others in terms of financial support, number of contributors and popularity as of now.

Nevertheless, the community is growing quickly and there is an ever-increasing list of third-party projects built for Svelte by the community which is available on Made with Svelte. The developers working on Svelte-related tools are geniuses and you can always ask for help on the Discord channel, Twitter or Reddit. Svelte also recently added TypeScript support and it works great!

I like Svelte's ease of use, small bundle size and developer experience amongst other factors so that I can accept a slower development speed as a trade off. If you always need the newest features to be merged as fast as possible, then you might want to look into other available JavaScript frameworks.

Lack of available jobs

Most companies are still looking for developers who are experienced with the major three front end frameworks but there are various, well-known early adopters of Svelte like IBM, Apple, Philips, GoDaddy, 1Password or The New York Times, just to name a few. You can find an extensive list of companies who are using Svelte at the bottom of the Svelte website. Usually, the adoption of a new framework takes a while to show up in job offers of companies. Nevertheless, Svelte is fun to learn and many developers enjoy using Svelte especially for their own personal projects or small scale applications.

Conclusion

If a beginner-friendly syntax, a small bundle size output and an insane performance with Svelte sounds like a great choice to you, I would recommend you to start hacking away with the Svelte tutorial. The tutorial is really detailed and you can quickly get an understanding of how powerful the framework is.

Things can definitely change fast in the world of JavaScript frameworks and I hope you are as convinced as I am that Svelte has all the upsides and potential that can make it become the new #1 JavaScript front end framework around!

Did you work with Svelte before? What is your experience?

Tell me about it in the comments, I am curious to know.

Thanks for reading, I hope you enjoyed it!

Helpful resources

Looking for a Svelte powered server side rendered solution?

After getting into touch with the framework through using Sapper, I am a big fanboy and try to promote the way of Svelte whenever I get the chance.

In case you are about to set up a website and are looking for the right tool, I published an article about my experience so far with Sapper for you to read about here: "Why I Chose SapperJS For My Website, And What I've Learned About The Framework So Far".

Contributing To Open Source Projects The Right Way

Markus Hatvan — Mon, 09 Nov 2020 20:13:00 +0000

When I started with open source contributions in April 2019, I remember being scared about doing everything wrong.I didn't want to mess up on a pull request and be branded as a noob, never able to taste the sweet success of getting an open source pull request reviewed and merged.

There were so many questions that I had to find answers to:

What skills do I need to be able to contribute successfully?
How do I write commit messages correctly?
What is forking? What is upstream?

Although there were articles and tips and tricks available on the web, it was tedious to gather all the necessary information bit by bit.

After contributing to open source projects regularly for a while now and feeling comfortable with the workflow, I decided to share my knowledge with you so you don't have to start from zero like I did.

Additionally, my motivation is to bring people who are hesitant to start with open source contributions to take the first step. More developers contributing to open source projects means better quality of code, more documentation written and faster development speed which is a benefit for all of us.

Why you should contribute to open source projects

Improve your coding skills. Working with different code bases is a great way of getting better at coding fast. Contrary to a work environment where you might work on one project for a longer period, with open source projects you can switch to another project whenever you want and get to know various tooling and setups.
Give back to the community. You are probably using a lot of different repositories daily for free and this is your chance to contribute as a way of thanking the project.
Improve your prestige. You will be easier to hire with merged pull requests for well-known projects or you might even turn into a thought leader for a certain topic.
Work with different teams. Each repository has different contributors and coding conventions that you will need to adapt to.
Solve interesting problems. Finding solutions to complex problems can be fulfilling and a lot of fun. You are also able to choose which issues you want to work on.

If you think that you don't have enough experience to contribute to projects with code, don't worry. You can always help out by improving documentation, answering issues, or with the internationalization of a project until you feel ready.

Some of my contributions

To give you a bit of an overview of projects that you could be working on, here are some of the open source contributions that I worked on:

sveltejs/svelte: add accessibility rule
sindresorhus/eslint-plugin-unicorn: add lint rule
microsoft/webtemplatestudio: improve generated angular and react code, fix e2e tests
react-boilerplate/react-boilerplate: dependency changes and upgrades
ethereum/ethereum-org-website: fix setTimeout leak, fix accessibility issue
foundry376/mailspring: add preferences options, allow cancel upgrade prompt

As you can see, my favorite areas in web development include working on code quality improvements like linting and accessibility as well as dependency upgrades.

One of the great things about open source contributions is that you get to choose whichever issue you feel like working on right now!

Contribution flow

Before starting to work on open source contributions, it is essential to know how the usual workflow will look like.

A high-level overview of the step by step flow that open source contributions follow.

Although most pull requests can be created, reviewed, and merged within the same day, it is not uncommon for PRs to take even multiple months from start to finish! I have pull requests which are open for more than a year and they are not merged yet because the project is maintained irregularly or project focus moved away from that issue.

How to find a project to contribute to

GitHub: there is an Explore page where GitHub recommends repositories based on your interests and previous contributions.
Work: you are actively using a repository for a project at work. You want to fix a bug or add a feature that is necessary for your progress at work or you simply want to contribute as a way of giving back to the project.
Contacts: you hear from co-workers or friends about cool repositories and want to be part of them too.
Stock Market: not the most obvious way, but you could be invested in a company and want it to flourish.

Naturally, starting an open-source project yourself if you have a great idea is an option as well.

Bug bounty programs

Unfortunately, participation in most open source projects is voluntarily and therefore unpaid, but there are websites where you can find issues with monetary rewards on them:

Issuehunt: I collected various bounties of up to $100 for issues here and the site gets updated regularly, so I highly recommend you to check it out.
Gitcoin: Most issues here are specific to blockchain development and the payout is in cryptocurrency.
Bugcrowd
HackerOne
Bountysource

What to do first

Let's assume that you found a project of your liking, here are some ways that you can find out if it is a smart idea to start working on that repository:

Proficient with the used programming language

No matter how great the project sounds, if you have no prior experience with the used programming language or tech stack, you will have a hard time fixing an issue.

Check the popularity of the project

I recommend going for a project that is not too popular yet - all the good issues would be gone too quickly - but also not so small that the chance is high that the project might become unmaintained at some point. Aiming for a star count on GitHub between 1000 and 50k is usually a good bet, but there are some exceptions.

Check the latest commit in the master branch

Don't contribute to a repository if you see that there was no commit added to master for more than a couple of months, it can be a sign of a deserted project. When having doubts about the ongoing development of the project, ask some of the contributors or open up a new issue.

Take a look at the number of open pull requests

Are there a lot of open pull requests? If it is not a highly popular project, this can be a clear indicator that the repository cannot keep up and doesn't have enough members for handling the reviews. Alternatively, it could also be that there are organizational issues that lead to slow decisions or the direction of the project is lacking.

Check for interesting issues to work on

Well-organized repositories usually have issue labels like "good first issue", "help wanted" or "documentation". These can be an optimal start to get to know the repository. When you find a suitable issue, make sure it is not taken by someone else yet. If it is an older issue, write a comment to find out if there is still demand for a solution to avoid working on an issue that is not wanted anymore or superseded by other changes.

Find contribution guidelines for the project

While you can always find out how to get a project up and running locally yourself, a good project usually has information for contributors in the README.md file or more specifically in a dedicated CONTRIBUTING.md file.

Preparations before working on a project

By now, you selected a project that fulfills all the criteria of being a good pick: it is continuously maintained, you found interesting open issues and you feel skilled enough to start the work!

(Optional) Make sure to add an SSH key to your GitHub account

With GitHub, you can clone a repository either with HTTPS or SSH. Various online discussions are going on between which way is better, I prefer and recommend SSH over HTTPS because you don't have to re-enter your GitHub password every time you use operations like git push.

If you are unsure about how to generate an SSH key and put it into your GitHub account, here is a good article: Connecting to GitHub with SSH.

(Optional) Add a GPG key for verified commits

Although you can commit to a repository just fine without your commits being verified, I recommend setting up a GPG key for these three reasons:

your commit will receive a green "Verified" label which gives it improved authenticity
you show other people involved in the project that the commit comes from a trusted source
others can be sure that no one impersonated your account

Most of the commits in the React repository are verified by GPG key.

You can read more about generating a GPG key and verifying your commits here: Managing commit signature verification.

When you have your GPG key generated and set up in GitHub, it can be helpful to run these commands to tell git to auto-sign every commit:

git config --global user.signingkey <publickey>
git config --global commit.gpgsign true

Ready to clone

Let's say you want to contribute to React, then the command for copying the project to your local disk would look like this:

# ssh
git clone git@github.com:facebook/react.git
# https
git clone https://github.com/facebook/react.git

After the project is successfully cloned to your local disk, you can find the repository available under the file path that you were located in when cloning it.

Find the used branch for development

Before you start to work on the project and begin modifying files, it is a good idea to check the branches on the GitHub repo. Although most of the time you branch away from the master branch for your contributions, there are repositories that use a separate dev or development branch. These intermediate branches are used for PRs and get merged back into master regularly when deciding on pushing out a new release.

Familiarize yourself with the project

Depending on the size of the project, it can be quite the challenge to figure out which files require a change for providing a bugfix/feature. Try to scan over the file structure once at least before using the search in your IDE for pinpointing the location for your code changes.

Don't get discouraged!

Starting with a large project can be overwhelming at first. I often wanted to give up on issues already only to find the ideal solution a moment later. It can pay off to be perseverant.

Nevertheless, you will encounter projects - especially older ones - which can suffer from bad developer experience. When you realize that it will take you a lot of time to even get the project setup or the tests and linting to pass, focusing your work on another repository might be a better idea.

Getting things done

At this point, you have familiarized yourself with the project and you are sure that you can make some meaningful code changes.

Reserve the issue of your choice

You can signal the contributors of the repository that you want to take an issue by simply writing "I want to work on this" as a comment.Ideally, you will get assigned to an issue and avoid that your issue will be taken by someone else.

Be aware that you are expected to deliver a PR or a status update once you volunteered for an issue. Some contributors also might ask about the progress if is a high priority bug fix.

Save work into a branch

Since we are still in the default branch that we cloned the project from, it's about time to check out into a separate branch to be able to commit.

I recommend naming a branch according to the <issue-number>-<issue-name> naming convention.

An example of checking out into an issue-specific branch would look like this:

git checkout -b 345-expose-options-for-gtag

If you want to read up more on the topic, there is plenty of information available about Git branch naming conventions.

Ready to commit

We already learned that there are naming conventions for creating branches in Git, so we also want to follow the best practices for the structure of a commit message. Conventional Commits is a good resource of "a specification for adding human and machine-readable meaning to commit messages".

Set up git commit default message

As programmers, we prefer to avoid unnecessary work and stick to the DRY principle. That's why I advise using a git commit default message. I linked the template for you that I use myself. Whenever I start a commit message, I can check which type of change I am working on and adapt the message and its body accordingly.

A useful hint: whenever you put the issue number into your commit message like (#<issue-number>), the respective issue on the remote repository will receive a timeline notification that looks like this:

Everyone interested in the issue will see that you started working on it.

This can be helpful especially for pull requests that span across a longer time frame to further signal to other subscribers of an issue that you are indeed working on it right now and that the pull request is not abandoned.

Check how commits are done in the repository of your choice

Although you are good to go most of the time with sticking to the conventional commit structure for commits, I advise running git log in a project where you contribute for the first time to see how strict commit messages are handled.

Make sure you comply with the outlined contribution guidelines

Before committing, double-check that you fulfill all the requirements of a potential CONTRIBUTING.md file. Whenever you add a new feature, it can be a requirement to add a corresponding unit test to the project to verify that your changes are reliably working or that you update the documentation to explain the feature.

Focus on the issue at hand exclusively

Don’t touch any code not related to the bug you are fixing or the feature you are implementing and stick to the code style of the project.

Sometimes, the pull request reviewers will also explicitly tell you to revert formatting or refactoring changes that you did out of goodwill. The main reason is to keep the pull request easy to read and review and to avoid time-consuming discussions about irrelevant changes in the code diff.

Squash commits

Do as many commits as you need while the pull request is in a work in progress state, but rewrite and squash your commits to result in one nice and clean commit in the end. This way you avoid polluting the master branch with excess information in git log.

In case you are unfamiliar with squashing commits, this beginner's guide to squashing commits with git rebase can help you out.

Ready for pushing

If you've gotten this far, great! You're almost ready to open your first PR! There are only a few steps left.

Fork repository

Forking is just a fancy word for taking a repository on GitHub and copying it under your own GitHub username.It can be done by clicking the Fork button on the right upper corner on any repository as can be seen here:

The fork button is in the upper right corner in the GitHub UI.

The reason why we need to fork a repository is to be able to submit a pull request against it.By default, you don't have push permissions to a repository that doesn't belong to you.Therefore we fork a repository under our username where we are allowed to push to and then we can submit a PR against the original GitHub repository.

So if you would decide to fork React, it would take a few seconds, and then you would have an exact copy of the repository available under https://github.com/<username>/react.

Although the step of forking can be done earlier in the workflow, at this point we already made a git commit previously so we know for sure that we have a meaningful contribution to push. If you fork a repository before checking out the project locally and finding out if you can do valuable changes, it can be that you decide against working on it and then you forked it in vain.

Set up a git remote

When you clone a repository from GitHub to your local disk, it has the origin set up for you.

If you run git remote -v inside the location where you cloned the repository to, it should look similar to this: origin git@github.com:facebook/react.git.

When you run git push it will try to push against origin which would not work in this case since we are not a member of the Facebook group.

We need to change the origin to be our fork and the upstream repository to be facebook/react.

To do that, we can run:

# add facebook/react as upstream
git remote add upstream git@github.com:facebook/react.git
# change origin url to be <username>/react
git remote set-url origin git@github.com:<username>/react.git

If you did everything correctly, the output of git remote -v should display origin and upstream set up:

Output of git remote -v

Does it look similar like in the screenshot above? Good job!

Push to origin

The remaining steps should be fairly easy. We push our branch with the squashed commits that we made to the origin, which is our fork.

The command to do that is:

git push origin <branch-name>

Super, we are almost through!

Ready to open a PR

If you did everything correctly, you will be presented with an alert box at the location of your forked repository, notifying you of your recent push.

A real-life example of a pull request that I made for React Carousel.

After you are 100% done with your work, click the "Compare & pull request" button.

Write a useful pull request description

To make the review for the maintainers of the repository as easy as possible, we should follow the best practices for a good pull request description.

This is the minimum that I would put there:

Closes #<issue-number>.

<explanation>

GitHub will parse the "Closes" keyword and automatically close the issue when the PR gets merged.

The <explanation> part can be very different depending on your contribution. It might be that you want to explain the bug that you fixed, notify about potential problems that could show up in the future, or discuss breaking changes that your PR might lead to.

Additionally, some repositories might have dedicated pull request templates set up. Then you would need to check checkboxes making sure that e.g. linting goes through without errors, you added unit test cases for your new feature, no formatting changes were committed, depending on the repository.

When you are content with your pull request description,the only thing left to do is to click that rewarding, green "Create pull request" button and voilà!

Wait for approval

Depending on the project, this can happen quickly or take a while. Sometimes you will have to do multiple iterations of improvements for a pull request, other times your work will be merged right away.

That's all folks!

You successfully created your first pull request!

Wow, you did it! I hope you are as enthusiastic as these kids ;)

Thank you for wanting to give back to the open source community, a lot of projects can only thrive with support from people like you!

I know this was a lot to digest, but you should have all the necessary steps laid out to go from zero to hero.

I hope this article has been helpful to you, let me know if there are any open questions left or passages to add.

Thank you for reading!

Helpful resources

Wix, WordPress, JAMStack - Oh My!

Markus Hatvan — Wed, 02 Sep 2020 14:29:06 +0000

There are many options to choose from when building your website:

WordPress is the go-to option for many people who are not coders
different WYSIWYG ("What you see is what you get") tools like Wix
JAMStack solutions like Gatsby or Next.js

Why I didn't choose a CMS like WordPress

Due to its big ecosystem of plugins and popularity, you can bootstrap a website in no time with WordPress and release your MVP.

Nevertheless, having experienced various WordPress sites either through building them for clients, browsing the web myself or helping out my girlfriend with hiccups of her company's website, I can clearly say that WordPress sites feel slow, sluggish and laggy to me and don't provide the performance that I would expect from a simple website.

As a coder, I am interested in the code quality and want to have control over as many aspects of the website as possible.

When you start with a theme or template, there is way too much magic happening under the hood, and only some customization options are surfaced for the user to benefit from.

If you lack the coding skills or time for working on your website, I can understand why it’s a good choice to take the shortcut and fire up a WordPress site, install a handful of plugins, and focus solely on content creation.

In a single day, you can probably finish the MVP of your website depending on the complexity, while with a classic HTML/CSS/JavaScript framework you would be still working on the first page or even stuck with configurations.

This is of course very subjective, but here are my pro & cons regarding WordPress:

Pros

no coding skills necessary
open-source and free
huge community
extend functionality with endless plugins
ready fast with UI themes
strong focus on blogging and SEO

Cons

fresh installation lacks in security
updating plugins can break site easily
attractive for potential hackers due to popularity
bad page performance out of the box
further customization not provided through plugins and themes is difficult
spaghetti code
no version history e.g. Git

Why I didn't choose a WYSIWYG editor like Wix

The big upside of WYSIWYG tools is the possibility to drag and drop content and building the website in a way that a user can relate to since changes are immediately visualized and impactful.

It resembles a Microsoft Word editor with a lot of shortcut buttons e.g. bolding the text or attaching an image.

Compared to WordPress, my subjective pros & cons for a WYSIWYG editor look like this:

Pros

fast workflow with drag and drop
strong focus on the visual aspect of a page
no coding skills necessary
ready fast with UI themes

Cons

spaghetti code
bad page performance out of the box
weak SEO optimization
further customization without provided plugins or themes is difficult
the site can look like a clone of another one fast

Hello JAMStack!

Building my website with a JAMStack solution came naturally.

When you receive various programming newsletters, there are always clickbait articles like "Why you have to try XYZ" or "Check out the fastest framework called XYZ".

There is the ever-present need for staying relevant and up to date on the job market and also having some fear of missing out when not using the latest and greatest bleeding-edge technology.

So it happened that I worked on a project with Gatsby to satisfy my developer curiosity for trying out new technologies and got in touch with JAMStack.

It can best be described as a nostalgic reliving of the good old static website days.

A classic JAMStack project looks like this:

provide website content through Markdown files or write static HTML, no database is needed
since the content is generally static, minimal or no backend setup needed
the production bundle goes through steps like tree shaking, minification and is stripped of development tooling to become a small and performant end product
you deploy your site with a hosting provider e.g. Netlify
serve assets through a CDN
the website loads fast for the user due to server-side rendering optimizations and cached content

You can find a detailed explanation of JAMStack on jamstack.wtf. Choosing JAMStack or not depends a lot on the scope of your website. Most of the content needs to be requested on runtime e.g a corporate website with a lot of dynamic forms and user input? Don't use it. Is the content mostly images and text which rarely gets updated e.g. a blog post or a one-page product website? Yes, do it!

Pros

great performance out of the box
excellent developer experience
very cheap due delivering cached static files
fast deployment
just a static HTML page
free and open-source frameworks
extend functionality with plugins
all your changes are version-controlled

Cons

coding skills required
dependent on 3rd party services
cannot request dynamic data on runtime
the time required for learning the stack
no GUI

Wrapping it up

Using a JAMStack setup for your next project can be a great choice, depending on the scope of the project, possible company requirements, and many more factors. You will benefit immensely from a blazing fast page performance and an enjoyable developer experience.

In case you are not a programmer or need to get a project bootstrapped really quickly, it is advisable to stick with either WordPress or Wix where you can manage your project through a graphical user interface.

If you are interested in building a JAMStack website, you can read in my article "Why I Chose SapperJS For My Website, and What I've Learned About the Framework So Far" about how I was able to work and choose the perfect solution for me.

Thank you for reading! I hope you found the information useful in this article. If you have any questions, feel free to leave a response below.

Why I Chose SapperJS For My Website, And What I've Learned About The Framework So Far

Markus Hatvan — Tue, 01 Sep 2020 07:43:48 +0000

Wow, what a framework!

In this post, I will explain my thought process of how I was able to single out a tech-stack that would fulfill all the criteria I need to build a well-structured website:

snappy, lightning-fast performance
optimized SEO for being visible on the web
developer friendliness for hacking away efficiently
innovation in the field of website tools
natural curiousness as a developer to try out new technologies

Since I wanted to go for a website built on a modern JAMStack setup, I had these options based on framework popularity and matureness:

Next.js
Gatsby
Hugo
Nuxt.js
and maaaany more

You can see a full list of available static site generators provided by Netlify on StaticGen, there are a lot of competitors!

Next.js

Since I have about 2 years of professional experience working with React, it would have made a lot of sense to choose Next.js as my preferred framework, but that would have been too easy, right?

To be more versatile with different JavaScript frameworks out there, I decided against a React-based framework like Next.js.

Gatsby

I didn't want to pick Gatsby again because I am already using it for another project of mine that I recently started working on called DAW Comparison.

Apart from wanting to try different tools, I didn't fully enjoy the developer experience using Gatsby as I ran into issues with performance, having a difficult time figuring out how to get gatsby-image working the way I want and getting frustrated by unmaintained/duplicated plugins.

Nevertheless, I am certain that Gatsby is here to stay and will grow into an excellent framework , especially since it is already very popular and received $28M in Series B Funding in May 2020.

Hugo

Although I am interested in trying out the Go language for writing a backend project at some point, I was not interested in Hugo due to it not being on my radar, but also because of its confusing-looking templating syntax , for example:

{{ define "main" }}
<main aria-role="main">
  <header class="homepage-header">
    <h1>{{.Title}}</h1>
    {{ with .Params.subtitle }}
    <span class="subtitle">{{.}}</span>
    {{ end }}
  </header>
  <div class="homepage-content">{{.Content}}</div>
  <div>{{ range first 10 .Site.RegularPages }} {{ .Render "summary"}} {{ end }}</div>
</main>
{{ end }}

It might be a really powerful site generator, but I aim for simplicity for my website project.

Nuxt.js

Building the website with Nuxt.js would have made a lot of sense as I would have gained some hands-on experience with all three major JavaScript frameworks (React, Angular and Vue.js).

Vue.js is gaining a lot of popularity on GitHub and across the JS scene because it pretty much combines the best features of React and Angular, but as you will read further below, I eventually decided to go with the underdog.

Small detour

A while ago, I found out about Svelte and felt intrigued and fascinated by its promise to be a radical new approach to building user interfaces.

As seen on their website, "Svelte shifts the bulk of work that is usually done in the browser into a compile step that happens when you build your app". Hey, that sounds like a great way to solve performance issues for me!

After working through the whole Svelte tutorial, I had a few WTF moments (in the most positive sense) where I was impressed by its absolute simplicity and smooth developer experience.

Nevertheless, after acknowledging that it's too underground and might die a horrible "Just another JavaScript framework" death sooner or later and lacking a real-world project to try it out on, I dismissed it and forgot about Svelte again.

SapperJS

Fast-forward to the initial research of the potential JAMStack setup of this website.

I coincidentally ran across SapperJS and realized that it is "powered by Svelte" and developed by the same core team.

After a short moment of triumphing, I saw this notice on their documentation:

This will be a risky choice. - Early development notice on Sapper documentation

Oh, snap! That sounds like a lot of potential headaches, I still remember the upgrades from Angular 2 to 4 and Webpack 3 to 4 much too well.

So my choices came down to

go with stable and mature Nuxt.js, be relevant to the job market and profit from a large community in case I get stuck and have to rely on Stack Overflow
choose early development SapperJS, which did not hit a major version yet and potentially run into a few breaking changes along the way

In doubt, get a second opinion

Not an easy choice, am I right? I decided to ask a former work colleague that I can always rely on for good information and advice.

He is smart as hell and has about 20 years of experience in the JavaScript ecosystem, so that helps in situations like this.

I asked: "Hey Pete, I would love to use SapperJS for my website, but it is still in early development, it's a stupid idea, right?"

He responded: "It's not stupid at all, just be aware that you might need to refactor or redo a lot of code. But especially with personal projects, it's great to try out new tools and grow from the experience."

Kind of surprised that he wouldn't turn down the idea right away and that he even encouraged me to try it out, I felt motivated and jumped right into it!

Starting with an underdog framework also meant that there would be a lacking ecosystem of plugins and solutions, but I was aware of that and accepted it as part of building the website from scratch and seeing it as a great learning experience.

Progressing fast with Sapper

I started with the sapper-template-rollup and quickly set up the first few pages.

Now after working on the website on and off for about a month, I am proud to have reached these goals:

fast, performant and fully-responsive site
a blog site with filtering options and sub-pages for categories/tags
GDPR-compliance with own cookie notice and opt-in to Google Analytics
a commenting system with ReplyBox
fast styling of layouts with Tailwind CSS
shipping less than 300kb of resources and ~20 requests across each page
lazy loading and image optimization with svelte-image
easy deployment to Netlify
close to 100% on Lighthouse audit

I was able to focus almost exclusively on these goals without worrying about site performance because Sapper comes with advanced features and optimizations like route prefetching, server-side rendering, automatic code-splitting, and offline support out of the box!

My experience so far

In case you feel inspired to start with SapperJS as well, these are my thoughts and experiences so far about what works well and what doesn't:

Pros

great starter template with plenty of optimization options provided
it works smoothly without any hiccups or weird errors even though it is in its early development stages
you automatically profit from awesome Svelte features like concise syntax, built-in linting, a11y, marking of unused CSS, and more
development server starts fast and does hot module reloading
no framework-specific <Link> components, just <a> tags which support prefetching
guaranteed smooth integration with Rollup, which was also created by Rich Harris, the founder of Svelte
Discord channel with a nice community for all your potential questions

Cons

Sapper documentation is good but doesn't cover various edge cases which happen in development
a lot of necessary SEO attributes are not set by default, e.g. meta description
lacking ecosystem and component libraries either not existent or early development e.g. Svelma (Bulma components for Svelte)

All in all, I didn't encounter any severe cons at the time of writing, and I am optimistic that with all the hype around SvelteJS we will see the ecosystem steadily grow into a mature and well-respected web application framework.

If building a website with JAMStack doesn't sound interesting to you, you can check out my other post about Wix, WordPress, JAMStack- Oh My! for some great alternatives.

Thanks for reading!

DEV Community: Markus Hatvan

How I Raised My Hourly Rate by 78% in My First Year as a Web Development Freelancer

Generate multiple sources for incoming project offers

Keep talking to recruiters even when you are fully booked

Update your online freelance profiles regularly

Showcase your passion through an active GitHub profile

Move on to the next project regularly

Pick a project that can advance your skill set

Try to move on from every client with a positive impression

Conclusion

How To Win Your First Clients as a Freelance Web Developer

How Do I Even Find a Promising Client if No One Knows About Me?

Talk to Your Network of Peers, Friends and Family

Receive Inbound Offers From Recruiters on LinkedIn

Get Approved on Curated Freelancing Platforms

Browse Job Boards the Old School Way

Use Lesser-Known Ways of Finding Qualified Leads

So How Did I Find My First Clients?

Wrapping Up

Reclaim Your Data Privacy From Big Tech With the Best Privacy-Focused Alternatives

Why should you care about online privacy?

Google Search alternatives

Google Chrome alternatives

Google Maps alternatives

Microsoft Office Suite alternatives

Google Gmail alternatives

Services that I still want to switch

Conclusion

Helpful resources

8 Common Web Development Mistakes And How To Avoid Them

1. Not enabling code quality tools right away

2. Using outdated dependencies

3. Writing variable names and comments in a language other than English

4. Different naming conventions throughout the whole project

5. Using meaningless variable names

6. Leaving console.logs and to-dos scattered all over the code

7. Mixing up async/await, promises and callback syntax

8. No unit or end-to-end tests for complex business logic

Wrapping Up

Why You Should Start Contributing to Open Source Software Right Now

You can learn a lot from the source code

You will work with the smartest people

Your own code could be used globally

Open source projects are inclusive

Projects are starting to become sustainable

How to contribute to open source

Wrapping up

Helpful resources

10 Reasons Why I Recommend Svelte To Every New Web Developer

What makes Svelte different?

Svelte is simple, powerful and elegant and you will love it!

1. Svelte components are easy to understand

2. Simply write concise code

3. Reactivity with labeled statements

4. Easy global state management out of the box

5. Built-in accessibility and unused CSS checks

6. Components are exported automatically

7. Styling is scoped by default

8. #await blocks

9. Shorthand attributes for passing props

10. Built-in effects and animations

Fair reasons not to adopt Svelte

.svelte files cannot export multiple components

Template syntax in general

Receiving props in a child component with export let

Development speed

Lack of available jobs

Conclusion

Helpful resources

Looking for a Svelte powered server side rendered solution?

Contributing To Open Source Projects The Right Way

Why you should contribute to open source projects

Some of my contributions

Contribution flow

How to find a project to contribute to

Bug bounty programs

What to do first

Proficient with the used programming language

Check the popularity of the project

Check the latest commit in the master branch

`.svelte` files cannot export multiple components

Receiving props in a child component with `export let`