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

81–90 of 157 posts

Re: Go ahead, write the “stupid” code

#81

Post by FearNotDaniel »

grugagag wrote: post #29
VladVladikoff wrote: post #9

This is a particularly bad mobile layout. Fix your margins.

At least on IOS, if you double tap the text it’ll fill the viewport just nicely.

Partially true, in that on Safari on iOS, you can use that to enlarge the text. But that doesn't change what's really broken about the layout, which is that it forces the column width to allow only a small number of words-per-line, which is what makes for uncomfortable reading. Another Safari-on-iOS option would be to use the built-in "Reader" function, which re-flows the text into a cleaner layout.

Re: Go ahead, write the “stupid” code

#82

Post by KronisLV »

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'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, having so much friction and analysis paralysis that you never ship is also no good.

Re: Go ahead, write the “stupid” code

#83

Post by yxhuvud »

KronisLV wrote: post #82
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'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.

Re: Go ahead, write the “stupid” code

#84

Post by withinboredom »

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…

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 process I follow for PRs and projects alike. Sometimes you can mix all the steps into a single commit, if you understand the problem&solution domain well. But if you don't, you'll likely have to split it up.

Re: Go ahead, write the “stupid” code

#85

Post by atoav »

One thing I have found to be a very valuable habbit is to first think about what your software has to do on paper and draw some shitty flow charts, lists and other things, without too much care about whether you will do it (especially if it isn't software that you strictly need to do for some reason).

Whether an idea is good or not can often only be judged when it becomes more concrete. The actual finished project is as concrete as it gets, but it takes time and work to get there. So the next best thing is to flesh it out as much as possible ahead and decide based on that whether it is worth doing it that way.

Most people have the bad habit of being too attached to their own ideas. Kill your darlings. Ideas are meant to be either done, shelved or thrown into the bin. It doesn't do any good to roll them around in your head forever.

Re: Go ahead, write the “stupid” code

#86

Post by mkesper »

NotGMan wrote: post #80
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…

In many project it's impossible to know the requirements up front, or they are very vagues. Business requirements != programming requirements/features. Very often both the business requirements and programming requirements change a lot since unless you have already written this one thing, in the exact form that you are making it now, you will NEVER get it right the first time.

You are both right and that's why so many projects are over budget or even fail miserably.

Re: Go ahead, write the “stupid” code

#88

Post by philipwhiuk »

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…

> ... for WEEKS before actually starting to write code...

I'm curious who is in these kinds of jobs. Because I've never seen this in practice.

Re: Go ahead, write the “stupid” code

#89

Post by balamatom »

Scarblac wrote: post #78
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.

I really don't see how your comment has to do with his at all. You're both talking about completely different things, I think.

OK, just to make sure we're on the same page here: you've already tried trying to make the connection, right?

Re: Go ahead, write the “stupid” code

#90

Post by Cthulhu_ »

bitwize wrote: post #38
grugagag wrote: post #28

Earlier quoted context omitted.

Luckily you can still pursue being a musician without all the pressure of having to be successful. On this road, one day you are free to declare your own success to yourself

Maybe if the internet and piracy hadn't fucked artists over, they could have made decent money as a musician selling their work without having to be a major-label superstar. Alas, we do not live in that timeline.

Piracy didn't fuck artists over I think (anecdotal), because it was the precursor to Spotify which has been great for artist discovery. Until the industry / artists caught on and started pushing shit. And the payment model for Spotify is bad, a million streams earns about $3-5K according to a quick google and few actually get that far.

But it's good for discovery, and artists generally don't make much off album sales either; concerts and merchandise is where it's at.

Post reply on HN