Knowing when to refactor

Just feeling like refactoring is not a good reason to do it. Make an educated decision: Is the code change worth the effort? Stay straight on track, don't go astray.
Note: Usually, you'd refactor after finishing your story. At times, it might be necessary to refactor up front. But try to keep refactoring out of your current task.

Knowing where to optimize

Rails professionals since 2007

Our laser focus on a single technology has made us a leader in this space. Need help?

• We build a solid first version of your product
• We train your development team
• We rescue your project in trouble

Read more Show archive.org snapshot

Things should only be optimized a) when they have settled, i.e. haven't changed for a longer time, and b) when there is a measurable gain from the optimization. Ask yourself: Why would you want to optimize this? Will it bring a 10x speedup, or rather 1.5x? Where is the real bottleneck? Find the point where optimizing is worth the effort.

Knowing when to cancel a task

Sometime a task just cannot be completed in reasonable time. Keep an eye on effort and time. Is the time spent still reasonable? If it's not, think of alternatives.

Knowing when to ask for help

Don't troll others with silly questions. Put some effort in solving problems yourself. However, if you're stuck, do ask for help.