Programming tactics

Well The idea of this topic is to get a wide spread on how people think abstractly on there thinking process when it comes to programming. This gave me the idea when i watch the movie the Social network. How they sit down on a computer and say they are "wired in." That was there tactic. In my opinion it was a very inspiring movie and maybe i will get there. Well lets not get carried away now. Now getting back to the main topic.

When i start to approach a topic to start programming:

1. I sit down and write down on a piece of paper what my objective is and what i want it to do.
2. I think of different methods on how i should program it because there is no one way to programming.
3. I sit down for quite some time trying to code this ting.
4. Take breaks because my brain gets fried.
5. Get back on to it.

Now my tactics are not all sufficient to everyone else. Some people say how i plan or decide to do something can be more difficult than others. Now this topic can go very broad on how in-debt you want to explain your tactics. Just want to get a general idea how how people go about there programming tactics.

1. Get the idea for the program/game to create.
2. Start drawing up some diagrams and thinking of the classes I want to use, as well as the design patterns to implement.
3. Write some code
4. Evaluate code and redesign as needed
5. Carry on
6. Back to 3 until finished writing code
7. Optimize code.

That's about it for me!

approach from the back, use blunt object.

The systems/software engineering way for a complex application would be to do the following:

1. Draw a tree diagram of the system and subsystems (What the program performs overall and what its individual processes/algorithms are) This is known as the top-level design.

2. Split those sub systems in to what a system engineer would call a set of modules and components.

I suppose if you were thinking along the lines of any C type language, the "modules" are close to writing all the function prototypes or class prototype (C++) The "components" are really the individual function definitions (IE the code to carry it out) Obviusly, think about any inputs and outputs and what those are likely to be and note them down on the block diagrams or along side.

4. Then to implement it, you simply work from the bottom level upward. Since you've drawn out the diagrams you can verify each individual module/subsystem at various stages.

This method exploits the use of abstraction at various levels which makes it easier to understand the program flow overall right down to the code that carries it out. This method can be overkill for a trivial program, and is really only useful when you have a large application and a team of developers/engingeers.

===

However, I've never really had to write something that has required the previous method - if it were a professional piece of code I would use it since you can sit that right next to the client specification.

The way I go about proogramming is to:

1. Let the idea(s) develop in my head and think through all the stages it must complete, note them down in a text document. Usually interaction between functions, whether a class or set of structures are best. At that point I will often decide which language is appropriate for the task - depending on factors such as speed of execution, ease of programming and whether I am doing it as a learning exercise in that language.

2. Then I will think out the code in that language - Will it need any 3rd party libraries? (or write from stract) What WinAPI functions will help with (blah)?.

3. Then I open a text editor stick down all the ideas, maybe type out a basic program flow or just layout the program in the target language so that there is a framework.

4. Write the code. If things are not working out or I come accross a logistical problem I will often make a second copy and experiment with another method. Sometimes, I will see if another language maybe beneficial for simplicity of implementation (as a model) then return to the language I wish to write it in.

5. If there is any strictly unnecessary code/variables I will then remove them (usually where I've stuck it in for debugging purposes). Simplify any code that is wasteful - for example, where I may have used multiple loops just for clarity of implementations' sake where one could be used…

Jim,

1. come up with the idea.
2. start writing code.
3. fix any problems/issues that arise, when they arise.
4. step 2 and 3 till complete.

I hardly ever write down anything. No trees, no bullet-points, not even ideas. I just start writing the code until I am happy with what I have.

1. Brainstorm
2. Refine
3. Prototype
4. Solution
5. Support

Brainstorming ideas comes in many different forms. From writing down every idea that pops into my head, to talking with friends, and epiphany's in the bathtub.

Once I have an idea I refine it by writing up requirements documents, making charts, graphs, and thinking out the finer details of the application.

Now that my idea is refined and I think I have most of the details worked out I will prototype my application. Often using a scripting language like Python I can create a full mock up of what my app will do. Sometimes however I only create and test certain features of my application to get the idea of how to implement them. During and after this phase I may go back and refine my ideas some more depending on the results of my testing.

When I am confident that I can implement features of my application and my idea has been well thought out I will begin a more stable development of my application. Often using a more production quality language, and organizing my source code into a project is enough. I may also create a repository online for team development.

After an application is released and considered stable development may continue , users may require help using the app, and developers may need documentation for your code. It is up to you what, if any services you provide for supporting your software. I at least make my email available for users or developers to contact me. I make my best effort to get back to anyone who mails me.

1. Think about it
2. Do it

Repeat as necessary.

Optional steps inserted wherever you wish is: not sitting around doodling unstructured random ideas like a fucking third grade kid trying to write a story for class. Personally I very much enjoy this step since if I am to program something, I first, you know, know what the program is meant to do…

Meh, it depends on the complexity, but generally it's something like this:

1. Pick a method
2. Layout the basic code
3. Code
4. Test/Fix errors
5. Repeat 3/4

I sort of "wire in", depending on the time of day. If it's late, I typically just throw some headphones on and code like hell. During the day I take breaks for stuff like checking the news or playing some games.

1. get cheeto's
2. wash hands
3. brain storm
4. get my beer cooler
5. code
6. code
7. repeat steps 5-6 till done
8. optimise and rewrite faults
9. plant Easter eggs
10. gloat over final copy

1. Just start coding/copying the Utils class and the main class, form or menu which I always have.
2. If all is easy and well continue coding. If not then take a piece of paper and draw the problem (usually path-finding and such or matrices ARGH)
3. Continue programming.
4. Drink enough water (If not I'll regret it at the end of the day)
5. repeat step 3 and 4 unless: >> I go ZzzzZzz and brainstorm about any possible solutions for the unsolved problems. >> I remember that even a programmer requires food. >> I want to smash the PC trough the wall (idclip?) because the code just doesn't work. Usually taking a short break helps and then I just see the mistake after 30 seconds.
6. (may be weeks or months later) Re-factor the code and being silently embarrassed about how many optimizations can be applied.

Or in a more professional manner: 1: Proof of Concept 2: Implement the skeletal structure (menu's or classes depending on the type of project). 3: Create the library with lots of debug code and unit testing 4: Create the actual project's main code 5: Test 6: Test more 7: Test even more 8: Add error handling and logs and the credits section and so on. 9: beta 10: RC1 11: Making sure to skip writing any documentation or convincing the project manager that there is no need for any documentation because the code is so 'clearly written' and the 'GUI is so user friendly' :happy:. I HATE that. No documentation also makes me more valuable :D

As autistic as I am, I spend 95% of my time designing an architecture, without breaks, unless its a gigantic project which takes multiple days, weeks, months.

After that, I just write all of it out.

– I draw the architecture/design pattern out on papers, so my desktop looks like this.

Not even going to mention my room.