6 ms·
> Write your code for this game only - not for a future game. You’re going to be writing new code later because you’ll be smarter. This really stood out for me
by a3n 10y ago
> Write your code for this game only - not for a future game. You’re going to be writing new code later because you’ll be smarter.
This really stood out for me. I'm always tempted, while writing something specific, to generalize it. I try to resist that, when I recognize it. Writing a ThingThatImWritingFramework risks ThingThatImWriting never seeing the light of day, or never being used.
- cryptozeus 10y agoYeh totally..simple but so true
- irfansharif 10y ago> "Write code that is easy to delete, not easy to extend."
- msangi 10y agoAbsolutely! https://vimeo.com/108441214 https://vimeo.com/108441214
- NumberCruncher 10y agoAt 3:57 he mentions erlang. Somehow I am not surpised.
- alkonaut 10y agoIt completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. If the product is Doom this shouldn't be a problem - but for most of us the product is form validation or calculations involving plywood. Making frameworks and generalization is the only reason I manage to keep doing what I do. (I'm exaggerating somewhat, but I think this is a clear distinction between two kinds of programmers those who love the code; and the craft, and those who like making products. Have too many of one kind and you'll ship a mess. Too many of the other and you'll never ship)
- xyzzy_plugh 10y agoI've never thought of it this way. While I don't necessarily agree, I'm thankful for this insight.
- NumberCruncher 10y ago>> Making frameworks and generalization is the only reason I manage to keep doing what I do. <sarcasm> This could be written on the tombstone of JS. </sarcasm>
- alkonaut 10y agoI hate writing boilerplate and I'd rather have pineapples shoved up my behind than write code of the kind that should be in the freaking standard library. But yeah
- brokenmachine 10y agoThis is what always bugged me about java. I'm only just above a beginner, but it seems to me that in 2017 you shouldn't have to write so much crap just to read from a file. BufferedReader, FileReader, blah blah blah http://www.mkyong.com/java/how-to-read-file-from-java-bufferedreader-example/ http://www.mkyong.com/java/how-to-read-file-from-java-buffer... Maybe there's a good reason to make it this difficult, if so I'm not aware of it.
- alkonaut 10y agoThere is - but there is no good reason to not have good naming plus also a simple wrapper to do the most common cases. That the IO framework is very general is good, but that you need tons of boilerplate for a common scenario is bad. C# var txt = File.ReadAllText("file.txt"); This is exactly the abstraction you want if you want to read a (whole) text file. The point of abstractions is to pick the right one. For IO it's likely best to have many layers of abstraction so you can choose the simple top level function or use a more complex one when needed. I'm sure there is something similar in Java these days too. Would be a huge mistake to not have simple IO helpers to the std library.
- hermitdev 10y agoThis is basically the Mythical Man Month in a few lines. You once wrote something specific, and it was great. Then you had to write a second thing, and you remember things from the first, so why not make it more general for the inevitable 3rd, 4th, 5th to come? And, then, you fail to deliver the 2nd.
- whazor 10y agoTheir tools are also a form of generalization. Furthermore, it is definitely possible to create value by generalization.
- a3n 10y agoYeah, sometimes. And other times, the whole contract gets spent on a framework that only makes sense if there's another contract, and ... well, I guess that never happens anymore. Didn't someone say premature generalization is the root of all evil?
- msangi 10y agoThat's indeed a very good advice. All abstractions have a cost and no abstraction is better than the wrong abstraction. I found this talk on the topic very interesting https://youtu.be/4anAwXYqLG8 https://youtu.be/4anAwXYqLG8
- Ace17 10y agoIn the same vein: prefer duplication over the wrong abstraction ( https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti... )
- buzzybee 10y agoIt helps to allow yourself to be philosophical about what you're writing. Sometimes a generalization just moves around the problem. Sometimes the generalization you want competes badly against cut and paste. Increasingly I try to find a strategy that transitions towards the generalization over time by following a path of "lower friction instead of greater friction." It's easy to increase friction by adding a new configuration step, new concepts and idioms that are discordant with the rest of the environment, and then the point of doing it gets lost - you don't want to pay for that overhead most of the time, you can't ship code that way.
- nlyan 10y agoGeneralizing is part of how you'll be smarter later though. You cannot generalize something unless you understand its essence. It's easy to confuse abstraction (choosing to deal with one, possibly newly contrived, concept over another) and generalization (reducing the number of concepts required to explain something to a minimum). The former is like building a Haswell CPU from a description of 70s microcontroller architecture, whereas the latter is like trying to figure out what CPUs were like in the 70s by looking at a Haswell core under a microscope.
- a3n 10y ago> Write your code for this game only - not for a future game. The quote refers to a future product, one that is very likely unspecified at best, and more likely just something that an individual contributor dreamed up. Unless we have some sort of multi-phase contract, how do we know we'll ever build another thing like this again? Markets change, hardware changes, experience changes. Hell, building this thing may show you that you should never build another one like it. Generalize where sensible inside the project, sure. But as the quote says, build what you're building, not what you're not.
- hyperpallium 10y agoIf you know you're going to have to experiment a lot on some aspect of the game/product, it seems to make sense to isolate that part, removing the commonalities into some kind of framework (perhaps informal, jury-rigged, so you can iterate on just that aspect. A bit like the Wright brothers building a wind tunnel, so they could experiment quickly with control systems. But Id wrote some great games, so maybe I'm missing how they handled this aspect...
- pjmlp 10y agoThere is a saying in game circles, either one writes a game engine or a game, as most studios tend to die spending the publisher's money build the next great engine.
- EliRivers 10y agoFactories. I've got a codebase to work with using factories everywhere. Static arrays of them. Classes are given hardcoded enums and there's macro magic all over the palce to join classes to the factories that make them, and to generate all the factories in these static arrays of factories. Sometimes the static array of factories contains a single factory. Creating a single item. No variation, no types, just one kind of one item. The item is needed once. In one place.