10 programmers must learn to accept the brutal truth

Most of the time, writing code is a very meaningful thing, not only to increase the experience, solve the problem is also particularly cool. Patience, perseverance, persistence, coupled with the right tools-as long as they have close collaboration, elegant, beautiful code is extremely easy.

But, with the rough deployment of resources, new feature requests, and bad document updates, it broke our dreams.

But that is not to say that our efforts are worthless. It's just that we need to face reality. Here are 10 brutal truths that programmers must accept.

The brutal development of the truth No. 1: Programming is the use of If-then-else statements

Programming language designer discussion, abstract thinking and so on as, in fact, are simply repackaged on the old If-then-else statement.

This is almost all the functionality of the hardware. Yes, we can smoothly move the data input and output for operation and storage by opcode, while the rest are branched or not branched on the basis of comparison.

And the comrades dedicated to artificial intelligence have wrapped up a mysterious cloak for these if-then-else statements, and the machine will automatically perform calculations from some number matrices as we say, searching until the target is found.

The brutal development of the truth No. 2: The Internet is actually the data stored in the table

Over the past 20 years, the word "Internet" has created fabulous wealth, built up all corners friendships, produced cheaper products, facilitated faster communication and so on, and so on, in addition to treating cancer, it is almost omnipotent. But ultimately, the essence of the Internet is a bunch of data stored in tables.

Match.com? is the form of Lie hair color, religious beliefs and hobbies. ebay is a transaction sheet that records a sum of contracts. Blog? It's just a list of every row in each line. Write down your rambling data sheet. No matter how we name it, it's essentially a data table.

This can also be seen in the programming language. For example, Ruby on rails--One of the most popular programming languages in the web, in fact, is to make a niche in the database: Specifying a global variable, Rails will automatically create a column, because its role is to create a table in the database.

The brutal development of the truth No. 3: Users have their own ideas

Occasionally users become sensible and sensible, but in most cases they are eccentric and elusive-even very demanding. programmers simply can't imagine what these users would think when they saw the product. Because users are not programmers, they do not follow the programmer's idea.

The brutal development of the truth No. 4: Most of the code you write will never be used

This point will not say more, said more is a tear ah!

The brutal development of the truth No. 5: Changes in demand are inevitable

One of the managers told me that his secret was a smile and his team said they were great, he admired what they had done, and then he said, "Right, there's one more thing ...". This is the thing that tends to subvert the entire project and bring everyone back to the beginning of the design app.

Demand change is a direct consequence of the project structure. The manager will do all the planning and set goals before the event is carried out.

But once the matter is given to the developer, the manager is relaxed, and then he starts to sit around and be fussy. This is where the button is placed, right? Should I change the login page? Anyway, a little bit of idea lets the developer make the change.

This occurs frequently in the course of the project and is long-standing. To be sure, even the ADA Lovelace's analysis machine, known as the first computer program, also has a problem with the need to change, stemming from nearly a year of note-taking discussions.

The brutal development of the truth No. 6: No one understands you, especially your boss.

We can divide the programmer into two kinds: the first kind of boss is not programmed, and do not know how much effort is needed to make the code compile successfully, and a kind of boss who used to be a programmer but has now forgotten the difficulty of compiling the code.

The first kind of boss will obviously never understand you and your job. However, this is understandable, after all, the study is different, the surgery industry has specialized.

And the second kind of boss, we can understand. For example, even the best programmers will forget about this if they don't use the API for a month or two. and the mainstream programming languages they used to learn are likely to be quite different from what they are today.

Also, if your boss knows how to solve the problem, he will often choose to stay up late to solve it rather than take time and effort to hire other programmers to solve it. So we have to thank the bosses who don't know how to write code.

The brutal development of the truth No. 7: About privacy, pain in the tangle

We all want our services to protect our users and their information. But at the same time, we want the Web page to be simple and easy to operate. Click Depth-the number of clicks needed to reach your goal-as little as possible.

However, protecting the user's privacy means asking the user questions before the user points to the page to make sure that the user is aware of the possible consequences of doing so.

Privacy also means responsibility. If the user doesn't want the server to know what's going on, the user has to be self-responsible because doing so will cause the server to not be able to read the user's data. Responsibility means trouble, and on this level privacy is a problem.

Privacy also means contradictory logical thinking. Hoping to be alone, hoping to know a lot of information, wanting peace and quiet, and hoping for invitations, shopping coupons, job interviews, and so on, on the other side.

Alas, as the saying goes, the fish and bear can not have both. In short, privacy is not private, it's a question.

The brutal development of the truth No. 8: Trust comes at a price

Project Web 2.0 sounds beautiful! It feels like a miracle happens as long as you connect the code together. You can call other people's code, others can call you, and complement each other.

If only it would be as simple as you think. The fact is, first you have to fill in some forms before someone else allows you to use their code--most of the cases drafted by professionals--to sign an "unequal treaty". What is your return? Give someone the beautiful code you've worked so hard to write about, but don't know what the others are giving you? But, no way, you can only trust them.

But they don't know if you really have the real material? You're just a impostors guy, aren't you? But they also have no way, can only trust you.

And the user has to trust both of you. Ha, you mean privacy? Of course, everyone promises to use the highest level of encryption, but at the same time share your information openly with everyone else. But you don't have to worry about it.

The result is that you have to spend more effort and more work on the project than you expected. This is the price of trust.

The brutal development of truth No.9: Software has a certain life cycle

When you start a new project, you will often take advantage of everything from the latest repository. The 1.0.2 version of Library A is now available, but it cannot be compatible with the latest version of library B, as library a programmers remain on previous releases. Then library C publishes some of the new features your boss really needs you to tap. Of course these features are only available for version 1.0.2.

If the decay of houses and boats is in a way that subtly "moisturizes", then the code collapses in a complex and swift form. If you want library C, then you have to give up library B, again, if you choose Library B, you have to explain to your boss why you are not directly using library C.

Of course, the case I'm holding consists of only three libraries, but in fact there are at least 10 of them in real-world projects and more problems. What's worse, many times we don't see the trend of extinction. Sometimes it may even seem like a trivial problem, and it can be solved immediately by writing a little bit of code. But it is often such a small incompatibility that the termites eat up everything until the building collapses.

The existence of the life cycle allows us to understand the computer more profoundly. Do not think that the code is not friction, no oxidation, no microbial reproduction, is eternal, can be immortal, it is not the case.

The brutal development of the truth No. 10: Survival and development in the wall

Even though we have repeatedly stressed the importance of openness, there is growing evidence that the market is still small. To make matters worse, many people tend to be reluctant to invest in the cost. Some free software advocates insist that society should provide free software. In short, few people want to spend money on software.

This may be why Linux and BSD's biggest followers hide their proprietary code. TiVo-like devices may also use Linux internally, but the interface that makes them look different is not open. The same is true for Macs.

Casually speaking, the Linux system today is significantly more than the Windows system. People will think the same money on this side only enough to buy a Linux system, where I can buy a Windows computer, how does the system have any relationship? How to choose the user can imagine.

I just hope that in the future more and more people will be willing to pay for the license on the software, so that our industry can survive this four-walled environment.

10 programmers must learn to accept the brutal truth