elliotchance

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!

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.

You should totally turn this into a xkcd-like comic ;)

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.

That's great, I'm totally using that: https://twitter.com/elliotchance/status/751926458658852864. I couldn't find your twitter?

I'm a software engineer. If that's not clear from the article, you should be able to tell from the bio at the top and bottom of the page.

Yes and no. I think we read these things in textbooks and either don't truly understand why they exist until we've made the mistakes or we go too far the other way and start dictating best practice on to everything.

It's best to be be somewhere in between. It can only be learned by doing, not studying.

Cheers, great article. Left my own comment ;)

Spot on in my opinion ;)

I'm generally not a fan of recruiters simply because the vast majority of them are sales people first, and tech people second (or often no technical experience at all). Compounded by the fact some people interview very badly but are good engineers and visa-vera.

Even if you have experienced engineers doing the screening process (separate from the company being applied for) I still think it would be challenging because theres no "correct" way for a team to work and companies are so vastly different.

It definitely is something to think about. If you do some up with something, let me know :)

Fresh eyes on the problem is always good, usually after lunch or you have slept on it.

I find when my brain starts to grind to a halt I just go an do another un-related task to force myself to completely forget about the original task. It does help because when I go back to the original task my brain has to context-switch back into it and in doing so it may look at the problem a different way.

Extra holidays would be great! However, I think more holidays would make some engineers more productive and some less productive... I'm not sure if Google is still doing their 20% time, and if they are I know it doesn't apply to all the FTE engineers.

Thank you for the kind words :)

Thanks, I've fix it up.