Keep ’em coming: Why your first ideas aren’t always the best(gsb.stanford.edu)

132 pointsby hhs4 anni fa32 comments

gsb.stanford.edu

Keep ’em coming: Why your first ideas aren’t always the best

https://www.gsb.stanford.edu/insights/keep-em-coming-why-your-first-ideas-arent-always-best

33 comments

I'm quite cynical about my own ideas. If I actually stop and think about them when I have them I tend to dismiss them because I focus on the flaws more than the good bits. Writing them down and coming back later helps immensely.

Somewhat tangentially, this is one of the reasons why I dislike a lot of meetings, or, more specifically, meetings that don't have an agenda or a one-page doc upfront. If I'm in a meeting and someone drops an idea on the attendees expecting an immediate evaluation I'll say what I think but that's very often quite wrong and not really what I think. My first impression of things is driven by what I can see as flaws and problems and I don't see the good bits particularly well.

If you give me 24 hours and a doc outlining what you want to do you'll let significantly better feedback. I believe this is true of everyone.

spudzz4 anni fa

Could not agree more. I hate speaking off-the-cuff and being forced to evaluate an idea with only a split-second of contemplation time within a meeting.

We're trying to move to 6-pagers (a la Amazon) or at least a documentation-first culture but buy-in has been difficult. People find it easier to simply drop a meeting on everyone's calendar and then aimlessly toss out ideas for 30 minutes. When I try to send a document ahead of time, no one has read it when they show up, and they bristle when asked to take the time within the meeting to read it.

Has anyone had success moving to this kind of format? How do you change the culture of an organization away from blathering and toward thoughtful writing?

BiteCode_dev4 anni fa

One mistake a lot of people make while writing code, slides, essays and so on, is trying to structure the ideas too soon in the process.

Throwing ideas on a paper in no particular order and in a few words will exercise the least possible the part of you that expresses idea, and keep the one that generate ideas in focus. Then after you have exhausted the muse, you can start ordering them, chaining them, then putting full sentences, sections, or code blocks, functions and classes.

So the other should be, generate as many ideas as possible, then express them, structure them, put them in shape. Then generate ideas again. Then structure again. But not at the same time.

Because expressing things needs a structure, while creativity thrive without it.

mszcz4 anni fa

This drove me nuts when I was writing my master thesis. Professor handling it insisted on writing the outline first and then, in order (!), each of the chapters.

I found that approach problematic, at least for me. How was I supposed to know from the get-go what problems I'll stumble upon, what the conclusions will be, what pivots I'll make. So I just ignored that and started out in the middle, wrote what I knew when I knew it, and then progressed outward to more general, summary chapters. Turned out ok and I think with a lot less rewriting had I listened to her advice.

"From the middle out" ;)

kstenerud4 anni fa

Coming up with actually good, creative things is deceptively simple yet surprisingly difficult; in fact it's quite a slog.

I've been working on a new data format [1] that I'd expected would take me two years to create. 5 years later, I'm finally seeing the light at the end of the tunnel. The format that exists now is almost unrecognizable compared to the initial version, or even what I had after the first year of development (digging through the git repo would prove interesting).

Other than devouring every data format spec I could get my hands on, one big help was to _leave_ it for weeks, even a month, and then come back to it. This allowed me to view something with a fresh perspective that I simply couldn't see if I were working on it every day.

Case in point: Unicode escapes.

I wasn't happy with the current state of affairs for unicode escapes (\uDDDD or \UDDDDDDDD) which are clunky. I wanted something better, without the zero stuffing.

My first incarnation was as follows:

    * backslash
    * a digit from 0-9 specifying how many hex digits follow
    * that many hex digits

So for example \0 is NUL, \19 is TAB, \51f415 is dog, etc.

Sure, it works, but that length prefix really makes it hard to read.

A year after that, I came up with the following:

    * Initiated with \+
    * The hex digits to represent the codepoint
    * .

So for example \+0. is NUL, \+9. is TAB, \+1f415. is dog, etc.

That was much less confusing, since the numbers are properly isolated from the escape characters.

It wasn't until months later that I finally spotted the obvious after a break:

    * Initiated with \{
    * The hex digits to represent the codepoint
    * }

So for example \{0} is NUL, \{9} is TAB, \{1f415} is dog, etc.

