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

61–70 of 147 posts

Re: How to build quickly

#61

Post by throwaway4aday »

spencerchubb wrote: post #33
andrewstuart wrote: post #6

This message is suspiciously like being told to draw the outline of an owl then draw the rest of the fucking owl. https://seths.blog/2014/01/how-to-draw-an-owl/ The word recursively does a lot of work in the post. Every project I go into thinking I can do it quick and it never works that way because the minimal viable or minimum lovable thing is a long way from the minimum actual concept of what I have in mind. I fee…

The post is meant for people who already know how to draw an owl, and want to draw owls quicker.

You can only learn how to draw owls by drawing owls, repeatedly. The more owls you draw, the better you will get so it helps to draw quickly and often.

Re: How to build quickly

#62

Post by tzs »

I did something like that the first time I had to write a device driver, but I did it kind of stupidly.

It was in college and I had a part time job doing doing system administration and programming for the high energy physics department. They had an RX02 8" floppy drive that they wanted to use on their VAX 11/780 which was running Unix/32V and I was assigned to write the driver.

I basically started with a C file that just had empty functions for all the functions that I knew Unix expected a driver to have, and then started filling those functions with comments recording what I had figured out that they had to do.

Each started with just a few high level comments. Then I'd add more comments breaking those down, and so on, until I finally had all the information I'd need in there and could start coding.

That's when I then did something stupid. As I started implementing the things the comments described I replaced the comments with the code.

I got about half way through before I realized that I should adding the code below the comments rather than replacing the comments.

Re: How to build quickly

#63

Post by macintux »

theZilber wrote: post #23
tbm57 wrote: post #12

I'm not as much of an overhead strategist, but I do have a rule that I follow that matches this article: if I hesitate to start working on a problem because it seems too difficult, it's because that problem has not yet been broken into small enough parts.

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”.

Re: How to build quickly

#64

Post by intelVISA »

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…

Yes. Ideally a codebase is just a monorepo of pure functions and apps are simply the control flow that weaves them. Write reusable libraries not microservices (silos).

Sadly incentives are not aligned for this at scale - easier to buy cloud SaaS n+1 whose sales team insist "this $badware solves a Hard Problem" while your devs sit in ceremonies all day.

Re: How to build quickly

#65

Post by truetraveller »

This is almost a 100% "divide and conquer", but a good article with concrete examples.

Definition : "A divide-and-conquer algorithm recursively breaks down a problem into two or more sub-problems of the same or related type, until these become simple enough to be solved directly. The solutions to the sub-problems are then combined to give a solution to the original problem."

Re: How to build quickly

#66

Post by matheusmoreira »

> DO NOT PERFECT ANYTHING UNTIL DONE

> without caring about quality AT ALL

I really need to master this. I spend absurd amounts of time thinking about the littlest things. It can take a long time for me to mentally accept that the code is fine and ready to be committed to the repository and published.

Re: How to build quickly

#67

Post by 1659447091 »

3abiton wrote: post #13
captainkrtek wrote: post #7

This is a great article that summarizes a method I’ve already used for my work over the years. When writing a new project from scratch ill make a bunch of structure (defining modules, writing pseudo code) then start to fill things out piece by piece. Often times ill need to adjust the structure as I go but helps for building a mental model of a new project (at least for me)

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-routes, web-middleware etc) and add a readme to those. Then (what I planned to do but usually skip) add function names to the interface file based on the readme, then work on the implementation (I usually end up going straight to this and wish I had created the interface "guide" cause now I've gone off track and need to clean it up)

Not sure if this is a common way to polylith, or if I'm doing it wrong. It helps me keep track better than trying to search through outlines and notes that are scattered all over the place, or in an app I dont feel like opening or logging into, usually ending with me re-writing the same thing 2-3+ times.

[0] https://polylith.gitbook.io/polylith

[1] https://cljdoc.org/d/polylith/clj-poly/0.2.20/doc/production...

Re: How to build quickly

#68

Post by iman453 »

allenu wrote: post #29

This is how I work on my projects as an indie dev. When I start working on something significant (a new feature, for instance), I'll create a markdown file that has a summary of what I'm trying to achieve and then a TODOs section which turns into this massive outline of all the tasks that I'll need to do to complete the work. At first, the outline just has a few tasks that are fairly high-level, but as I dive into ea…

Sounds like you’re not looking for an app since a text file works well, but I’ve been using Godspeed and it’s been amazing for this kinda workflow.

Re: How to build quickly

#69

Post by kmoser »

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…

It can definitely lead to under-optimized code, but on the flip side, prematurely optimizing can waste time and lead to overly complex code that is difficult to maintain. The key is to know how much to optimize and when.

The point of the article isn't to show you how to produce a shoddy first version as soon as possible, but rather how to avoid things like analysis paralysis and prematurely focusing on style over substance. This applies not just to code but to pretty much anything you create.

By completing a skeleton as soon as possible, you get a better idea of the different components you'll need and how they will interact, before you flesh any of them out. I think there is real value in this approach.

Re: How to build quickly

#70

Post by begueradj »

There is the spirit of "divide and conquer" in this method. Which thing is good.

However, I do not know how to follow this advice: "DO NOT PERFECT AS YOU GO. This is a huge and common mistake" because, when you develop something critical and apply TDD, testing actually is a synonym of perfecting your approach to solving an issue. Not to mention that testing comes before code itself: it pushes you to think carefully, and come out with the best strategy before iterating any further.

Post reply on HN