[HN Gopher] How Do You Like What You've Built?
___________________________________________________________________
How Do You Like What You've Built?
Author : f1shy
Score : 50 points
Date : 2025-01-05 15:13 UTC (1 days ago)
(HTM) web link (morrisbrodersen.de)
(TXT) w3m dump (morrisbrodersen.de)
| hluska wrote:
| Maybe I'm misinterpreting the article. But I fail to see how the
| question (or leaving a conversation in the middle) added anything
| to the solution. Their colleague executed despite a problematic
| conversation.
| jpitz wrote:
| My take from it was that the question prompted the change
| author to introspect his feelings about the change and revisit
| it, making it better.
| mfro wrote:
| Yeah, I think what they are getting at here is a bit holistic.
| The question(unrelated to actual code quality) happened to
| prompt the author to play around with the new build, which
| happened to result in a bug discovery. I can see how it's a
| good question to ask (gauges confidence in code and end
| product) but this is really just another feel good anecdote
| from middle management.
| joshdavham wrote:
| Nice little post!
| apitman wrote:
| Perhaps the largest cause of wasted programming time is building
| things based on what sounds plausibly useful rather than what is
| actually useful. It's not an easy question to answer, but it
| needs to be asked constantly to avoid the trap.
|
| Many of us have had the experience of spending an entire weekend
| feverishly hacking on something that was going to change the
| world, only to have someone point out a critical flaw in our
| assumptions as soon as they try it.
|
| This is why scratching your own itch is so effective. If you make
| something that you actually use every day, you might be on to
| something. Going from 0 to 1 users is the hardest step.
| hnthrow90348765 wrote:
| It's why you get user feedback before it goes into development.
| Then the developers don't have to question/gamble whether
| things are good for the users. If you can't answer that with
| evidence, then you are guessing at what users might want, which
| can definitely be a large gamble if you are a solo developer.
| User opinions count as evidence in this case, and guessing is
| sometimes correct in certain situations though.
|
| For some of us, we will not deeply use the industry-specific
| line-of-business things we've been asked to work on and won't
| have a good, calibrated opinion. In these situations,
| developers without the industry knowledge should get that
| validation before making those kinds of decisions.
| Joel_Mckay wrote:
| Rule #17: "Only forward meaningful data at every layer of a
| design, as it often naturally ensures a feasible convergent
| behavior."
|
| Most people only learn this after failing hard with a "big data"
| project... =3
| rbjorklin wrote:
| Rule #17 from where? I'd like to take a peek at what the other
| rules have to say!
| Joel_Mckay wrote:
| That is quite a long list, and already tends to elicit a lot
| of negative karma.
|
| Rule #6: "Perspective is earned, and cannot be given freely."
|
| Besides, we all know truisms tend to be terrible wit... Best
| of luck =3
| rozap wrote:
| I don't think this phrase has ever been uttered by a Facebook
| programmer.
| softfalcon wrote:
| I've honestly come to find flaws in most of what I build over
| time. This isn't to say that the products I build or the code I
| write is inherently bad, it's that I keep learning new ways to be
| better over time and deadlines always necessitate making trade-
| offs.
|
| The truly great moments though, are when you go back to a "tried
| and trusted" solution to a problem. In the past I might have used
| a more complex algorithm or framework, but my experience tells me
| to keep it simple and build on something I know is more
| applicable.
|
| Those are the moments when mere knowledge is surpassed by
| experience and that's when I truly feel proud of what I've built.
| josephg wrote:
| I have a friend who's a scholar of history at Oxford. They do a
| lot of 1-on-1 tutoring with students, and he makes his students
| stand and read out their essays to him.
|
| He likes to stop them halfway through and ask ... "does that
| sound right to you?". He does it so much that its become a
| running joke amongst his students.
|
| I love the question. It tugs ever so subtly at your sense of
| pride in your work. I'm tempted to start using it myself.
| ChrisMarshallNY wrote:
| I write a lot of tutorials and explanations[0].
|
| I don't think anyone other than me, reads them, or even give's
| a rodent's backend about it, but I do it, to learn.
|
| Just a little while ago, I wrote a short series on customizing
| SwiftUI Charts[1].
|
| What I learned, made such a difference, that I immediately
| rewrote a dashboard app to use the new techniques. It's working
| great.
|
| [0] https://littlegreenviper.com/miscellany/
|
| [1] https://littlegreenviper.com/series/swiftui-charts-
| gestures/
| ChrisMarshallNY wrote:
| This happens to me, a lot. I now consider it part of my workflow.
|
| I submit something for testing.
|
| It gets ignored by everyone else.
|
| I keep testing like mad, fixing even the smallest "niggles" that
| I can find, re-releasing, and, each time, asking for input.
|
| Which I seldom get.
|
| In the end, I say "Fuck it. Let's ship." but I don't do that,
| until I'm _really sure_ that there 's no more bugs to be found
| _(spoiler: There 's always more bugs to be found, and they pop
| up, immediately after I release)._
|
| I'm _constantly_ testing my work. It never stops, and the
| frequency of my testing, has virtually nothing to do with whether
| or not anyone else tests, or even gives me any feedback.
|
| I use Apple's TestFlight for my team testing. It registers
| -roughly- how many times the app under test is run by individual
| team members.
|
| My own testing is always an order of magnitude greater than the
| next person, and that is just a fraction of how many times I run
| it in the simulator, before releasing the test build.
|
| I'm not especially upset about that, but I don't spare a lot of
| sympathy for folks that complain about something after shipping,
| that they had every chance to catch, beforehand.
|
| But, if they are right, I'll still fix it. I just won't feel very
| sorry for them.
| mattgreenrocks wrote:
| These intangible factors are why I still love software dev over
| 20 years in.
|
| The sixth sense of, "this still can't be right" and really
| getting into the intellectual muck to find out what the proper
| abstraction should be while also balancing what is needed for
| great UX.
|
| It still keeps me up at night (or more specifically, from getting
| deep sleep!) from time to time. And then when you crack it...such
| a rush.
| jmathai wrote:
| This is something I call latent product development. Many times,
| the best solution is not the first one you think of - even though
| it may be one of many correct solutions.
|
| I have found that the best products and product features have
| come from latent thinking. Subconsciously pondering the problem
| and letting the solution arise. An example of this is a solution
| which comes to you in the shower - I don't know why the shower is
| such a hotbed for latent ideas to emerge - someone should study
| that!
|
| What I found most displeasing at large companies is that there's
| no room for latent product development. Everything is rushed.
| Even brand new product ideas, once the machine gets a hold of it,
| gets put on the conveyor belt for new ideas at a predictable and
| imposed rate.
|
| One such example is my last startup. We had wanted to make it
| easy for users not on our platform to collaborate. It was a
| product feature we talked about for a year but nothing ever felt
| right. Until one morning at 2am while I was sleeping on a
| recliner at my sister's house in Mali - it came to me. It also
| turns out that this feature was the first feature we would
| relaunch after being acquired by Western Digital.
___________________________________________________________________
(page generated 2025-01-06 23:00 UTC)