Watch out for these 10 common pitfalls of experienced Java developers & architects
Common Pitfall #7: Using excessive lazy loading (i.e. not understanding your object lifecycle)
Common Pitfall #4: Ignoring method visibility
I have seen so-called architects who believe that that it’s acceptable to convert private methods to public so that they can run unit tests against them.
Testing private methods is simply wrong. Just test the public method that calls the private one. Remember: in no case you should expand your API with more public methods only because of unit tests.
Common Pitfall #3: Suffering with project-specific StringUtils (i.e. or the more general NIH syndrome)
If your job title contains the word architect in it, there is no excuse for not knowing Apache Commons, Guava libraries or the Joda Date library.
Common Pitfall #2: Environment-dependent builds
-- Check out code, build, it should just work.
Common Pitfall #1: Using Reflection/Introspection
10 Things I Never Want to See a Java Developer Do Again
1. Write PL/SQL on a transaction system
3. Cast
4. Do date calculations with Calendar or Date
The built-in classes provide only the most primitive operations and are everything except intuitive. Use a modern library like JODA Time. Or use jdk 8 api.
Code changes in our codebase are peer reviewed on six dimensions - correctness, privacy, performance, architecture, reusability and style.
What Makes a Good Programmer?
1. PROBLEM DECOMPOSITION
One skill good programmers have is the ability to break the problem down in smaller and smaller parts, until each part can be easily solved. But it is not enough simply to find a way to solve the problem. A good programmer finds a way to model the problem in such a way that the resulting program is easy to reason about, easy to implement and easy to test.
2. SCENARIO ANALYSIS
Good developers have the ability to consider many different scenarios for the program. This applies both to the logic in the program, and to the internal and external events that can occur. To consider the different paths in the logic, they ask questions like: What happens if this argument is null? What if none of these conditions are true? Is this method thread-safe? To discover what types of events the software needs to handle, they will ask questions like: What if this queue becomes full? What if there is no response to this request? What if the other server restarts while this server is restarting?
The good programmers ask themselves: How can this break?
In other words, they have the ability to think like testers. In contrast, inexperienced programmers mostly only consider the “happy path”
KNOWLEDGE IN 3 DIMENSIONS
Programming.
Domain.
Codebase.
Lessons Learned in Software Development
DEVELOPMENT
1. Start small, then extend.
use short iterations. Do one thing, make sure it works, repeat. This applies down to the level of commits. If you have to refactor the code before you add a new feature, commit the refactoring first, then (in a new commit) add the new feature.
3. Add logging and error handling early.
4. All new lines must be executed at least once.
5. Test the parts before the whole.
6. Everything takes longer than you think.
7. First understand the existing code.
8. Read and run.
TROUBLESHOOTING
9. There will always be bugs.
A much better approach is to have a system in place that lets you quickly troubleshoot problems, fix the bugs and deploy the fixes.
10. Solve trouble reports.
It gives you a much better understanding of what the customers are trying to do, how the system is used, how easy or hard it is to troubleshoot and how well the system is designed. It’s also a great way of taking responsibility for what you develop.
11. Reproduce the problem. The first step when fixing a bug is to reproduce the problem. Then you make sure that when the fix is added, the problem is gone
12. Fix the known errors, then see what’s left.
13. Assume no coincidences.
14. Correlate with timestamps.
COOPERATION
15. Face to face has the highest bandwidth
16. Rubber ducking.
17. Ask.
18. Share credit.
Make sure to give credit where credit is due. Say: “Marcus came up with the idea to try…” (if he did), instead of “we tried …”. Go out of your way to mention who else helped or contributed.
MISCELLANEOUS
19. Try it.
20. Sleep on it.
21. Change.
22. Keep learning.
Why /you/ should talk at conferences
Understanding the 4 Rules of Simple Design
Common Pitfall #7: Using excessive lazy loading (i.e. not understanding your object lifecycle)
Common Pitfall #4: Ignoring method visibility
I have seen so-called architects who believe that that it’s acceptable to convert private methods to public so that they can run unit tests against them.
Testing private methods is simply wrong. Just test the public method that calls the private one. Remember: in no case you should expand your API with more public methods only because of unit tests.
Common Pitfall #3: Suffering with project-specific StringUtils (i.e. or the more general NIH syndrome)
If your job title contains the word architect in it, there is no excuse for not knowing Apache Commons, Guava libraries or the Joda Date library.
Common Pitfall #2: Environment-dependent builds
-- Check out code, build, it should just work.
Common Pitfall #1: Using Reflection/Introspection
10 Things I Never Want to See a Java Developer Do Again
1. Write PL/SQL on a transaction system
3. Cast
4. Do date calculations with Calendar or Date
The built-in classes provide only the most primitive operations and are everything except intuitive. Use a modern library like JODA Time. Or use jdk 8 api.
Code changes in our codebase are peer reviewed on six dimensions - correctness, privacy, performance, architecture, reusability and style.
What Makes a Good Programmer?
1. PROBLEM DECOMPOSITION
One skill good programmers have is the ability to break the problem down in smaller and smaller parts, until each part can be easily solved. But it is not enough simply to find a way to solve the problem. A good programmer finds a way to model the problem in such a way that the resulting program is easy to reason about, easy to implement and easy to test.
2. SCENARIO ANALYSIS
Good developers have the ability to consider many different scenarios for the program. This applies both to the logic in the program, and to the internal and external events that can occur. To consider the different paths in the logic, they ask questions like: What happens if this argument is null? What if none of these conditions are true? Is this method thread-safe? To discover what types of events the software needs to handle, they will ask questions like: What if this queue becomes full? What if there is no response to this request? What if the other server restarts while this server is restarting?
The good programmers ask themselves: How can this break?
In other words, they have the ability to think like testers. In contrast, inexperienced programmers mostly only consider the “happy path”
3. NAMING
Programming consists to a large degree of naming things: classes, methods and variables. When done well, the program becomes largely self-documenting, meaning that the function of the program is quite clear just from reading the source code. One effect of self-documenting code is that it naturally leads to many smaller methods, rather than a few large ones, simply because then you have more places to put meaningful names (there are other reasons why many small methods are good too).
4. CONSISTENCYProgramming.
Domain.
Codebase.
Lessons Learned in Software Development
DEVELOPMENT
1. Start small, then extend.
use short iterations. Do one thing, make sure it works, repeat. This applies down to the level of commits. If you have to refactor the code before you add a new feature, commit the refactoring first, then (in a new commit) add the new feature.
3. Add logging and error handling early.
4. All new lines must be executed at least once.
5. Test the parts before the whole.
6. Everything takes longer than you think.
7. First understand the existing code.
8. Read and run.
TROUBLESHOOTING
9. There will always be bugs.
A much better approach is to have a system in place that lets you quickly troubleshoot problems, fix the bugs and deploy the fixes.
10. Solve trouble reports.
It gives you a much better understanding of what the customers are trying to do, how the system is used, how easy or hard it is to troubleshoot and how well the system is designed. It’s also a great way of taking responsibility for what you develop.
11. Reproduce the problem. The first step when fixing a bug is to reproduce the problem. Then you make sure that when the fix is added, the problem is gone
12. Fix the known errors, then see what’s left.
13. Assume no coincidences.
14. Correlate with timestamps.
COOPERATION
15. Face to face has the highest bandwidth
16. Rubber ducking.
17. Ask.
18. Share credit.
Make sure to give credit where credit is due. Say: “Marcus came up with the idea to try…” (if he did), instead of “we tried …”. Go out of your way to mention who else helped or contributed.
MISCELLANEOUS
19. Try it.
20. Sleep on it.
21. Change.
22. Keep learning.
Why /you/ should talk at conferences
Understanding the 4 Rules of Simple Design
The rules that will lead you to a simple design are
- Tests pass
- Express intent
- DRY
- Small
