Take the 2-minute tour ×
Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. It's 100% free, no registration required.

I have a question for a long time. I am very much bothered by this one. The question is "What approach is good in doing job? Is it first getting the job works, then improve it over time, or You should focus from the beginning to get it in improved way"

This isn't clear, so I am using an example, As a student, If I have given a task (more specifically a programming task), I have two methodology in workflow,

  1. First only focus on the getting it working. Then improve it over time.
  2. In the beginning, try focus on the cleaner and better method to get it.

Another example can be, In reading books (specially text books, like learning programming). Should I first read it and finish it, ignoring the unclear things or the other way?

Please, note that, I am basically asking it with having previous programming experience. Just trying to learn a new Language.

Also note that, I want to have a general answer about this matter. (Several answers are here, I thank to all, but all answers are geared to only the programming task). For example, as I write answers in AU site, Which is better in this sense, "First submit the answer with only the necessary pieces, then improve or submit answer with all good things?"

share|improve this question
    
It is a canonical problem, i think. –  mmdemirbas Jul 3 '12 at 12:18

7 Answers 7

up vote 6 down vote accepted

Regarding programming there are a lot of different formal methodologies for how you should go about it. But a lot of those assume you are already knowledgeable in the programming language and coding task at hand.

There's also a lot of differing ideas on how to best learn things. But most of these are geared for pure learning, and don't really address the situation of a busy person who just wants to learn enough to get something done, for which there may not be examples, documentation, or mentors.

The most effective method I've seen for this kind of situation I picked up from some mathematician/programmers on one of my projects, which they called "Toy Driven Development". I've adopted that style with my own personal projects to good effect.

Starting from zero, you think about the general goal you want to get to, and identify one or more problems you think you'll need to solve in order to get there. Select the simplest sounding problem that isn't something you already know. Do some research (via google) to see if anyone's already done it (or asked about it on StackExchange!), and if so snag the example, take it apart, study it, master it, and tweak it into something more closely resembling the project ahead of you.

If there is no such thing, then you have some experimenting to do. Find out what you can via manuals or whatever and get hacking. If you get stuck, ask for help or to bounce ideas off others. But keep your goal simple. You may realize that the single problem is often several; if so pick one and write the others down to work on later. Don't worry to much about proper code formatting or writing tests or documenting interfaces or any of that (unless it helps you think), just focus on the specific problem you're trying to sort out. Once you've solved the problem, do tidy up the code to get rid of superfluous scaffolding or test code to make your toy clearer. You want it short, something that makes a good example. If you can get the toy to do something useful by itself, that's perfect. Use the toy in various different ways to see if you can break it or find bugs.

Next, whether you found an example or made one yourself, put it in an Experiments folder, and move on to the next problem you want to have done. Keep iterating until you have a handful of these toys.

Then, shift gears to "integration". In this phase your coding should stick to things you already know well. Assemble a good solid infrastructure for your code, documenting and writing tests for each bit as you go (or write the tests and/or documentation first!) Don't cut and paste your toy code directly into your project, but instead use it as a reference as you re-write the code properly. When you get to a point where you're just not certain how to properly do some new feature, that's your signal to go make another toy.

Anyway, the point is to keep the (fun) experimental work separate from your project. This helps you control the balance of time you spend learning vs. implementing, and helps you shake bugs out of new code ideas before they infect your main codebase.

Same approach when reading a programming book. Read a little, run the examples and do some experiments to solidify what you've learned. Then go back and read more. But if it's something you already are relatively comfortable with (like learning your 5th programming language) then just read straight through.

share|improve this answer
    
+1, Thanks for the answer. specifically for the programming related topics. But I wanted a more general answer, which can be applied to most of the area. May it was my fault to not clear the things in first place. though I have edited the question. –  Anwar Jun 29 '12 at 17:43
2  
I've found the same approach can be used in any technical matters. I use it in woodworking when I get new tools for instance. –  Bryce Jun 29 '12 at 18:09

Studies show that design is always improved with every iteration.

It often takes a lot longer to create a really good design from the start than it is to take a poor design and iterate on it.

