Page 1 of 1

Understanding how to code

PostPosted: Mon Aug 29, 2005 6:20 am
by blkmage
So far, I've pretty much learned the basics: branching, looping, functions, and the like. I've also learned the basics in a few languages, like C, Python, and Javascript. Now the problem I'm having is moving from these basics to larger projects.

How do I make the jump from writing 'guess the number' to nontrivial stuff that I or others will actually use?

PostPosted: Mon Aug 29, 2005 6:24 am
by shooraijin
I know that I needed a "killer project" to actually develop code on that sort of scale. My rule of thumb with development is that if I think it's worth using myself, then there will probably be other people who want to use it too. I didn't want to use Apache, so I wrote my own in Perl:

http://httpi.floodgap.com/

UMN gopherd was no longer maintained and I didn't like how the configuration files were run, so I wrote my own:

gopher://gopher.floodgap.com/1/buck

At the time I wrote it, no one had written even a partial simulation of this computer (which was my first) for *any* platform. (The page is now wrong, there's a MESS driver for it and I need to update it.)

http://www.floodgap.com/retrobits/tomy/emu.html

The only thing I can suggest is to find a niche and fill it, or find some program or application that you use frequently that has things you don't like and make your own. That's what started me on these projects. Hopefully this makes a little sense.

PostPosted: Mon Aug 29, 2005 8:29 am
by Fsiphskilm
Recursi

PostPosted: Tue Aug 30, 2005 1:23 am
by LorentzForce
I believe it would be now time to think of a project that can be described in a sentence. Then break that down, and break it down until you get this massive document that outlines everything that would be required to make that project happen. Then, code away.

The tricky part is how to juggle such a huge idea in your head and still not come out confused. Keep the overall image, but only work at one thing at a time, and keep at it. One by one, like making a tall tower out of consumed Coke cans. Make sure each function is perfect in its own right, and them combine them, make new functions, and keep building.

Soon enough you'll find that even the biggest programs out there are nothing but snippets of functions everywhere all linked together, and you'll also get a nice smile on your face when that >1MB-project compiles without a hitch anywhere. And that, is where real fun in coding is :)

PostPosted: Tue Aug 30, 2005 5:57 am
by Technomancer
As tiresome as they can be, the sort of small, trivial programs are valuble in building your skills since they allow to focus pretty much exclusively on one problem. Importantly however, there is a lot more to programming than just the branching and looping; you should also concentrate on understanding data structures and algorithms.

As far as a major project, you'll have to decide what you want to do, and what you think you might want to try. You could take a look for example, at http://www.programmersheaven.com for ideas and articles. If you have school projects, you could try designing a program around one of them, or some kind of simulation program. If you're interested in graphics programming, you could also look up Denthor's tutorials on the website I just linked to.

PostPosted: Tue Aug 30, 2005 6:34 am
by shooraijin
Actually, if it helps you any, I'm suddenly finding myself writing a new archiver (rather than using tar or pax). This was born out of necessity when my system kept crashing from overly large backups that it couldn't pound through the network fast enough, and it buffered it all in memory ... until it ran out of memory vainly trying to send it. So I'm writing a network-friendly archival system for my own purposes, and I'll probably release it for others to play with. It's in Perl, my language of choice.

That's how *I*'ve gotten started on such things ... necessity. ^_^;;

PostPosted: Tue Aug 30, 2005 10:02 am
by blkmage
Any suggested reading or anything?

PostPosted: Tue Aug 30, 2005 11:17 am
by TurkishMonky
Anything that is just a huge reference of the language is what i use pretty much extensively. many times books that "teach you to do somthing" have sloppy/bad coding practices that doesn't work well in the real world. (however, if you're just starting out, some of these books can help you see how to think logically)

To get somthing you'll actually use, think about what you would use. My first often used program was a set of utilities for excel that would do specialty repeats across cells that i found myself needing constantly. Overtime, it has grown to do ighly customized excel layouts, etc. Otherprograms i've worked on were a code-hilighting editor and a (pretty basic) algebraic calculator. From there i switched to web page designing in ASP.net - first small time, then gradually improving my techniques to make better web sites.

