tags:

views:

208

answers:

9

As my question implies, I seem to have a problem getting my hands dirty when learning new programming methods and technology. My problem lies in knowing there may be faster, more efficient, less tedious, and overall "better" ways of doing a certain task. Instead of spending the time writing bad code and learning from my own mistakes, I continue absorbing information -- searching for the "right" way of coding (if there is such a thing). I understand I need more practical knowledge to properly associate new information with my own experiences. But the fact that I know I may not using some coding convention or standard practice continually irritates me while I'm writing code.

At this point, the vast amount of information almost becomes a disservice to my learning process.

Does anyone have any tips to strike a balance between theoretical learning and practical knowledge? Could it really be as simple as "stop thinking and start coding"? Perhaps someone might have a relaxation technique they could share which helps focus their mind?

+1  A: 

What I'm going to say kind of sounds like a big M Methodology, but so be it.

One of the things I got out of reading Refactoring (it is kind of a meta message) is that there is no "right" way of doing things. There's only "right for now". Once you are versed in the practice of refactoring "bad" designs into "better" ones, you start worrying less about the shortcomings of the current code because you know you can fix it in the future...

In terms of all the stuff that goes on outside of coding, "The Process" as it were, I think you just have to get over it do what you need to do to get the code out the door. It's a little less easy, but you can refactor the process as well once you learn what works for you.

I'm not saying that your learning about all this stuff should stop, but that you need to be able to get things done in order for any of it to matter.

Jason Punyon
A: 

I've found that learning new languages can help with learning better practices. For example, if you're a C# coder learning Rails, you can't help but get acquainted with TDD, MVC, etc.

And, for a coder, learning a new language often doesn't feel as much like work.

dommer
When I realized I couldn't extend my Flex/AIR apps without server side services, I started experimenting with PHP and Ruby. Experimenting with a couple other languages definitely opened my eyes a bit, but I'd prefer to be really savvy in 1 area, than average in a bunch.
blindf1re
+1  A: 

I believe if you put more purpose into your coding the standards problem will go away. This will help you decide which standards to use or throw out.

meaning: what is the priority of your code, is it supposed to be easy to update, efficient, both.

Are you building for efficiency or modularity and expandability.

The chief rule I've operated under for standards practices is this:

"people are more expensive than computers, therefore code for ease of updating in man hours even if it's costs you in performance."

But consider what the pitfalls are of not following standards, and try to find the underlying reason for the standard.

Over time you will develop your own standards that make sense in your particular development style, and they may or may not fit in with what you've read.

Fire Crow
A: 

The test-driven-design methodology could help a lot with this. Write a test, then write any code that passes the tests, then worry about refactoring it into something better.

Once you think you've done all the refactoring you know how to do for a particular test, just start another test case. You can always come back to the old ones later after you've learned a few more things.

The benefit of this approach is that you concentrate on the practical matter of writing working code, and you'll shy away from any fancy stuff that breaks it.

Kristopher Johnson
Thanks Kristopher! This methodology seems right up my alley (I've been working in QA for about 4 years now). Specifically, the idea that I know I'm going to come back to improve my code, and the certainty the code will work seems very appealing.
blindf1re
A: 

Have a goal. If you just write code in order to learn, then you'll get stuck in this loop for quite long (if you have that kind of mentality).

If you've got a project to finish (preferably with a deadline), then you'll quickly find yourself behind the plan and running to keep up. That's probably a good thing if "thinking too much" is your problem.

Set yourself a goal for a small project that you want to achieve within n days. Then go implement the project in that time.

Joachim Sauer
A: 

I think that in that case you should this like investor, really :)

You can choose your learning/investing strategy in one way or another, depending on your requirements. If you will spend all your time for investment you will spend all your free assets, until this investments will start to bring value.

Get things done, and spend some part of your time to learning about different concepts that can help you get more things done more easily :)

Good luck! :)

Fedyashev Nikita
+2  A: 

This isn't a technical problem - it's a psychological one. Perfectionism, versus good-enough.

Alister Bulman
A: 

I can relate, I just always try and repeat this quote over and over:

"Perfection is the enemy of done."

jfar
A: 

Aside from purging perfectionism from one's train of thoughts, here are a couple of other ideas:

  • Try to be mindful of the moment, not the past or the future. This is sort of a "live in the now" idea.
  • Concentrate on the little part you need to do now and remember the YAGNI principle and over engineering that you want to avoid.
JB King

related questions