When I was young I would reinvent the wheel for everything stupidly. Then I went through a maturation phase where I cut back on that and tried to use existing solutions and be sensible. But now I'm starting to see that a certain judicious amount of "Casey Method" is a good idea for certain programmers.
For example, if I had to write a game level editor tool in C# the straightforward way, it would probably be the most efficient way, but that's irrelevant, because I would probably kill myself becuase I finished, or just quit the job, so the actual time to finish would be infinite. On the other hand, if I invented a system to write the tool for me, and it was fun and challenging, it might take longer in theory, and not be the most efficient/sensible/responsible/mature way to go, but it would keep be engaged enough that I would actually do it.
6 comments:
The real joy of "The Casey Method" is that you get to eliminate many of the reasons why the original task was so onerous, so it isn't so much that you get to distract yourself with a much more interesting task, but your problems with the original task go away.
If you do a good enough job, that you also remove those problems for other folks. For example, doing GUIs are far less painful with IMGUI if you are a coder. I happened to implement my own IMGUI lib, but I'm sure I would have been happy using someone else's. In this case, getting away from the pain of building a widget scenegraph, threading state and registering callbacks was all win.
Hmm, aren't most workplaces nowadays using scrum-thingys etc. How do you "hide" a major Casey-sidestep project in such a controlled environment? Perhaps in a mega-corp but certainly not in a slimmer organization?
" Hmm, aren't most workplaces nowadays using scrum-thingys etc. How do you "hide" a major Casey-sidestep project in such a controlled environment? "
Yeah, that's a problem. It's more useful in solo projects.
I think scrummy methods are very good for getting a product out, but they really discourage creativity and passion, which sometimes involves doing experimental coding that nobody in a group would approve.
That said, I always managed to hide major projects back when I was a wage slave. You just have to be fast enough to do your normal work and also do your side work. Of course I was working 16+ hours a day then and had zero life.
I'm sure my managers hated me, because every month or so I would be like "oh I did this curved surface tesselator (or whatever) on the side, can I stick it in the engine?" and they would have trouble saying no since it was all done (even though in reality months more of support work would be needed - a tech demo is only 10% of the work), but I now realize that it was not a positive contribution towards actually shipping something useful.
" Hmm, aren't most workplaces nowadays using scrum-thingys etc. How do you "hide" a major Casey-sidestep project in such a controlled environment? "
Only if they are actually tracking the scrum work. Who actually does that except maybe Microsoft?!?! Games are all 'strike team' now, right?
I think we need some more synergizing and proactive silly names for development processes which are basically "don't do much planning".
Post a Comment