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

How to build quickly

learnhowtolearn.org

Post reply on HN
Print view View original

91–100 of 147 posts

Re: How to build quickly

#91

Post by MaxBarraclough »

teo_zero wrote: post #25

This is a good way to maximize speed. I'm not convinced it's also a good way to master quality. Rushing ("speedrunning") to a first working version may force you to choose sub-optimal paradigms (algorithms, data types, etc.) that you won't have the time or the will to correct later. I'd even postulate that's why we have so many crap applications today that are first on the market but slow, inefficient and user unfrie…

Agree. In the context of software development, you might choose different tools (programming language especially) if your goal is rapid application development rather than general high quality and long-term maintainability. You can't easily go back and change those decisions.

This is one of the perennial software development questions: to what extent can you improve an existing solution with a flawed or now-inappropriate architecture or implementation? This topic turned up a couple of months ago. [0]

[0] https://news.ycombinator.com/item?id=40623263

Re: How to build quickly

#92

Post by andai »

I think there's tremendous value in keeping and publishing the outline itself. I know this because I just spent a week turning a book back into an outline and discovered that there was a great demand for it.

Re: How to build quickly

#95

Post by viraptor »

jimbokun wrote: post #16

This is incredibly simple yet incredibly powerful, and something that everyone who becomes proficient at delivering things of value learns eventually, but is rarely taught so succinctly. By the way, for the programming case, this is a big part of the reason functional programming is so powerful. Avoiding shared state allows you to write your outline of smaller and smaller pieces, then write each piece as a stateless…

To be fair to other styles, we generally learned already that shared state is bad. It's avoided in basically every language/service these days. It may be enforced more strictly with functional programming. But "With other programming paradigms, you can't just knock out all the little pieces without thinking about the other pieces" is taking it too far. For example, you want to add email sending to your app? The library for it is a little piece of software independent of the rest.

Re: How to build quickly

#96

Post by gizmo »

This reads like a strategy for creating filler content. If you have to write a school essay an outline helps you churn through all the BS. By contrast, when you try to write something meaningful almost all effort goes into two things (a) figuring out what you actually have to say and (b) finding the right words to express it. School essays are written by people who don't have anything to say. Intro fluff. Chapter one fluff. Conclusion fluff. It's not real writing. You can speedrun it because no thinking is involved.

The same applies to fluff software, but only to fluff software. If you have to create a page with a dozen buttons with a bunch of click handlers, hook those up to basic AJAX calls, then yes, you can speedrun that as well. Because it's extremely easy work that involves no thinking.

Many things in life are kind of mundane and tedious. Fake school work, taxes, cleaning, ironing, to give just a few examples. And having strategies to blast through that kind of work effectively is useful. But these strategies absolutely unhelpful when you're trying to do anything creative or difficult.

You can't write a great spy novel with an outline like: 'introduce spy character', 'successful mission 1 in present time', 'flash back to failed earlier mission', 'introduction of big bad guy', 'flash back to tragic backstory', 'spy gets assigned special mission only his handler knows about'. Filling out an outline like this produces an uninspired, boring, formulaic trash. You end up with bad airport reading, the equivalent of AI slop.

To give another example: PG spends MONTHS on a single essay. He is not bottlenecked by a missing outline. Speedrunning the wiring process doesn't help. Figuring out exactly what you want to say is the hard part. Putting words on paper is trivial in comparison.

Re: How to build quickly

#97

Post by RamblingCTO »

lee wrote: post #27
teo_zero wrote: post #25

This is a good way to maximize speed. I'm not convinced it's also a good way to master quality. Rushing ("speedrunning") to a first working version may force you to choose sub-optimal paradigms (algorithms, data types, etc.) that you won't have the time or the will to correct later. I'd even postulate that's why we have so many crap applications today that are first on the market but slow, inefficient and user unfrie…

I think it's the opposite. I think quality often comes from evolution and iteration. There've been so many projects where I get stuck because I want to maximize quality, so I get writer's block. The worse, is that sometimes you'll try to perfect something on your project that ultimately isn't of great value. Building something quickly, and then iterating to perfect it seems to work for many people.

And what many people of either side forget: both are not a one size fits all. There are some things that need planning up front (a car or a rocket) and some things can be done agile and iteratively. Likewise, some things can't be made via solopreneurship/indiehacking and some things can't be achieved with classic VC-backed entrepreneurship. There's a time for both.

Re: How to build quickly

#98

Post by twelvechairs »

2 counterpoints

- if you are pushing technical boundaries you may need to prove something is achievable before you go back and do the comparatively easy stuff (build the website, set up the company etc.)

- As context switching creates a huge cognitive load it can be useful to create discrete chunks of work and not just jump around all the time.

Re: How to build quickly

#99

Post by diggan »

viraptor wrote: post #95
jimbokun wrote: post #16

This is incredibly simple yet incredibly powerful, and something that everyone who becomes proficient at delivering things of value learns eventually, but is rarely taught so succinctly. By the way, for the programming case, this is a big part of the reason functional programming is so powerful. Avoiding shared state allows you to write your outline of smaller and smaller pieces, then write each piece as a stateless…

To be fair to other styles, we generally learned already that shared state is bad. It's avoided in basically every language/service these days. It may be enforced more strictly with functional programming. But "With other programming paradigms, you can't just knock out all the little pieces without thinking about the other pieces" is taking it too far. For example, you want to add email sending to your app? The libra…

> To be fair to other styles, we generally learned already that shared state is bad. It's avoided in basically every language/service these days.

I don't know how true that really is. JavaScript added `class` relatively late in it's lifespan, and most JavaScript/TypeScript projects use `class` to hide shared state/mutations behind that interface, in the name of `encapsulation`, rather than just passing stateless data from function to function.

Both patterns obviously has their places, no silver bullets and all that, but you'll have a hard time finding any relatively popular JS/TS project that doesn't overtly rely on shared state one way or another.

Re: How to build quickly

#100

Post by gchamonlive »

_heimdall wrote: post #59
gchamonlive wrote: post #47

Earlier quoted context omitted.

What I do for my blog is I write everything at once. Then I figure out where to put images, then I publish it! It makes me go back and read it carefully since I have already published it, and then I polish, rewrite sections and add stuff that I missed.

I have done something similar on the past and I was very happy with the results. At the time I was starting up a consulting business and got the first few gigs directly from engagement with my blog. I also time boxed myself when writing. I wouldn't write unless I had a really clear topic in mind, then I'd give myself an hour to get it published. A few times I ran out of time and ended it with a "follow-up post coming…

Follow up posts are important! It takes the pressure off having to cram everything into a single publication. Nice!
Post reply on HN