0 Members and 1 Guest are viewing this topic.
As a technical writer who has focused as much on the “technical” as on the “writing,” I came up with a phrase that describes my reaction when a programmer tells me something “can’t” be done: “Its just software.”<..>“Can’t” is shorthand. What it’s shorthand for depends. It could mean there’s no time to do the work. It could mean there are no resources to do the work. It could mean that the work does not provide enough value. (A reason that’s especially tough to hear when you’re trying to make a product better.) Heck, it could mean that the underlying system was designed so badly that there’s no way anyone wants to touch any of it because one light breath will make it all fall over like a Jenga tower.What “can’t” almost never means is its literal meaning. A programmer almost always can, so when one says “can’t,” it becomes incumbent on us to translate.
Making a game is more fun than making accounting software.
"Give someone a program, you frustrate them for a day; teach them how to program, you frustrate them for a lifetime." - David Leinweber
If you’re able to make a bit of software that enables a zombie to wander through a town searching for fresh brains, then you should be able to make a toaster oven do the same and reuse the same code for both.
I think every company needs to make the decision to either invest significantly more in tools, or just not bother.That applies to everything. It's not only for the 3d editor used to build your levels, but it's your build system, and it's your programming language, it's your production pipeline, it's the DCC tools you use, all of that.Tools are supposed to have a multiplying impact on productivity, and when you find that they have a dividing impact on productivity, get the hell out.
I saw a great quote the other day:If it doesn't work,it doesn't matterhow fast it doesn't workand this is kind of my coding philosophy.