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

141–150 of 157 posts

Re: Go ahead, write the “stupid” code

#141

Post by amatecha »

yxhuvud wrote: post #83
KronisLV wrote: post #82

Earlier quoted context omitted.

> I'd argue to write the "stupid" code to get started, get that momentum going. Yes and no, depending on how dependent you become on that first iteration, you might drown an entire project or startup in technical debt. You should only ever just jump in if: A) it's a one off for some quick results or a demo or whatever B) it's easy enough to throw away and nobody will try to ship it and make you maintain it That said,…

or C): You cultivate a culture of continuous rewrite to match updated requirements and understandings as you code. So, so many people have never learned that, but once you do reach that state, it is very liberating as there will be no more sacred ducks. That said, it takes quite a bit of practice to become good enough at refactoring to actually practice that.

Yeah, I think it's actually a great skill to be comfortable with not getting attached to your code, and being open to refactoring/rearchitecting -- in fact, if you have this as a common expectation, you may get really good at writing easily-maintainable code. I have started putting less and less "clever optimizations" into my code, instead opting for ease of maintainability, and onboarding for new team members to join up and start contributing. Depends on the size of project/team (and the priorities therein), but it helps me later too when I have to change functionality in something I wrote anywhere from 6-48 months ago :)

Re: Go ahead, write the “stupid” code

#142

Post by withinboredom »

captainkrtek wrote: post #123
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…

This is fantastic, but how do you communicate this within your organization to peers, and not allow the pace of the organization to interfere? For example, can see many teams stopping after step 1.

And in some cases, there isn't a reason to continue to step 2 or 3. Software generally has a shelf-life. Most businesses write code that should be rewritten every 5-10 years, but there's that kernel of code that _never_ changes... that's the code that really needs step 2 and 3. The rest, probably only runs occasionally and doesn't explicitely need to be extremely tested and fast.

Re: Go ahead, write the “stupid” code

#143

Post by withinboredom »

pixl97 wrote: post #131
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…

This somewhat depends on how big of program/application you are making. Again, this is something I set bite enterprise style applications quite often as they can be pushed out piecemeal where you can get things like the datastore/input APIs/UI to the customer quickly, then over the next months things like reporting, auditing, and fine grained access controls get put in, and suddenly you find yourself stuffed working…

This is where 'knowing the domain' lets you put a ton of stuff in all at once. If you have no clue what you're doing, you have to learn the lesson your talking about. As long as you can avoid joining teams that haven't learned this lesson (and others like it), you'll be fine.

I once joined a team where they knew they were going to do translations at some point ... and the way they decided to "prepare" for it was absolutely nonsensical. It was clear none of them had ever done translations before, so when it came time to actually do the work, it was a disaster. They had told product/sales "it was ready" but it didn't actually work -- and couldn't ever actually work. It required redesigning half the architecture and months of effort across a whole team to get it working. Even then, some aspects were completely untranslatable that took an additional 6-8 months of refactoring.

So, another lesson is to not try to engineer something unless your goal is to "get it working". If you don't need it, it is probably still better to actually wait until you need it.

Re: Go ahead, write the “stupid” code

#144

Post by balamatom »

braebo wrote: post #109
balamatom wrote: post #71

Earlier quoted context omitted.

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.

>unhinged and unprovoked

I could of course explain exactly what my words "hinge" on, and what "provokes" them. I've found that this does not create understanding where previously it was lacking. So instead let's talk about what you said.

Two of your words I consider harmful and insulting:

>is seemingly

What the hell?!

...oh, right:

- If you say "X is Y", you gotta back it up. Scary!

- If you say "X seems to me Y", you gotta justify your perceptions. Nasty!

- But saying "X is, seemingly, Y", that's totally safe! Because it's bullshit. It posits a statement as true knowledge and elidies the need for justification outright, on the syntactic level.

What's worse, you probably didn't even notice you were doing this. You just picked up the pattern from people who looked like they had what you wanted.

That cognitive habits like yours are so widely accepted as "normal", is exactly why I'm guessing that CBT (or, for that matter, parent poster's wireheading suggestions) are probably going to be super effective on you, not kidding.

If you were to give those a shot, anyway. Instead of, you know, just stating existences of literatures at people. Also unless your current state of mind wasn't already achieved by similar methods. In any case, do report back!

Re: Go ahead, write the “stupid” code

#145

Post by balamatom »

cardanome wrote: post #122
braebo wrote: post #109

