One of my biggest pet peeves is code duplication from lazy copy/pasting. I find it's a good exercise for myself to sometimes pretend like the copy/paste key are not available to me.
I had to think about the first one for a moment, but I do agree. It's better to abstract later with greater knowledge than the much more difficult task of trying to debug or fix it later.
It's an outstanding list and great rules to work by!
> I find it's a good exercise for myself to sometimes pretend like the copy/paste key are not available to me.
This is a great idea! I'll try to remember this whenever I have the urge to lazily duplicate some code (which is quite often now that I think about it).
That is a fantastically comprehensive list - I was racking my brain for a while to try and think of something before I replied. Not sure if this one is covered already but maybe...
Student; is able to ask for help.
A lot of these are hard to objectively test for (in a recruiting sense) because they can be subjective or be dependant on the working environment itself. It never hurts to have more information that less, though!
Yep, here it is for everyone that doesn't want to waste a browser tab:
"I find that when someone's taking time to do something right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took time to do something right in the past, they're a master artisan of great foresight."
#974 is great! I know I have been guilty of #1319, when I really should of just done the repetitive task instead of spending so much time thinking it would save me some time in the future.
Totally agree. I think when people hear the word "lazy" they think "incompetent", like "they didn't know how to solve the problem, so they took a lazy route by not doing it very well" when this is not what is meant by the phrase at all, it is exactly what you said.
I would also say that it's doubly important with the experience because I've seen people spend far too much time one something that they think will save them time in the future, but that future changes. It's a balancing act.
Actually, this is the kind of complexity and misunderstanding that makes software more difficult to maintain.
If you step back and understand that the problem is the method name is not clear, creating more code to get around that is totally unnecessary - just fix the method name. The other repliers hit the nail on the head with better options.
I personally would opt for the renaming of the method first:
$this->executeAfterSeconds(5);
If it was a third-party library or I was able to refactor the method itself I would go for constant named after what it represents, rather than what it is:
$this->executeAfter(FIVE_SECONDS);
As a last resort (like if you had some reason why would couldn't physically change the source) a comment would also be totally acceptable.
For me this falls in to the "understanding" category. The problem your trying to solve and what the client wants are often mixed up as the same thing - but they seldom are.
You shouldn't expect that the client will know what they want even if they ask for it. There is however always an underlying reason why they think they need it. Take the time to understand that rather than just more billable hours. It will be better for you and them in the long run.
I had to think about the first one for a moment, but I do agree. It's better to abstract later with greater knowledge than the much more difficult task of trying to debug or fix it later.
It's an outstanding list and great rules to work by!