How is programming different in school than in real life?

[[151621]]

When you first join a company, you will probably need to understand the code base before you start writing code. This process will last at least a month, depending on the size of your project. You will find that you have to use all your knowledge to understand how ancient programmers solved practical problems. Sometimes you feel complacent, "Haha, I use this technique often, you guys are also a little knowledgeable." But most of the time you are confused.

At this stage, your daily work is to read documents, design drawings, read code, set breakpoints for debugging, hack, fix, and ask colleagues.

You're tired. You're bored.

In addition, when you first join the company, you will find that your project team is using some weird tools and unpopular technologies. They are very difficult to use, especially compared with the mature IDE you used in college. You may want to smash the keyboard, "Who the hell came up with this tool! Who the hell wrote such a stupid tool!"

You are disappointed.

Gradually, you begin to understand your business domain, so-called mastering a certain amount of domain knowledge, and you begin to be able to judge which are trade-offs, which are stopgap measures, which are extremely sophisticated designs, and which are legacy codes.

Your leader also noticed this, and began to assign you simple tasks. They might be fixing some obvious bugs or implementing the simplest new features. At this point, you have an illusion of control, you quickly write the function, submit it, and start to imagine that your exquisite code will be praised. Of course, as expected, 10 bugs were found in the 100 lines of code you submitted, 2 of which were serious logical errors, 4 were unrealized requirements, 2 were UI errors, and 2 were unchecked boundary conditions.

You feel really bad, "Fuck, you guys don't even appreciate my awesome code!"

At this point your leader comes over and says casually, "We need to do a code review before submitting."

So you ask a kind guy who often answers your questions to review your code. After 10 minutes, your beautiful code has been changed beyond recognition. You feel like crying but have no tears, but you don't want to offend your senior, so you silently submit this code that you don't know who wrote it.

After struggling for a few months, you start to figure out the tricks, and then you start to use the skills and knowledge you learned in or out of class during college. The boss naturally noticed this, so he began to arrange for you to organize technical exchange meetings. You carefully prepared the PPT, rehearsed at home, and tried to add some high-brow or tasteless humor.

The meeting was a success, and you feel your colleagues start to look at you with new eyes. You start to feel elated, and regain the feeling of "being in control". You think to yourself, "You guys are just coders. I will be an architect in the future!"

Gradually, you start to get into the state, and you submit more and more code. The code specification documents that you never opened when you first joined the company start to come back to bother you, but this is not a big problem. The leader starts to emphasize quality to you, while you complain about the design of the old code in your heart. You want to refactor, you want to innovate, you want to make a big news.

At the same time, a new colleague named Lao Li came to the group. He was an old employee transferred from other departments. The leader organized the group to welcome him warmly. You were not convinced, but he was a good person, and you chatted and laughed happily.

The opportunity has come.

The company needs to implement a demonstration function urgently. Whether the million-dollar contract can be won depends on this time. Your leader has already flown to the client in person to take charge. When he left, he told you, "The team is relying on you and Lao Li!"

You are very excited and have bought instant noodles and snacks, ready to work all night to provide the most powerful firepower support to your leader.

The first functional point has been discussed. The leader sends you the requirements.

You find that you only half understand.

You have heard of some other modules mentioned in the monthly technical exchange conferences, but the code you have written has never called their APIs, and you have never read their code. You are a little confused and start to feel guilty.

Never mind, let’s get started.

You find some similar functions and dig out some moldy old code with comments saying 2004/06/18. You don't have time to read it thoroughly, so you start copying and pasting and debugging directly. Of course, the code reports errors, and you start solving them one by one, and this goes on all night.

The next morning, you finally got the backend part you were familiar with set up, and you discovered new troubles.

It's the front-end. You are not familiar with the front-end. You know that the original name of javascript is ECMAScript, and you know the difference between JQuery objects and DOM objects, but you find that you still can't understand your front-end code.

what to do?

Well, you decided to put on a sullen face and ask Lao Li. Lao Li looked at you and said, "Go to sleep for a while, I'll help you." You felt a little unwilling, a little embarrassed, and a little grateful. You really want to make them yourself, but you can't, and there's no time. You want to learn how he did it, but your brain has stopped working. So you smiled tiredly, "Okay, I'll leave it to you. Take a look here, here, and here... I'll go to sleep for half an hour, and I'll come back to you in a while."

