16

On personal projects (or work), if one gets stuck on a problem, or waiting to figure out a solution to the problem, if you jump to another section of your code, don't you think it will be a good reason your application will be buggy or worse yet never get completed?

Assuming you are not using git and code each feature to a specific branch, things can get out of hand since you have 3 different features you are working on, and you have unresolved issues in each.

So when you get done to work, you get stressed out because you have these hanging issues and half-baked code lingering about.

What's the best way to avoid this problem? (if you have it)

I'm guessing using something like git and creating a branch per feature is the safest way to avoid this bad habit.

Any other suggestions?

Improve this question
1
  • Do you have this problem for yourself? Or do you observe this by some of your teammates? Commented Mar 1, 2012 at 21:11

6 Answers 6

Reset to default
33

This is not a issue. Temporarily stepping away from a perplexing problem is one of the best ways to have a breakthrough on such a problem (either later when you are thinking about it or the next time you sit down with a fresh perspective/mind).

Always make sure you utilize source control branching properly and you wont have to worry about the half solutions in code. Some people never commit breaks, but that is just a personal choice. You should never really push breaks to share with others though.

Improve this answer
1
  • +1 for the version control branching. We've seen commits that fix 10 problems in one diff but one was bad, so no way to isolate the bad change. Commented Mar 17, 2013 at 15:37
8

As smp7d mentioned, jumping around can give you a good mental break from the problem at hand. However, it is important to not forget that the code you were working on is still incomplete. Make sure you know where you left off.

As smp7d mentioned, source control and branching is a great way to split your new feature code off, and see how it differs from the main code base.

One suggestion I have is that if you're working on a particular method, make sure that there is a well named unit test around that method. That way when you work on that code the next day/week/month/year, you should be able to clearly tell what the method is supposed to do, even if it doesn't currently pass the test.

Improve this answer
1
  • 1
    +1 for your very pragmatic idea of having a failing unit test (say, rather than a TODO comment) to make sure that you remember the problem that you put off. Commented Mar 1, 2012 at 21:24
3

Is it a problem? Not when it occurs to you for 10% of the features you are trying to implement. Sometimes you get your mind clearer when you do something different first.

Obviously it is a problem when you get stuck for 90% of the features you try to implement - then you either need help from others, or a slight kick-ass from your boss to finish what you have begon (of course, the latter will be contra-productive if you got stuck because of a real technical problems).

Best option for this case often is trying to split the feature you are working at into smaller sub-features or "feature-slices", which can be implemented, tested and debugged one-by-one. For me, it helps to write those feature-slices, open issues, parts to be done down on a list, give them priorities (A, B, C is enough), and work on the things with highest priority first.

Improve this answer
1
  • Good point. Jumping around should not be the norm. Commented Mar 2, 2012 at 13:47
3

It's been my experience that "jumping around", or more clearly "Jumping randomly around" is a symptom of a more urgent problem, one of poorly stated goals.

If you have a very clear idea, in writing, whether post-it notes on the side of your monitor or in formal specs attached to your issue tracker of choice, then you almost always know exactly what to work on next. If you are always working on one of those next things, then you are going to have a good chance of succeeding with the project.

If, on the other hand, your idea of what's the next most important thing is hazy, it's much harder to actually find a thing to work on that actually addresses the problem your project aims to solve, or more specifically, it's much less cut-and-dry when deciding that this particular change is complete and solves a particular issue.

If you have a goal like "make the UI easier to use", well, it's just about impossible to say what the next fix aught to be, or when you have finished "fixing the UI" and can move on to something else. If, on the other hand, you have a goal like "combine these drop-downs into a search field with autocomplete" and "'foo' should auto complete to 'Fooly Brand Baring'", its totally obvious to when you've fixed that problem.

Don't write any code until you have a really clear idea of when to stop, and if you don't have any clear ideas, work on getting one of those instead of starting another branch for some general feature.

If you do have such a good spec of work (even for personal projects), then "jumping around" is totally fine and safe and useful.

Improve this answer
0

While getting away from a problem may help you solve it, keep in mind that there is a cost to switching contexts. You should try to do so only when you are truly stuck or a mission-critical task comes up (e.g. a customer is down).

If you are constantly switching back and forth between tasks, you may end up with several half-finished features and lots of wasted time. This is why practices like kan-ban encourage you to set a work in progress limit. This way you can focus on completing, at most, only a few tasks at a time, thus increasing throughput.

Improve this answer
0

Sometimes it can be helpful to limit the number of features that are implemented in parallel. Refuse to start implementing an extra feature if that limit would be exceeded until one other feature is finished. This approach is called Kanban

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.