Earlier quoted context omitted.

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.

CBT and mindfulness can help with SOME problems. It is great when it does but it also can work less well or even harmful for other problems. Especially people that are prone to rumination don't benefit much from it, they need the opposite of mindfulness. The unhinged part was to imply that people can just choose to be happy under any circumstance which is obviously magical thinking.

>to imply that people can just choose to be happy under any circumstance which is obviously magical thinking

Worse, I'm afraid. It's ideological thinking of the basest sort.

Magical thinking at least lets a person see that their bullshit isn't working, potentially even walk it back, correct themselves.

In ideological thinking, you gotta act as if the impossible wish has already come true. Reality says otherwise? Well, wish harder - or else. That's ideological thinking for ya.

And those are only two of the cards in that deck. I've observed that with sufficient mental self-mutilation, people can in fact choose to be happy under any circumstance. Occasionally even at no cost to innocents. (Though rarely - who'd permit them a clean getaway?)

Woulda had a field day with figuring out what complexes are puppetting AdieuToLogic, if their most coherent argument wasn't "fuck off" - pardon, "full stop".

Re: Go ahead, write the “stupid” code

#146

Post by Ntrails »

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…

> These days, I think the pendulum has swung too far from thinking about the program, maybe mapping it out a bit on paper before writing code.

Sometimes I think about code structure like a sudoku where you have to eliminate two possibilities by following through what would happen. Writing the code is (to me) like placing the provisional numbers and finding where you have a conflict. I simply cannot do it by holding state in my head (ie without making marks on the paper).

It could definitely be a limitation of me rather than generally true.

Re: Go ahead, write the “stupid” code

#147

Post by balamatom »

balamatom wrote: post #144
braebo wrote: post #109

Earlier quoted context omitted.

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.

>unhinged and unprovoked I could of course explain exactly what my words "hinge" on, and what "provokes" them. I've found that this does not create understanding where previously it was lacking. So instead let's talk about what you said. Two of your words I consider harmful and insulting: >is seemingly What the hell?! ...oh, right: - If you say "X is Y", you gotta back it up. Scary! - If you say "X seems to me Y", yo…

*elides #noprocrast

Re: Go ahead, write the “stupid” code

#148

Post by jasonjmcghee »

sokoloff wrote: post #97
jasonjmcghee wrote: post #56

Earlier quoted context omitted.

Knowing hard requirements up front can be critical to building the right thing. It's scary how many "temporary" things get built in top of and stuck in production. Obviously loose coupling / clear interfaces can help a lot with this. But an easy example is "just build the single player version" (of an application) can be worse than just eating your vegetables. It can be very difficult to tack-on multiplayer, as oppos…

I once retrofitted a computer racing game/sim from single-player to multi-player. I thought it was a masterpiece of abusing the C pre-processor to ensure that all variables used for player physics, game state, inputs, and position outputs to the graphics pipeline were guarded with macros to ensure as the (overwhelmingly) single-player titles continued to be developed that the code would remain clean for the two title…

Pain aside, this sounds like an absolute blast.

Re: Go ahead, write the “stupid” code

#149

Post by captainkrtek »

withinboredom wrote: post #142
captainkrtek wrote: post #123

Earlier quoted context omitted.

This is fantastic, but how do you communicate this within your organization to peers, and not allow the pace of the organization to interfere? For example, can see many teams stopping after step 1.

And in some cases, there isn't a reason to continue to step 2 or 3. Software generally has a shelf-life. Most businesses write code that should be rewritten every 5-10 years, but there's that kernel of code that _never_ changes... that's the code that really needs step 2 and 3. The rest, probably only runs occasionally and doesn't explicitely need to be extremely tested and fast.

Agreed. Having worked the range of boring backend systems to performance critical embedded systems, only few areas are worth optimizing for, and we always let data inform where to invest additional time.

I much prefer a code base that is readable and straightforward (maybe at the expense of some missed perf gains) over code that is highly performant but hard to follow/too clever.

Re: Go ahead, write the “stupid” code

#150

Post by theshrike79 »

captainkrtek wrote: post #123
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…

This is fantastic, but how do you communicate this within your organization to peers, and not allow the pace of the organization to interfere? For example, can see many teams stopping after step 1.

You write a tech debt ticket and move on.

I've used a similar mantra of "make it work, make it pretty, make it fast" for two decades.

I think I've had to get to step 3 once and that was because the specs went from "one device" to "20 devices and two factories" after step 1 :D

Post reply on HN