Abandon student thinking

Work is not study, there is no concept of preparation

Work is not learning. There is no concept of preparation. Most of the time, you are not allowed to learn before you do.

What has been done by hand is not necessarily his own

What you do is not necessarily yours, don’t indulge in reinventing the wheel, and don’t put your written wheel into production (except macho man).

My last company was a project, three or four ORM tools with repetitive functions, and when I looked at the code, I was like

You don’t have to be completely independent

When doing the problem, the teacher will always emphasize that the problem must be completed by you independently, but the work is not to do the problem, the work is the pursuit of efficiency, when you encounter difficulties, after thinking there is no answer, you should turn to the search engine for help, no more, it is necessary to ask the mentor/colleagues, seek directional guidance

Asking for guidance will help you grow better than someone telling you the answer

Listen patiently to the advice others give you

Work for a long time, if someone is willing to give yourself some advice to improve some points, in a certain direction development, these Suggestions are very, very precious, so if someone give you advice, be sure to listen patiently, if you feel the other party that makes no sense, or unsuitable, smile to the past, Don’t approach these suggestions with a “you’re teaching me what to do” attitude, or you’ll get hammered!

Just entered the company, see more, do more, talk less

Just entered the company may have a cavity blood can not help but want to spray out, but please resist, really resist!!

Even though you may be imagining yourself working at this company until 5:30 a.m., even though you may be fast-forwarding to a scene where you’re there giving directions, you really have to hold back, hold back!!

When just entering the company should see more and do more, think that the blood is very likely to someone else once spit out an old blood, first feel clear rules, stand firm, first see, understand why it exists, while working while understanding, slowly, see more and do more and understand, there is always a chance to let you display the ambition in the heart.

Learn to ask questions and improve in discussion

Asking questions is a very expressive job, and being able to articulate a problem to others is half the battle.

I think to express a question well, you need these points:

  • Where (environment, account number)
  • What’s the problem
  • Expected (what is achieved), actual value
  • What is your thinking (does anyone else have a better idea)

Here’s an example:

  • In the test environment, the updated data cannot be queried after the database work order is executed normally. Is the address of my work order execution database incorrectly filled? Or did the work order go out of the warehouse?

A good question can lead to discussion, and the process of discussion can lead to the idea of solving the problem

Learn to pay, but pay not at will

Learning comes at a price. You need to put in enough energy and money. There are a lot of great platforms for paying for knowledge (e.g. ** time I use)

But paying for knowledge is shopping itself, and since it is shopping, there will be times when it is irrational

“This course is cheap, I’ll buy it now, I’ll see it later.” There is usually no future

You need to get rid of the thrill of ordering and learn to get the thrill of learning the course itself

Besides, not all courses are needed by myself. I generally divide the contents of courses into three categories:

  1. Introduction type, speaking concept, speaking demo (may follow the official website), may add some of their own understanding (for example: XX days introduction xx language)
  2. Actual combat (dry project) type
  3. Design class, actual combat class experience summary

If the first category takes up a large part of the course, the best way to get started with a pass is on the official website, where you can talk about concepts and demos, and the quick start and manual on the official website are the most clear

If categories 2 and 3 occupy a large part of the course, decide whether to start or not based on whether your work involves the use of the technology and your own interests

In general, I think the main goal of knowledge payment is to learn the practical experience and design experience accumulated by others, basic entry of this kind, see the official website for quick entry and documentation

Endure the days of sitting on the bench, quietly work hard

Every programmer wants to work on high-concurrency, high-data projects, but even in large companies, there may not be many such projects, only a few holes

Most likely, the project you get is tens of QPS, hundreds of thousands or millions of data (maybe not even at all).

No entry or C a chance and don’t feel disappointed, sit the bench first, from the side projects, kept digging some points (for example code specification, coding techniques, the project have the risk of OOM, timing task if there is any need to change to real-time, synchronous if there is any need to change to asynchronous, etc.), mining projects more points, familiar with the project, First do your job well, enhance your knowledge reserve, and then wait for the opportunity

Of course, if you can’t wait for the opportunity, you can also run, young, low cost of trial and error, just not too often

Write code from comments

Since graduation, I have always maintained a coding habit of writing comments before writing code, and putting key steps in comments before writing code

func receiveAward(userId int64) {
  // Supertube role
  
  // Basic package
  
  // Whether to cross the level
  
  // Whether to repeat the collection
  
  // Create an order to get a reward
}
Copy the code

While this coding habit isn’t necessarily advanced, cool, or even schoolboy, I enjoyed it and found it helpful in clarifying my coding thoughts

Unit testing is a really good thing and must be taken seriously

I remember my former leader told me that when he was working in XXX, what he wrote most was unit test

I didn’t believe it at first. Who writes unit tests?

I thought, well, there’s no problem with testing, isn’t that the end of it?

It wasn’t until I took over an old project to write unit tests (to improve single-test coverage) that I realized I was wrong, and very wrong

During the process of writing a single test, I found a number of code bugs (including overreach risk, improper transaction usage, unnecessary code logic, etc.) and I was shocked at the fact that this was a tested and proven application that was stable in production, with a large QPS and data volume

I went over the story later, and I concluded two things:

  1. The job of testing is not to find all the problems, but to find as many problems as possible. After all, they are not the ones who write the code.
  2. By writing unit tests well, you can avoid problems in advance that your tests might not find and improve your code robustness

Make time to talk to friends