Category: Careers

Software development is a great skill to have in the modern world.

We can take advantage of it by making money in multiple ways.

In this article, we’ll look at some ways we can make money as a developer.

Get a Developer Job

Getting a developer job is an obvious way to make money.

There’re many kinds of developers you can be.

Popular choices include:

• mobile developer
• front end developer
• back end developer
• full stack developer
• embedded developer
• database developer

and many more.

They’re all high paying and there’re lots of demand since not everyone can do everything.

Also, there’s a lot of flexibility.

You can work as an employee or freelance and make money.

This means there’s a possibility that you can work anywhere or with multiple clients.

Sell Digital Products

You can easily sell digital products teaching people development skills.

We can sell products like ebooks, courses, videos, etc.

There’re many things you can teach like web development, database, mobile development, and more.

Amazon KDP is a great choice for publishing ebooks.

You have access to a big market and it has an ad platform built in so that you can build ads to promote your book.

This is something that isn’t available on all platforms.

Other websites you can sell digital products include Gumroad or your own website.

SAAS

Lots of people are making money by selling their own SAAS.

SAAS is a software as a service.

You can make something that people want to use and sell it.

It’s easy to gauge what people need by building minimum viable products in a few weeks and get the feedback.

Also, we can promote it with ads to get more traffic to it.

Host Your Own Website

We can host your own website and put ads on it.

Your website should help people.

With your developer skills, you can help people with lots of things.

You can put tutorials on your own website and put ads and make money.

AdSense can make you some money, but premium ad providers like Ezoic, MediaVine, AdThrive, etc., will make you a lot more money.

Also, affiliate links can be put on your own website, and you make money when viewers click on your link and order stuff from your website.

Your site can also host sponsored content. You partner with sponsors to promote their content.

And of course, you can promote your own products like ebooks and video courses on your site.

Books

Books are something you can write to make money.

As a developer, you got a lot to share with others.

You can write tutorials to teach people development skills.

They change all the time so you won’t run out of ideas.

Also, you can publish them in various formats like eBooks or physical books.

You can also approach traditional publishers with your book idea and write about them.

There isn’t a lot of competition for writers who are also developers, so there’s a decent that traditional publishers like Packt and O’Reilly will accept your book.

This is something that’s different from other genres which have lots of competition like fiction or self-help.

Conclusion

As a developer, there’re many ways to make money.

Software development is a great skill to have in the modern world.

We can take advantage of it by making money in multiple ways.

In this article, we’ll look at some ways we can make money as a developer.

YouTube Channel

You can shoot videos teaching people how to write apps and how to do other popular development tasks.

This is something that has fewer competitions like travel videos since software development is an exclusive skill that not everyone can master.

You can live code or shoot prerecorded videos.

Prerecorded videos can be sold.

With YouTube, you can sell ads through AdSense if you have enough people.

Of courses, you can sell ad spaces in your own videos instead of using Google ads.

Also, you can promote affiliate products and promote your own products in your videos.

Shooting videos is hard work and takes lots of work to succeed, so this may not be the best option if you want to make money fast.

However, if you’re known on the Internet, then more opportunities will come for you.

Online Courses and Programs

This is like shooting YouTube, except that you’re organizing the videos into a course.

Also, you may want to create a book only courses instead of book and video courses.

Live Streams

You can live stream yourself coding or doing some kind of webinar.

This can be done in Twitch or YouTube.

There’s less competition than other kinds of live streams since being able to live code means you can code mostly on top of your head.

This is not something many people can do.

Live code sessions also have discussions on the side to engage your audience more.

In your stream, you can ask for donations and you can ask for sponsorships to make money.

Open Source Projects

This is also not something everyone can do, so the competition is definitely lower.

You can create an open-source project or work on an existing one.

As long as you make something useful to other people, people will notice.

In the process, you can get donations or sponsorships.

Patreon

Patreon is a donation platform where people can donate to you.

If you contribute something useful, people will donate to your eventually.

However, this is not something that’ll happen often until you get a very large audience.

So you may have to find more reliable ways to make money.

Create Your Own Job Board

Since you have development skills, you can create your own job board and employers can buy posting space on your site.

Each posting usually cost a few hundred bucks, so you can make money fast if you have lots of postings.

Ads may help you here to promote your job board so employers and prospective employees can notice your job board.

Conclusion

There’re many channels you can gain exposure for yourself and make money online as a developer.

Building software requires some basic tools. To build software, we’ll have to use source control and debuggers to track our changes and debuggers to help us step through our code to debug them.

In this article, we’ll look at why and how we should use source control and debuggers.

Source Code Control

We need to check in our code to source control systems so that code change history can be tracked.

This makes reverting our code easy if anything goes wrong.

It’s also very good for letting people review our code since people can see what we changed and compare them.

