Why am I an idiot?

You appear to be right. I remembered Poltergeist a bit differently.

I’ve seen cases where programmer’s lack of skill is the reason for the program not being finished. But in K.I.L.E.R’s case it appears that he has lots of skill in programming, but not in controlling himself to produce only the most simple solution.

Maybe one way to solve this would be to plan a list of all the features, which you would like the program to have, and prioritize them. First produce only a minimal set of features which are absolute required for completing the task. Then if you have time (after testing, writing good documentation and cleaning the code), add other features one at time.

While your statement may be true for many university courses, it’s not true for all. Teaching software engineering is hard, and there are many professors who do a poor job of it. Hooray for tenure. However, there is a lot of interesting research on how to teach good software engineering practices within the traditional university system of courses and semesters; check out some of the papers in SIGCSE and CCSC conferences for examples.

Clearly, the education problem is not" solved," nor are the best practices widely adopted. I would like to know what specifically is it that you see as the problem, and what kinds of solutions do you propose. I’m always up for new ideas.

As for K.I.L.E.R’s case, I sand by my earlier assertion: either your professor is a good one whose guidance you have not adequately sought, or your professor is a bad one whose advice should be ignored. In the former case, use office hours, email, and regular appointments, and avail yourself of time management tools and strategies such as milestones; in the latter case, find a new professor or mentor.

Simple solution:

Make a TODO list for all the requirements. Keep that list in your sight. Mark each item when it’s completed.

The problem is evaluation. When someone delivers a project and passes with a minimum grade without any documentation, it’s an incentive not to do it in the first place. Clearly a student working alone or in a small team of 2 or 3 doesn’t need waste time creating good docs if the work is just to be delivered once and then forget about it. That’s why good doc pratices should be enforced even when it is not necessary to make students pratice.

You may be interested in this, documentation is where half the marks fell into on my assignment.

Thats good for you if they enforce good documentation pratices on the place where you are learning. I’m almost finishing univ (just 4 to go, one will have to made next year). Now that i’m working on my own game engine in java I noticed how much of what i have learned from univ is basic to worthless. I’m mostly relearning everything myself and learning other things they don’t teach in there or just teach so lightly it’s a waste of time. One thing we can get from univ for a computer science course is bibliography, references, people with similar interests and free software, but otherwise, at least in the majority of the universities in here, we don’t know enough to be a real engineer and know how to work like an engineer.

You might be surprised how many “real engineers” don’t work like engineers :slight_smile:

Kev

EDIT: Damn you bleb and your typo greatness! :slight_smile:

He’s right, they usually just crack into the beers and get the women to do the work. ;D

Where’s the suprise? Just look at the most used operating system for home computers. Someone must have done the mess we are in now.

A lot of the stuff that I did at university seemed stupid at the time and I forgot about for years, but I have recently started to see the utility in it and realise that actually I was kind of being arrogant in discounting it at the time.

That doesn’t go for formal methods for system specification though. I still maintain that class was a waste of everyone’s time.

I don’t say that what i learned in my univ. was stupid. It’s just that teaching is too relaxed and we are paying the consequences. People need someone to tell them how to do things right and follow a program schedulle. No wonder that project management is the biggest weak point. We mostly do toy programs and never get a chance to work in a complex applications that spans over more than one year so we never learn how to manage a project properly. I find all my disciplines related to this area have little to nothing to do with engineering as it is claimed and teachers often teach about those methods without any convinction about what they are teaching. What i’m learning on this subject mostly comes from internet projects i participate on my own free will.

I’ve been browsing the game ideas section and looking at a few 4K competition entries (My favourite being Dungeon4K) and it occurred to me recently that expectations of how to solve a problem are “do the simplest method available”.

As I’ve said previously, all the solutions I create tend to be fancy.
One thing that got me was Matzon’s advice to a newbie posting in the Game Design forum about creating a maze.

Matzon’s advice to the newbie struck me as normal but I’ve actually been wandering if such simplicity is good? So I tried to make a maze game.
My previous maze games in the past when I was a noobie have all been using arrays.

While it is easy to knock up a quad tree, I’ve actually spent 2 days devising a method recently of avoiding all boolean checks and branches when adding a volume into a quad tree.
I ended up doing a calculation of step functions and dot products, for what it’s worth and ended up being trashed as someone on a specific forum I frequent ended up asking me “What does it do?” and I just responded by saying that it’s the world’s fastest quad tree(simply because it reduces conditional checks to 2, both are calculated from a numerical function anyhow and memory is accessed by the results), again I haven’t actually tested it however after all the work it ended up being quite simple.

Anyway it’s amazing how a very simple problem that can be accomplished within a few lines of code ended up turning into a research project. ::slight_smile:

NOTE: By saying “I haven’t tested it.” I mean that I haven’t benchmarked it.
If anyone’s interested in the code I can knock it up quite quickly.

I saw this and thought of this thread…

I used to have the same problem as you, a simple crappy larva of what one day would be a game would have lots and lots of classes.

I think working on engines and games, unlike other applications, is a constant exercise of exploratory coding. So I follow a simple rule, I write only what I need when I need. I don’t waste too much time abstracting anything, thinking of “future needs” and APIs and all that, I just put in the code what’s necessary to perform “A, B and C” nothing more.

Then with time and when I figure out what I want next I just refactor it.

The size of the OpenGL stuff I play with has been reduced greatly, both in number of classes and LOC.

And that’s why SPGL is such a total mess :smiley: Works though dunnit?

Cas :slight_smile:

In my opinion, documentation and design is key to a good program. Requirements engineering is absolutely important, and in extend to that, working bottom-up and thus starting with the most simple things will prevent you from exponentially adding all kinds of extra’s. Finish one thing first, make it work, put comments to it, and then add the next feature on the list. Working like this keeps you sane, its very efficient and if you’re working in a team you don’t get frustrated. If you find yourself doing trial-and-error stuff, back away, and re-evaluate your initial design first. Ofcourse it requires a bit of patience, but i think it really pays off.