Solution:

  • Just create a design in a limited period of time (better if done individually, in parallel with colleagues.
  • Pick the best design out of the group, mix and match good ideas.
  • Build it.
  • Test it until it breaks and find out why.
  • Iterate on your previous design using the test results.

Brainstorming is actually a poor method as creativity comes with association. You'd need feedback to get something done right.

share|improve this answer

Early optimization is the root of all evil. -Donald Knuth

My approach is to just get things done, and then see if something could (and should) be improved. If you can program a computer, you know that 90% of the time is spent on 10% of the code. Optimizing anything other than the key 10% is usually a waste of time and effort.

share|improve this answer
    
Thanks for the answer. But the problem is I also have read many quotes from many famous/good person. If they helped me, I may probably not ask the question. I will be much glad, if you give what your personal experience and belief is. –  Anwar Jul 3 '12 at 17:37
1  
My personal opinion is what follows the quote. I have found it in the past that when I optimize things before I have actual data, I normally waste my time. A quick prototype is infinitely better than a perfect plan with no implementation. –  Riviera Jul 3 '12 at 20:59

While you do, you will learn more.

While you learn more, you will do better.


So,

Focus to complete the task doing your best. Then improve it. Note that, improvement can be made at early phases. Because, you are learning while doing.

But,

If your job is hard to change after it is completed, then you should improve quality as early as possible.

share|improve this answer

I used to have a guy who worked for me as a management analyst who was the king of "how can I come up with a better way to do the job". He would take 40 hours to come up with a way to do a job in an hour. Unfortunately the job would have only taken 10 hours to do using the intial method proposed and was a one-time task. He missed every dealine and other people usually ended up doing his work. Needless to say, people hated having him work on their projects even though he eventually came up with a good process.

So especially if it is a one time project, just get it done. If it will be repeated, then decide case-by case which is better. You should probably spend some time to get a decent method in most repeateble processes, but it may include some "just get it done" interations until you find what is best. It is hard to find the best method the first time you try to do almost anything.

share|improve this answer
    
+1 I love to analyze stuff and to look for the perfect solution. But my experience told me that doing a quick design, implementing it and then finding the flaws and eventually fix it takes sometimes about the same time. Benefit of the quick implementation: You have the chance to test early and maybe have a decent enough solution during the first try. I sometimes have to force me to start implementing, because committing to something I don't trust 100% and maybe have to rewrite is not a thing I like. –  0x6d64 Jul 4 '12 at 6:51

Let's look at it from another perspective. From past experience, do you know which of the two methods you present works better for you? From my experience, I know that I learn programming best from ~doing~. I started learning Java last year. I had a 500+ page textbook that was completely daunting, and I just could not focus on the content. I wanted to program! No matter what I did, I could not force myself to read and learn everything I needed to know.

I flipped to the exercises at the end of the chapter, and while I had a general idea of how to construct the program, I then went back and re-read the sections of the chapter that were relevant to the specific procedure and syntax of what I wanted to do.

I come from a procedural programming background, and in chapter 5 of my Java book, having covered syntax in chapters 1-4, we started getting into object oriented concepts. Reviewing past programs, I had written OO programs in a very procedural way. Armed with OO ~concepts~, I went back and improved those programs using the new information.

For me, that method works really well. I jump in, I study what I NEED to know along the way, and if I stick with it long enough, I'll eventually learn all the content from doing and applying the knowledge instead of just memorizing.

What's interesting, is that when it comes to language, I'm very visual. I learned that I can pick up languages better from a textbook than from listening to CDs.

My point is that different methods of learning--starting from nothing and laerning along the way or learning everything and starting with a large body of theoretical knowledge to apply--work for different people, and even for different subjects in the same people. If you understand what you need and what's worked best for you in the past, you'll be able to answer you own question quite easily.

Either method is equally valid, depending on the situation and the person. It's up to you to choose the one that fits for YOU.

Good luck!

share|improve this answer
    
+1 for "I jump in, I study what I NEED to know along the way". I would say, " you need not be a mechanical engineer to drive a car, just learn enough to drive the car, then learn remaining as per your interest". –  Abid Rahman K Jan 23 '13 at 10:05

When first learning programming, you are unlikely to know the clean way to do it on the first try anyway. So there is no harm in exploring better ways as you learn. At work, there is a balance. You don't want to hack together something nobody will ever understand that may happen to work. You also don't want to spend loads of extra time to make it elegant.

With reading, it also depends. At the beginning of the book, you should understand everything because it is likely pre-requistie knowledge to understanding everything else. Later on, you can skim and go back to sections when they are more specialized.

share|improve this answer
    
Thanks for the answer. I have programming experience before. In that case, what will be the best options. I'll update my question to include this thing –  Anwar Jun 29 '12 at 15:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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