Ask HN: Does being practical act as a hinderance to one’s imagination?

I think that maybe it's the difference between simply "imaginative" and "creative" - creative implies that you're involved in the act of creation. Things can't be created in impossible contexts, so part of being creative is understanding and accounting for the constraints you're working under.

Pler

Constraints can actually breed creativity, though you might be asking a slightly different question.

Check out the writing of David Kelly and his brother (of IDEO) — they’ve probably done more than anyone else in the field to try and crack the formula of creative thinking.

There is work by Frank Vahid (founder of ZyBooks) on many small programs and how students performed comparable to other traditional styles.

However, in the vein of this thread, I think that is only playing one note to learning CS. When I compare CS to martial arts (MA), I consider the traditional programming exercise akin to sparring. It is real world situated, but with the number of new variables it is difficult to successfully demonstrate or refine your understanding. MA, like CS, has a high attrition rate to start, and for reasons I consider isomorphic - a false sense of what CS/MA is and the demoralizing effect of "losing" constantly (sparring or debugging).

So, in MA, there are attempts to make sparring less intimidating. You can pair equal experienced partners or against an understanding senior, but you also focus on drills. If we consider sparring as a combination of problem solving and applying technique in the moment, then drilling removes the problem solving aspect to allow for technique refinement.

So, in combination with traditional programming exercises, my current work is looking at novel practice activities separate from tradition - for example, error finding, output prediction, and even typing exercises (which I have published on).

> In other words: engineers are only good at "yes, but" (convergent thinking phase) and prematurely shut down the "yes, and" (divergent thinking phase).

I do this sometimes. In many cases, I feel like "yes, and" would be an endorsement of the original idea. If I say "yes, and" and then there are delays or problems in implementation because of things that would have been obvious to "no, but", the question becomes "why wasn't this brought up earlier on before people sunk so much time in." In the reverse case, saying "no, but" in a case where the problem is easily surmountable just makes the questioner look like a good planner. So in that sense the reason devs tend to "no, but" is matter of them responding to incentives; it's not that they can't think divergently, it's that they're putting themselves at risk for little reward for doing so.

> So how about we treat thinking as a two-phase problem and give divergent thinking some room?

Yes, I think separating these two phases (and thus separating "throwing an idea out there" from "endorsing an idea as definitely workable with no foreseeable complications") would be very helpful.