Mmmm, I'm not sure I buy the sound-biting going on here, as well intended as it perhaps is. About the only one that would stand in my experience is:
Before you release, test.
As this particular one is always the one that comes up short. The rest kind of ... don't quite cut the mustard, even as sentiments I think. The idea is nice though, don't get me wrong.
Stephen001 wrote:
The rest kind of ... don't quite cut the mustard Hmm...so apparently you code with a dead brain, write without ever having seen letters, talk to yourself, and comment without having a reaction? Just kidding, I know you don't do that, but what do you find wrong with the other statements? Have you ever talked to someone who would interrupt you to "respond" to what your saying with their own babble...and didn't you want them to take a breath and let you finish? | |
It's more they are just quite valueless, empty statements, all be it well meaning ones.
To take an example "Before you code, think". I'd have thought, realistically, it would be quite difficult to write code without really thinking about the task at hand at least in some capacity. It's actually quite a natural thing to do, to at least identify a "problem" to solve before solving it and indeed writing code is solving some identified problem or constructing some mentally conceived creation like a feature. So obviously (I hope), the statement can't be pitching at that. Because as you point out, writing code with your brain literally switched off is actually kind of laughable. So you know, pledging to think in the basic sense before writing code is a bit like pledging to chew your food. So instead, what is it pitching at? Should I reflect on how the problem I'm trying to solve might affect the overall system, or whether the problem needs solving at all, or whether I can use a more lateral approach, or whether the design has issues, or something else? The statement in itself offers up no real intellectual content, or structured thinking point. It is of course a talking point, hence we're on page 2 here, but that isn't a pledge or valued recommendation. Indeed, if it's so open (and not discussed by OP) I'm not sure if has much value to newer programmers on BYOND either. The statement would have me believe the author would like that I design and plan more before doing. Which is fine ... sometimes. Sometimes, you don't know the best way forward and due to your own inexperience (be it generally or in the problem area), can't design a solution you have any faith in being neat, robust or even working. That is actually the situation facing most BYOND programmers, I'd wager. It is these situations, to which "lick it and see" comes into play. You have a design and just roll with it, see how it goes, as a prototype of sorts almost. This is actually what BYOND as a platform is also very good at supporting as well. From that, you gain an experience of how you might solve the problem, and have a solid solution you can evaluate and learn from. That for many on BYOND I suspect, is a very valuable experience. It also of course, keeps your development momentum, and should, I think, keep you moving towards your end release of the game. Design blocks stop being such, they become prototyping opportunities. This is how industry gets over a lack of experienced in a problem domain, if bringing in expertise is not possible or doesn't make sense. | |
I feel this picture is relevant to the discussion at hand:
 On a more serious note, its quite hard to cook down programming advice into an ideology or philosophy like that. One risks the advice becoming trivially useless , or extremely restrictive and often incorrect. And that seems to be the case here. | |
Stephen001 wrote:
So instead, what is it pitching at? Well I think it is pitching at the idea that, as you said, some thought needs to be done before coding. It's funny that you related it to pledging to chew your food. In America, most people do not pay much attention to chewing their food. Instead they chew just enough to swallow, they scarf their meal down while in the middle of getting to work or socializing or studying. Instead of taking the time to enjoy their meal - and pay attention to when they are full - they just go ahead and eat, usually in larger quantities than necessary. Diving headlong into some programming task is definitely how I have learned a lot, but it's also how I have started dozens of projects that never went anywhere and gotten way too far over my head. So while it's not a 100% of the time type of rule, it's generally a good idea to ask yourself what you want to accomplish and how you could do so. | |
Well I think the thing is I'd rather not assume you're all sufficiently daft that those words actually needed saying, or putting into a pledge. It's trivial to reasonable people, and not very helpful to the rest thanks to it's sound-bited nature, as I've stated.
Now what would have been interesting, was a case study or discussion on how OP's gone about designing a particular game feature they have, to demonstrate some sense of methodology. Still, with BYOND as it is, not a lot of planning is really needed. That's one of it's virtues. | |
I think what I said is neither restrictive, incorrect nor useless. It is my personal pledge and comes natural to me. Leave it to programmers to destroy something simple yet meaningful.
Honestly, what I originally said makes way more sense to me than any of your replies. | |
I feel like Heero Yuy after this thread.
| |
FIREking wrote:
I think what I said is neither restrictive, incorrect nor useless. It is my personal pledge and comes natural to me. Leave it to programmers to destroy something simple yet meaningful. I think people might of mistaken it for a global pledge rather than once based upon your views and such. I myself thought that but also agree with yours, that's if you don't take it too seriously and decide not to be technical. (: | |
FIREking wrote:
I think what I said is neither restrictive, incorrect nor useless. It is my personal pledge and comes natural to me. Leave it to programmers to destroy something simple yet meaningful. Oh come now, this is design philosophy, analysis and exchange of ideas is what this area's all about. What I feel you'd stated in your first post was largely obvious. Sufficiently so that it's kind of like "... Yeah, alright ... I guess ... why'd you share that?". Don't get me wrong, it's not like you've said anything that's made me go "That's terrible advice to people" or "You're setting yourself up for failed projects", and if that post carries a lot of useful meaning to you, great! But to the wider world, it's just a bunch of sound-bites really, some obvious, some quite hollow, mostly due to the lack of surrounding explanation. | |
Stephen001 wrote:
What I feel you'd stated in your first post was largely obvious. What is obvious to you may not be obvious to others... like, people who talk over others and only think about what they want to say. At least one that is not obvious to most people in american society. It can be difficult, having been raised here, to take a breath and actually listen intently without constantly thinking about your own response. | |
Magicsofa wrote:
It can be difficult, having been raised here, to take a breath and actually listen intently without constantly thinking about your own response. I believe the phrase "This is what separates the men from the boys." is a perfect example. | |
Well I think it's just that your audience here is technical, and can digest somewhat lengthy or reasoned explanations. A topic like this (if OP were looking to share an philosophy for development for example, which maybe he's not) tends to work a lot better with those sound-bites forming sub-titles, almost, like this topic:
http://www.byond.com/forum/?post=1032248 Or this: http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-500/ usccse83-500.pdf Where you have a bullet list of short "Do this" notes, and then expand on that to explain why you feel the way you do, the problems you think it solves and the benefits you think it provides. | |
Interesting. When I post a series of good practice statements, it gets deleted (intent to stir up trouble?). While these general, empty, sound/feel good statements remain. Very interesting.
| |
Lugia319 wrote:
Interesting. When I post a series of good practice statements, it gets deleted. While these general, empty, sound/feel good statements remain. Very interesting. Life isn't fair sadly :( | |
Looking at the log, it's the fairly tongue in cheek nature of what you wrote that got it deleted. I don't think the moderator felt you were trying to make a serious or qualitative design philosophy topic.
As it goes, I probably would've knocked your topic into here anyway, as they are in the same ballpark. I can do that if you'd like, now? | |
Don't bother with it. I'm less bothered than I am surprised with this whole business is all.
| |
I was gonna get around to addressing your points, probably with the same kinda concerns as this topic, mind. Brother loves an explanation with his commandments.
| |
Most of those points were ones that I had addressed back when we still had blogs. *misses their blog terribly*
| |
-In my opinion.
Falacy I believe, in his own way - wants/wanted BYOND to prosper and grow. Sure he might of sounded harsh and shoved his thoughts down everyone's throats but he in his mindset thought he was doing it for the greater good. Maybe it could have been his ego or maybe it's something else. His attitude makes him hard to like in most eyes but if you can look past that there's something there. ^^