Ensayia wrote:I lean the furthest in the direction of inventive.
I usually either pick apart code to understand it, or follow someone's directions to the letter until I understand the core concepts and then build my way up from there. I often don't explore unless I have a solid base understanding of what I'm working with. Often times this can be a hindrance, but usually when I finally do write code it's solid.
I really should break out of the box and just explore a little without knowing for sure. I think it's what holds me back as a programmer. I;m about ready to get my feet wet with C++, so I have a feeling it will happen.
I'd have to follow what Robin said. There's so many ways to do things that using 1 set approach never really works, there's always room for reading new methods and refining your implementations of them. Meanwhile lots of more trivial tasks can be easily thought out and built without external aid.
Do you recognise when the world won't stop for you? Or when the days don't care what you've got to do? When the weight's too tough to lift up, what do you? Don't let them choose for you, that's on you.
I went structured. I see programming as solving a problem:
1. Divide problem into as many small problems as I can.
2. Pick the simplest of the problems, and get coding.
3. When done, test that it glues well with the rest of the things I have, and then pick another small problem.
4. When no small problems are present, I'm done.
That's the happy path, of course. Each of the steps has traps, so it is rarely a straight line. But that's the main idea.
I tend to overengineer my work, like small prototypes. Just to make a simple test program I add miscelaneous things that is practical but not needed. Example: made a simple web "browser" so I could test out th functionality of using internet in a löve project. And so I added an adress field and all that to not have to edit the code, wich would've been faster. I feel like this as a strength 'cause I can go back and oue my old code with ease.
I picked "logical" because I tend to think a lot about how I want to structure the program before I start coding. Sometimes that's a problem, in that when I have thought of a good way to do something, and it ends up not working, it feels like I've wasted a lot of time. But when you realize things you didn't think of before and end up changing your plan as you go, you learn things and become a better programmer.
Judging by the poll results I think you should change it to be multiple choice and I don't think anyone really does one style completely but uses elements of different. For example I am intuitive but also logical to an extent. I will know what I want to do for each section (logical), but have no idea what the actual calculations are until I dive in (intuitive)
Changed it to multiple votes:
You're right there is no "straight path" and usually including myself I change "style" depending on the situation. But I think we all have something we fall back on for example I tend to be intuitive mostly and get into a lot of problems then break those down until I solve them (destructive). Everyone is unique and our styles seem to be more dynamic than just one straight thing.
I guess its a journey. I wish that I could pop a pill and master Lua just like that, instead I have to read PIL and master it a couple months-years maybe even a lifetime. maybe never. (<_<) such limitations drive me crazy. Anyway I guess its a journey...
