I have a background as UI designer. And I realized that it is a bit hard for me to write a pieces of logic. Sometimes I get it right, but most of the time, I end up with something hacky (and it usually takes a lot of time). And is not that I don't like programming, in fact, I'm starting to like it as much as design. It's just that sometimes I think that I'm better at dealing with colors an shapes, rather than numbers and logic (but I want to change that).

What I usually do is to search the solution on the Internet, copy the example, and insert it into my app (I know this is not a very good practice).

I've heard that one tip was to write the logic in common English as comment before writing the actual code.

What other tips and techniques I can use?

  • 7
    Problem-Solving Strategies
    – yannis
    Dec 2 '12 at 3:50
  • @Yannis Rizos Thanks, wow, they are a lot. Should I try them all or there are some that are particularly effective in programming?
    – janoChen
    Dec 2 '12 at 3:53

Baby steps.

Break up a big problem into smaller problems. Then solve the smaller problems.

Bonus points if you can back up your solutions to the smaller problems with automated unit tests.

  • 1
    This comment basically summarizes everything. Divide and conquer not only helps in finding the solution to problems, but also encourages identifying spots where reusable functions can be born, and thus it naturally leads to better Unit testing.
    – Juan
    Dec 18 '20 at 2:01

I usually write things down on paper while I'm thinking things through. That way I can write pseudo-code or do drawings (usually both), and I don't have to worry about the limitations of the drawing software or what can fit in a comment.

I find that if I'm doing something at least mildly complicated, I really need to get things down on paper first, or else I end up with something hacky, like you mentioned.

If I end up with something hacky, it frequently almost works. Sometimes I can hack on it until it finally does work, sometimes not. If I take the time to work it out on paper, it often works without too much trouble.

  • 3
    +1 for thinking before coding. This almost always leads to a better solution. Dec 2 '12 at 10:14

I think that you've sort of answered your own question, and I don't mean that in a bad way -- it's a common piece of advice that the best way to learn how to code is simply by coding. I would personally try to avoid copying code directly from a source unless it's absolutely clear-cut as to what's going on (that is to say, that there isn't necessarily another good way to do something), though many of those sorts of issues are syntactical. Taking the time to understand what's going on and how you (or someone else) is implementing it matters the most.

