Concepts, techniques, paradigms that really helped you

[Cogman]

I thought it would be fun if we could have just a fairly open thread where we list the "things" in programming that have helped us become better programmers, even just the little things.

For example. Learning the object oriented paradigm really changed the way I think about programming, it has made programming loads easier and really shifted the way I do things. Rather then saying "do this, then this, then this, ect...." you say "Ok we have a thing, what can a thing do, how does it work with other things, ect". It is much easier to think of and far easier to encapsulate.

As a small improvement, I would say that learning the difference in the speed of different containers vs a straight array have really changed when I think of working with groups of objects and when to use either.

A technique that I really enjoy is the radix sort. This puppy is so powerful and great for a small to medium list of integers. It makes quicksort look slow

 

[Crusty]

Data structures! Knowing how they work, how to implement them, and knowing all the advantages and disadvantages of different structures in terms of memory and speed is definitely what has changed my programming the most.

 

[tfinch2]

bitwise operators

 

[xtknight]

Know how to split your main subroutine in mini-subroutines and mini-functions as useful and needed. Learn how to design your program in an object-oriented manner, so it will be easier to reuse some pieces in other applications if you need to. Never make things more complicated than you need to, for no reason. Don't try to anticipate the future all the time. It just makes you lose sight of your current goal, and sometimes it's best to reimplement things anyway.

I usually end up making a "rough draft" of a program that's made a little sloppily and is more of a proof-of-concept. Making that takes longer than you think. But not until you have the proof-of-concept can you design your classes and types properly to work for you. So you don't want to start designing from the ground up. Have some good, solid, sharp code to start from before you start putting in the packing peanuts and bubble wrap. Prototype things before you put them in your main application. For instance, test a new class in isolation by making a new project for it, and use that project as a test bed for the class. Make sure the classes in your program work well before utilizing them all over your code. If you feel queasy about something you just implemented, put breakpoints in (even if the first run works fine) to ensure all your variables are what you expect them to be.

Use the facilities available to you. Usually they are more well-tested and faster. Never implement things yourself unless you absolutely need to. This adds complexity to your project and makes debugging difficult. Break your project up into big, manageable pieces only.

 

[Capitalizt]

up up down down left right left right b a start

 

[Cogman]

Originally posted by: Capitalizt
up up down down left right left right b a start

I was always a fan of down left right prim. fire

 

[IHateMyJob2004]

1) singleton
2) data encapsulation

 

[Rainsford]

Modularization, without a doubt. Code that "does it all" is incredibly difficult to debug because it's hard to check the functionality of any one piece. Not only that, but being able to re-use code is something that, while glossed over in college computer science programs, becomes a BIG help in the real world.

The second most important thing has got to be the idea of understanding the platform your software is running on. Computer science generally teaches you that the computer is a generic interpreter for whatever code you're writing, and that the functionality of the code is more important than how it works at the low level on any particular platform. This gives us things like bcopy routines that read a single byte at a time instead of taking advantage of "load word" instructions available on most architectures and other things like that. Computer science professors would like to pretend that the machine is an abstraction layer, but you don't get the best performance results that way...performance matters!

 

[reverend boltron]

For me when I started drawing things out that really helped my programming.

For instance... drawing out a small binary tree

Or drawing out memory and addresses to understand pointers.. I picture pointers as mailboxes.


------- ----------
| 6000 | CAT |
------- ----------
------- ----------
| 6128 | Dog |
------- ----------
------- ----------
| 6256 | Rat |
------- ----------

Where the numbers are the memory addresses, and the words are the data that are held there.

That might be really basic to everyone else, but when I started to see things like that, it REALLY helped me out a lot.

That and, again, drawing everything out... As in, drawing out my data structures and my program flow, and my MySQL Schemas, and all that fun stuff.

Once I got into the habit I bought a few whiteboards on sale and I used them all the time.

 

[Train]

Originally posted by: Crusty
Data structures! Knowing how they work, how to implement them, and knowing all the advantages and disadvantages of different structures in terms of memory and speed is definitely what has changed my programming the most.

this.

When I think of core knowledge, data structures are key. Knowing all of them (linked lists, arrays, various tree types) and the various base algorithms that go with them (binary sory, bubble sort, etc) can carry over even into high level languages that handle all of that for you.

Even though I program in managed languages almost exclusively nowadays, I wouldnt have the expertise i have now without having learned things in a non managed language such as C++ first. Knowing exactly what the garbage collector is doing and when, and knowing about the memory allocation of your objects, is crucial. Just because the compiler/gc handles a lot of this for you in the newer high level languages, doesnt mean you shouldnt really know whats going on behind the scenes.