Solve the problem directly in front of you. You are not as good at predicting the future as you think you are. (aka: YAGNI)
Organize your code around the problem domain, and name things accordingly. As a basic razor, consider someone seeing your codebase for the first time – they should be able to easily glean what your app does, not just what language (Java) or frameworks (Rails) or design patterns (MVC) you might be using.
Each function must Do One Thing. And yes, each test case is a unit, too.
It must be clear to someone reading a function call what is expected to happen. Only use positional arguments when this is true and when order matters and is reasonably intuitive. Otherwise, always use named arguments.
Your tests must run quickly. Your code must build quickly. Your CI/CD pipelines must be measured in seconds, not minutes or hours.
Take nothing for granted. Declare all dependencies, and avoid implicit globals.
Use a linter, and enforce compliance. It doesn’t matter what the rules are, but once established, avoid changing them.
Never isolate yourself from your team for too long. If you’re working on a multi-day implementation, check in with the people who would be reviewing your code at least every couple of days. The longer you isolate, the more exhaustion and conflict you can expect during review, for both you and your reviewers.
Learn to work iteratively, validating minimal implementations that fall short of the full feature as requested, but which build up to it. As opposed to One Big Release. It helps everyone to experience and validate early and often how the feature feels and whether it’s the right direction.
Never rush. Always take the time to build properly. Your professionalism and expert opinion is non-negotiable, even if (especially if) there’s a deadline. I’m not saying to say “no” – rather, just give honest estimates and offer functional compromises or alternatives when possible. Never “try” to do more than is reasonable.
A lot of this, I attribute to Martin’s books (“Clean Code” and “The Clean Coder”) and his Laracon talk from several years ago (you can find it on YouTube).
Solve the problem directly in front of you. You are not as good at predicting the future as you think you are. (aka: YAGNI)
Organize your code around the problem domain, and name things accordingly. As a basic razor, consider someone seeing your codebase for the first time – they should be able to easily glean what your app does, not just what language (Java) or frameworks (Rails) or design patterns (MVC) you might be using.
Each function must Do One Thing. And yes, each test case is a unit, too.
It must be clear to someone reading a function call what is expected to happen. Only use positional arguments when this is true and when order matters and is reasonably intuitive. Otherwise, always use named arguments.
Your tests must run quickly. Your code must build quickly. Your CI/CD pipelines must be measured in seconds, not minutes or hours.
Take nothing for granted. Declare all dependencies, and avoid implicit globals.
Use a linter, and enforce compliance. It doesn’t matter what the rules are, but once established, avoid changing them.
Never isolate yourself from your team for too long. If you’re working on a multi-day implementation, check in with the people who would be reviewing your code at least every couple of days. The longer you isolate, the more exhaustion and conflict you can expect during review, for both you and your reviewers.
Learn to work iteratively, validating minimal implementations that fall short of the full feature as requested, but which build up to it. As opposed to One Big Release. It helps everyone to experience and validate early and often how the feature feels and whether it’s the right direction.
Never rush. Always take the time to build properly. Your professionalism and expert opinion is non-negotiable, even if (especially if) there’s a deadline. I’m not saying to say “no” – rather, just give honest estimates and offer functional compromises or alternatives when possible. Never “try” to do more than is reasonable.
A lot of this, I attribute to Martin’s books (“Clean Code” and “The Clean Coder”) and his Laracon talk from several years ago (you can find it on YouTube).