I was recently asked in an interview for my insights on being a great programmer . This is an interesting question, I think we can all be great programmers, no matter our talents, if we follow some rules - I believe - it should be common sense. In fact, these rules apply not only to the field of programming, but also to any profession.
Of course, not everything in these 10 points is completely serious, some things are just my opinion and your situation may be different, so don't take it to heart if there is a contradiction.
These points are:
1. Learn how to ask questions
There are basically these types of programmers asking questions:
- Perfectionists: Especially when asking questions about some open source tools, they may have debugged through the code and discovered the real cause of the problem. But even if no real cause is found, a perfectionist will explain the problem, reproduce steps, suggest possible workarounds, or even suggest possible fixes. In fact, perfectionists have no problem. There are only answers.
- Chatterbox: The person didn't actually ask the question. They state their minds, sometimes placing pompous question marks all over the place. For questions, they give their thought process, and if you wait for the answer, they either find the answer themselves, or they ask the real question after multiple emails. "Oh right, I found this requirement to be completely wrong, I solved it with some other technique. Actually, I completely changed the library." Hehe. Just hope they stop asking questions.
- Idiot: The code is here. I don't know where is wrong? please help me.
- Manager: For this type of person, time is money. Questions must be short, and the quicker the answer, the better. Ironically, by keeping the question short (meaning: incomplete, not concise), most of the time, a lot of important details are lost, and then the programmer can only ask for more details in order to answer the question. So the manager (who is naturally disappointed because he got not an answer but a new question) will send a short message again and ask for an answer more urgently. cycle back and forth. In the end it may take 1-2 weeks to answer.
- Complainer: This type of person doesn't ask questions. They kept complaining until the problem went away. If things don't get better, there's even more reason to complain.
It should be clear by now that a well-prepared question (brief, simple, short, but with enough detail) will yield a better answer. If you know exactly what you need to learn about the subject, you're more likely to get what you want.
2. Learn how not to ask questions
In fact, it's best to avoid asking questions as much as possible. Maybe you can figure it out yourself? Of course this is not always the case. There are many things you simply don't know, and asking domain experts can help you find the quickest and most efficient path to success. However, there are many benefits to frequently trying to solve problems yourself:
- What we learn this hard way is better kept in memory - we will remember what we learned.
- It's more valuable to find the answers yourself.
- You don't make "noise". Remember the "chat box" I mentioned earlier? Unless the person you're asking is responsible for answering the question (thus delaying their work), they may try to answer every incomplete "question" without understanding your thought process. This doesn't help anyone.
- By deferring asking questions (at least for a while), you can gather more relevant information, which you can then provide to someone who might be able to answer the question. Think of "perfectionists" who spend more time looking for details first and then answering the questions themselves.
- With training you can become better at asking questions. It takes time.
3. Don't leave broken windows
There was a very interesting article recently about not leaving broken windows . The essence of the article is to never compromise on quality. Never be a deserter. Never leave behind...broken windows. The following quote is from this article:
"Reflecting our careless code when we take some shortcuts to deliver something in the shortest amount of time can lead developers after us (from the same team, future teams, even ourselves!) to draw an important Conclusion: It's not important to pay enough attention to the code we produce. It will be an unstoppable process that the application gradually starts to deteriorate."
Actually, this does not mean to be a perfectionist. Sometimes, repairing broken windows can be put off. Usually, however, no one is happy about allowing windows to be broken and to remain broken. We programmers are not happy, our customers are not happy, our users are not happy, and our project managers are not happy. It is an attitude that is at the heart of being a professional. What does Benjamin Franklin think?
"After the sweetness of the low price is forgotten, the bitterness of the low quality will linger long."
Everything is so. "Low price" is our quick win for implementing something in a sloppy way.
4. Software should be deterministic. That's 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. eg String.contains(). No matter how many times you do the following:
assertTrue("abcde".contains("bc"));
...the results are always the same, all expected. Even a cosmic explosion would have no effect on 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 without side effects. It really doesn't matter what technology we choose. Deterministic programming can be done in any language - even functional languages have more tools to prevent unintended side effects through a more sophisticated type system. But the example I show is a Java example. Object orientation allows for determinism. Yes, programming languages like PL/SQL allow determinism. If you want to use a function in an index, you need to request a deterministic function:
CREATE INDEX upper_first_name ON customer (upper (first_name));
-- Deterministic function here: -----------^^^^^^^^^^^^^^^^^^
This is again a question of rules. Procedures/methods/"functions" with side effects are "broken windows". Having side effects might be easier to maintain, and of course hopefully eliminating side effects eventually. But it's usually a lie to yourself. When one day in the future unexpectedly pops up, that's when you pay dearly. Don't believe it, say Cao Cao and Cao Cao will arrive.
5. Accept the unexpected
Programmers should always obey Murphy's Law. Everything can be broken. And it's about to be broken. As software engineers , we should remember that it breaks. Because our world is uncertain, so are the business needs we are implementing. We can only implement technique #4 (determinism) when we can finally be sure. Otherwise, we will inevitably enter a world of uncertainty (aka the "real world"), a world where things will go wrong. So, use that as a foundation. Accept the unexpected. Train your inner power to anticipate troubles in a positive light.
Of course, how to write code in a concise way to foresee all kinds of trouble is another story. It takes some practice to tell what will fail (and therefore need to be dealt with) from those that may fail (and therefore need to be dealt with).
6. No cargo worship. Don't be dogmatic. Always be case by case.
Everything taught you is potentially wrong. Even those buzzwords. To quote a very good quote:
"At least 50 percent of my career has been about helping or extricating dogmatic disasters.
Our profession is full of falsehoods. We like to think of ourselves as mathematicians, clinging to the purest ideas, believing that they must be right.
That's a fork in the road. Our profession is built on the foundations of mathematics, but unless you enter the funky world of category theory or relational algebra (and even if you do, I doubt everything is "right"), you have to face the real world Pragmatic business needs. Well, frankly, this is still a thousand miles from perfection. Let's take a look at some of the most popular programming languages:
- C
- Java
- SQL
Do you really think these languages don't resemble math at all? OK, let's talk about segmentation faults, Java generics and SQL three-valued logic first. These languages are platforms built by pragmatists. All of this has some really cool theoretical background, but in the end, there are the tools.
The same is true 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 of a tool in its context. Never use this tool as a stand-alone reason. We are not "art for art's sake".
So say no to these doubts:
- XML
- JSON
- functional programming
- Object-Oriented Programming
- Design Patterns
- Microservices
- Three-tier architecture
- DDD
- TDD
- Actually: *DD
- the list goes on
All of these are good tools for some given context, but not always, learn to be case by case. Being curious, developing creativity, and knowing when to use these tools will help you become a better programmer.
7. Just do it
This is the truth. In other words, there are always some great people who are outstanding and can stand out from the crowd, leaving people behind.
But most programmers are only at the "good" level, or have the potential to be "good." So how does one become a good programmer? Just as Rome wasn't built in a day, and great software isn't written in a day, popular people aren't the only heroes of our time. I have met many obscure but great programmers who have worked tirelessly to solve software problems and solve hidden problems of many small companies.
Great programmers all have one thing in common: When you have a problem, you just do it. Practice, practice. Commit to work and study every day and become better and better.
Want to get better at SQL? Then do it! Every day try to write a SQL statement with some new function. Use window functions. grouping. recursive. Partitioned outer join. MODEL and/or MATCH_RECOGNIZE clause. No need to deliver to production every time, just to practice. These are all valuable.
8. Focus on one theme (long-term perspective)
There may be only a few "good" full-stack developers that dominate. In fact, most full-stack developers will be in the middle. Of course, a small team may only need a few full-stack developers to cover a lot of business logic and quickly launch a new software. However, the software will be very clunky and "just work". Maybe this is enough for a production phase as long as it works, but in the long run, full stack developers won't have the time to properly analyze (or foresee!) more complex problems.
Mainly focus on one topic and get really good at it. Real gold is not afraid of fire, as long as you have the ability, you need it wherever you go. So, commit to your career and do something really good instead of "just about."
9. Be wide-ranging
While you should focus primarily on one topic, you shouldn't completely forget about others. You can never really be good at everything right away with SQL, scaling, scaling, low-level performance, CSS, object orientation, requirements engineering, architecture, and more (see tip #8). This is impossible.
But you should at least understand the essence of each of them. You need to understand when SQL is the right choice (and when it isn't). When low-level performance tuning is important (and when it isn't). How CSS works in principle. Object-oriented, FP advantages. etc.
You should spend some time dabbling in these (and more) concepts and techniques to better understand their importance. Know when to apply them before getting a professional to actually perform the work.
Dabbing with new paradigms and technologies helps you think in a completely different way, and you may unconsciously use them in some way or another in your day-to-day work.
10. Keep it simple, foolish
Einstein once said:
"Everything should be made as simple as possible, but no simpler."
("Everything should be made as simple as possible, but no simpler.")
No one can handle enormous complexity. Not in software, not in any other aspect of life. Complexity is the killer of good software, so simplicity is the enabler. Easy to understand. difficult to achieve. You need a lot of time and practice to identify 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 parameters. Let's take a look. String.contains()This is the case with the methods mentioned earlier . We can write "abcde".contains("bcd") and without reading any documentation, everyone immediately understands what this does and why. The method does one thing, and only this one. No complicated context/settings/other parameters passed to the method. There are no "special cases" and no warnings.
Also, it's much simpler to simplify in the library than in the business logic. So can we make it happen? Maybe. through practice. by refactoring. But like great software, simplicity doesn't happen in a day.
(Advanced tip: Apply Conway's Law . It's totally impossible to write good and simple software in an environment where a business is super complex. Either you choose complexity and ugliness, or you better get rid of that business).
Link to translation : http://www.codeceo.com/article/10-tips-be-great-programmer.html
Original English: 10 Tips on How to Be a Great Programmer