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

101–110 of 147 posts

Re: How to build quickly

#101

Post by diggan »

idk1 wrote: post #83

What's interesting about this is, I have always done what the author describes and I just assumed when people wrote (for example) an essay, they would outline all the points and the structure first and then go and fill in each section and refine it over time. Same with ideas and projects, I would do rough outlines, then add fidelity. Same with programing, I'll make an outline and go and refine it all. It's strange, I…

> It's strange, I assumed this so strong I never thought anyone would ever start writing and essay from the beginning without considering more of it, similar to just starting projects or code, I guess they do and it works really well.

It really depends on the task/text at hand. With some things I set out to do, I know I want to reach a concrete goal, then it's easy to do an outline first with the finish point being the known goal, then fill out the middle-pieces.

But at other points, you're not 100% sure what the goal is. Then starting from the beginning and just going with the flow until you reach something that feels like the goal is the way to go, and you'll adjust as you go along.

Other times a mix between the two is optimal, where you think you knew what the goal was, but as you're half-way of filling out the outline, you see that another goal would be better fitted, and you adjust. Or you realize what the goal was all-along as you're nearing the finish, and you go back and adjust.

Basically, there is no single path/process that fits all types of problems or people even. You try out different things until you find the way(s) that fit you and the stuff you typically handle.

Re: How to build quickly

#102

Post by viraptor »

diggan wrote: post #99
viraptor wrote: post #95

Earlier quoted context omitted.

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…

Objects with instance variables don't automatically mean the state is shared. A JS event loop holding onto a simple object with some data is not practically different from a functional event loop with some big context carried between executions. One will have mutations, the other will do effectively the same with tail call and some IO executor. In both you have to add the shared state explicitly, one just makes it way harder.

> 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

That's sampling bias. Where's the thousands of the event driven DOM UI Haskell projects, which doesn't rely on shared state?

Re: How to build quickly

#103

Post by captainkrtek »

1659447091 wrote: post #67
3abiton wrote: post #13

Earlier quoted context omitted.

Do you mind sharing a concrete example of one your project s?

not OP, but I do something similar with polylith[0]. Example structures [1] I'll create the base directories(e.g. www, api, auth). Then the components (e.g config, data, geo, mailer, utils, web etc) In each component I'll make a readme.md with what the component should do. Sometimes this leads to large components and when that happens I break the component directory into smaller ones (e.g. web-client, web-server, web…

Thanks for the write up, this is pretty close to what I do as well.

Re: How to build quickly

#104

Post by eaglefield »

gizmo wrote: post #96

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…

I think that's an overly uncharitable read on this approach. Lots of tasks that have difficult thoughts, that need to be thought before they can be completed, also have phases in which work just has to be done. I'm in the middle of collaborating on an article for submission to a physics journal. I wouldn't term it filler work, but most of the complex thoughts on the problem have been thought through and the work right now is creating a coherent story that goes over our results. An outline method would work fine for this part of the project.

As for the spy novel, i think the outlining is actually quite similar to how Sylvester Stallone described his writing process[0]. You wouldn't fill the outline with generic beats, you would put in your basic plan for the story.

[0] https://www.youtube.com/watch?v=v_xqfkVNwEU

Re: How to build quickly

#105

Post by brabel »

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…

> With other programming paradigms, you can't just knock out all the little pieces without thinking about the other pieces because the state is all tangled up. Which slows you down.

I don't think so. I use the style of programming described in the post, and my code is mostly OOP, but almost entirely without mutable state. You may claim "but that's not OOP", but I would reply that FP is not about having no shared state either (which a lot of people were quick to tell me when I myself made the mistake of confusing immutability with FP, as almost all FP languages allow mutation without much cerimony), that's just something encouraged in FP, and it's something that can be easily encouraged in OOP as well.

Re: How to build quickly

#106

Post by DelaneyM »

I’m constantly amazed at how differently I learned to do things from my father than from school.

My father had all sorts of approaches similar to this, and it’s how I learned to write essays (outside-in) and research (inside-out), and which I later applied to programming. It made school trivial and fun, and it’s what I’m teaching my kids.

Re: How to build quickly

#107

Post by aswegs8 »

DelaneyM wrote: post #106

I’m constantly amazed at how differently I learned to do things from my father than from school. My father had all sorts of approaches similar to this, and it’s how I learned to write essays (outside-in) and research (inside-out), and which I later applied to programming. It made school trivial and fun, and it’s what I’m teaching my kids.

Sounds interesting. Can you provide some more examples?

Re: How to build quickly

#108

Post by strken »

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…

Much of the reason sucky applications suck is because the people who work on them can't change them quickly enough. If you can open up your IDE, grab a flame graph, and chuck out your shitty brute-force algorithm in favour of a dynamic programming one that you thought of in the shower, then one Friday morning you're likely to do just that.

Re: How to build quickly

#109

Post by diggan »

viraptor wrote: post #102
diggan wrote: post #99

Earlier quoted context omitted.

> 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…

Objects with instance variables don't automatically mean the state is shared. A JS event loop holding onto a simple object with some data is not practically different from a functional event loop with some big context carried between executions. One will have mutations, the other will do effectively the same with tail call and some IO executor. In both you have to add the shared state explicitly, one just makes it wa…

> Objects with instance variables don't automatically mean the state is shared.

Agree, but JS's syntax and constructs are almost begging the user to encapsulate their state in classes and instances and share those instances between function calls, rather than passing the data itself around. This is very visible if you browse the various JS APIs as well.

Re: How to build quickly

#110

Post by Keysh »

macintux wrote: post #63
theZilber wrote: post #23

Earlier quoted context omitted.

I agree, I follow the same principle. Also i would like to extend it to - "if you slow down when working on a problem, you might have stumbled upon something unexpected, identify it, and break it down.

I have a similar rule when writing documentation. As soon as I find myself writing something in the passive voice, I know I’ve hit part of the system I don’t really understand. “This event happens” instead of “subsystem A triggers this event”.

Nitpick: “This event happens” is not in the passive voice. “This event is triggered” is in the passive voice — and so is “this event is triggered by subsystem A”. (What you probably mean is “writing something vague or lacking agency”.)
Post reply on HN