Isn't the word you are searching for called "code optimization"? (Which is technically building on something that is already built.)

"Code tinkering" by definition is casually messing around with the code to see what else can be done. Yes, they both are similar with one difference. Optimizing usually reaches the same result faster, while tinkering diverges into new ways to solve a problem. To make a quick example...

Optimizing and tinkering are close, but they are not always the same thing. Tinkering can actually broaden your thinking and make a better programmer. For business, obviously this is bad because you are on a strict time limit. In hobbyist projects not controlled by time, programmers should be given a little slack.

It really goes back to the whole needs thing though. All examples I've laid out above create 0% productivity. As far as a program is concerned, there is no gain from optimizing, tinkering, or refactoring except the time data takes to hit the user. Or, is it the fact that the result isn't tangible a good reason not to pursue these methods.

I think that we know there are more factors than just tinkering that contribute to a program not being finished. Especially something as difficult as game making. When tinkering crosses the border into optimizing, I think that is the real problem that needs to be addressed. Of course, it is a problem that needs to be dealt with on a case by case basis and really a whole other bag of worms I don't want to get into here.

Tinkering can actually broaden your thinking and make a better programmer.

As long as you understand what you're doing it can, but it's not a very effective way. A high percentage of people don't even understand that they are tinkering and it makes them into worse programmers. From my days of working for the man...tinkerers, especially very skilled ones, was my biggest nightmare. Joe average that's willing to stick his nose to the gridstone and work on what he/she's suppose to and at the right time and writes the worst possible code that's still to spec...loved those people.

From my days of working for the man...tinkerers, especially very skilled ones, was my biggest nightmare.

That's because those guys hate working for the man! Most people here would fit into that category. Chances are that they're bored with their jobs and the best part of their day is finding a little tinkering challenge that they can struggle with to make the perfect API or the most efficient code.

Oh I know I am a tinkerer. Well...only on some things. When i have something I want to get done I do it and say screw everything else until it is working.

I am more about code readability. I hate languages that are just hard to look at. Why do we need to use every single possible key on the key board for programming? Java can be very pleasant to look at.

Chances are that they're bored with their jobs and the best part of their day is finding a little tinkering challenge that they can struggle with to make the perfect API or the most efficient code.

And like I've said...there's nothing wrong with that if you understand what you're doing. I'm not attempting to dictate how people should spend their time. But if you think you're writing a game, then you're racing toward a brick wall...sooner or later you'll daunted/bored and quit.

Finally someone that understands why I hate looking at any C* language...

Definitely. I don't know if this is just me, but IMHO "SomeClass extends AnotherClass" looks better than "SomeClass : AnotherClass". The same with long class/variable names, for example "WindowClassExtended" against "WNDCLASSEX".

As long as you understand what you're doing it can, but it's not a very effective way. A high percentage of people don't even understand that they are tinkering and it makes them into worse programmers. From my days of working for the man...tinkerers, especially very skilled ones, was my biggest nightmare. Joe average that's willing to stick his nose to the gridstone and work on what he/she's suppose to and at the right time and writes the worst possible code that's still to spec...loved those people.

Agreed.

Actually, I face similar challenges on the project that I'm working on. To be honest, the open source world and the business world co-existence is baffling, but both have its fair share of tinkerers and optimizing gurus. I know from my experiences, it depends on the approach that you have towards it.

A lot of our current problems have to do with our outdated business model and business practices. Information has reached a point in where our business tracking methods can't keep up with the speed that users can destroy credibility. We have technically been using the same model that has been around since our grandparents time, and those guys did not even consider the vast speed of the internet's information highway. Instant gratification is deadly, and it is the real death blow to businesses today. Those who fail to keep up with changing technology, fail completely.

What does this have to do with tinkering?

Everything. There is a reason why we programmers must continuously tinker. Updates and information actually happens on a minute-to-minute basis on the internet. It is survival. As I'm typing now, my code is already becoming outdated with the new methods and libraries that are coming out today. We can't code something today that'll remain relevant in the next 50 years.

I know we programmers shun change. Hell, I even do. I still am in disbelief on how fast Java is becoming irrelevant when just barely 5 years ago it was practically on every (Android) mobile device. As much as I hate to see people rewrite the same code over-and-over again, I realized something. It actually has its place in the programming world, even if it isn't on purpose.

I don't think businesses are ready to get into that level of thinking yet. It just isn't cost effective to have a group of programmers re-invent the wheel. However, with the rate of speed the information highway is churning out new data, it is those same people who are going to open up new doors and gateways. Anyway, I'll leave it up to the business model to catch up. If they don't, well... it'll just have to end up expiring like everything else that isn't relevant.

Just make games and solve every problem well(you can even tinker with it when you are it) that comes ahead of you. Just don't stop solving same problem again and again and forget your real goal. Those people who never get anything done neither invent or innovate anything.

If Columbus had the equivalent to "code tinker" disease he would have never set of. He'd have spent his time designing the best way to make the trip, designed new boats, find the best people to accompany him. He'd eventually gotten bored and wondered off to some other "great" idea...which also wouldn't get complete.

Or he would have ended up in f**king India.