often times, like others have said, the small things gradually lead to bigger things. (That's not to say that the small things aren't ever used. My most used program is a simple timer that keeps track of how many minutes i've been working - basicallly a stopwatch)

My tips:
- learn how to document and write code so it is neat and organized. Most huge applications are just simple processes en masse. For example, with my current web content management product i'm finishing up, 75% of the code is taking data from the sql database and puting it on the web page, or vice versa.

- read through others' code. Open source from a good programmer has taught me more than any books could ever do. Open source from a bad programmer has helped me determine what of the code is junk and what could be done to clean it up. Often i just play around and clean up the code on my machine for fun, even if i never use the program afterwards.

- Think somewhat realistically. There are big projects that are possible with my (and your) resources, and there are monsterous bears that arent (with my budget anyway.) I haven't always, and have wasted (a year and a half's) time attempting google and ebay like mega-web-innovations that eventually ended in wasted time, and about 50% done (although the experience was great for learning...)

PostPosted: Tue Aug 30, 2005 2:52 pm
by Kaligraphic
To kind of echo Shooraijin here, if you want to write a program that will be used, find something that you actually want to use. Something that would make you more productive, your life easier, or something like that.

For instance, I'm working on an invoice generation and tracking system that I hope eventually to expand to a full billing and customer management system aimed at independent contractors. (I have a pretty clear idea how it would work, but I don't have too much free time to code it.) When I've got most of the modules working, maybe I'll put in on sourceforge or something. (I've got the invoice generation working, but the rest is pretty skeletal and relies on user input for the moment.) I started this because I wanted such a system for my own use.


The key to larger projects is simplicity - if you come up with a cool way of doing things, but it's hard to read, then you will probably come back in a few months and have to figure out what you were trying to do. Write clear code and you won't need that many comments. (Writing clear C is like writing clear English - it takes practice.)

I will suggest that you not measure your progress in your own mind by lines of code - only functionality really matters in terms of progress, and it's better to think "I made this, this, and this work" rather than "I wrote x lines of code". It makes it seem like less work.

PostPosted: Tue Aug 30, 2005 6:43 pm
by Warrior4Christ
As an intermediate step, after you've done some basic programs, and before you jump into something big, search around for some 'medium-sized' programs that others have made, just to get ideas of what you could make. Just look at final product, not the source code (though it may help), for the features of the program and what it does. Then try to build your own program similar to it (maybe even in a different language), but try to improve on it, if possible. Of course, this may take some research into the methods it uses for doing things.
But when deciding on something to make, evaluate in your mind if the program is doing anything fancy that you wouldn't be able to replicate with your current knowledge and a bit of research.
This is for skill building rather than making a program to fill a need that you can't find any other program do. Although it may turn out that way.

PostPosted: Wed Aug 31, 2005 10:10 am
by Technomancer
The books that I use myself are excellent, but alas, out of print. Instead I'd recommend:

For introductory C programming:
'Applied C : An Introduction and More' by Alice Fischer et al.

For more advanced concepts:
Data Structures and Algorithm Analysis in C by M.A. Weiss.

That's if you're interested in learning C. As far as applications go, I can't really help you unless you're interested in mathematical stuff or signal processing. However, you might be interested in Sayood's book "Introduction to Data Compression", whic I used for my multimedia signal processing course. Most of the examples are in C, and are also pretty straightforward.

PostPosted: Wed Aug 31, 2005 12:30 pm
by termyt
Desire is how you make the jump from "Hello World" programs to actually useful ones.

You need an idea. What program would you like to write?

For example, I'm a fan of the game Yahtzee and was addicted to the hand-held version of the game for a while. I figured I could write a program to play Yahtzee, the rules are simple enough. That motivated me to figure out how to do it. It was a good exercise to help me learn the primary programming language I use at work - Visual Basic.