Sign in to follow this  
tom_mai78101

When you start programming, how do you start off?

Recommended Posts

tom_mai78101    693
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.

Share this post


Link to post
Share on other sites
szecs    2990
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.

Share this post


Link to post
Share on other sites
Darg    213
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.

Share this post


Link to post
Share on other sites
rip-off    10976
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.

Share this post


Link to post
Share on other sites
owl    376
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.

Share this post


Link to post
Share on other sites
demonkoryu    980
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.

Share this post


Link to post
Share on other sites
Telastyn    3777
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.

Share this post


Link to post
Share on other sites
tom_mai78101    693
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.

Share this post


Link to post
Share on other sites
CzarKirk    100
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.

Share this post


Link to post
Share on other sites
Palidine    1315
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

Share this post


Link to post
Share on other sites
cmv    180
I use paper. A lot of paper. And when I'm done with drawing everything from UML-ish diagrams, bullet points and doodles of tiny people doing acrobatics, I start creating all the class definitions. I don't actually implement anything at that point, I only write the function signatures. It's very much an iterative process for me. When I have defined all the interfaces, I start filling in some blanks here and there, while sketching out more stuff on paper and changing things until I feel comfortable that everything will interact as intended.

I guess it's worth noting that if I'm using some kind of scripting language for my data and parts of the implementation, I tend to define this before implementing stuff as well. That is, I write several scripts so I get a clear idea about what kind of functionality I need to support in order to get these scripts to work. My number one priority when creating systems utilizing scripts is to create a simple and robust interface/api for whoever is making the content.

When it comes to the implementation process, I'm totally all over the place. My goal is to get fast results, which means jumping around a lot, and writing several half-implemented functions. Basically writing "just enough" code to get something working.

Once everything stabilizes, I start to refactor and tidy things up so it's easier to maintain/extend. From there on out, it's all smooth sailing.

I *always* think of whatever I'm working on as a series of interfaces communicating with each other. I seldom worry about implementation details (algorithms and so on), I cross that bridge when I come to it. And with enough experience, you can almost instantly recognize what sort of interface you need for whatever purpose you have, so the implementation details become much less important.

Share this post


Link to post
Share on other sites
theOcelot    498
Quote:
Original post by tom_mai78101
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...


That made me think of this: Functional specifications. You need to know what your program is actually going to do in some detail.

This is a discipline I'm still working on. I don't know how thoroughly things need to be specced out in practice, but you can't just say, "I'm going to write a calculator" and sit down and write main.

Share this post


Link to post
Share on other sites
enunes    123
Usually when I come with the idea, I will keep brainstorming (while unconsciously walking in circles if at home).

When it comes the time for the code, I usually have some older project or template to start from. From there it is to develop a lazy prototype to get some first results and then reorganize that code so that it can be extended into the full thing.

Share this post


Link to post
Share on other sites
CzarKirk    100
"UML is great if you don't want to do any work; you just draw pictures of what it would look like if work was actually done."

Haha! That made me laugh. And true. I never draw any diagrams. Sometimes I jot down pseudocode but usually I just write code. "Rough notes"-style program code can at least be compiled or made into something useful. Things on paper will just get discarded.

Share this post


Link to post
Share on other sites
jwezorek    2663
If it's a GUI application I try to get at least a sketch of the user interface up and running first and build on that. Generally proceed by breaking the app down into digestable tasks and implementing the tasks in order of difficulty starting with the task that is the hardest and/or most likely to fail. I like to have pretty much the whole application in place from the beginning using stubs for unimplemented high-level functionality so that the application runs at all times during development even if it doesn't do much.

Share this post


Link to post
Share on other sites
alvaro    21246
In my job I rarely get a full specification of a project. We only write software for internal consumption and I know our business well enough that I am as qualified as anyone else to decide what the exact requirements should be. Sometimes I just get a two-minute description of what needs to be done from my boss, and sometimes I come up with the project on my own.

When it comes to design, I also have almost always done something similar before. Explaining the design to a coworker on a whiteboard is a great way to find out if there are some important things I haven't thought about. Some projects have some key component that I might be less certain of how to implement: I start with that first. I dream up a few possible ways to tackle the difficult bit (this is another place where coworker input is great), then I play around with a compiler for a few hours. I can usually get some working prototype in a few hours. At this stage I usually get a good idea of whether the solution to the difficult bit will work or if I need to do it in some other way.

Once I am convinced that I have a good handle on the part that was initially uncertain about, the rest of the pieces usually just fall into place and there is a natural way for me to proceed.

An important feature of how I write code is that I try to implement the program in little chunks so I can compile and test my program often. For instance, if I am going to have to implement a calculator, I might start writing a Rational class and a main() that contains a few test cases to make sure the functions I am implementing give the expected results. If I then need to parse some expressions, I will write down the grammar on a piece of paper and then implement a parser bit by bit, testing every piece (make sure I can parse integers, then terms, then simple expressions without parentheses, then expressions with parentheses, then unary operators...). If the program will read some input, I usually implement that last, and in the meantime I have hard-coded data in main(), so it's easier to test. I strongly recommend following this way of programming. Or at least try it to see if it works for you.

