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

YOLO-Driven Development Manifesto

andersoncardoso.github.io

Post reply on HN
Print view View original

31–40 of 75 posts

Re: YOLO-Driven Development Manifesto

#31

Post by agentultra »

sherburt3 wrote: post #26
agentultra wrote: post #18

Gotta go fast. Somewhere out there a competitor is eating your lunch. Now is better than later. Later is better than never. Avoid anything that slows you down: thinking, testing, fixing bugs, writing code.

Yeah, for all the garbage codebases that are difficult to maintain there's an entire graveyard of projects that got stuck in analysis paralysis and never got past the hello world phase.

I'm having too much fun imagining a project starting with a single `main.c` with nothing but `printf("Hello, world!\n");` back in 2010 with the project being stalled by endless enterprise architecture meetings.

Re: YOLO-Driven Development Manifesto

#33

Post by unconed »

bobajeff wrote: post #7

>No Documentation, No Problem >Who needs documentation when you have the power of intuition? YOLO-Driven Development encourages you to keep your genius solutions locked away in your head. After all, real developers don’t read documentation; they conjure it from thin air. Apparently this style of development has already become very popular as almost none of the projects that I look at have any documentation at all.

When people say documentation, they could mean:

- a guide to the system to orient yourself

- a reference for the api to look up in

- tutorials to teach it

- examples to copy/paste

Each has a different audience and requires a different structure and writing style.

I once spent a project being the lone wolf against my will, writing tons of documentation with diagrams. Didn't matter, if anything it just made the rest feel insecure and look bad. Everyone says they want docs but often they don't, really, because they don't read them when they do exist.

Re: YOLO-Driven Development Manifesto

#34

Post by scubbo »

unconed wrote: post #33
bobajeff wrote: post #7

>No Documentation, No Problem >Who needs documentation when you have the power of intuition? YOLO-Driven Development encourages you to keep your genius solutions locked away in your head. After all, real developers don’t read documentation; they conjure it from thin air. Apparently this style of development has already become very popular as almost none of the projects that I look at have any documentation at all.

When people say documentation, they could mean: - a guide to the system to orient yourself - a reference for the api to look up in - tutorials to teach it - examples to copy/paste Each has a different audience and requires a different structure and writing style. I once spent a project being the lone wolf against my will, writing tons of documentation with diagrams. Didn't matter, if anything it just made the rest fe…

Amen! https://documentation.divio.com/

Re: YOLO-Driven Development Manifesto

#35

Post by _jal »

pjerem wrote: post #20
alexjplant wrote: post #11

Earlier quoted context omitted.

Some problem domains are inherently complex and the code written for them needs documentation. Some are not but get complicated during the design process and perverted into abominations that wouldn't have required documentation if the design and source were more readable. I'm inclined to say that if you name things obviously and avoid cutesy idioms (AOP/reflection magic, ridiculous object hierarchies, etc) that code…

That’s the theory. In real life, code is written by teams with different levels of skills over multiple periods of time. Expressiveness is a really hard skill that take years to master and that few people have and that you can only learn by yourself.

> Expressiveness is a really hard skill that take years to master

It is worse than that. Being good at expressive, self-documenting code correlates with strong communication skills and empathy. So programmers who get good at it tend to increase the risk of managerial borgification.

Re: YOLO-Driven Development Manifesto

#36

Post by bitwize »

agentultra wrote: post #31
sherburt3 wrote: post #26

Earlier quoted context omitted.

Yeah, for all the garbage codebases that are difficult to maintain there's an entire graveyard of projects that got stuck in analysis paralysis and never got past the hello world phase.

I'm having too much fun imagining a project starting with a single `main.c` with nothing but `printf("Hello, world!\n");` back in 2010 with the project being stalled by endless enterprise architecture meetings.

Maybe that's how the Brillant Paula Bean got written: https://thedailywtf.com/articles/The_Brillant_Paula_Bean

Re: YOLO-Driven Development Manifesto

#37

Post by scubbo »

alexjplant wrote: post #11
bobajeff wrote: post #7

>No Documentation, No Problem >Who needs documentation when you have the power of intuition? YOLO-Driven Development encourages you to keep your genius solutions locked away in your head. After all, real developers don’t read documentation; they conjure it from thin air. Apparently this style of development has already become very popular as almost none of the projects that I look at have any documentation at all.

Some problem domains are inherently complex and the code written for them needs documentation. Some are not but get complicated during the design process and perverted into abominations that wouldn't have required documentation if the design and source were more readable. I'm inclined to say that if you name things obviously and avoid cutesy idioms (AOP/reflection magic, ridiculous object hierarchies, etc) that code…

