I was recently asked in an interview what I think makes a great programmer. It’s an interesting question, and I think we can all be great programmers, regardless of our talent, if we follow a few rules that — I believe — should be common sense. In fact, these rules don’t just apply to programming, but to any profession.
Of course, not everything in these 10 tips is completely true. Some things are just my opinion, and your situation may be different, so don’t take it personally if there is a conflict.
Here are some key points: 1. Programmers who learn how to ask questions generally fall into one of these categories: Perfectionists: Especially when asking questions about some open source tool, they may have already debugged the code and discovered the real cause of the problem. But even without discovering the real cause, the perfectionist will explain the problem, reproduce the steps, suggest possible solutions, or even suggest possible fixes. In fact, perfectionists have no problem. There are only answers. Chatterbox: The man didn’t actually ask a question. They state what they think, sometimes with grandiose question marks everywhere. For questions, they give you their flow of thought, and if you have an answer, they either find the answer on their own or ask the real question after multiple emails. “Oh, by the way, I found that requirement to be completely wrong, and I solved the problem with some other techniques. In fact, I completely changed the library.” Ha ha. I just wish they’d stop asking questions. Idiot: Here’s the code. I wonder what went wrong? Please help me. Manager: Time is money for these types of people. The questions must be short, and the sooner the better. Ironically, by keeping the problem short (i.e., incomplete, not concise), in most cases important details are lost, and then the programmer has to ask for more details in order to solve the problem. So the manager (disappointed, of course, that instead of an answer he gets a new question) sends another short message, more urgently demanding an answer. The cycle repeats. In the end, it could take 1-2 weeks. Complainer: This person doesn’t ask questions. They keep complaining until the problem goes away. If things don’t get better, there’s more reason to complain. It should be clear by now that a well-prepared question (concise, simple, short, but with enough detail) will yield a better answer. If you know exactly what you need to learn about the problem, you’re more likely to get it. 2. Learn how not to Ask Questions In fact, it’s best to avoid asking questions at all costs. Maybe you could figure it out for yourself? Of course, this is not always the case. There are a lot of things you simply don’t know. Asking a field expert can help you find the quickest and most efficient way to success. But often trying to solve problems on our own has many advantages: what we learn the hard way is better retained in our memory — we retain what we have learned. It’s more valuable to find out for yourself. You don’t make noise. Remember that “chatterbox”? Unless the person you’re asking is responsible for answering the question (and thus delaying their work), they may try to answer every incomplete “question” without knowing your thought process. That doesn’t help anyone. By putting off asking questions (at least for a while), you can gather more relevant information that you can then provide to someone who might be able to answer the question. Think of the “perfectionist,” who first spends more time looking for details and then solves the problem themselves. You can become better at asking questions through training. It takes time. Don’t Leave Broken Windows There was a very interesting article recently about not leaving broken Windows. The essence of writing is never to compromise on quality. Never be a deserter. Never leave… Broken Windows. Here’s a quote from the article: “When we take some shortcuts to deliver something in the shortest amount of time, a reflection of our careless code will cost us later developers (from the same team, future teams, even ourselves!). One important conclusion: it’s not important to pay enough attention to the code we produce. The gradual deterioration of applications is an inexorable process.” This doesn’t have to mean being a perfectionist. Sometimes, fixing a broken window can be postponed. But, more often than not, no one is happy about allowing Windows to be broken and staying broken. We programmers are unhappy, our customers are unhappy, our users are unhappy, and our project managers are unhappy. It’s an attitude that’s at the heart of being a professional. What did Benjamin Franklin think? “The sweet of low price is forgotten, the bitter of low quality will linger.” Everything is like that. “Low” is the quick victory we get by implementing something in a sloppy way. 4. Software should be deterministic. This is what to aim for! In an idealized world, everything in software should be “deterministic.” We should all be functional programmers, writing pure functions with no side effects. Such as a String. The contains (). AssertTrue (“abcde”. Contains (” BC “)); … The result is always the same, always the expected result. Even the cosmic explosion does not affect this calculation. This is deterministic. We can also do this in our own programs, not just in the standard library. We can try to write as many deterministic modules as possible with no side effects. It really doesn’t matter what technology we choose. Deterministic programming can be done in any language — even functional languages with more tools can prevent unintended side effects with more complex type systems. But the example I’ve shown is a Java example. Object orientation allows determinism. Yes, programming languages like PL/SQL allow determinism. If you want to use a function in an index, you need to request deterministic functions: CREATEINDEXupper_first_nameONcustomer (upper(first_name)); – Deterministicfunctionhere: — — — — — — — — — — – ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ this is a rule. The process/method/” function “that has side effects is” broken Windows “. Having side effects may be easier to maintain, but hopefully they will eventually be eliminated. But this is often a self-deception. When something unexpected happens in the future, it will cost you dearly. Don’t believe me. Speak of the devil. 5. Accept the Unexpected Programmers should always follow Murphy’s Law. Everything can be broken. And it’s about to be broken. As software engineers, we should remember that it will break. Because our world is uncertain, so are the business requirements we are implementing. We can only achieve technique #4 (determinism) when we can finally be certain. Otherwise, we will inevitably enter the world of uncertainty (i.e., the “real world”), a world that will go wrong. So, build on that. Accept the unexpected. Train your inner prehistory to see trouble in a positive light. Of course, writing code in a succinct way to anticipate trouble is another story. How to distinguish between things that are likely to fail (and therefore need to be dealt with) and things that will fail (and therefore need to be dealt with) is a matter of practice. 6. Don’t worship goods. Don’t be dogmatic. Always treat it on a case-by-case basis. Everything you are taught is potentially wrong. Even the buzzwords. Here’s a good quote: “At least 50 percent of my career has been spent helping or undoing one dogmatic disaster after another. Our profession is full of falsehood. We like to think of ourselves as mathematicians, insisting on the purest ideas that must be true. That is a wrong road. Our careers are built on mathematics, but unless you enter the fashionable world of category theory or relational algebra (and even if you do, I doubt it’s “right”), you have to face the pragmatic business needs of the real world. Well, frankly, it’s far from perfect. Let’s take a look at some of the most popular programming languages: C Java SQL Do you really think these languages are anything but math? Let’s start with segment errors, Java generics, and SQL three-valued logic. These languages are platforms built by pragmatists. All of this has some pretty cool theoretical background, but in the end, there are these tools. The same goes for everything built on top of a language: libraries, frameworks, design patterns, even architectures. Nothing is right or wrong. Everything is a tool designed for some context. Think about the tool in its context. Never use this tool as a separate reason. We are not “art for art’s sake”. So say no to the skepticism: XML JSON functional programming Object-oriented programming Design pattern Microservices three-tier architecture DDD TDD In fact: DD goes on and on All of these are good tools for some given contexts, but not always. Take it on a case-by-case basis. Being curious, being creative, and knowing when to use these tools will help you become a better programmer. 7. That’s the truth. In other words, there are always some great people who stand out from the rest of the pack. But most programmers are only “good” or have the potential to be good. So what makes a good programmer? Just as Rome wasn’t built in a day, and great software wasn’t written in a day, popular people aren’t the only heroes of our time. I’ve met a lot of great, unsung programmers who work tirelessly on software problems and solve hidden problems in small companies. Great programmers all have one thing in common: they just do it. Practice, practice. Commit to work and learn every day and get better and better. Want to get better at SQL? Then do it! Try to write an SQL statement every day with some new functionality. Use window Functions. Grouping. Recursion. External connections of partitions. MODEL and/or MATCH_RECOGNIZE clause. It doesn’t have to be delivered into production every time, just for practice. These are all valuable. 8. Focus on one topic (in the long run) and only a few “good” full-stack developers are likely to dominate. In fact, most full-stack developers will be in the middle. Of course, a small team might only need a few full-stack developers to cover a lot of business logic and quickly roll out a new piece of software. But the software will be clunky and “just so-so”. This may be sufficient for as long as the production phase is viable, but in the long run, the full stack developer will not have time to properly analyze (or anticipate!) More complicated questions. Focus on one topic and be really good at it. True gold does not fear fire. As long as you have the ability, you will need it wherever you go. So work on your career and do something really good, not “just about.” While you should focus on one topic, you shouldn’t completely forget about others. You can never really get good at SQL, scaling, extending, low-level performance, CSS, object-oriented, requirements engineering, architecture, and so on all at once (see Tip #8). It’s impossible. But you should at least understand the nature of each of them. You need to know when SQL is the right choice (and when it isn’t). When low-level performance tuning is important (and when it is not). How CSS works in principle. Object-oriented, FP advantages. And so on. You should spend some time dabbling with these (and more) concepts and technologies to better understand their importance. Know when to apply them, and then get the professionals to actually do the work. Being exposed to new paradigms and technologies helps you think in a completely different way, and you may unconsciously use them in some way later on in your daily work. “Everything should be made as simple as possible, but no simpler,” said Albert Einstein, a fool. (No one can handle great complexity. Not in software, not in any other aspect of life. Complexity is the killer of good software, so simplicity is enabler. Easy to understand. Difficult to implement. You need a lot of time and practice to recognize and produce simplicity. Of course, there are many rules you can follow to achieve simplicity. One of the simplest rules is to use methods/functions with only a few arguments. Let’s take a look. This is the case with the string.contains () method mentioned earlier. We can write “abcde”. Contains (” BCD “), without reading any documentation, and everyone can immediately understand what this does and why. This method does one thing and only one thing. No complex context/Settings/other parameters passed to the method. There were no “special circumstances” and no warnings. Furthermore, it is much easier to simplify in the library than in the business logic. So can we do that? Maybe. Through practice. By refactoring. But like great software, simplicity doesn’t happen overnight. (Advanced tip: Apply Conway’s Law. It is impossible to write good, simple software in a business environment that is super complex. Either you choose complexity and ugliness, or you’d better get out of that business). A programmer learning platform to share with you, so that you accumulate experience in practice to master the principle. The main direction is JAVA engineers. If you want to get a high salary, want to break through the bottleneck, want to compete with others to gain an advantage, want to enter BAT but have worry about the interview, * can add my Java learning exchange group: 282711949. Note: 1. I majored in Java in college, but I was frustrated in the interview after graduation, so I could not find a suitable job. 2. Need to pursue advanced study in a short period of time, move of 3 big salary, participated in the offline training, knowledge to master the profound enough, employment difficulty, want to continue to study 4, already in the Java on-the-job personnel of relevant departments to work, for their own career planning is not clear, about 5, the C language of a certain basis, contact with Java development, want to change careers trumpet you are the one, Don’t like don’t add the link: www.codeceo.com/article/10-… 10 Tips on How to Be a Great Programmer