Be a software engineer making more than 130k USD per year

15 min read

Be a software engineer making more than 130k USD per year

Caution

The book is heavily opinionated.

The book doesn’t provide any step-by-step guide. But it offers you solid perception and direction towards being a successful software engineer. The term 130k USD is relative. It might be very less or high depending on where you live. Here I share my learnings trying to be a successful software engineer. I may be in this field for a long time, but that does not make me an expert in all possible fields. I share only what I know.

If you love the book, please let me know. I would highly appreciate it if you can rate the book on Gumroad.

I would like to thank you that you purchased this ebook and want to start your career as a software engineer. You might already be learning to program or you are already working for a software company. This book is for all of you.

Thank you and all the best.

Table of Contents

Caution

Table of Contents

What’s up? Who am I?

Get your expectations correct

Focus on your learning

Projects, projects and side projects!

How to start? Any roadmap?

Fail Fast

Be flexible

Communication is the key

Boss is always not correct

Be responsible, take ownership

Go remote

Job Security

What next

What’s up? Who am I?

I am Sandeep. I studied electronics in my college where it had a very basic course in computer programming. I am mostly self-taught and started my career with PHP and XAMPP.

I am from a place where I am very fortunate enough to earn in dollars. My father used to earn around 10,000 INR (133 USD) a month. I have struggled my whole childhood with a lack of money. I studied in a government school and completed my engineering with a 100% scholarship.

I received my first computer in 2014 and I started to learn to code. I found it very interesting and I was spending 10+ hours learning to code and building stuff. In August 2016, I landed my first internship. Then in 2017, I started to earn via a programming job.

It was a Data visualisation company and I was writing vanilla javascript to render some mathematically heavy charting solutions. I was paid 390 USD a month. It was good but not enough. By then I could understand that I am being paid a lot less but I had no choice.

In 2018 I found a FB group called Hackathon Hackers and back then I had a craze of building Android Games and I end up building and publishing one Android Game in the play store. I was sharing my progress in building the game in that FB group. In 2018, I was making around 1000 USD a month.

In Nov 2018, I received a Facebook message request offering me a remote job. I was interviewed and I was given a small project to execute. I completed the project and submitted it in time. The guy hired me for the remote job and I was offered 3400 USD a month. I was so happy 😀 and my life changed after that.

Now I am making around 135K USD a year, from Kolkata, India for a company based in Los Angeles, USA. All thanks to remote working.

Follow me over Twitter

Get your expectations correct

Now you can find a ton of tutorials online on how to be a developer, how to start learning programming or learn python in 30 mins. I do not want to sound rude but it’s never possible to learn something in a few days. But it’s possible to start something in a week. You might question me that there are thousands of people who are coders and make a living out of it. This book is not about how to be a common developer, the book is all about how to excel as a developer, how to shine in the crowd.

This book is not for people who don’t enjoy programming. If you do not enjoy building software, if you do not enjoy creating stuff that people can use online then this book is not for you. If you want to make a good living from programming then you must enjoy coding.

You must like changing the color theme of your code editor, you must enjoy changing the font of your code editor. These are the very small, very small kinds of stuff that make you apart.

Focus on your learning

When we are starting to code, we do not see the bigger picture. This means we try to choose newer shiny technology/libraries over traditional programming languages. An example would be people starting to learn Reactjs before even learning javascript. This works for a few days but you can’t go much if you keep on doing these.

I always encourage people to learn an object-oriented programming language with great depth. Now you will ask me how I can master a language. You can’t master the language but you can use the language so much that there would be no barrier between your thinking and coding.

This means you won’t be thinking much about the syntaxes and system designs because you would always do it the correct way. You would only care about how you can improve the current system and all you care about is writing quality code.


People judge others on how they park their vehicles, in the same way, people will judge how you write readable code. There are some rules to be followed when learning a language. Pay special attention to variable naming, function namings, and modular design of the solution. Identify the modules you need to create to arrive at the final product. Then code those modules part by part.

Your code may not contain comments if you can write readable code. A function must do a single task. If you need to do multiple stuff altogether you must break the function into multiple functions and name the functions correctly.