You slept until the afternoon.

You woke up and looked at the clock, jumped up in shock, and hurried back to the office to find Lao Li. Lao Li had already returned to his seat from yours, and was drinking tea leisurely. You asked him with some surprise, "How is it?" He turned around and saw you back, and said, "Don't worry, it has been debugged by the front line, you can go and have some food."

You don't have the heart to eat. You said to Lao Li in surprise, "Okay! Great!" Then you returned to your seat and couldn't wait to open the code and start running it. Just as Lao Li said, the function has been implemented. You breathed a sigh of relief, took out a bowl of instant noodles, and started to work on the code, thinking to yourself, "I must be well prepared this time to prevent trouble next time."

As you read more and more code, you get impatient because you find that the more code you read, the more your brain can handle it. You think about it and decide to put it aside and check your email to relax.

The mailbox was filled with new employee training materials, social event notifications from various departments, and of course the most common were build reports and test reports from the server. Nothing interesting.

You think about what to do next. Forget it, just continue writing new features, the testers are still waiting for you. But you are actually very nervous, your heart has long drifted to the front line, but you know you can't email to ask about the situation, because your boss may not have slept for a few days, and you don't have anything particularly urgent. For the first time, you open the email client and pay attention to every new email you receive.

In this state of anxiety, the day passed. Anyway, there was nothing to do, so you went home, took a good bath, set an early alarm, and went to bed peacefully.

The next morning you rushed to the company, and sure enough, there was an email from your boss in your mailbox, which said, "The demonstration was very successful, the customer is very satisfied, and the next step is the negotiation stage. My fellow developers at home are awesome!"

Of course, you are happy. But you are also a little disappointed. You don't quite understand why, so you think about it. Then you seem to understand that although this is good news, it seems to have nothing to do with you or anyone else. It seems to be a natural thing, without any "holy shit" sound.

After a while, your boss, the project general manager, replied to your boss's email and said, "Well done! I would also like to commend your brothers at home! Come back and have a celebration party!" You felt a little bit expectant and thought, "Not bad," you thought, although you are not the protagonist, you are also a hero after all.

You have been secretly preparing for the celebration party for a long time. You browsed online what to say when having dinner with your boss. You thought of many general and meaningful questions to prove your understanding of the project. You also want to know more about the general direction of the project.

A few days later, your leader came back and everyone held a celebration party. At the dinner, everyone chatted about family matters and your leader's experiences abroad. The big boss knew your name, and everyone seemed to play cards casually for a while, and it ended uneventfully. You felt a little disappointed.

Life returns to normal.

But it seems different from before.

In addition to your development work, you have new tasks, including learning and promoting new technologies. You start to talk with your leader all night long. He shares his experience with you, and you share your experience with him. You start to get involved in his work, such as improving team capabilities, improving automated testing, improving code quality, improving code performance, enhancing functional configurability, etc. You start to calmly accept new work and no longer fantasize about becoming famous overnight. After all, meeting challenges is what you are really interested in.

However, in the following months, you barely submitted any code except fixing the bugs you left behind. Your daily work has become looking at frameworks, reading code, reading technical documentation, learning and testing new tools, browsing technical forums, etc. You begin to feel a lack of accomplishment, and you also miss the green unit test results and your hands flying like playing the piano.

One night, you and your boss were the only ones working overtime. You had been thinking about this problem for a long time, so you asked, "Boss, why is my task different from others?" The boss said, "Of course, you are being trained as a future technical manager."

The sudden happiness overwhelmed you, but you restrained yourself and asked, "What does a technical director do?" The boss did not answer you, but said, "You will know later."

Life goes on.

Xiaoming, who joined the company on the same day as you, is a hardworking, lively and cheerful person, but you feel that he seems to have chosen the wrong career. He always struggles to think about why there are logical errors in his code. Even a piece of code that is simple and straightforward to you is difficult for him to understand. The leader also discovered this, so he arranged for him to gradually develop in the direction of configuration management (CM). However, he seems to be very good at this. No matter how tedious the task is, he can always complete it step by step. He is also familiar with various complicated scripts. More importantly, he is very patient. No matter what strange problems the server has, he will fight it to the end. Everyone likes him and trusts him.

