This is the fifth day of my participation in Gwen Challenge

The original address: thecodist.com/article/les…

Having been a programmer for over 30 years, I’ve learned a few things. There are some good suggestions, and I bet I can make more.

  • Customers know what they want only when they see it

I learned that from my first job. Customers won’t realize what they really need until you show them what you have. Functional prototypes are always better than lengthy presentations.

I don’t know what I want, but when you make it, I know what I don’t want.

  • Given enough time, all security will fail.

In today’s world, security is a huge challenge to correctness. You have to be perfect all the time, but a hacker only needs one hit to break you.

  • Given that your security will fail, the consequences depend on whether you plan ahead for the situation.

If you set up an attacker who will eventually break the defense, you need to plan for what happens. If they get into the system, it’s less likely that the security incident will make national news simply because you used some security measures correctly that prevented them from using what they stole, such as making the database unreadable or isolating the servers from each other. Deep defense always defeats shallow attacks.

  • Good security is not an expense, but a strategic asset; Poor security is a high price to pay for assets.

Throughout my career, I’ve heard people complain about how complex or expensive it is to properly maintain system security, but if you fail, you can lose billions of dollars. Losing your company to save a few dollars is stupid.

  • It’s hard to make something that looks simple complicated. It’s easy to make something that looks complicated more complicated.

This is true in programming, design, and almost any creative act. I’ve always tried to write code that is as simple as possible for me (or anyone else). If you try to make your code too complex or too clever, it’s less likely to work. Of course, I’ve seen some permanent code that the programmers have worked hard to make unintelligible.

  • Success comes from learning from mistakes; Failure is the belief that mistakes are normal and tolerable.

I’ve heard a lot of people claim that because programming isn’t sustainable, mistakes are normal and bad software is inevitable. People also learn to live with controversy because they’ve heard it so many times. However, as a programmer, you should not accept this and try to make mistakes only once. You end up doing them all once, and now you might as well just make uncontroversial software, which is the expectation. No one is perfect, but at least you need to be on that path.

  • The only thing that doesn’t change is change, and you can’t change it anyway.

Planning for tomorrow’s world and assuming it will be as it is today is foolish. Especially in the programming world, nothing is permanent. The Luddite attitude, the idea that you can stop change, doesn’t work.

  • Never stop learning, the technology steamroller is right behind you, waiting for you to stop.

My favorite analogy is the big roller on your ass trying to overwhelm you. That’s the only way to have a long career as a programmer, and you have to move on. As soon as you rest and feel like you know everything, you’ll get squashed along the way.

  • The entire software industry is built on wild guesses.

In my career, everyone insists on predicting how long something will take, no matter how big or small, and everyone is always wrong. Long ago, prophets who wrongly predicted the future were stoned to death; Now they just move on to the next sprint.

  • It works for you, but not necessarily for me or any other programmer behind the tree.

There are countless technical choices you can make in any software project. Some of them are better, some are more accepted, and some are the worst. But what works for you, your situation and your set of choices may not work for anyone else at all. It’s always nice to hear what other people are doing, but I’ve never liked people insisting that the choices they make are the only way to do something well.

  • In a changing world, the most important thing is to take stock.

It’s not obvious to everyone, but the ability to see new things, or see what other people are doing, or compare multiple ways of doing things, and then make the best choice for you, your team, your project, and even your company is incredibly valuable. Most people I’ve met aren’t very good at it. Most leaders are really bad at this. It’s easy to do what someone tells you you should do, or what you read in a blog, or just do what someone else is doing. It is much more difficult to consider all aspects and combine your needs, and then make the choice that seems best at the time. Of course, you have to make some decisions, and people often get paralyzed by having to evaluate which often leads to random selection or following the herd.

  • ** There is more than one way to skin a cat; But from the cat’s point of view, it doesn’t matter. 支那

Customers don’t care what your problem is, they just want your software to do what it needs to do. If your system breaks down, exceptions happen, hardware is broken, programmers are bad, hackers are hacking: users don’t really have any interest in it. It’s great to be honest when things are unstable, because sometimes they are, but it’s best to make sure the flaw isn’t permanent before the client sees your work.

  • ** Quality is best measured by customers. 支那

It doesn’t matter how many metrics you have, how many checklists you check, how many code reviews you go through, how many tests you write; None of this matters unless the customer sees that your software does everything it’s supposed to do and never does anything it shouldn’t. Customer perceptions of code quality, performance, design, and usability are ultimately the only factors that determine quality.

  • ** What you don’t know will kill you because you didn’t print any logs. 支那

It always amazes me that even today, people don’t collect enough logs, crash reports, and usage information to know what their software is doing. People who don’t collect this kind of information always overestimate the quality. If you don’t measure and record, you won’t know. Of course the client will know. I’ve always insisted on detailed and useful logging, tracking crashes, reading comments and comments, and anything else I can learn about immediately when a problem occurs. However, I know people who think these things have nothing to do with being a programmer.

  • There’s always a better way to do everything, but time goes by.

The hardest balancing point in assessing what to do is when to stop looking. You may miss out on better methods, but if it takes too long, there may be no other reason to do everything. It’s hard to get it right, but sometimes making smaller choices today is better than making better choices next year.

The last two are from a salesperson I worked with a long time ago. I don’t entirely agree. These are lessons.

  • ** is always looking for stupid clients with money. 支那

Favorite quote from a salesperson I know at a consulting firm. In his view, finding people who don’t know technology but have a lot of money to burn is the mother loge. A wise man asks too many questions; Poor people can’t afford you. I’m glad I’m a programmer!

  • ** My job is to lie to clients, your job is to make me look good. 支那

Second favorite quote from the same salesperson. He likes to promise the impossible and reap the rewards when we actually do it. It’s cool to do something challenging, but it’s painful to do the impossible every time. My advice is to find a better salesman!