Projects, projects and side projects!

As a fresh grad, you must know algorithms. You should be comfortable using arrays, linked lists etc. But once you start building real-world projects on your own, you get to learn more. You learn how the frontend talks to the backend, you learn how different systems work together, how login works, how oauth2 works, how you can use different APIs to add excellent behavior to the app. How there can be multiple frontends (app, web, desktop) with the same backend.

So chances are you learn more about the entire ecosystem once you start building your app or website. Once you are done with adding features, you will dive to share that with your friends. That time you get to learn about hosting, deployments, continuous integrations etc.

If you see bugs in your app, to solve them, you learn about tests, integration testings, test-driven developments (TBD) and unit tests. You would learn the importance of tests.

If I simply tell you that tests are important you would never take them seriously. But once you have a project on your own, you would feel the importance of having tests.

The main takeaway from this is projects are the most important aspects to becoming a very good developer. You can even show that off to your future employer. How you have solved one particular issue. All these matters!

You must start building something as you read this book. You just start. The rest of the learning would happen automatically.

Around 4.66 billion users use the internet. Imagine yourself as the creator. You get the chance in building kinds of stuff that these people can use.

How to start? Any roadmap?

There is no syllabus for being a great developer. You will encounter the following or similar roadmap for being a web developer in 2022

HTML & CSS -> JavaScript -> React -> Nextjs

This doesn’t scale well. There is an entire book written by Kyle Simpson about how we do not know js. We can only learn by doing. You may need to dedicate more than 5 months to learn javascript and it may need more if JS is your first programming language. The fun fact is I am still learning CSS.

The most important skill of a developer is that you know how to use google and you know how to find the path for your learning. Sometimes you will encounter some issues in the system, for that particular situation only you may need to assess multiple technologies.

It might happen that you are hearing the names of these technologies for the first time. You should not be afraid of the new terms, new stuff. Start with the documentation available, start looking at the example codes, try to find the community around that technology, try to use it for a while and ask smart questions in the community. People would help you. But try to be as specific as possible. Do not expect that people would be writing code for you.

Let’s take an example. Let’s say you would like to learn svelte. I choose svelte because it’s a little less popular than react/vue/angular. Do the following in order

  1. Google the term svelte
  2. Open the first 5 links
  3. Before diving into the code, try to learn about it, what’s its purpose
  4. Watch 3 or more youtube tutorials
  5. Read 3 or more blogs around svelte
  6. Open the terminal and code editor and try building something svelte following their quickstart guide
  7. You may hear of server-side rendering in react, now google svelte ssr and try to read about it
  8. Google svelte ui components, google svelte social login etc

You got the idea right? You need to learn on your own while building something. It sounds boring but it works well for everyone. If you learn something new or solve a new critical bug, try to write a blog on it and share it on social media. You never know how you may get hired to your next company.

Just start learning to code. Rest will happen automatically.

Fail Fast

You can invite your friends to help you finish your project. This would teach you how people work in teams. In the initial days, we tend to do everything on our own. But that’s not the case in big companies.

If you and your friend struggle to understand your 4-month-old code, that means we need to improve your documentation and the way you write the code. Your friend may code or come up with solutions different from yours. That’s fine. But you and your friend must agree on a middle ground.

Let’s imagine you are stuck on a problem and are not able to fix it, then you must declare the situation to your friend as soon as possible. This is very important, in this manner you will save important currency in the development that is TIME. The goal is to waste as little time as possible.

Be flexible

Imagine the phones we had in 2009, and now they see the smartphones in 2022. They have changed significantly. You can not expect something once you learn something and you do not need to learn anything afterwards.

I would say the market is pretty competitive and companies prefer people who can learn things fast. I mean fast. You should not be afraid of new technologies. You should not be afraid of reading the documentation. Smart people expect that you are capable of learning something on your own and doing good.

If you require training or mouth feeding, that means you need to go back to your initial learnings. Once you start using multiple technologies, the easier it gets for you to learn new technology.

Initially, you would watch youtube videos to get to know about new technology, but once you have some 2 years of experience building, you would open documentation or may even check the source code of the library to understand. You would find bugs in other libraries.