> code can be quite grokkable with little documentation

Indeed, the code _itself_ can often be understood from reading the code. Documentation is for everything _else_ - explanation of the choices made and motivations when picking a particular design (so that they can be re-evaluated when a redesign is considered), customer-facing onboarding guides, runbooks for how to carry out operational tasks, and so on.

That is - https://brooker.co.za/blog/2020/06/23/code.html

Re: YOLO-Driven Development Manifesto

#38

Post by hk__2 »

bobajeff wrote: post #7

>No Documentation, No Problem >Who needs documentation when you have the power of intuition? YOLO-Driven Development encourages you to keep your genius solutions locked away in your head. After all, real developers don’t read documentation; they conjure it from thin air. Apparently this style of development has already become very popular as almost none of the projects that I look at have any documentation at all.

I started a new job at a small company 3 years ago and the very first thing I did was to create a central documentation repository, using Jekyll for some "fancy" rendering. All you have to do is dump your knowledge in a markdown file. There’s no hard convention; the goal is to have no barrier for entry.

Three years later I can’t say that everybody uses it (I do!), but it has 176 pages in it, from infrastructure to how to run the company to things we learnt on the tech we use. Every time we lose time on a silly bug, we document it there so next time you can save the day with a Ctrl+F. All relevant dev or ops changes are documented here so when you notice some strange pattern in Grafana you can check the log and see that someone updated some config on that day. Every time there’s an incident in production we document how we fixed it.

If tomorrow I leave the company, I know I’ll have very little to write down because everything is already there.

The hard parts are:

* not all people are willing to "waste" time filling the docs. It feels like wasting time but it’s always valuable for your future self as you won’t remember all the things you know today, and when someone joins the company you can point them to the docs instead of spending days explaining stuff

* the more content you have the harder it is to keep it updated. We try to do it but in any case it’s in git so you can check the last commit to know if some content is old or not

* having non-tech people contribute to it. At the beginning they had access to it but were a bit confused by Markdown. Now the marketing docs are in ClickUp (the tasks manager we use). We looked at Notion and similar solutions but for tech people there’s nothing better than a repository cloned on your computer in which you can grep

* when you’re exhausted or frustrated because you spent the day on an issue, it can be hard to motivate yourself to document it. What I do is I keep a file open while I debug an issue and I write down what I do _as I do it_. That way all I have to do at the end is some formatting.

Re: YOLO-Driven Development Manifesto

#39

Post by munk-a »

scubbo wrote: post #37
alexjplant wrote: post #11

Earlier quoted context omitted.

Some problem domains are inherently complex and the code written for them needs documentation. Some are not but get complicated during the design process and perverted into abominations that wouldn't have required documentation if the design and source were more readable. I'm inclined to say that if you name things obviously and avoid cutesy idioms (AOP/reflection magic, ridiculous object hierarchies, etc) that code…

> code can be quite grokkable with little documentation Indeed, the code _itself_ can often be understood from reading the code. Documentation is for everything _else_ - explanation of the choices made and motivations when picking a particular design (so that they can be re-evaluated when a redesign is considered), customer-facing onboarding guides, runbooks for how to carry out operational tasks, and so on. That is…

This is quite true and one of the reasons I hate auto-doc comments. If a function tells me that an input is an integer there's no reason to repeat that information in the header above the function unless that information is then being parsed to produce a more readable form of documentation (i.e. as JavaDoc was originally used). Additionally I personally, though I am happy to concede that it may benefit some people, loathe "$documentId The ID of a Document" style comments. If you are adding more information above and beyond what is relevant from code - especially if that information relates to why you chose this approach over a different one - that is useful information.

Documentation in the form of project planning documents, SOWs, data diagrams etc... - that stuff is always quite valuable, especially since it comes with an understanding that it was valid at a certain point in time (and may no longer be valid) but belies underlying decisions in how things were built and why.

Re: YOLO-Driven Development Manifesto

#40

Post by Tainnor »

sherburt3 wrote: post #26
agentultra wrote: post #18

Gotta go fast. Somewhere out there a competitor is eating your lunch. Now is better than later. Later is better than never. Avoid anything that slows you down: thinking, testing, fixing bugs, writing code.

Yeah, for all the garbage codebases that are difficult to maintain there's an entire graveyard of projects that got stuck in analysis paralysis and never got past the hello world phase.

The problem is that when your codebase is garbage enough, after a couple of years you inevitably get stuck in analysis paralysis because nobody understands how to make changes to the system in a way that doesn't break everything.
Post reply on HN