The original link

The introduction

I know some very talented developers who can easily create amazing software in a short period of time. It is these talents that make the layman curious and adoring about the industry. But HERE’s the sad truth: not everyone is an expert.

Unfortunately, I’m not in the spotlight. I’m just an average, even mediocre developer. If you’re not a genius gamer, here’s how to survive in this industry.

The simplest thing – just Google it

I can’t remember much. Functions and methods in the standard library, parameter locations, package names, boilerplate code, etc., are all out of my head.

So, I had to use Google. I do this every day. I’ve also been reusing code from older projects. Sometimes I even copy and paste answers from StackOverflow or Github. Yes, my development can actually be called StackOverflow driven development.

But I’m not alone. Many other developers do the same. One popular Twitter discussion was started by the creator of Ruby on Rails.

So why is it considered bad in the first place? Because it has several disadvantages:

  • Can lead you to copy bad design decisions or code that is vulnerable to attack by others
  • It creates a dependency mentality: if we can’t Google the content, we’ll have to ask someone for help
  • You can’t work without a net

But I don’t think these are big problems. It can even be your secret weapon. I have some suggestions to reduce its negative effects.

Survival Guide:

  • Use the IDE for auto-completion and advice, so you don’t have to Google the basics of the programming language;
  • Remember where (not how) you solved the problem. So you can always find a solution there;
  • All the code pasted into the project should be analyzed, refactored, and reviewed later. This way we can provide a solution quickly without damaging the project.

Keep everything simple and clear

The machine does what we say. Even when they are wrong, they don’t hesitate. Therefore, the main problem in software development is not the machine, but the mental ability of the developer. And the room for improvement is very limited. So we — as mediocre developers — can’t afford to waste our limited brainpower on creating complex abstractions, fuzzy algorithms, or long, unreadable blocks of code. You need to keep everything simple.

But how do we know if the code is simple or complex? We use the WTFs/Minute method to measure code quality.

The principle is easy to understand. Every time you find something in your code that you don’t understand — oh, it’s too complicated. So how do we do that?

  • Rewrite to make the design cleaner
  • To provide the document
  • Add comments to the most difficult parts. But remember, comments are supposed to describe the code itself

How to keep it simple from the beginning:

  • Use correct names for variables, functions, and classes
  • Make sure that each part of the program does only one thing
  • Pure functions are superior to regular functions
  • Regular functions are superior to classes
  • Use classes only when there is a strong need

I’m not confident

Some developers will prove that they can deliver high-quality code. Take a look at Margaret Hamilton, the lead software engineer for the Apollo moon missions. And what is it that is almost as tall as her? Well, that’s exactly the code she wrote for the moon mission:

But whenever I write any code — I’m not confident. I can make a mess of even the simplest parts of a project. The reasons for messing up include:

  • Language error
  • Logical error
  • Design errors
  • Style error
  • Security error
  • WTF error (my all-time favorite!)

There is no magic book about learning how to write bug-free code. Because all software has bugs — except this framework. We should deal with bugs when we encounter them.

The key point is that no one should write code with obvious bugs. Right, at least, we should be working towards that goal. But how do I protect my project from myself? There are many ways.

Survival Guide:

  • Write tests. Write lots of tests. From integration testing to unit testing. Run the tests in the CI before each pull request. This avoids some logical errors;
  • Use static typing or an optional static type. For example, we use mypy in Python and flow in javascript. The positive: cleaner design and “compile-time” checking;
  • Use automatic style checking. There are many style checkers for every language;
  • Use quality checks. Some tools run complex heuristics on top of your code base to detect different problems, such as too much logic in the code line, the class is not needed, the function is too complex;
  • Review your code. Review it before merging to master. And at some point after the merger;
  • Pay someone else to review your code. This approach can have a huge positive impact! Because unfamiliar developers are more likely to spot inconsistencies and bad design decisions if they’re looking at your code.

Not just for me

About a decade ago, when my team developed our first large software project, we released it as a Java source file. However, it does not compile on the target server. This is only a few hours before it needs to be submitted to the customer. This is a colossal failure! Eventually we managed to get it up and running, but it was an unforgettable experience.

This happens because there is a lot of configuration and complexity in the build pipeline. And we couldn’t manage the complexity of that system properly. So, from that day on, TO reduce this complexity, I tried to package my programs in isolation. And test them in this environment before the actual deployment takes place.

Things have gotten easier in recent years with the rise of Dockers (and often containers). Docker allows you to run development, test, and production in the same isolated environment. So, you’ll never miss anything important.

So what do you do? Speaking for myself, I always forget something when creating a server, initial configuration, or connection. Because there are so many things to remember! Fortunately, we can automate all of this. There are many different tools available to automate the deployment process, and some of them are great: Terraform, Ansible, and Packer. Read the tool information to find out which one is actually needed for the task.

I also try to set up CI/CD as soon as possible. That way, if my build fails during testing or deployment, I get a report.

Survival Guide:

  • Automate anything for deployment;
  • Application development, testing, and deployment using Docker;
  • Use deployment tools.

After the application was deployed, I was still not confident

Finally, my application is in production. It’s working. I can take a break. It should be all right. Wait, no! Everything fell apart. Yes, I’m not wrong: everything.

In fact, there are tools that make it easier to find and solve existing problems.

  • The Sentry. You will be notified when an error occurs to any of your users. Binding to almost all programming languages;
  • Collect logs from multiple processes and servers in one place using different services and tools;
  • Server monitoring. This is where you can configure displays for CPU, disk, network, and memory. You can even see the added time before users actually break your service

In short, we need to monitor the application in production. Sometimes we use all of these tools, and sometimes we only use the parts that are most needed.

Live and learn

There is no end to learning. If we want to write good software, we need to keep learning how to do it. There are no shortcuts and no magic. Make a little progress every day and you’ll get better and better.

In conclusion, we need to understand two basic things:

  • Everyone has problems. The key is to be prepared for them;
  • We can control the source of the problem to some acceptable level.

These have nothing to do with your mental abilities or mindset.


Sorted out some Java architecture and interview materials (microservice, cluster, distributed, middleware, etc.)Hundreds of e-books, partners in need can pay attention to the public number [programmer internal point], as needed to get their own