"Keep on sowing your seed, for you never know which will grow - perhaps it all will."
Albert Einstein
Unfortunately it all doesn't
But I'm hoping some of it will.
Whats your philosophy?
What your Philosophy when it comes to coding?
What your Philosophy when it comes to coding?
Heres a quotation from Albert Einstein which I think sums up my philosophy when it comes to coding;
"Keep on sowing your seed, for you never know which will grow - perhaps it all will."
Albert Einstein
Unfortunately it all doesn't
But I'm hoping some of it will.
Whats your philosophy?
"Keep on sowing your seed, for you never know which will grow - perhaps it all will."
Albert Einstein
Unfortunately it all doesn't
But I'm hoping some of it will.
Whats your philosophy?
-
Kaeru Gaman
- Addict
- Posts: 4826
- Joined: Sun Mar 19, 2006 1:57 pm
- Location: Germany
My philosophy is to assume that I will need to edit the program in a few months time therefore I must prepare for this at the time of writing the program. Amongst other things, this means including meaningful, helpful comments that don't merely paraphrase the code.
Also, (though this is probably more of a strategy than a philosophy) on first writing a program, before working on it's main logic, I initially focus all my efforts into producing a good, functional graphical interface (GUI) because it tends to make debugging much more meaningful as the context is then correct. It also enables a program demo/simulation to be rapidly available, if required.
P.S. I know what KISS means, but what about STRiP? This is new to me.
Also, (though this is probably more of a strategy than a philosophy) on first writing a program, before working on it's main logic, I initially focus all my efforts into producing a good, functional graphical interface (GUI) because it tends to make debugging much more meaningful as the context is then correct. It also enables a program demo/simulation to be rapidly available, if required.
P.S. I know what KISS means, but what about STRiP? This is new to me.
Anthony Jordan
-
Kaeru Gaman
- Addict
- Posts: 4826
- Joined: Sun Mar 19, 2006 1:57 pm
- Location: Germany
-
Hroudtwolf
- Addict
- Posts: 803
- Joined: Sat Feb 12, 2005 3:35 am
- Location: Germany(Hessen)
- Contact:
Tom Cruise once said ''It doesn't matter what I believe, it only matters what I can proove'' - in A Few Good Men, if I'm wrong about that, then feel free to point and laugh.
If I don't understand the problem, or if I don't think it will work, then I simply won't even start coding it. Some people can just go onto a project without worrying too much about the details, as they plan to research as they go, but I find that unless I know that what I'm working on definitely does the job, I can't justify working on it.
I guess it might sound arrogant if I say that I already know that the code will work before coding it - but it's a factor of experience, not confidence. For example yesterday to help a buddy out I agreed to draw some sprites for him, Lode Runner to be exact, so nothing too difficult. I probably spent 2 hours on the sprites, then I made him a mini level editor in the space of 15 minutes, thing only has like 50 lines of code in it. Because I've made a lot of editors, I knew exactly the bare minimum of what was needed, and hammered the code in - thing compiled first time too. My point is not that I work fast, my point is that the little project sits perfectly in the groove I've worn with my techniques - a project that doesn't fit the groove is unlikely to succeed.
I guess this is the major factor in deciding what project to take on next. If you have to sit and think about if you can do it for any length of time, then you might be better off avoiding it - if you could do it, then the chances are you'd be doing it already!. Never start a project until you have a clear path, have tackled all the major components before, and can visualize the finished product clearly.
I've learned far more doing mini projects and messing with examples than any book I've read, and I've read at least 2.
If I don't understand the problem, or if I don't think it will work, then I simply won't even start coding it. Some people can just go onto a project without worrying too much about the details, as they plan to research as they go, but I find that unless I know that what I'm working on definitely does the job, I can't justify working on it.
I guess it might sound arrogant if I say that I already know that the code will work before coding it - but it's a factor of experience, not confidence. For example yesterday to help a buddy out I agreed to draw some sprites for him, Lode Runner to be exact, so nothing too difficult. I probably spent 2 hours on the sprites, then I made him a mini level editor in the space of 15 minutes, thing only has like 50 lines of code in it. Because I've made a lot of editors, I knew exactly the bare minimum of what was needed, and hammered the code in - thing compiled first time too. My point is not that I work fast, my point is that the little project sits perfectly in the groove I've worn with my techniques - a project that doesn't fit the groove is unlikely to succeed.
I guess this is the major factor in deciding what project to take on next. If you have to sit and think about if you can do it for any length of time, then you might be better off avoiding it - if you could do it, then the chances are you'd be doing it already!. Never start a project until you have a clear path, have tackled all the major components before, and can visualize the finished product clearly.
I've learned far more doing mini projects and messing with examples than any book I've read, and I've read at least 2.
I disagree with this statement entirely!vanbeck wrote:If you have to sit and think about if you can do it for any length of time, then you might be better off avoiding it - if you could do it, then the chances are you'd be doing it already!. Never start a project until you have a clear path, have tackled all the major components before, and can visualize the finished product clearly.
I always try to improve my programming skills by taking on projects that i don't necessarily know if i'm going to be able to do. To learn new things you have to push yourself beyond your comfort zone and try something you find hard to do. I don't mean that a beginner should start trying to write a compiler but you should find something you don't know much about and incorporate it into a project to learn more.
It doesn't matter if you fail! You will learn more from your failures than you ever would if you never tried!
Here's an interesting blog post on the subject:
http://www.codinghorror.com/blog/archives/000300.html
My main approach to programming is:
► Write code as if others need to be able to read and understand it.
► Properly learn stuff that you found hard last year.
► Try starting and completing a project that you know nothing about.
► Learn a new programming language at least once a year.
► Do nothing malicious.
Last edited by Kale on Tue Apr 21, 2009 4:38 pm, edited 1 time in total.
--Kale
Hate to quote myself but...
I agree completely, what I mean is that I make sure I know everything I need to before trying to implement it into a main project. Then I tend to recode, but the main thing is to get the untidy 'learning' code out of the way first.I've learned far more doing mini projects and messing with examples than any book I've read, and I've read at least 2.