Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go ahead, write the “stupid” code

spikepuppet.io

Post reply on HN
Print view View original

101–110 of 157 posts

Re: Go ahead, write the “stupid” code

#101

Post by gverrilla »

AdieuToLogic wrote: post #43
analog31 wrote: post #21

>>> When I finished school in 2010 (yep, along time ago now), I wanted to go try and make it as a musician. I figured if punk bands could just learn on the job, I could too. But my mum insisted that I needed to do something, just in case. Amusing coincidence. I also wanted to be a rock star, or at least a successful working musician. My mom also talked me out of it. Her argument was: If there's no way to learn it in…

> Amusing coincidence. I also wanted to be a rock star, or at least a successful working musician. > I still play music, but not full time, and with the comfort of supporting myself with a day job. Some people say; Pursue your dream or you will regret it. This is said by people who regret their own choices. Other people say; Don't make your dream a job, because all it will be is a job and no longer special. This is s…

Easy to say it's immaterial when you're probably an american or european with plenty of material comfort. When was the last time you didn't eat for lack of food, for instance? Adieu to logic, indeed.

Re: Go ahead, write the “stupid” code

#103

Post by rafaelbeirigo »

Yesterday I spent the entire day working on a lib to create repos in Github from inside Emacs. It was the first time in 3y that I had touched it. When googling, I saw potential candidates that were much better than my simple one. But I kept going, for the pleasure of making my own thing. I learned a lot, and felt very accomplished, even if, at the end, it was messy, and I'll have to go back and reorganize it. It feels like making _my_ thing, even if it is drawing my copy of Monalisa.

Re: Go ahead, write the “stupid” code

#104

Post by mananaysiempre »

withinboredom wrote: post #84
tacitusarc wrote: post #55

Earlier quoted context omitted.

I think this is mostly true, but also I’d highlight the necessity of having a mental model, and iterating. I think it is common for a programmer to just start programming without coming up with any model, and just try to solve the problem by adding code on top of code. There are also many programmers who go with their first “working” implementation, and never iterate. These days, I think the pendulum has swung too fa…

My philosophy: 1. Get it working. 2. Get it working well. 3. Get it working fast. This puts the "just get it working" as the first priority. Don't care about quality, just make it. Then, and only once you have something working, do you care about quality first. This is about getting the code into something reasonable that would pass a review (e.g., architectually sound). Finally, do an optimization pass. This is the…

> Finally, do an optimization pass.

Depending on how low-level your code is, this... may not work out in those terms.

In other words, I’d say that if you actually want good software—and that includes making sure its speed falls within a reasonable factor of the napkin-math theoretical maximum achievable on the platform—your three steps can easily constitute three entire rewrites or at least substantial refactors. You might well need to rearchitect if the “working well” version has multiple small loops split by domain-level concern when the hardware really wants a single large one, or if you’re doing a lot of pointer-chasing and need to flatten the whole thing into a single buffer in preorder, or if your interface assumes per-byte ops where SIMD can be applied.

This is not a condemnation of the strategy, mind you. Crap code is valuable and I wish I were better at it. I just disagree that the transition from step 2 to step 3 can be described as an optimization pass. If that’s what you limit yourself to, you’ll quite likely be forced to leave at least an order of magnitude’s worth of performance on the table.

And yes, most consumer software is very much not good by that definition.

(For instance, I’m expecting that the Ladybird devs will be able to get their browser to work well for daily tasks—which I would count a tremendous achievement—but I’m not optimistic about it then becoming any faster than the state of the art even ten or fifteen years ago.)

Re: Go ahead, write the “stupid” code

#105

Post by RossBencina »

tacitusarc wrote: post #55
amatecha wrote: post #50

For sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to…

I think this is mostly true, but also I’d highlight the necessity of having a mental model, and iterating. I think it is common for a programmer to just start programming without coming up with any model, and just try to solve the problem by adding code on top of code. There are also many programmers who go with their first “working” implementation, and never iterate. These days, I think the pendulum has swung too fa…