Also, we can use it to merge people’s code together easily. There’s just no alternative way to merge different people’s code together in a systematic way if there are no source control systems to control the merges.

It’s also great since we know who worked on which piece of the code so we can get help on that part of the code from that person if needed.

Furthermore, source control systems let people branch code so that different people can work on different copies of the same code base and apply their own changes.

Once they’re done, then they can merge their changes in after it’s been reviewed.

Always Use Source Control

With all the benefits that source control systems brings, we should definitely use them whether we work by ourselves or within a team.

If we’re working by ourselves, we can track our own change history and revert code to a previous state from the change history if needed.

If we work on a team, then we use the undo feature plus, we can merge things from different branches in an easy, systematic way.

When 2 branches have code that conflicts with each other, then we can fix them with the built-in programs to diff and merge changes by fixing them ourselves.

Another good thing about source control systems is that some systems like Git are distributed.

This means that one copy of the repository is stored remotely in some server outside our computed, mostly remotely, and the other is stored locally.

It a repository is stored in a remote Git host, then we can treat that as a backup.

Source Control and Builds

Source control systems create the possibility to create automatic and repeatable builds.

A computer can automatically check out the code and then build it with an automated system of some kind.

Also, we can run regression tests automatically on that computer to make sure that our code didn’t break anything.

It’s repeatable because we can always check out the code and rebuild the code to create a new build artifact.

Therefore, it’s time to use control. There’s just no excuse not to use them for any sized project.

Debugging

To make our lives easier when we run into issues with our code, we should use a debugger to see what’s wrong.

With a debugger, we can run each line of the code with the debugger and check the values of the variables that are in each step.

Then we can easily see what’s going on in each line of the code.

With that, we’ll see what happens to our code in no time.

In the end, debugging is just problem solving, so we should attack it as such.

It’s not good to blame people. Instead, we should help each other instead of blaming others.

It’s easy to panic if we’re rushed or have a nervous boss or client breathing down our necks.,

However, panicking is just going to make matters worse. We just got to calm down and ignore everyone.

We shouldn’t eliminate any possibility until they can be proven that they can be eliminated.

This way, we won’t ignore anything. For instance, the error that takes the longest to fix may be a simple typo because we have overlooked it when we’re debugging.

Conclusion

Source code control is a must so that we can revert code easily. Also, it lets us work from a branch of the code instead of working on the code itself.

Also, we should use a debugger to debug, don’t panic and don’t eliminate any possibility when we’re trying to find the cause of a bug.

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.

In this article, we’ll look at mistakes that newbie front end developers make that we can all avoid.

Relying Too Much on Frameworks

Front end frameworks are great. But we shouldn’t rely too much on it. We should still be able to do things on our own if we aren’t using the frameworks that we’re used to using.

Also, we should only learn frameworks once we’re proficient with plain JavaScript constructs and DOM manipulation.

Otherwise, we don’t know why everything works.

Using Bootstrap For Layout

Bootstrap was great when flexbox and grid were releases or when it wasn’t widely available in browsers.

Now we can use both to create layouts for our pages. Even Bootstrap itself uses flexbox and grid for layouts.

Therefore, we should use flexbox and grid for layouts instead of Bootstrap. Relying on Bootstrap too much doesn’t help us too much. And we’ll forget about the fundamentals.

Instead, we should just stick with the flexbox and grid, which makes the layout very easy.

Putting Our Code All in One Place

JavaScript had modules as a standard for a few years, so there’s no reason to have long scripts anymore.

Instead, we should use modules to divide up our code into manageable pieces.

Also, we shouldn’t have global variables anymore. Instead, we have variables we want to export in modules.

If we want to package everything together into a custom component, we can use the web components API to do that. This way, we can use them anywhere.

Projects created with framework all divide our code into modules. They encourage best practices by dividing things into modules.

Not Optimising Images

Many people don’t have fast Internet connections. Even though many parts of the Earth have broadband, they may not be the best quality.

Therefore, we should make sure that we compress images and shrink them so that their file size won’t be too big.

We can’t have many images that are megabytes in size. They’ll still take a long time to download with slower broadband connections.

To test out the performance on slower connections, we can simulate loading our website or app with a slower connection on the Network tab of the Chrome console.

We can choose from 3G, 4G, and a regular connection.

Using Inline Styles

Inline-styles are bad since they clutter up our page. Instead, we should clean them up by moving them to a CSS file.

This way, we won’t clutter up our page with styles and we can reuse the same style in multiple places.

Not Using Heading Tags for Styling Purposes

Heading tags are great for styling and tell us that they’re headings. Suitable headings have an impact on SEO.

Therefore, we should change headings to h1, h2,…, h6 tags if they’re actually headings.

Photo by Alvan Nee on Unsplash

