Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Coding filosophy-strategy

  1. #1
    Join Date
    Dec 2007
    Beans
    1,060

    Coding filosophy-strategy

    Hello guys, as a new in the field, as I read the forum they are many gurus here.
    Could you guys chair your experiences of getting so far in coding ? the obstacle for a new who want to be good at coding her i am using java, I don't think that makes much of difference.
    What is the mental field, the transition from a problem definition to a good code. I have look at many books they all have lots of codes, but not a word about the mental gymnastic of the decision making.
    Maybe I am looking for how to acquire a strategy from problem to coding.
    tks.

  2. #2
    Join Date
    Aug 2006
    Location
    60°27'48"N 24°48'18"E
    Beans
    3,458

    Re: Coding filosophy-strategy

    The only way to learn it is to actually do it. First, learn one language well enough so that you're comfortable with it. In this phase, don't jump between languages too early on. Advance your learning by doing simple training tasks. Also, read other people's code. I should have done that more when I was learning instead of always trying to figure out everything on my own from scratch.

    Java is an OK beginner language but I do have a reservation about the static-typed OOP which forces you to think about object-oriented design too early. A beginning programmer should not be forced to end up stumbling on insufficient object decomposition skills -- that is a separate skill that comes in due time, after seeing enough code and examples.

    Then, when you want to move on from simple tasks to more "real" projects, you may want to read some on algorithms and general design principles. Again, books really aren't a replacement to actually getting your hands dirty... the line between actual code and abstract principles and structure of your problem at hand starts to eventually become quite blurred once you're both a competent programmer and a problem analyst At about this time you need to expand your horizons by learning different paradigm languages... something like functional programming, to get new perspectives to languages and problem solutions.
    LambdaGrok. | #ubuntu-programming on FreeNode

  3. #3
    Join Date
    Jun 2007
    Location
    Maryland, US
    Beans
    6,267
    Distro
    Kubuntu

    Re: Coding filosophy-strategy

    Well for starters, never think of coding as the first step to solving a s/w problem. I see it too often (and I did it myself in the early stages of my career).

    The first thing to consider is the design. The second thing to consider is the design. And the third thing... ok, you get it now.

    Basically, before you commit yourself to a lot of coding, try experimenting with a design using UML, visio, or whatever (Use Cases?). You should have a high-level idea of what the s/w application will do and whether it satisfies all of its intended requirements. You should also question whether it is adaptable to new requirements.

    Feel free to prototype program snippets to get a feel for new programming tools (e.g. C++ Boost library) that you may encounter. These little exercises can be applied towards the bigger project.

    Anyhow, once you make it to the coding-phase, it should pretty much be a cake-walk. The design, which is hopefully in place, will be your guide.

    P.S. As the ol' saying goes... "There's no substitute for experience."

  4. #4
    Join Date
    Jun 2007
    Location
    Porirua, New Zealand
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: Coding filosophy-strategy

    +1 to the previous suggestions, plus learn to break problems into managable chunks
    Forum DOs and DON'Ts
    Never assume that information you find using a search engine is up-to-date.
    Please use CODE tags.

  5. #5
    Join Date
    Jun 2008
    Location
    Sin City
    Beans
    588
    Distro
    Ubuntu UNR

    Re: Coding filosophy-strategy

    Quote Originally Posted by dwhitney67 View Post
    The first thing to consider is the design. The second thing to consider is the design. And the third thing... ok, you get it now.
    On the flip side, design is not everything. There is something to be said about organically grown code, especially in a language that makes it fairly easy to refactor.

    Coding is like battle. Just as there has never been a plan that survived battle so too has there never been a design that survived coding. When you get down into coding you find that your preconceptions in the design stage were flawed. If the flawed preconceptions are at the core of your design the entire design is flawed. So, yeah, designing is good. But don't dwell on design too much and be prepared to scrap it in a heartbeat if it simply doesn't work.
    Warning: Any code examples I write are probably untested and contain bugs. Do not execute directly. Look for intent, not accuracy, please!
    L.A.G. - Jobs Dissembles - 2010/4/29

  6. #6
    Join Date
    Aug 2006
    Location
    60°27'48"N 24°48'18"E
    Beans
    3,458

    Re: Coding filosophy-strategy

    The problem with telling a beginner in particular to use UML is that paper designs require pretty much perfect foreknowledge of the language you're using, plus how to apply it to the problem. Once you know those, you might just as well start coding already. This is why I have always considered UML to be mostly a business communication and documentation, not a design, tool.

    Especially a beginner just needs to do a lot of exploratory programming to learn "how programming applies to problems". It's more fun too
    LambdaGrok. | #ubuntu-programming on FreeNode

  7. #7
    Join Date
    Dec 2007
    Beans
    1,060

    Re: Coding filosophy-strategy

    Lisati.
    you have touched something I struggled with when you said
    "+1 to the previous suggestions, plus learn to break problems into managable chunk"
    it seemed like you are good at it what is your secret ?

  8. #8
    Join Date
    Dec 2007
    Beans
    1,060

    Re: Coding filosophy-strategy

    Quote Originally Posted by lisati View Post
    +1 to the previous suggestions, plus learn to break problems into managable chunks
    you have touched a problem i am struggling with
    What is your secret of it
    "Break problems in manageble chaunks" ?

  9. #9
    Join Date
    Jun 2007
    Location
    Maryland, US
    Beans
    6,267
    Distro
    Kubuntu

    Re: Coding filosophy-strategy

    Quote Originally Posted by Greyed View Post
    On the flip side, design is not everything. There is something to be said about organically grown code, especially in a language that makes it fairly easy to refactor.

    Coding is like battle. Just as there has never been a plan that survived battle so too has there never been a design that survived coding. When you get down into coding you find that your preconceptions in the design stage were flawed. If the flawed preconceptions are at the core of your design the entire design is flawed. So, yeah, designing is good. But don't dwell on design too much and be prepared to scrap it in a heartbeat if it simply doesn't work.
    IMO, you opinion is pure rubbish.

    What is a person (or group of persons) supposed to do when building s/w for the next generation of aircraft or spacecraft? Go to the farm to grow organic code (whatever that is)??

    How can you be serious and say that design does not matter. How do you propose to earn the privilege to work on a $100+ million contract? You better show the client that you indeed have a clue about how to go about designing/implementing the project. Simply telling the client that you have 50 code-monkeys won't do the trick.

    If you are talking about developing simple little projects that one spends an hour or a weekend pursuing, then fine, dispense with the design. But for any serious s/w developer or engineer, the design phase is paramount. The same applies to any engineering profession; well, with the exception of Sanitation Engineering.

    P.S. Software does not fight back, have independent thoughts, or mood swings like the enemy in a battle situation. You might as well compare apples and oranges.

  10. #10
    Join Date
    Jun 2008
    Location
    Sin City
    Beans
    588
    Distro
    Ubuntu UNR

    Re: Coding filosophy-strategy

    Quote Originally Posted by dwhitney67 View Post
    IMO, you opinion is pure rubbish.
    Likewise.

    What is a person (or group of persons) supposed to do when building s/w for the next generation of aircraft or spacecraft? Go to the farm to grow organic code (whatever that is)??
    Something tells me your hostility is born out of ignorance. And...

    How can you be serious and say that design does not matter.
    ...you have horrible comprehension skills. At what point in my message did I say that design did not matter? When in my message did I say don't design at all?

    I didn't.

    I simply stated that design is not everything and to not dwell on it. At some point you have to sit down and code. Design all you want, until you start to code your design is nonfunctional.

    If you are talking about developing simple little projects that one spends an hour or a weekend pursuing, then fine, dispense with the design. But for any serious s/w developer or engineer, the design phase is paramount.
    And yet show me one project that ever went off exactly as design.

    P.S. Software does not fight back, have independent thoughts, or mood swings like the enemy in a battle situation. You might as well compare apples and oranges.
    Tell Kasperov that... but I digress.

    You have trouble with the concept of analogies, don't you? Of course code doesn't fight back. The adage that no plan has survived combat isn't about people killing people for whatever reason. It is about the changing nature of the process and while the beginning condition (pre-battle) and end condition (victory) are known the path between those two points, the battleplan, cannot foresee all possible factors.

    My point was that during the process of coding things change. Those things might be requirements on the code to constraints from where the code will run on through to the preconceived notions of the developer(s) being destroyed by learning a new, more efficient way to do something or, alternatively (and more often) that their ideas simply are inefficient and need to be scrapped. It is this last part that is most important to the neophyte programmer since by the very nature of their ignorance most of their designs will be inefficient and, after they gained the experience, will need to be scrapped.

    Since both battle and programming involves change the analogy fits. Albeit one is most often external change while the other is most often internal. But that is why no analogy is perfect.

    If you think that the process is a constant which can be controlled by the design stage alone then I invite you to read up on why microkernels have yet to take the world by storm. The design seems elegant; a tiny kernel to control processes and process communication while all other traditional kernel-space, hardware-level processes moved up a layer. This would allow for faster development and the ability to swap in and out different implementations of the same subsystem on the fly. I won't spoil why the design is a prime example on why design only carries you so far. I'll just say that it would behoove you to go read up it before responding lest another well known adage be attached to your name, "It is better to be considered ignorant by keeping silent rather than open your mouth and prove it."
    Last edited by Greyed; September 23rd, 2008 at 10:37 AM.
    Warning: Any code examples I write are probably untested and contain bugs. Do not execute directly. Look for intent, not accuracy, please!
    L.A.G. - Jobs Dissembles - 2010/4/29

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •