I guess I thought I put my two cents in as a smart but "scatterbrained" type of programmer. Prioritizing and focus has been my private war during my programming

I guess I thought I put my two cents in as a smart but "scatterbrained" type of programmer. Prioritizing and focus has been my private war during my programming career. Here are some points I'd like to make. 1. Concrete, quantifiable goals. The first time I really ran into a wall with my issues prioritizing was during summer CS research after my sophomore year of college. I was given vague tasks that were basically "make the program better." This doesn't help someone that is prone to tangents. In the process of working on some part of the program I might discover a new thing that needed fixing, switch to working on that, and then down the crazy refactor rabbit hole. 2. Deadlines. Deadlines help a lot (as annoying as they are). I always did well in school because of deadlines. At my work we have a goal of completing X% of Q1's weekly sprints on time. It's a team goal, so if I don't get my tasks finished for the week, the whole team doesn't get clear the sprint for that week. I find the team aspect helpful. It also facilitates communication between team members. People that finish early often look at the sprint and check on members that aren't done yet, offering assistance. 3. Boredom. Boredom is a real issue for me. I do better on harder tasks than easy ones because they're interesting. This isn't something I think a manager can solve because I think it's on the programmer's end to learn how to do work when it's less-than-engaging. But you might find some of your scatterbrained programmers actually tackle hard problems better than easy ones. It really depends on the programmer. 4. Communication. I was pretty upfront with my manager about prioritization and focus issues. It's something we discuss every time we have a one-on-one meeting. How things are going, what strategies I'm using, etc. He's also great at pruning down my conceptions of tasks. I'll read a task and think, "Oh I need to get X, Y, and Z done" and he'll say, "No, you just need X, the task doesn't actually call for Y and Z." 5. The optimization struggle. This is probably the single largest contributing factor to my prioritization issues. I don't like doing things a way, I like doing them The Best Way. A lot of time is spent figuring out which way is The Best Way. I might waste several hours working out a linear time solution to something I could easily write polynomially all the while n is small and it doesn't really matter. Inelegant code bothers the hell out of me so I might start a small refactor which snowballs into a larger and larger refactor. This is something that your programmers will have to get a grip on--saying no to refactors in order to better focus on a task. But as a manager you can help by watching out for tangental refactors and putting a stop to them.