Not Removing Redundant Styles

Redundant styles are a pain. There are things like having 100% width in block elements like divs that are redundant.

We don’t need to set a width of a div to 100% since the default width is to take 100% of the width of the parent.

Chrome often tells us which styles are redundant so that we can remove them if we see that warning in our console.

Embedding Fonts in a Wrong Way

@font-face is for specifying the font name for fonts that have to be imported.

However, we can also specify the weight of the font within the @font-face block to control the font-weight of the font and keep the same name in both the block for the regular font and the one with a different font-weight.

For instance, instead of writing the following:

@font-face {
  font-family: 'Open Sans';
  src: url('opensans.woff2');
}

@font-face {
  font-family: 'Open Sans Bold';
  font-weight: bold;
  src: url('opensans-bold.woff2');
}

We should write:

@font-face {
  font-family: 'Open Sans';
  src: url('opensans.woff2');
}

@font-face {
  font-family: 'Open Sans';
  src: url('opensans-bold.woff2');
}

Then we can just set the font-weight in our style and then the right font will be picked from the font with the right font-weight or other styles on the list.

For instance, we can use Open Sans as follows:

.foo {
  font-family: 'Open Sans';
  font-weight: bold;
}

Then the browser will pick the Open Sans font face that has font-weight set to bold.

Conclusion

Inline-styles are bad, we should move them to a CSS file so we can reuse them.

Also, we should embed fonts properly by putting the styles in the @font-face block.

Finally, we should think about users with slower connections and optimize our assets.

To be a good programmer, we should follow some easy to adopt habits to keep our programming career long-lasting.

In this article, we’ll look at the best practices to apply to make us better developers.

Duplication is Bad

If we have to write the same thing 3 or more times, then we should definitely consolidate them into one place and reference that one place only.

Duplicating things men’s that we have maintained the same thing in different places.

This means more work for us at the end just by copying and pasting in one place.

When we have to perform maintenance, we’ve to find and change things.

If we duplicate things, then we have a maintenance nightmare.

It starts before whatever code we have is shipped.

Therefore, we should stick to the do not repeat yourself, or DRY, principle.

Instead of having the same thing in 3 or more places, we should consolidate them into one place.

2 of the same thing isn’t quite enough for them to be needed to be consolidated since we don’t if we need them again.

If we know that they’re needed a 3rd time, then it makes sense to move them out into their own component.

This doesn’t only apply to code. It includes any kind of duplication.

There’re a few kinds of duplication. They include imposed duplication from environments that makes us keep duplicating things because we’re forced to.

Also, we may be inadvertently duplicating things because we may not that something like what we have already existed for example.

We can also duplicate because we just didn’t both to abstract out things that are duplicated.

Duplication may seem easier at the beginning but it’ll make our lives difficult later.

Interdeveloper duplication may also occur if multiple people on one or more teams duplicate something.

Imposed Duplication

We may be forced to top duplicate something because of requirements and.

Programming languages may require certain structures to be duplicated.

Multiple representations of something may occur if we have to create the same thing in different languages for example.

This kind of duplication is hard to avoid since whatever we need to implement is needed in 2 different programming languages, so we can’t just apply the DRY principle straight up.

Instead, we may have to stick with duplication if it’s a one-off change or we can make a code generator to create the code for us if we have to change the same thing multiple times.

Documentation in Code

Documentation in code may duplicate what we have in our code.

Since our code is supposed to be mostly self-documenting, we don’t need to put in comments in addition to having our code in most cases.

Unless something really needs explaining like if it’s not completely obvious why we’re writing a piece of code to do something, then we need to comment on it.

Otherwise, we just make sure that our variable and function names are clear and following the usually clean code principles like dividing our code into small pieces.

Comments are easily ignored and become out of date, so that’s another reason not to have so many comments that are duplicate of what we convey in our code.

Documentation Outside Of Our Code

We may also be writing documentation outside of our code.

We can also remove most of those if they’re only for internal documentation and let our code explain themselves.

Also, we also have tests to document our code to tell us what the business requirements are, so that’s also great documentation.

Therefore, we really only need documentation for external users of our API or app so that they’ll know how to use it.

This is because they are the only people that can’t read our stuff. There’s no way that they can access our code in most cases and even if they can, it’s not practical for them to read every line of code to understand how to use our API.

Therefore, we need documentation for them.

Language Issues

Programming languages may be making us duplicate things. We may have the same method in different objects or namespaces for example.

This is a form of duplication that we can’t avoid, but since it’s namespaced, we won’t get confused so easily.

Conclusion

Duplication is something that may come in different forms. We may be forced to duplicate something, we may not know that we’re duplication something, or we may be doing it on purpose.

Duplication doesn’t only apply to code, it may also apply to other things like documentation and anything else that can be duplicated.