What I mean, it's not really something like "How to write Hello World." or "How do you create a program."
Suppose you have an empty project, based on the language you prefer. (Like, C++, C#, Java, etc.) And you were given a task to create a program that matches your task's needs under a deadline.
When you start making programs, how do experts start off? Do they first find a scratch paper, and a pencil, and start designing how their program logic is going to be? Do they start off small and simple, from creating short simple functions and going up like using small LEGO bricks and build upwards?
And, when they are programming, what do they think about while doing these sorts of things in their heads? Do they have to think of algorithms, or math algebra, or equations straight off of their heads? Or do they think about what they should consider using on that scratch paper they have on their desk?
Hopefully, I can actually get used to this sort of feeling.
When you start programming, how do you start off?
I'm no expert, but i begin to brainstorm, make some sketches, make some notes.
Then I usually start to code the display code with place holder graphics, then basic placeholder input handling. I do this to ease debugging, and this way I don't need to hard code too much stuff. But It really depends on the task.
That's pretty much it.
Then I usually start to code the display code with place holder graphics, then basic placeholder input handling. I do this to ease debugging, and this way I don't need to hard code too much stuff. But It really depends on the task.
That's pretty much it.
Whenever I am set a task I always first write down exactly what needs to be done in clear bullet points. Next I work on sketching out a simple class diagram with interactions. I might go through a few iterations of this until I find the simplest set of interactions that will get the job done.
After that I like to write out a set of milestone lists, if it's a big project then I might only write out the first couple of milestone lists and usually aim for each list to last a week. This of course depends on the size of the project, it's perfectly okay to write out a milestone list for each day on smaller projects. Don't assume that you need to have all the milestone lists finished either, I like to have the one I'm currently working on, and the next one pretty solidly laid out before I start coding.
Once that's done I just set up the appropriate project and start off with the basic framework, once that's done it's just a matter of adding pieces of functionality in. It's hard to describe the methods used generically as they will change from person to person and project to project, a lot of times you have a library to work from or someone else's work to use as a starting point.
After that I like to write out a set of milestone lists, if it's a big project then I might only write out the first couple of milestone lists and usually aim for each list to last a week. This of course depends on the size of the project, it's perfectly okay to write out a milestone list for each day on smaller projects. Don't assume that you need to have all the milestone lists finished either, I like to have the one I'm currently working on, and the next one pretty solidly laid out before I start coding.
Once that's done I just set up the appropriate project and start off with the basic framework, once that's done it's just a matter of adding pieces of functionality in. It's hard to describe the methods used generically as they will change from person to person and project to project, a lot of times you have a library to work from or someone else's work to use as a starting point.
It depends on the programmer, the technology, and the size and complexity of the project.
I've rarely had to start a project from scratch. More often than not, I have some code I can reuse to prototype what I want to do. The more code I write, the more likely I am to have a base I can start from in a given language. For games, I just try to get a gameplay prototype done first (doesn't always work out).
I never try to put a complex design on paper, my experience with this is that it is easier to refactor the code into a good design than to think of all the concerns up front.
I've rarely had to start a project from scratch. More often than not, I have some code I can reuse to prototype what I want to do. The more code I write, the more likely I am to have a base I can start from in a given language. For games, I just try to get a gameplay prototype done first (doesn't always work out).
I never try to put a complex design on paper, my experience with this is that it is easier to refactor the code into a good design than to think of all the concerns up front.
If the requirements are well defined, I usually start by defining data structures (on paper or in my head). Then some user interface (in the case of applications) to interact with them.
In the case of games, I've come to the conclusion that the major reason I never finished one (not counting tetris/breakout/etc clones) is because of lack of proper (complete) design. I always tend to do it backwards, first the programming and then the game. Which I realize now it's a mistake.
In the case of games, I've come to the conclusion that the major reason I never finished one (not counting tetris/breakout/etc clones) is because of lack of proper (complete) design. I always tend to do it backwards, first the programming and then the game. Which I realize now it's a mistake.
Quote:When you start making programs, how do experts start off?
Instead of directly answering this question, let me quote Niels Bohr:
Quote:Original post by Niels Bohr
An expert is a man who has made all the mistakes which can be made, in a narrow field.
As mentioned, it depends on the programmer (personality/traits and experience), the project, the team... many things.
Generally, I start by getting the task. Especially if it's someone else giving the task it's important that I understand what needs to be done, by when, with what resources/constraints/etc. This often means asking questions, sometimes about requirements, sometimes about what shortcuts I'm able to take (since I personally tend to do as little as possible that satisfies the criteria).
Then comes design. Often in a group if a team is involved, often with a whiteboard if a team is involved. Often very high level, and then iterate through for the logical chunks as needed. Usually each chunk goes over a few days while I try to piece things together/model them in my head. Complex/detailed things can sometimes go to paper/whiteboard, but the key bit here is to make sure I have a good mental/visual model of how the thing is constructed (because that's how I work, ymmv).
Depending on the project, I might start actually coding by setting up a project skeleton, sometimes with prototyping, sometimes with infrastructure (logging/messaging), sometimes with a small bit of code that can work and then be expanded upon. Different things lend themselves to different approaches.
I rarely think very detailed about logic/flow/interactions anymore when writing code. The big picture is more important, and I've written the basic patterns for things so often that they just roll off the fingers.
Generally, I start by getting the task. Especially if it's someone else giving the task it's important that I understand what needs to be done, by when, with what resources/constraints/etc. This often means asking questions, sometimes about requirements, sometimes about what shortcuts I'm able to take (since I personally tend to do as little as possible that satisfies the criteria).
Then comes design. Often in a group if a team is involved, often with a whiteboard if a team is involved. Often very high level, and then iterate through for the logical chunks as needed. Usually each chunk goes over a few days while I try to piece things together/model them in my head. Complex/detailed things can sometimes go to paper/whiteboard, but the key bit here is to make sure I have a good mental/visual model of how the thing is constructed (because that's how I work, ymmv).
Depending on the project, I might start actually coding by setting up a project skeleton, sometimes with prototyping, sometimes with infrastructure (logging/messaging), sometimes with a small bit of code that can work and then be expanded upon. Different things lend themselves to different approaches.
I rarely think very detailed about logic/flow/interactions anymore when writing code. The big picture is more important, and I've written the basic patterns for things so often that they just roll off the fingers.
Author
Interesting experiences from everyone. :D
After I posted, I decided to try out how to really get started. I thought up about a simple program that calculates fractions, without mixed numbers and without reciprocals.
After I typed in the basic int main() function, that's when I started to feel so "concerned" about how to display the results, how to calculate, whether to consider parentheses and the order of priorities of the symbols, and such...
I felt like what I'm starting off isn't really a good sign of what I should be doing. And I ended up wasting some free time along the way.
There is a scratch paper on my desk, and I discovered that about 80% of the paper area is covered in pencil sketches and notes. And I found out none of them works, or it's almost impossible to implement it into code. The reason is that I have been declaring a lot of integer and boolean variables.
Now that I have some info on other people's experiences, I wondered if I can take a few as references and while hoping I can learn something from these, am I doing wrong? I'm no expert, so I still have a lot of mistakes to tackle. And I'm willing to tackle them by myself.
After I posted, I decided to try out how to really get started. I thought up about a simple program that calculates fractions, without mixed numbers and without reciprocals.
After I typed in the basic int main() function, that's when I started to feel so "concerned" about how to display the results, how to calculate, whether to consider parentheses and the order of priorities of the symbols, and such...
I felt like what I'm starting off isn't really a good sign of what I should be doing. And I ended up wasting some free time along the way.
There is a scratch paper on my desk, and I discovered that about 80% of the paper area is covered in pencil sketches and notes. And I found out none of them works, or it's almost impossible to implement it into code. The reason is that I have been declaring a lot of integer and boolean variables.
Now that I have some info on other people's experiences, I wondered if I can take a few as references and while hoping I can learn something from these, am I doing wrong? I'm no expert, so I still have a lot of mistakes to tackle. And I'm willing to tackle them by myself.
Perhaps give an example task, and see how people would go about solving? It might get you some more specific suggestions, as I think "task" is too vague. It depends a lot what you are doing.
Completely depends. Most things these days I've already solved generally before so it's a matter of more or less regurgitating the designs that I already know work. If it's a new task then sometimes I'll just know how to do it since it's somewhat similar to other tasks I've done before. Otherwise if it's a new task to me, it's really unlikely that it's a new task to the world so I'll spend a few days or a week researching standard solutions. Occasionally it'll be something relatively novel (some weird design-specific AI implementation or something) and I'll want to play around with on the whiteboard for a couple weeks before honing in on a software design that works. If it involves an unfamilliar API/SDK then I'll obviously spend a couple days just reading through the documentation.
-me
-me
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