One day, Xiaoming grabbed you and asked you questions as usual. It was a bug. You were used to starting from code review. You confidently asked him to show you the code. However, you did not find any problems. So you asked what the phenomenon was. He said that an error was reported when deployed to the server. You looked at the log. You did not understand. So you carefully rechecked whether all the links were done correctly. Yes, there was no problem.

Well, you know you have a tough problem. But who knows if you can solve it in the next second? You have been in the company for so long, and all kinds of weird problems are already commonplace for you. You open the search engine and start trying to find similar problems. You keep making assumptions, then deny them through evidence, and then make new assumptions... until you break through your sanity and think that there may be something wrong with the compiler.

Really? You never thought that the compiler would have problems, just like you never thought that your liver would have problems one day. You thought it was your fault, so you carefully checked other possibilities, no, there was no other problem. So you opened the compiled bytecode on the server through a decompiler, and you found something subtle. So you followed this clue and continued to search the Internet for the cause. Finally, you found that it was a compatibility problem. You discovered a new world.

Although the problem is complicated, you only need to adjust the code to bypass it, so you quickly modify the code and test it. Hmm, haha, there is no problem. Xiaoming is stunned and asks you, "What's going on?" You feel a little proud. You excitedly pull him over to look at the web page you searched. You decompile the code and compare it with the source code. You explain to him how to implement dependency loading... You excitedly talk a lot, and he listens quietly, blinks, and says, "God!"

Fuck, he didn't understand at all. You are immediately deflated. You have nothing else to say, but you don't know how to respond, so you modestly say "No, no, I'm not an expert."

Despite this, he still follows you and calls you "god" every day. Although you know he is a nobody, it's not bad to be a fake "god". You feel a little smug and want to tell your classmates about it, but you think it's too low. How about posting a status saying "I haven't been a god for many years"? Thinking about it, it's too stupid, so you give up.

Until you realize that there are many other people who are also called "Great God" by him.

Lost?

A little bit.

You are used to this kind of loss. Since you graduated with high spirits, you no longer have that strong feeling of victory. You feel that life is not as unified as you thought before. Everyone has their own completely different strengths, interests, knowledge and experience, and you have yours too. You are not omnipotent. Even though you were always the best in the class when you were in school, you gradually find that the world is still very big and there are still many things you don’t know. There are mountains beyond mountains and people beyond people. The road is long and arduous, and I will search up and down...

At this thought, your train of thought suddenly stopped. You felt that you were really excellent and that you knew how to reflect. You began to feel smug again, thinking that you were such an excellent person, and that you would do something great one day. So you gathered your thoughts and continued to work.

The project is not so tight these days, and you have more time. Your boss is the same. So he recommended a few books to you, all of which are design books, such as Domain Driven Design, Enterprise Application Architecture Patterns, and The Art of Modifying Code. You remembered the books he asked you to read when you first came, such as Refactoring and Design Patterns. You still remember the feeling of enlightenment when you first opened them. You smiled and said "OK".

These books are so well written, you exclaim.

When reading them, you can't help but think of your code. You can understand the phenomena described in the book very well, and you think your code has the same problems. But when the book introduces the solutions, you find it difficult to understand them. The problem domain in the book is different from yours, and you have different requirements and architectures. The book says that such a layer of encapsulation should be done for database operations, but you have a web service in addition to the database; the book says that such isolation should be done for UI and business logic, but your UI does not directly call the backend, but also through the web service; there are many techniques mentioned in the book that you don't need...

You are bored and gradually lose your patience. After flipping through the second half of the book, you feel that you have almost understood the methods in the book. You feel like you have reached the seventh level of the Great Shift of the Universe, and you are eager to find something to test your skills.

You say to your boss with great confidence, "I want to refactor our code."

To your surprise, your leader was not surprised at all. Instead, he asked you with a smile, "Oh, OK, how do you plan to do it?" You had not thought about this question, and after a pause, you said, "Just follow the method of domain-driven design and construct a full-blooded domain model." The leader continued to smile, "OK, how do you plan to implement it?"

How to implement? What do you mean by how to implement? Changing the code is just changing the code, how to implement it? You looked confused.

The leader laughed even more happily, "Do you remember what was said in "Refactoring" that when refactoring the code, you have to ensure that all unit tests pass? But now you want to redesign it, and the unit tests will definitely be useless. You have to revise it. Take a look at this." He took out a book, pointed to the title of a chapter and said, "If you want to do a large-scale refactoring of the code, you have to settle for the second best and use high-coverage automated tests to ensure the correctness of most functions. But this is far from enough, we also have to ensure that the original functions are not damaged, so you can also do this and that..."

You are mesmerized by what you hear. You remember that in school, if you are not satisfied with the code, you can just delete it and rewrite it. You don't even need a version control tool. You have never thought that there are so many complex problems in real engineering and so many smart predecessors have invented various systematic methods. You have discovered a new world again.

After the discussion, the conclusion is that you are responsible for supervising and improving the coverage of automated tests. At the same time, you can construct new model codes first, or submit them, but do not include them in the release. When the new code is written, test it internally first to ensure that there are almost no problems, and then release it strategically.

You get started right away, and you are very excited. "Finally I can write code!" You happily say to your boss. The boss smiles again, "Writing code is not the point, the point is to make it run correctly." You nod thoughtfully, but your heart has already flown to your new design.

You opened the most core business code that you had reviewed and modified countless times, and imagined what it would look like after you modified it, a perfect domain model, highly cohesive and low-coupled classes, elegant code, complete comments, and the admiring looks of your colleagues... You felt like you were about to laugh out loud like Hanamichi Sakuragi.

But the devil is in the details.

You find that you don’t know how to change the first line.

It's a log.

You thought about it for a long time, but couldn't come up with any ready-made solutions. You asked yourself, is the log considered business logic? If it is, it has many dependencies on the framework; if it is not, where should it be placed? You spent a whole afternoon looking at the log code, but still have no idea. You feel that the log is simply a killer that destroys your elegant code, and you really want to delete them...

Forget it, don't think about it for now. You decide to give yourself a day off today, go home early, watch a movie and go to bed.

As soon as I opened the door, wow! It was snowing outside.

Snowflakes are dancing in the sky, sweeping away the bleak scene of ordinary nights. Under the dim street lights, the snowflakes reflect warm light. You think of your hometown in the north. Friends in the north say that the damp and cold weather in the south of the Yangtze River is unbearable, "It's as cold inside as outside." But you have a different feeling at this moment, and you think it makes sense to say "It's as warm outside as inside."

Maybe that's how life is. You think, you're not always happy, nor are you always disappointed. Your expectations always sneak into your life in a cunning disguise, while your pride always slips through your fingers, and you can't hold it. But no matter what, you feel happy and blessed. You are glad to be a programmer. You feel proud of yourself now.

Realizing that you have been standing at the door for a long time, you smiled, laughing at yourself for becoming so sentimental. You walked out the door, stepping on the snow, making a crunching sound...

[End of article]

[The programmer's story is not over yet]

/** Postscript

I really didn't expect that everyone would like this short article (I don't even know if it can be called an article) so much. My original intention was just to describe the differences between work and school through some real details, but who knew that it would become a story as I was writing:-D

In fact, there are more interesting stories behind this, but I have gone too far. If you want to hear them, bring some good wine and come to me!

As for Lao Li, whom you are concerned about, he is real, but he is not a sweeping monk. He is a front-end god. Later, he completely rewrote our front-end JS code. He is in his thirties, has thick hair, and has a lovely little daughter. He doesn't talk much, but likes to tell jokes with connotations.

The story has been processed and is both true and false, and the characters are not completely restored, but I am very happy to see your comments saying that it is very real!

Finally, as an engineering guy, I decided to summarize:

The amount of code you write after work is far less than the big assignments in school, but it needs to be more rigorous;

But you have to deal with a lot of legacy code, and you have to understand it, unlike in school where you basically reinvent the wheel from scratch;

Colleagues are all different, each with their own strengths. No matter if you are a big shot or a flatterer in school, everyone has made contributions to the company in one way or another.

You can't know everything. Work is the beginning of learning, and university life just prepares you.

In addition to code and technology, you also need to consider business knowledge, testing, quality, productivity and sustainability;

There are always opportunities, all you have to do is be prepared;

What you learn in school is very useful, but there is a huge gap between theory and practice. It all depends on your experience and engineering judgment.

That’s all I can think of for now, and you can find out more by yourselves.

Finally, I wish everyone who likes programming can become an architect!