what_are_some_things_about_coding_that_you_learned_from_good_programmers_around_you
What are some things about coding that you learned from good programmers around you?
Return to Programming Q&A
“What are some things about coding that you learned from good programmers around you?”
- Don’t be afraid of debugging other people’s code
- If you do not like doing a couple of things repeatedly, every single day, such as pushing your code changes to Git, building your cumbersome project, or generating test cases for your functions, then automate it.
- Coding shortcuts are underrated. They boost productivity in ways you have never imagined possible.
- If you are spending too much time to think of a particular solution, which is not domain specific (i.e. specific to the problem which you are solving), then don’t be shy to search it on DuckDuckGo or Google (or StackOverflow.) They probably have a better and proven solution than you can come up with at the moment.
- Knowing how to solve a problem in a given programming language is one thing. But knowing what that language is capable of, is completely different topic. Hence, when your manager/mentor asks whether you know how to make REST call using Java, then you only need to know how to perform REST call using Java.
- Maintain the pieces of code (or Linux commands) which you might use repetitively. Document it. Minimize the time you spend searching for it. Organize your directories properly.
- Unit-test your functions thoroughly.
- Embrace the fact that writing enterprise software is iterative. Sometimes you might remove several files which you have written over the years and replace it with a single function.
Don’t give up on a problem. Because more often than not, it is when you keep trying even after you feel like giving up, is when you actually find a solution.”
By Aditya Chandupatla, Programming since 6 years and counting
- “The most important lesson in any programmer's career is the first time they have to fix a bug or add a feature to something they wrote over six months ago. Until that moment happens, everything you learn about coding style and code quality is theoretical. This should be an exercise in any computer science or software engineering course. A large part of a programmer's career is subsequently spent finding and developing tools and techniques to make this less painful.
- Learn a programming language every year. Pick one as different as possible to what you already know.
- Everything in this profession involves a trade-off. I mean everything. If you've ever wondered why you had to learn all those algorithms and data structures that you will maybe use 10% of in your life, it's for that reason: it's supposed to train your brain into thinking about tradeoffs.
- A programmer is a professional problem solver. Software is one of the tools with which to solve problems, but it's far from the only one.
- APIs could be as big as a programming language's standard library to as small as the interface to a single function. Either way, designing APIs is hard but made much easier by writing the usage code first. Good API design is the best kind of code optimization because you can replace / refactor inefficient code with efficient code easily.
- Before feeding your program to the compiler, manually check the code intent. Code syntax (and type correctness, in a statically typed language) will be checked for you.
- When starting out, keep a programmers notebook by your desk and write in pen every bug you found in your code, what caused it, and how you fixed it. After a year, you won't need the notebook any more.
- Performance always matters, but “performance” is not one single thing, and the kind of performance that matters the most will differ from program to program. Nevertheless, every millisecond that your program doesn’t burn is a millisecond that the machine can be doing something else, or can spend in low power mode. This goes double if the program is powered by a battery, and triple if the program is scaled in a cluster or cloud where you could potentially save whole machines.
- Never outsource your inconvence onto a paying customer. They’re paying you to solve their problems.
- All programs have real-time constraints. If your program takes three months to calculate the monthly payroll, it's useless.
- Coding shortcuts, IDEs and so on are a huge timesaver. Learn to use them well. On the other hand, they are not indispensable and you should never forget how to work without them. You will thank me when you have to debug something over a laggy SSH connection.
- Maintaining unit tests has a cost. Not only do you need to keep them up to date, they put an economic limit on how much you can modify the code that they purportedly test.
- Complex logic is inevitable. If it's at all possible to fit it on one screen, do that. If you are tempted to split it across files/modules/classes, see advice #1.
Further to that point: think very hard before you write a base class. There is a very good chance that what you're about to do isn't worth it.
- Trendy technologies come and go, but the craft of programming is eternal.”
By Andrew Bromage, 70+ programming languages, lost count
Fair Use Source: https://www.quora.com/What-are-some-things-about-coding-that-you-learned-from-good-programmers-around-you
what_are_some_things_about_coding_that_you_learned_from_good_programmers_around_you.txt · Last modified: 2024/04/28 03:23 (external edit)