The original link: https://dev.to/sobolevn/i-am-a-mediocre-developer--30hn
Copy the code

I personally believe that some programmers are geniuses who can easily create amazing software products. We have so much to look forward to in this industry because of this talent. But here’s the sad truth: not everyone is a master programmer.

In fact, this is me, a mediocre programmer. This article will guide you as a non-genius programmer on how to survive in this industry.

I’ve always googled the simplest technology

I can’t remember much. For example, functions and methods in the library, the locations of parameters, dependent package names, boilerplate code, and so on.

So, I need to Google it, every day. I also reuse code from older projects and sometimes copy other people’s code from StackOverflow or GitHub. Yes, I am a programmer for StackOverflow.

But I’m not alone. There are many, many programmers like me. The author of Ruby on Rails once had a very popular Tweet.

What’s wrong with writing code this way? It has the following disadvantages:

  • You probably copied it from someone else, and it was bad design or bad code.
  • It’s easy to get into a bad mindset: if you can’t find it online, “Houston, we’ve got a problem.”
  • If there is no Internet, then you can’t work.

But I don’t think it’s a big problem. It can even be your secret weapon. I have several suggestions to mitigate these negative effects.

Survival Rules 1

  • With IDE code completion and hints, you don’t have to search for the basics of the language.
  • Remember where or how you solved the problem. The next time you encounter the same problem, just take a look.
  • Any code you submit to a project should be analyzed, refactored, and reviewed later. By doing so, you don’t degrade the project with bad code, but rather help it get a quick solution.

Keep things simple

Machines do what we say. Sometimes machines do the wrong thing simply because we give the wrong instructions. The main problem in software development, therefore, is not the machine, but the thinking power of the developer. This ability is limited. So, as mediocre programmers, let’s not waste our brains creating complex abstract designs, writing obscure algorithms, or long, unreadable blocks of code. Keep it simple.

However, how can we tell whether this piece of code is simple or complex? We need to use WTFs per minute to measure code quality. WTF = What the Fu**

This rule is very simple and easy to understand. If you find something in your code that you don’t understand, it’s complicated. What should you do?

  • Rewrite the code to make it clear
  • To provide the document
  • Add comments in the most difficult areas. But remember, too many comments are, by themselves, a bad taste for code. (See 22 Code Smells)

Rules for Survival 2

  • Use the correct variable, function, and class names
  • Make sure you only do one event per part of your code
  • Use pure functions in preference to regular functions
  • Use regular functions in preference to classes
  • Use callbacks only when absolutely necessary

I don’t believe in myself

Some developers have proven that they can submit high-quality code. Like this goddess: Margaret Hamilton, chief software engineer of the Apollo program. In this picture, the paper next to her, of equal height, is the code that was written for the moon mission.

But for me, no matter what code I write, I don’t trust myself. I can mess things up pretty badly even with the simplest part of the project, which might include:

  • Language error
  • Logical error
  • Design errors
  • Presentation error
  • Security error
  • WTF errors (my favorite)

There is no magic book on how to write bug-free code, so these errors are normal. All software has bugs, just get rid of them.

In fact, no one is allowed to write code with obvious errors. So we should at least try to do that. How can I protect my own project? Here are a few suggestions.

Survival Rules 3

  • Write test cases, write lots of test cases. From large integration tests to small unit tests. Perform CI continuous integration before each pull request, which will reduce some of your logic errors.
  • Use static data types or optional static types. For example, we use mypy in Python and flow in javascript. The benefit: clear design and compile-time type checking.
  • Use an automatic style checker. Every language has a number of style checking tools.
  • Use quality inspection tools. Some tools run complex heuristics on top of your code base to detect different problems, such as too much internal logic for this class, too complex for this function.
  • Review your code. Review is sometimes required for code before merging into the main branch.
  • Pay someone to review your code. This has considerable advantages, because when other programmers first look at your code, it’s easy to spot inconsistencies and bad code design.

It shouldn’t just work on my computer

Almost a decade ago, when my team finished its first large software project, we released it as a Java source file. It failed to compile on the target server a few hours before we presented it to the client. It was a big accident. Eventually we got it up and running, but it was an experience of a lifetime.

That’s because there’s a lot of configuration and a lot of complexity in the build pipeline. We didn’t have the ability to properly manage the complexity of the system. From that day on, to reduce the complexity of this step, I tried to package the application in a separate environment and test it there before actually deploying it.

In recent years, with the rise of Docker (and containers in general), this has become easier. Docker allows you to develop, test, and go live in exactly the same standalone environment. This way, you won’t leave anything important behind.

Is bad? Speaking for myself, I always miss something when setting up a service, initializing configuration, or linking something. Because there’s a lot to remember. Fortunately, we can still automate. There are many great tools for automated deployment. Such as terraform, Ansible, and Packer. Check their documentation to find the right tool for you.

I also tried setting up CI/CD for continuous integration and continuous deployment. I get a report notification when automated builds fail during testing and deployment.

Survival Rules 4

  1. Everything is deployed using automation
  2. Use Docker as a development, test, and production environment
  3. Using deployment Tools

After deploying the app, I still didn’t trust myself

Finally, my application is up and running in production. I can take a nap and nothing will happen. Wait a minute. No, everything’s gonna fall apart. Yes, everything.

In fact, there are tools that can easily find and fix current problems.

  1. Sentry. You will be notified when any of your users generate an exception. Sentry already supports almost every development language.
  2. A variety of services and tools allow you to collect logs from multiple programs in one place.
  3. Service monitoring. You can configure monitoring for CPU, hard disk, network, and storage. You can even determine when service expansion is needed before users actually overwhelm your service.

In short, we need to monitor the production environment. Sometimes you’ll need all of the above, and sometimes you’ll only need some. Judge according to your own circumstances.

Continuous learning

Wow, there’s so much to learn. But this is how I live. If we want to write good code, we need to keep learning. There are no shortcuts to success. All you have to do is learn how to get better every day.

To sum up, we need to understand two basic principles:

  1. Everyone has problems. The most important thing is, are we prepared and to what extent are we prepared for these issues.
  2. We can reduce the source of the problem to an acceptable level.

It has nothing to do with your mental ability or mindset.