Totally agree. Iteration is key. Mapping things out on paper after you've written the code can also be illuminating. Analysis and design doesn't imply one-and-done Architect -> Implement waterfall methods.

Re: Go ahead, write the “stupid” code

#106

Post by moring »

brunooliv wrote: post #59

I both agree and disagree with this post, but I might be misunderstanding it. Near the end, it states: “Enjoy writing it, it doesn’t have to be nice or pretty if it’s for you. Have fun, try out that new runtime or language.” It doesn’t have to be nice or pretty EVEN if it’s NOT for you. The value in prototyping has always been there and it’s been very concrete: to refine mental models, validate assumptions, uncover g…

I feel like this is the time to mention "How Big Things Get Done", by Bent Flyvbjerg. "Long planning vs. start prototyping" is a false dichotomy. Prototyping IS planning.

Put another way, refining tickets for weeks isn't the problem; the problem is when you do this without prototyping, chances are you aren't actually refining the tickets.

Planning stops when you take steps that cannot be reverted, and there IS value in delaying those steps as much as possible, because your project then becomes vulnerable to outside risk. Long planning is valuable because of this; it's just that many who advocate for long planning would just take a long time and not actually use that time for planning.

Re: Go ahead, write the “stupid” code

#107

Post by withinboredom »

mananaysiempre wrote: post #104
withinboredom wrote: post #84

Earlier quoted context omitted.

My philosophy: 1. Get it working. 2. Get it working well. 3. Get it working fast. This puts the "just get it working" as the first priority. Don't care about quality, just make it. Then, and only once you have something working, do you care about quality first. This is about getting the code into something reasonable that would pass a review (e.g., architectually sound). Finally, do an optimization pass. This is the…

> Finally, do an optimization pass. Depending on how low-level your code is, this... may not work out in those terms. In other words, I’d say that if you actually want good software—and that includes making sure its speed falls within a reasonable factor of the napkin-math theoretical maximum achievable on the platform—your three steps can easily constitute three entire rewrites or at least substantial refactors. You…

Some optimization problems require an entire PHD dissertation and research budget to actually optimize, so some algorithms require far more effort applied to this than is reasonable for most products. As mentioned, sometimes you can combine these all into one step -- when you know the domains well.

Sometimes, it might even be completely separate people working on each step... separated by time and space.

In any case, most software generally stops at (2) simply due to the fact that any effort towards (3) isn't worth the effort -- for example, there's very little point in spending two weeks optimizing a report generation that runs in the middle of the night, once a month. At some point, there may be, but usually not anytime soon.

Re: Go ahead, write the “stupid” code

#108

Post by Vinnl »

amatecha wrote: post #50

For sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to…

This is also why I'm not a fan of the "software architect" that doesn't write code, or at least not the code that they've architected.

Re: Go ahead, write the “stupid” code

#109

Post by braebo »

balamatom wrote: post #71
AdieuToLogic wrote: post #57

Earlier quoted context omitted.

No, my point is happiness is a choice. There is no sociopolitical statement, no call-to-arms, no pontification as to the measure of one's life, no generational implications. There is an existential consideration, but not of the nature your post implies. Happiness is an individual choice, available to us all at any time. Full stop.

Yeah, no. What you're promoting is a deeply narcissistic worldview, and I hope either the cure or the consequences reach you soon. Though maybe those are going to present as the same thing.

They’re not entirely wrong, and your comment is seemingly unhinged and unprovoked… but there’s a lot of literature on stuff like mindfulness, CBT, and the impact thoughts can have on one’s emotions, especially happiness.

Re: Go ahead, write the “stupid” code

#110

Post by braebo »

noduerme wrote: post #24

I like this philosophy. It's interesting to me that the author writes about trying deno, specifically out of curiosity for compiling binaries with it, because that is something that's been specifically tickling the back of my mind for awhile now, but I've had no real reason to try it. I think this gave me the motivation to write some "stupid" code just to play with it.

Buns faster and the binaries are a bit smaller last I checked.
Post reply on HN