In the time I've spent learning how to develop, I've found that working with MVC technologies is a great way to understand how to do design, such as Rails (what I'm working with right now) or iOS/Cocoa Touch. Because you're working in such an object-oriented environment of design, once you start thinking in terms of models and their logic being separated from the view (with controllers being the glue that binds them), you also start thinking in terms of how you can keep your objects abstracted in a logical, yet (hopefully!) uncomplicated manner.

This is based on my own experiences, of course, but I hope my thoughts on your question can be of some help.


In addition to the answers already given, one of the best ways to get jump-started is to learn from an application that is simple and where the source code is available.

This is where such social repositories like Github shine. An incredible place to browse through for examples. And when you find one, you can immediately fork it as your own and do what you want to the application, so once you have it:

  • you can run it
  • tweak it here and there and see how things change
  • as you get more comfortable, you make bigger changes
  • you'll soon find you are really learning

Another option is to use the classic example reference implementations that are documented in so many different places. For example Java's Spring framework uses the venerable "Pet Store" example. I think you can even find that example on Github.

Other frameworks / technologies such as Groovy's Grail framework use other classics like a Book application for persisting and viewing Books and Authors, etc.

The final option that I've tried is following a good programming book and start typing up the examples by hand and putting them into a repository like Github; this has at least two benefits: 1) there is a reference for you with your own notes that will help you remember cool things in a way that you will remember and 2) if you get into tough spots you can easily get friends or colleagues to see your code and chime in with advice.

Science and especially programming is really built on the experiences of others. Figuratively speaking, copying/pasting and then tweaking until you understand is what helps developers become engineers.

  • 2
    Blindly copying code can be dangerous if you do not understand what it does. Especially in science, blind copying is very bad. If you copy, you could to tak the idea of the code, but still writ it from scratch. This way you'll understand it better. Similar to making the excercises at the end of a statistics chapter to see if you really understood what's going on. Dec 2 '12 at 10:19
  • Be careful with reference implementations. They often show techniques which could be used, but are not really applicable to the current implementation.
    – BillThor
    Dec 2 '12 at 15:28
  • Completely agreed. I'm using 'copying' as a euphemism ... we all begin learning by imitation. And you're correct - we need to be careful and understand ourselves well enough to know when we are in learning/imitation mode. Thanks for pointing that out.
    – Johnnie
    Dec 2 '12 at 23:50

Imagine you have to make a report about your problem to someone else.
Analyze the problem. Try to formulate it as clearly as you can. Write pseudocode, draw diagrams.
Think about what could be causing the problem and why your approach is wrong.
Ask yourself if there are any other perspectives you can view your problem from.
Don't just do that in your mind, put it on paper (or a document on your computer).

If none of that helps you immediately, try not to think about the problem for a while. Have a good night's rest. Still no solution? Try googling your problem, or searching SO for a solution.

If all else fails, ask a question on SO (or SE Programmers if it's more appropriate for your particular question). Be sure to actually include your "report" (or the important parts of it) when asking the question.
When you get an answer, ask yourself why your approach didn't work and what could have helped you to come to the solution by yourself. It might help you find a solution for some problem you come across in the future which requires a similar approach.


I agree with thinking on paper. As a rule, I identify every item of information that I'll need and where it will be coming from, first. It doesn't have to be elegant, just accurate. Business logic questions and design strategies usually come during this process.

With that, as a java developer working end to end on an application, I further divide things by tiers: presentation, web, business logic, and the data access layer. When I have time, I usually write out my class names during this part.

Last of all I always endeavor to run tests for the back end, before I write code. You can wire everything up elegantly, but if you can't hit the back end: database or web service for example, it won't work!


Some of the principles of test-driven development help a lot here.

One of the best ways to solve complex problems is to solve it for specific use cases and then discover a generalization. Using TDD promotes exactly that. You create a simple test case and get that working, then create another test case and get that working. Finally you see if there is some generalization you can make that allows you to handle both test cases with the same logic. If you can, then it will probably handle a lot of other test cases as well. Since you can run all your test cases at any time, you can feel free to improve your logic without worrying about breaking something. This way, a hacky solution doesn't have to stay hacky.

Test-driven development also promotes

  • breaking up large problems into smaller ones, so that it is easier to get good test coverage.
  • thinking up front about what you really want to achieve before you get bogged down into the details of the implementation.
  • avoiding over-engineering by trying to make the tests pass in the simplest way possible, and simple solutions are usually the best ones.
  • Here is a counterargument: TDD is not a good way to solve something you are unfamiliar with. See the infamous How to not solve a Sudoku where TDD "expert" Ron Jeffries embarrassingly fails to provide a solution while blindly using TDD, and Peter Norvig solves it using good old fashioned "knowing about the subject matter" and "thinking about it". You cannot generalize an algorithmic solution out of TDD cases, unless it is trivial or you already know your goal in advance.
    – Andres F.
    Dec 2 '12 at 16:07
  • @AndresF.: It definitely is an interesting example. I think the issue here though is "blindly". I think you always want to step back and take a look at how your code is evolving to gain some insight into the problem. I've had many times where I wasn't able to see a general solution at first, but after looking at how to solve a few simple test cases, the more general solution became clear. Dec 2 '12 at 16:18
  • Agreed that "blindly" is the most likely culprit. But if Ron Jeffries, an expert on TDD and cofounder of XP, cannot do it right, then who can? :P More seriously, I think the other answers to this question are more relevant than TDD: breaking the problem in smaller chunks and reasoning about them, writing pseudocode, writing a proof on paper, etc, are all more important than test-driven design and "test first". When the problem is algorithmic in nature and nontrivial, TDD won't help you (as much). TDD will help you when writing CRUDs, though.
    – Andres F.
    Dec 2 '12 at 16:34
  • @AndresF.: That may be true. I didn't get the impression from the OP that these were hard algorithmic problems though. It seemed to be related to the various bits of logic that come up in user interfaces, which often have pretty trivial solutions but are easy to get wrong. That may not be OPs actual situation. I would say though that even for hard algorithmic problems, working up test cases can be a huge benefit to understanding, and making code testable inherently involves breaking it into smaller and more manageable pieces. Dec 2 '12 at 17:00
  • Oh, test cases are definitely part of problem-solving. TDD is not just about test cases, though. I'm disagreeing with TDD, not with testing! I'm disagreeing with the design part of TDD. (Though now I agree with you maybe the algorithm scenario doesn't apply to the OP's situation)
    – Andres F.
    Dec 2 '12 at 18:35

There's actually a book which answers exactly that question:

How to Design Programs – An Introduction to Programming and Computing by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram Krishnamurthi

They are currently working on a second edition, and after that, a second volume (How to Design Components).

The really cool thing about this book is that it gives you a set of recipes for designing programs. In other words, it gives you step-by-step instructions which you can (semi-)mindlessly follow in order to design a program.

Or, to put it yet another way: it contains a set of programs for writing programs, so that you don't have to figure out how to write a program: the authors figured it out for you!


addition to the answers above, sometimes is not about knowing logic itself but to know the framework and language that you working with. Every framework or language has its own characteristic and it is great help get familiar with that.

Not the answer you're looking for? Browse other questions tagged or ask your own question.