[HN Gopher] Algorithms We Develop Software By
___________________________________________________________________
Algorithms We Develop Software By
Author : ksec
Score : 91 points
Date : 2024-11-10 18:37 UTC (4 hours ago)
(HTM) web link (grantslatton.com)
(TXT) w3m dump (grantslatton.com)
| lunarcave wrote:
| Although I disagree with the arbitrary limit of "one day per
| feature", I agree with the broader point that useful constrains
| drive creativity.
| 082349872349872 wrote:
| The generalisation I would make is: if you think, not just of a
| specific solution, but of the space of possible solutions, it
| makes it easier to find a point in that space which best "fits"
| (space, time, architecture) the program you're working on.
|
| Rather than trying paths in the dark, first look at a map, then
| try a few paths.
| MillironX wrote:
| I fundamentally disagree with the "gun to the head" strategy.
|
| One of the major projects I worked on was a virus genome analysis
| pipeline. Our initial funding was for single-segment virus
| analysis, but about a year into the project, our grant
| collaborators needed to demonstrate multi-segment virus support
| within two weeks. My PI and I agreed on a quick and dirty method
| that would produce the analyses needed and could be done in the
| allotted time. That piece of code was fundamental to how the
| whole pipeline worked, however, and so as the pipeline grew, it
| took on the shape of the "gun to the head" decision we had made
| to the point where other, more essential features of the pipeline
| had to be delayed so I could come up with more workarounds.
|
| There were clearly other issues at play here (scope creep and
| lack of separation of concerns were huge). My time at the lab
| came to a close, but if I were to have a chance to continue that
| project, I would start over from scratch rather than deal with
| the baggage that that one "gun to the head" moment created.
|
| I understand that it's a heuristic and not meant to be taken as
| 100% truth for every situation. I also understand that it's
| trying to avoid that "paralysis by analysis" that's so easy to
| fall into. I just question how useful it truly is as a heuristic,
| especially since it seems to go against the "write everything
| twice" algorithms presented in the rest of the piece.
| tikhonj wrote:
| I'd say it goes _with_ the "write everything twice" heuristic!
| If you're in an environment where you _can_ write things twice
| --you have trust and autonomy and aren 't encumbered by process
| --then writing an initial version as fast as possible gets you
| started faster, lets you play with something concrete and
| leaves you more room for your second version.
|
| My best projects were like that. I'd figure out something quick
| --some combination of reducing scope and doing "things that
| don't scale"--then spend time refining the conceptual design
| and interfaces, and finally rewrite the initial piece based on
| that new design. This can absolutely work better than just
| trying to write something "good" the first time around, but it
| looks wasteful to somebody superficially tracking individual
| "tasks" you're working on.
| qsort wrote:
| > I just question how useful it truly is as a heuristic
|
| I think the author is presenting them as analytical tools that
| might or might not be useful depending on the situation.
|
| Very often when faced with a difficult problem it's hard to
| know where to start attacking. Any idea, even if simplistic and
| wrong, can be useful to start gaining insight on what is going
| to work and why; even just refuting the original idea with a
| clear counterargument might suggest alternative avenues.
|
| OT: this is IMO part of the reason why people like LLMs so
| much. Maybe the answer is trash, but articulating why it's
| trash gets you unstuck.
| neilv wrote:
| These are useful mental tools, to have in your mental toolbox,
| and apply them as they seem appropriate, but don't make a
| religion of any of them.
|
| A related old idea about writing/reworking software _three_
| times: "Do it. Do it right. Do it fast."
|
| Startups provide ample opportunities to get experience with what
| the article calls "gun to your head heuristic". You have to
| decide what and how to compromise.
|
| And, if you want your startup to be successful (not just hit your
| metrics/appearances, and then job hop), you can't just do it like
| school homework (where the only goal is to slip something past a
| grader, and forget about it), but you have to creatively come up
| with a holistically good compromise solution, given all the
| factors. If you do this well, it's creative magic that can't be
| taught, but can be learned, through experience and will.
| n4r9 wrote:
| > A related old idea about writing/reworking software three
| times: "Do it. Do it right. Do it fast."
|
| The version I've heard is "Make it correct. Make it readable.
| Make it performant."
| mattlondon wrote:
| Gun to the head solutions: no tests, no quality, no future
| planning, hacks on top of hacks, tech debt.
|
| As a manager, this "thought exercise" is dangerous. You think it
| is a fun and harmless exercise to your reports to really focus,
| your reports at best think you don't trust them, and at worst
| think you are threatening them with violence (hypothetical or
| otherwise) unless they tell you what they think you want them to
| say. Psychology safety will be at rock bottom pretty quickly.
|
| Nice job you have there, would be a reaaaaalll shame if anything
| hypothetical happened to it huh? Now estimate again, and this
| time don't make me angry <imitates pulling a trigger of an
| invisible gun at someone's head>.
|
| Absolutely terrible behaviour.
| kvemkon wrote:
| Previous discussion:
|
| Algorithms we develop software by (18.08.2024)
|
| https://news.ycombinator.com/item?id=41284409
| ww520 wrote:
| For "write everything twice" I would say write some parts many
| times. You don't have to write everything twice. Most code are
| optimal or good enough already, but you should be willing to re-
| write some parts over and over again.
| w10-1 wrote:
| People learn to work better by reflecting on work. So any
| framework for self-observation is better than none.
|
| I suspect that algorithms as a framework demonstrates the
| structural aspects (e.g., how some searches are more extensive),
| but might hide the driving factors. Indeed, the article examples
| were almost all hacking personality, not technical or process
| solutions.
|
| E.g., most over-engineered solutions are driven by fear, often
| itself driven by critical or competitive environments.
| Conversely, much of the power of senior/staff engineers comes
| from the license to cut corners afforded their experience. Or
| people use the tools they know.
|
| You can't get to great by holding onto good. It's easy to go from
| bad to good, but takes some courage to toss good to start over
| for great. The lesson there is that we stand (hide?) behind our
| work, and we need to let go of it to improve it.
|
| A meta-lesson is that managers need to deeply understand personal
| space of each developer and the social dynamics of the team
| before they can do their job effectively, and a key part of that
| is likely checking in with developers in a way that enhances
| their courage and self-observation instead of making them fearful
| and paranoid.
| dakiol wrote:
| I spent 90% of the time reading and trying to understand the
| business logic behind the code that lies in the place that I
| think I need to put my feature in. So far, no methodology helps
| much with this part of software engineering.
|
| The remaining 10% is rather straightforward.
___________________________________________________________________
(page generated 2024-11-10 23:00 UTC)