Look at each change to your requirements, platform, or tool as a new challenge,
Caveat: Letting product owner make whimsical requests without any thought of consequences is also a recipe for disaster. It’s a ‘challenge’ that you won’t meet in the long run.
I agree; I was kind of hoping the context was post-meeting– if you don’t have enough whereabouts to discuss scope-creep or changes in requirements/goals with the owner/manager, I think you’re fairly doomed in the long-term.
I’m not normally a fan of lists, but this one hit home. It’s taken me a while to learn some of these things, but I think they’ve ultimately lead to me being a better engineer (and a better person for that matter). But, I still have a long way to go, and there are probably at least 10 other commandments that could be added, including my recent favorite:
Even the seemingly most ridiculous ideas in a brainstorming session can lead you to the right answer.
Too often the ego driven programmer will shoot down an “idiotic” idea in a brainstorming session, which only helps to shutdown the creative process.
I spent some time working in the television industry, and I learned a technique that writers use. It’s called “the bad version.” When you feel that a plot solution exists, but you can’t yet imagine it, you describe instead a bad version that has no purpose other than stimulating the other writers to imagine a better version.
For example, if your character is stuck on an island, the bad version of his escape might involve monkeys crafting a helicopter out of palm fronds and coconuts. That story idea is obviously bad, but it might stimulate you to think in terms of other engineering solutions, or other monkey-related solutions. The first step in thinking of an idea that will work is to stop fixating on ideas that won’t. The bad version of an idea moves your mind to a new vantage point.
That is a great way of thinking about stories. And engineering stuff too, I imagine, but it really precisely speaks to a block I have in my attempts at fiction. Thanks. :)
Caveat: Letting product owner make whimsical requests without any thought of consequences is also a recipe for disaster. It’s a ‘challenge’ that you won’t meet in the long run.
I agree; I was kind of hoping the context was post-meeting– if you don’t have enough whereabouts to discuss scope-creep or changes in requirements/goals with the owner/manager, I think you’re fairly doomed in the long-term.
I’m not normally a fan of lists, but this one hit home. It’s taken me a while to learn some of these things, but I think they’ve ultimately lead to me being a better engineer (and a better person for that matter). But, I still have a long way to go, and there are probably at least 10 other commandments that could be added, including my recent favorite:
That reminds me of:
(source)
I’ve seen this as:
This is much better wording than my crappy attempt. Thanks for sharing!
That is a great way of thinking about stories. And engineering stuff too, I imagine, but it really precisely speaks to a block I have in my attempts at fiction. Thanks. :)