TIGSource Forums

Please?

http://www.typingstudy.com/ (http://Touch Typing (CLICK-ME!))

Is typing speed your bottleneck? The slow part for me is figuring out how to design my systems so that they fit together best. All you can really do to speed that up is try to stay sharp on design patterns and know what to use where. If the problem is actually typing too slowly rather than thinking too slowly (which would surprise me), getting to know the features and shortcuts of your text editor can help quite a bit. I have several macros and keybinds set up to paste in common boilerplate, quickly compare files, search and replace, and other things.

Um... thanks for the link,
but typing is not a bottleneck in the least.
and if it was:
https://en.wikipedia.org/wiki/The_Typing_of_the_Dead (https://en.wikipedia.org/wiki/The_Typing_of_the_Dead)

Yep, I was wondering what were a few
tricks in designing the code itself
faster.

Are you diagramming your classes and how they relate to each other?  A visual representation can be a useful was to maintain architectural context on an increasingly large project.  I use graphvis to make diagrams from data that I can generate with a simple script.  That's assuming that I've waited until the code has already been written before diagramming (which happens too often).  If I diagram first (which I should do), then it's easy to generate the graph data by hand.

Ah, cool. This sort of thing mostly comes with experience and practice... Code frequently, read books (this one (http://www.catb.org/esr/writings/taoup/) is one of my personal favorites), try new programming languages and different ways of doing things. I haven't used it myself, but one of my friends once recommended Code Kata (http://codekata.pragprog.com/); maybe it'd work for you?

@ failrate: I've heard diagramming helps,
I haven't tried it much, though.
Looks worth checking out.

@ ThemsAllTook: CodeKata...
The Suzuki Method for programming?
I will look into this.

This is hard to answer as it usually is dependent on a persons coding style greatly as well. (How much architecture/detailed planning there is, vs just slamming down code and refactoring it, etc) Obviously hardware can help if you spend a lot of time compiling and in a debugger. (RAM and SSDs are so nice for this)

Is the design part your slow down or execution? Like for instance I find I tend to burn a ton of time when doing GUI work, often which just ends up being tweaking values, and graphics. Which usually means a tweak, compile, deploy, test, repeat cycle. If I instead set things up where I could just hot reload the new artwork and tweak variables on the fly all without a restart or re-compile I'd save tons of time.

Debug tends to be another huge time sink for a lot of coders, developing advanced debug skills, and using smart systems like custom asserts, better memory allocators/trackers, and so forth can all help this greatly. (Although all of this depends on language to.)

Even things like enforced coding styles/standards can help speed up coding, as your more familiar with code when going back and reading it thanks to the coding style enforcements.

I had the same problem with GUI's before, and your
absolutely right. Anything regarding fine tuning
is a lot easier and faster to fix if it can be
edited in game.
(I feel like setting my computer wall paper as a
list of stuff to remember like that. )

I will look into advanced debugging methods as well.

Well, more experience is always the best solution, but that doesn't really help you right now, so...

When I'm writing something that involves more than one or two simple classes, I usually start with my sketchbook, away from the computer, and talk myself through the problem. I find I code waaaay faster when I have an extremely clear definition of the problem and the goal. When I just kinda-sorta know what I'm trying to achieve, and "figure it out as I go along", it often takes me 3-4x as long to do.

In the sketchbook I just make notes and scribbles. Sometimes it looks like one of those mind maps, other times it's just a bullet list of properties and methods. The first pass is usually a mess as I get everything out of my head in whatever random order, and then I go back over it and try to group related things together and clean it up a bit (on a new page). By the end of this process I usually have a pretty strong idea of the solution, and when I start thinking "Why the hell am I wasting my time in this sketchbook, this code can be done in like 15 minutes" then I know I'm ready to get back to the keyboard. :)

Good advice. That is pretty much what I do also... :)

Ditto.
(Most of the time without a physical sketchbook,
just thinking about the problem in the same way
while walking around. )

Design time can help, but you need to also avoid the paralyzing effects that trying to find the perfect design can have on you.

It's rare you have all the requirements of the product when you start, or that they don't change/grow while building it. It's easy to try an over design/architect.

Practise. Also, use the same libraries and platform for all your projects - things go way faster when you don't have to stop the read the docs.

I worked for many years in fast paced environment (finance) as C++ dev where brokers/traders need things for yesterday (almost literally) and the usual approach - which usually served us well - is to code to get things "working", then refactor.

Refactoring iterations must be frequent enough to not end up in a spaghetti mess but this approach is unbeatable to get a product to market, fast, reducing the risk of inadequacy and time wasted trying to design around a problem no one fully understands fully in the first place - often the case with "big idea" projects. This certainly applies to making games as well.

There is a lot of resources about this subject on the web - worth having a look.

- Make things simple.
- well make things simple (twice)

- Every complex problem can be cut in very simple problem.

Don't over-engineer things. It's not because you learn a cool new pattern that's an excuse to put it everywhere. And don't try to boost your ego by trying to make a one hundred class engine.

- Don't make the exception the rule.

Most of the time I saw programmer trying to make a "generic" solution. We find another case not handled, and they changed their entire concept just for that, when a simple "if" is enough. The generic concept became so complex that no one else understand it.


- Make things simple (third):
Ask yourself if your mom can understand it.

- Focus yourself on the result not on the tech. (you make a game or an engine ?)

- Fix bugs earlier. Bug are easy to fix when they just appear.

Test your code yourself! It's like a good cook. A good cook taste what he do before it reach the client.
It's the same with code. You should test what you do to detect big bugs.
Clients should get most of the experience before hitting a bug.


Statistic show that Typing took 5% of a programmer time. So you won't earn much productivity.
You still can earn a small productivity by training to type because it "free your brain" from the load of thinking what you need to write. But it shouldn't be your focus.
(Side effect: you can also show other programmers how much you are "true" programmer by typing fast...)

Typing speed is like 1% of being a good programmer, I've seen people with blazing speed but with no analitycal thinking and mindset for programming. Thinking ahead and taking care of the architecture of your codebase will definitely make things go smoother.