Tips or techniques to use when you don't know how to code something? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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!

Answer 6

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.

Answer 7

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.

Answer 8

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!

Answer 9

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.