And there have been so many of these moments that never would have happened if I'd pushed the format through after only 2 years.

[1] https://concise-encoding.org/

wanderingmind4 anni fa

I think, most innovative ideas are deceptively simple *in hindsight*, but I don't think they were obvious in first place. Would love to hear from some Neuroscientist lurking on HN on the causality of such feeling.

Archelaos4 anni fa

I briefly looked at your specifications. They seem to provide some very useful features laking in other formats, but I think you have still a long way to go to polish the specifications. The main issue I have with them is the lack of formal definitions for individual entities. I would recommend treating data normalization very precisly and defining every syntactical element in Backus–Naur form.[1] The specification of Unicode characters should be made independent of a specific serialization (such as UTF-8).[2] Formal definitions are extremly helpful to clearify edge cases and to implement a processor one piece after the other.

For example, instead of specifying uppercase/lowercase sensitivity in an extra section on "Letter Case", I would recommend defining the allowed character range for every item individually. In addition, it should be specified in detail how characters need to be handled by a conforming processor. Just for example: What Unicode version must be supported? The whole code range or only a part of this version? Is a processor required to check for violations of certain rules, such as illegal case? Should or can a processor normalize case or must it not? If it should or can, must it implement the "default algorithms for case conversion, case detection, and case-less matching" from the Uncode spec,[3] or may it, for example, deviate and support only a subset of Unicode characters?

To take up your own example, here is an edge case that is only very difficult to specify verbally, but can be made very clear in Backus–Naur form: Do you want to allow leading zeros for numbers? If so, infinitly many? A leading '+'? ...

It might be helpful to dinstinquish two phases for a conforming processor, namely checking syntactic conformity of an entity to its Backus–Naur form (eg. Is this entity a number?) and validating a syntactically correct entity in its context accoring to some validation rules (eg. is the number out of range?).

[1] See https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form

[2] For example, you are defining: "A string-like array MUST contain only valid UTF-8 characters.", but when I look at "Escape Sequences", you are using Unicode code points, and not UTF-8 byte sequences. -- Your sepcifications may, of course, require that data exchange must happen in UTF-8 (and should say something about byte order marks). Besides, they should not be conserned with any particular serialisation, but should only work with deserialised Unicode code points.

[3] See sect. 3.13 of https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf

kstenerud4 anni fa

Hey thanks for taking the time to critique!