Communication is the key

A business person does not care that you have spent the last 6 hours making the CTA button beautiful, or you have spent the last 5 days fixing that critical bug. The Sooner you know this it’s better for you.

You need to communicate with all of the stakeholders about your progress. You should be speaking in clear, simple terms so they can clearly understand your thoughts.

If you require audio calls or video calls or meetings to explain any topic, then there must be something wrong. People’s time is very important. If you can not communicate with people in written form, then you must improve.

People prefer if you write the entire issue in one single written communication. Do not expect them to reply as soon as they receive it. Then it defeats the whole purpose of async work. They also expect you to be in deep work mode and do not expect an instant reply from you.

Boss is always not correct

As a developer, you tend to know more about the situation. Sometimes your boss may propose a solution and all the developers try to follow that without questioning. It may happen that once you start using that solution you get stuck and there can be a better solution than your boss’s solution. You knew about it but you never mentioned that to the team.

Understand one thing, your boss might not be spending time with the codebase. He might propose a solution that worked well in the past but it may not be a good fit in this scenario. You understood that while the team was discussing your boss’s proposal but you did not speak it aloud.

You must speak or propose your solution. You must have a direction. That’s how you would be better than others. You should believe in your instincts and your learnings. If you go against your boss or the leader, it won’t hurt them at all if they are capable of being a leader. They would be happy if you cross-question them. Technical debate is a good thing. It makes the product better.

Be responsible, take ownership

Take 100% responsibility for your work and tech decisions. If you have developed a feature, take the whole ownership. Do not blame people for bugs. A tech company works as a team. It’s your responsibility to educate people on things developed by you. It makes you a good developer. If a bug occurs, do not hide.

Bugs are part of the software. It has been seen that the original author of the code solves the bug much faster than other developers. If you search code ownership on google, you will find something like this "The individual is responsible for making changes to the code, making the design decisions, and for managing bugs."

If you help your company at a critical time, the chances of being promoted are higher. Hence I do encourage you to improve on your analytical thinking for fixing mission critical bugs. Hence whenever you join a new company, try to gather information around how different systems work together. Do not just focus on your designated codebase.

Go remote

The future of work is remote or in fact, the present of work is remote. Every company is looking to add more remote employees. It’s the golden era for remote jobs.

You can almost double or triple your current salary if you start working remotely. If you are already working remotely due to covid, I do encourage you to find remote jobs and apply to as many jobs as possible. I recommend applying to 40+ remote jobs based on your skills.

Some tips

  1. You must have a good solid online presence. Example Github profile, personal website, blogs, LinkedIn etc. Please work on improving them.
  2. Read the job description and research the company before applying. Also, try to adjust your resume and cover letter after reading the job description.
  3. Make a single-page resume, please. Projects on the top. Your degree doesn’t matter here, only your skills matter.
  4. In the interview, try to convey that you are very responsible and able to complete any given task without procrastination.
  5. Follow up and offer logical help improving their current product.

If you do all these correctly, you do have a very good chance to land a high paying remote job.

While hunting for a remote job, you need to understand that you are competing with the whole world. Unlike in a physical software engineering job, where you are mostly competing with the engineers based in that city/country.

Job Security

Job security is an illusion. In a physical job, people get to see each other and they do make good relationships. Thus people do have a notion that office jobs are more secure. It’s kinda true.

Once you join a remote company, you should start meeting with everyone and try to add value to the company from day one. Chat with everyone and ask sensible questions after doing your own research obviously.

Firing, hiring, onboarding is a lot easier in a remote-only company. But once you take ownership and do have a good amount of responsibility upon you, you do not have to worry. Your skills are your security.

What next

  • Go and apply to as many remote jobs as possible. You can use https://remotefront.io for the same.

  • Rate this book on Gumroad if you liked what I have mentioned here

  • Again I am emphasizing building side projects. All the best.

If I can do all these from Kolkata, India, none is stopping you from doing the same.

Checkout docswrite.com for starting a blog from Google Docs.

Join Docswrite.com Blog mailing list

We won't spam. Pinky promise

Powered by ⚡ docswrite.com