Pardon the severe digression, but everybody here understands why it is we mistakenly call Native Americans "Indians", right? Columbus was a boob.

I've been in this argument before, and I've learnt that there are two (main?) types of programmer.

There is the tinkerer/hacker*, that does things their way because they want to learn how things work so they can apply their skills in different areas.And there is the get-it-done programmer, that gets things done because that's all they want to do.

Neither is superior to the other, they just have different goals with their programming. They both get the job done when needed.The main difference you'll notice is that the former type of programmer are focusing on what comes next, while the latter are focusing on getting things done now.

I suspect that in the case of the Myer-Briggs types, this is simply Perceiving against Judging.

Personally I make a clear distinction between experimentation/research and tinkering. In the former the person understands what they are doing and why, in the latter they do not. So what I call tinkering statistically never results in anything of any use. Tinkering is procrastination and isn't focused. Tinkers virtually never do their homework. Newton said: "If I seen farther than others, it's because I stood on the shoulders of giants". Tinkers try to build a car and one step in that is (obviously) the "improved tire", but they have no clue how a modern tire is designed and they don't go and find out. More to the point, they're very unlikely to need an improved tire anyway...and sadly they end up with a 3 ton square tire.

Quote

There is the tinkerer/hacker*, that does things their way because they want to learn how things work so they can apply their skills in different areas.And there is the get-it-done programmer, that gets things done because that's all they want to do.

This is often repeated and is BS. The danger (if you will) of this kind of thinking is that it promoted unsound programming practices. You can be knowledgeable, get things done and not be a monkey programmer. As I've said above, what I call thinkers don't expand their skill set in an efficient manner.

Unless you are trying to achieve something practical and measurable, how do you know your tinkering has had any positive effect? For all you know you have just gone in circles. I find I can only think effectively about programming when I have a specific problem to solve.

Tinkering at the very least gives you practise and also experience. Even if it' snegative experience, when your tionkered solution has grown too unmaintainable and you see that you need more planning ahead next time.

Graphics artists at times make dozens or more sketches before they feel proficient with a scene or technique.

Also children learn a lot just by experimentinmg and exploring. Sure there are domains where teachers and books are a better way to learn, but for the more practical skills tinkering isn't the worst approach.

And quite often a "good enough" solution is really just that - good enough. No more work or perfection needed. You just need to get a feel what is appropriate to your problem. Quite often very simple solutions will do the job.

Actualy I consider it an important skill to find simple and yet good enough solutions. It usually saves time, money and material.

Finally someone that understands why I hate looking at any C* language...

Definitely. I don't know if this is just me, but IMHO "SomeClass extends AnotherClass" looks better than "SomeClass : AnotherClass". The same with long class/variable names, for example "WindowClassExtended" against "WNDCLASSEX".

That I agree with. I also develop web content and I have yet to learn JQuery because of this. I hate API atrocities which you constantly need to look at documentation to figure out what a method does. Any good programmer spends more time figuring out what code to write than writing code.

These are all pretty good points. Actually, experimentation is something that works very well when you specifically know what the problem is. Chemists do experiments all the time. They plan for a problem then take calculated steps toward the solution. Sometimes they pass, and sometimes they fail, but the result is always planned. Experimentation guarantees that no matter who you are, you can get to the same conclusion no matter what.

For anyone who has done programming for games, there are those moments in games where you have to do something that "feels right". These moments fall directly under the "tinkering" category. There is no clear-cut solution to a problem. You are just messing around with values until you get something close. The answer isn't necessarily "correct" or "wrong", it is just what feels right to you at the time.

It is also why "tinkering" is not always a bad thing. The people who do the most "tinkering" would be artists and musicians. Sometimes, you can't really calculate what the right note for a chord would be. Sometimes, you can't get that tree leaf to look correct. It is not something that many people can "experiment" with and come up with the same solution, it is just something that you "tinker" with until it feels right to you.

For games, this specific aspect happens a lot and it is something that separates good games from boring ones. Sometimes, there is just no solution to a game problem. You have to "tinker" with the values until you get something close. The people who do well at this are the ones that know when "good enough" is "good enough". In other words, they know when to stop "tinkering" and move on.

There is a place for "experimentation" in gaming when it comes to the mathematics, don't get me wrong. There are solutions for how to properly sort arrays, deal with Perlin Noise, and finding the best hashing method. You can be sure that my results and your results will always match in those cases. However, when you want to find out what is the perfect jump height, if your pistol is as balanced as your shotgun, or if there is enough challenge in this section of your game...

"Experimentation" fails and "tinkering", doing what feels most right to you, prevails.

It is also why "tinkering" is not always a bad thing. The people who do the most "tinkering" would be artists and musicians. Sometimes, you can't really calculate what the right note for a chord would be. Sometimes, you can't get that tree leaf to look correct. It is not something that many people can "experiment" with and come up with the same solution, it is just something that you "tinker" with until it feels right to you.

Which Is why I personally consider gamecode programmers to be artists. You can be able to code an OS kernel on your sleep yet if you don't know how to evaluate when something looks/feels good you end up with clunky gameplay and boring special effects.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org