Share this post


Link to post
Share on other sites
Starts and ends in perfect symmetry with a nice cigarette.

But aside from that there is no set thing except very often starts with some meeting or phone call.

Lots of tiny projects plus a few huge ones and they are all a bit different I suppose, and trying to worry about "process" too much is seldom all that profitable in the sense of getting stuff done. Just find what needs to be done, and do it, thinking about the parts you do not know before you get to them.

Share this post


Link to post
Share on other sites
Pomnico    110
Regarding GUI I always try to design basic layout and describe basics of functionality. Next I implement basic mechanics using placehodler arts and dummy functions. When I have that done, I add one functionality after the other one in the meantime (when I'm tired with programming) replacing placeholder with valid GFX. The last thing is retouching (resizing, changing font, etc.) so everything seems nice for me (so each layout parameter is not hard coded directly in many places in code, but defined by preprocessor definition).

When it comes to more complex projects I like to at least think about parts of code needed to obtain my goal. Next I start implementing those small tasks. Based on that I implement larger tasks using those small parts already implemented and so on (this could be called bottom-to-top approach). When I have basic framework of the application I add additional functionalities in a similar manner as described with GUI application, but reusing those parts of code that has already be implemented.

I also often separate some bigger problems to distinct tasks (for my own purposes) and create small applications to solve this particular problem only, implementing core of the solution as a separate class(es). This often gives me better testing possibilities etc. After such problem is solved, I incorporate those classes to my main application.

Share this post


Link to post
Share on other sites
Oxidda    103
1) Define requirements
2) Think of a technical solution (Can we use certain FX, can we use certain patterns etc.)
3) Identify possible problems and tackle those first
4) If it becomes a mess, delete the code and start over

Quote:
Original post by Decrius
I always Code Like Hell. Don't try this at home.


It might work for smaller applications, but if your building an application on the enterprise level which has to have a lifetime of at least 10years, then I wouldn't use this so fast.

Share this post


Link to post
Share on other sites
Decrius    100
Quote:
Original post by Oxidda
Quote:
Original post by Decrius
I always Code Like Hell. Don't try this at home.


It might work for smaller applications, but if your building an application on the enterprise level which has to have a lifetime of at least 10years, then I wouldn't use this so fast.


I know :). I've restarted my GUI project for like 4 times, and refactored thoroughly for 4 times as well. For 2 years I have the same feature set, the underlying structure is just getting better and better. But that is also part of the learning process. For any next project I'd be much better in analysing the complexity upfront, making better design decisions thereof...

Usually, I do code linearly. So for this parser I build, I first make a class to abstract the file IO, with caching etc. Next build a tokenizer, then build a semantics analyser...and as I go I optimize the previous steps, abstract them or shuffle the duties etc. Whatever needs to be done for my ultimate design (in other words, the project is never finished).

Share this post


Link to post
Share on other sites
demonkoryu    980
Quote:
Original post by CzarKirk
"UML is great if you don't want to do any work; you just draw pictures of what it would look like if work was actually done."


UML is a notation and as such only a tool, not more.

UML is not a religion, and nobody (well, maybe except your employer) forces you to produce copious amounts of diagrams instead of doing actual work.

Whenever I need to visualize structure and process, I turn to UML because as a well-known notation most people can read it easily.

Quote:
Original post by thatguyfromthething
Starts and ends in perfect symmetry with a nice cigarette.


This. [grin]

Share this post


Link to post
Share on other sites
theOcelot    498
Quote:
Original post by Decrius
I always Code Like Hell. Don't try this at home.

Quote:
Original quote from the article you linked.
I am not proposing a code-like-hell methodology.

Umm... I guess you're aware that you're violating the advice of that article?

Share this post


Link to post
Share on other sites
Marz87    122
Depending on the complexity of the project I'm undertaking, I usually do some research first. Find some tutorials, bookmark the ones that seem good so I can come back to them.

Once I have some idea of how to tackle the problem, I'd write out some pseudo code and get to it. Thinking about design is great, but in my opinion it's better to get through a quick iteration of the project so that you actually know what kind of problems you'll encounter (as opposed to relying on pure speculation when you concoct those UML class diagrams...)

Share this post


Link to post
Share on other sites
Decrius    100
Quote:
Original post by theOcelot
Quote:
Original post by Decrius
I always Code Like Hell. Don't try this at home.

Quote:
Original quote from the article you linked.
I am not proposing a code-like-hell methodology.

Umm... I guess you're aware that you're violating the advice of that article?


Yes, that's why I say "Don't try this at home", since it's a horrible way of coding. But once you started so, there's no stopping!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this