1

I'm new to coding , learning it since last year actually.

One of my worst habits is the following:

Often I'm trying to create a solution that is too big , too complex and doesn't achieve what needs to be achieved, when a hacky kludge can make the fit.

One last example was the following (see paste bin link below) http://pastebin.com/WzR3zsLn

After explaining my issue, one nice person at stackoverflow came with this solution instead https://stackoverflow.com/questions/25304170/update-a-field-by-removing-quarter-or-removing-month

When should I keep my code simple and when should I create a 'big', general solution? I feel stupid sometimes for building something so big, so awkward, just to solve a simple problem. It did not occur to me that there would be an easier solution.

Any tips are welcomed.

Best

Community
  • 1
Andy K
  • 285
  • 3
  • 9
  • 1
    **[Unclear what help you need](http://meta.programmers.stackexchange.com/questions/6559/why-is-research-important "see: 'Why is research important?'").** Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it’s hard to tell what problem you are trying to solve or what aspect of your approach needs to be corrected or explained. See the [ask] page for help clarifying this question. – gnat Aug 25 '14 at 14:25

1 Answers1

10

A good guideline that helps knowing when to create a "large", general and abstract solution, and when to just solve the specific problem, is The Rule Of Three.

The Rule Of Three is often applied to duplication: i.e. "if code is duplicated more then twice, move it to a function". However it also applies to the abstraction vs. solving-the-specific-problem argument:

First time that you need to solve the problem, just solve it. Don't try to build a big system that can handle more general cases, as you're most likely wrong in your estimations, and you will only lose clarity and add complication.

Second time you come back to the same problem, refine the design a little but still don't rush into building a big system.

Third time the same problem appears, you can build a general system to handle problems of this kind.

Don't rush into general solutions as you will only gain complication and lose clarity and focus.

A personal note: it took me some time myself to realize that usually, simple is better. You can always come back and refactor when a more general system is needed. But insisting on creating a big system to solve every small problem that appears, doesn't only complicate the code for nothing but also drains the mental energy that you should invest in actually working on the application.

Aviv Cohn
  • 21,190
  • 31
  • 118
  • 178
  • One more question, Prog. Let's say, you don't know the techniques that can simplify your coding e.g. using a `for` instead of using 2 `while`. You are creating with the 2 `while`, something that will be big and useless. But again, how would you do if the 2 `while`is the only way you know? – Andy K Aug 25 '14 at 14:37
  • Not really an answer but something to consider: http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it "Always implement things when you actually need them, never when you just foresee that you need them" – Jaydee Aug 25 '14 at 14:54
  • @AndyK I don't understand the question. – Aviv Cohn Aug 25 '14 at 14:54
  • @Prog, I would use an analogy. Let's say I'm way complex or stupid, take your pick. I can only open my car door by creating a new pair of keys each time I want to open it. A simpler solution would be to keep the key with you all the times and use it once you need it. Issue is you've never been taught that way. So because you don't know it, you keep building these keys again and again. My question is how do you learn something you don't know or you have never learn before? – Andy K Aug 25 '14 at 15:23
  • 1
    If I understand you're question, you're asking how to learn new techniques in programming? Firstly, program. In my opinion you get better at programming mostly by doing. Secondly, study the major principles and understand why they're important. E.g. SOLID, DRY... Once you understand the principles, you will have some sort of reference by which to judge your code. So for example you code, and then you realize that you're violating DRY. So you think how you can improve your code to not violate DRY, and you get better. Thirdly, ask questions on this site when you want to understand something. – Aviv Cohn Aug 25 '14 at 15:23
  • 1
    Two more things: 1- Study Design Patterns. They are common object oriented solutions to general problems. You can learn a lot by studying them. I recommend the great book Head First Design Patterns. But remember to only use Design Patterns where they fit. 2- Most importantly: *reflect on your work.* During and after coding, think about what you did and if it's good or bad, elegant or ugly. As I said, studying the major principles, such as DRY, YAGNI, SOLID, can help give you a measurement by which to judge your code and get better. – Aviv Cohn Aug 25 '14 at 15:25
  • You got it, @prog. Many thanks for your patience. I will do my own due diligence. – Andy K Aug 25 '14 at 15:26
  • I especially like your part where you advise me to reflect on my work. It is something no one told me, yet. I appreciate the wiseness of your comment. – Andy K Aug 25 '14 at 15:29
  • 1
    @AndyK Glad I could help. – Aviv Cohn Aug 25 '14 at 15:31
  • @AndyK Also here's a similar question I asked a while ago: http://programmers.stackexchange.com/questions/237123/how-to-make-consistent-progress-towards-the-goal-of-becoming-better-as-opposed – Aviv Cohn Aug 25 '14 at 15:33
  • @Prog, indeed. You nailed correctly my implicit goal. The aim is to get not only better but to gain mastery. – Andy K Aug 25 '14 at 15:36