I actually do have an ANTLR file that is about 90% of the way there ( https://github.com/kstenerud/concise-encoding/tree/master/an... ), so I could use those as a basis...

One thing I'm not sure about is how to define a BNF rule that says for example: "An identifier is a series of characters from unicode categories Cf, L, M, N, and these specific symbol characters". BNF feels very ASCII-centric...

Archelaos4 anni fa

Just base everything on Unicode code points.

I recommend the XML 1.0 (Fifth Edition) specification as an inspiration how to do it: https://www.w3.org/TR/xml

For example, it defines syntactically valid names (for XML tags, attribute names, etc.) as follows:

    [4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]

    [4a] NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
    
    [5] Name ::= NameStartChar (NameChar)*

jmathai4 anni fa

My most interesting ideas take months and sometimes years to click.

The most challenging part of my current job (PM at bigco) is that the time and space doesn't exist. Ideas are extruded based on timeline (and other) pressures.

I've only ever been able to let ideas percolate when I've done my own startups or with my open source projects. In some cases good ideas never came to fruition because I couldn't get them to the point they were great. This is one recent example, but there's so many [1].

  I've been thinking, for years, about an easier interface to manage
  my photos using @getelodie (the Github version) than the command
  line. I haven't put my finger on it.

  Probably doesn't have to work on mobile. Probably web. Mobile / 
  desktop apps deteriorate quickly anyways.

It's sort of the opposite of churning out MVPs. One's not better than the other but they definitely lead to different destinations. Lately, I've been even more convinced than before that software that's treated like art yields much more interesting products than software treated like a factory.

[1] https://twitter.com/jmathai/status/1587163999900037121

samsquire4 anni fa

I began journalling ideas in a Windows WikidPad. Then I summarised some ideas in GitHub README.md articles. I wrote 700+ ideas since 2013 across 4 repositories. I write my ideas in markdown and publish and work on them in the open on GitHub.

The more ideas you write down the more ideas you shall have. So keep writing them down! The important thing is getting them out so you know what to improve. Ideas aren't worthless. Mathematics, science all started as ideas.

I work on them in the open in the hopes that we can introduce some of these ideas in the industry.

I journal about futuristic software ideas and parallelism, algorithms, multithreading and database internals.

I am looking for people to talk about inspiring ideas. And to share talking about ideas for programming projects.

I am a member of eatonphil's Discord multiprocess community where we talk about system internals such as database internals and programming language development or theory.

I want people to read my ideas and share their ideas that they caused. And I want to read your ideas. So send me your idea lists!

https://github.com/samsquire/ideas https://github.com/samsquire/ideas2 https://github.com/samsquire/ideas3 https://github.com/samsquire/ideas4 (incomplete) https://GitHub.com/samsquire/startups

For some things I created due to my ideas see my toy database project https://GitHub.com/samsquire/hash-db And my userspace 1:M:N scheduler https://GitHub.com/samsquire/preemptible-thread

I am currently working on a parallel programming language ala Golang and Java

gppk4 anni fa

This would be great as it's own HN post. Would love to see the discussion on your approach/ideas!

mberning4 anni fa

I was watching an interview with Tom Englund of Evergrey and they were discussing the creative process. In this context the question was around how he and his band churns out so many high quality albums. His answer was that his goal is to write one riff a day. And at the end of the year he would have 365 riffs. And from that then he could come up with ideas for at least a few songs. And once those are done, he could build an album. At the end of the conversation he said something like “in reality, if you can write one riff, you will usually write thee or four”. To me that was the big take away. For any creative process, if you can just do something, anything, then that will likely produce a multitude of new ideas. It’s the same with software. I have tried to apply this idea to my side projects, and it works. I set aside 20 minutes a day and tell myself I’ll write one line of code. Some days thats all I can do. But as Tom said, some days if I can write one, I can 3, 4, or more.

kristiandupont4 anni fa

John Cleese makes a similar point in this talk on creativity: https://www.youtube.com/watch?v=Pb5oIIPO62g

gravitate4 anni fa

I like to iterate on ideas and flesh them out a bit. Many learn the hard way through trial and error and sometimes find their idea is not compatible with the world, or even needed at scale. It might work in their home town (New cafe needs to be opened, gap-in-the-market type stuff, but hardly Starbucks scale).

paulpauper4 anni fa

What if all your ideas are bad and you never get to the phase of having good ideas. That seems to be my problem, probably others too.

malux854 anni fa

Try metacognition, analyse your thought patterns for repetitions that are leading to bad ideas,

As humans we shy away from the unknown and embrace comfort - this causes us to make the same mistakes over and over, because better the devil you know than confront the unknown and it’s implied possibility of judgement and inadequacy.

The good news is : Often things aren’t as hard as we think! Fear of the unknown is almost always worse than the unknown ends up being - so get out of your comfort zone and get some new neural pathways forming, in whatever form that takes

mayankkaizen4 anni fa

An idea, when actually executed, transform the original idea. It doesn't necessarily means that your plan or objectives have changed. It is mostly that your idea, post execution, bears different look, feel and meaning.

So, always try to convert your idea into action. Your idea is your call to an unknown journey. In that sense, no idea is bad.

WWWWH4 anni fa

Don’t be too hard on yourself! Keep it up, have fun and remember it’s a long game.

karmakurtisaani4 anni fa

Your goals may be too ambitious.

atentaten4 anni fa

What's your criteria for a bad idea?

ChrisMarshallNY4 anni fa

One of the biggest issues, is accepting the first idea, and stopping the search for ideas.

I actually wrote a "shortie" about exactly that: https://littlegreenviper.com/miscellany/problems-and-solutio...

aschearer4 anni fa

One thing I've wondered is whether working as a software engineer shapes one's thinking in a manner that's not conducive to creativity. I find I often start analyzing new ideas, looking for faults or potential pitfalls -- as if I were being handed a spec to implement.

justinlloyd4 anni fa

Not meaning to be flippant and dismissive of your conjecture, but that "sounds like a you problem." I have met many an engineer who is creative, and I have met many an engineer who immediately jumps to the negative mindset of why it won't work, and many more who succumb to pedantry that stymies ideas and conversation flow very quickly. I don't think there is a solution to this, it's just how we are, as individuals. And we all have our contributions to make, be they creative or pragmatic.

dwenzek4 anni fa

What a refreshing post!

So many good points are highlighted: embrace as many as possible ideas without apriori triage, look for ideas in many places, with diverse people, make unexpected connections, add but also subtract, put things into actions, ...

I recognize myself on many points, even I would not pretend to be perfect on these lines - being also tempted to take shortcuts. And this is why this post is refreshing. It encourages me to keep exploring ideas and putting them into motion.

izuchukwu4 anni fa

Check out the Creativity Faucet by Julian Shapiro. It’s a brief take on the same phenomenon: you’ve got to let the tap run and let the wastewater out before getting to the good stuff.

That’s because, in part, the good stuff is made out of identifying why the wastewater fell short.

https://www.julian.com/blog/creativity-faucet

justinlloyd4 anni fa

Most of my ideas, at least the initial iones, are, to put it bluntly, utterly shite.

That said, usually as I explore an idea it begins to slowly crystalize in to something interesting. I've built furniture, created recipes, written software, designed games, made toys, invented interesting gadgets, published stories and articles, and shot videos, and in all of those cases the resulting artifacts looked nothing like the original concept. There might be a sliver of the original idea, but it has usually drifted far from the initial idea.

I'm currently building an electrocs workbench, I say building, but I mean "thinking about it a lot." I've purchased some cabinet hardware, I've got a stack of boxes for internal storage, but the workbench itself sits as nothing more than a CAD drawing as I tweak how the workbench & cabinet will work. "How deep should this drawer be? How wide should I make that swing out tray?"

I am currently kicking around an ML idea to do with some data at work, I'm doing it as a "fun side project" in my own time, my PM keeps trying to "task it and track it." Don't do that, I need to keep kicking the idea around for a while. When I'm ready, we'll stick a pin in it, nobody is waiting on this, nobody outside of me and the PM knows about it, why add artificial urgency and process to something that's fun?

As a personal side-project I'm building a task list. The idea has evolved so far from "I want to build a task list" that it is barely recognizable. I wrote a lot of the lab notes from that project here at https://github.com/justinlloyd/retro-chores, and without expecting anyone to read through those lab notes, there are places where I write "I'm going to solve it this way" and then a few paragraphs later I write "nope, actually we're going in this direction now" because a little research showed some new evidence.

My lab notes are very free-form, the way to kill creativity and an idea is to impose structure on it. As a creative exercise for problem solving when working on an invention or gadget, is to take a part or component with me, and go for a walk, and mull over how the component works, how it fits in to the design, what issues I will run it to with it. The component acts as a McGuffin, to keep my thoughts focused on the project as I walk.

lleb97a4 anni fa

I believe Stephen King said something along the lines of "Good ideas stick around." I've come to treat it as gospel. Any idea that nags at me over days/weeks/months tends to be worth pursuing.

hardwaresofton4 anni fa

It’s got a bit of a capitalist/startup-y slant but I’ve found some tactics super effective:

- Writing ideas down to let them leave your mind

- Expanding on ideas to help ideas and fresh thinking enter and leave your mind (if you think of ideas like books on a shelf, whose pages get written as you turn them).

- Sharing ideas[0] that you aren’t going to work on in the near future. (Fittingly, building a paid list for ideas was one of the ideas from edition #1 [1].

- Getting better and faster at validating ideas and iterating iff they show promise

- Do not talk about ideas you’re working on until after they’re finished except to close friends who ask/care. Marketing/early customer discovery is one thing but avoiding talking helps build “desire” I find.

The idea of trying to pad my backlog of ideas every week is good, but this idea of coming up with ideas every day is quite interesting.

[0]: https://unvalidatedideas.com

[1]: https://unvalidatedideas.com/editions/1

chatterhead4 anni fa

All my ideas are award winning level. I'm just super lazy and don't care about being successful.

passion__desire4 anni fa

Congratulations. You fit the trope of Lazy Genius.

https://tvtropes.org/pmwiki/pmwiki.php/Main/BrilliantButLazy

[deleted]4 anni fa

lob_it4 anni fa

Timing is everything :p

Don't be so hard on yourself. I completely understand the stress of breaking a nail by being in a hurry.

Haste makes waste :)