Live data from Hacker News

Throw away your first draft of your code

ntietz.com

191–200 of 230 posts

Re: Throw away your first draft of your code

#191
If waterfall is:

  specify-design-code-test
Then agile TDD with prototype and discard/refactoring is:

  specify-test-code-design-recode
A POC is different from a prototype. A POC helps to define the problem space, but it may also suggest a better initial design (identify useful abstractions):

  poc-specify-test-design-code

Re: Throw away your first draft of your code

#192
post #94

Earlier quoted context omitted.

Speaking personally my urge to rewrite at least partially comes from not truly understanding the problem and the solutions to it until I've written something reasonably functional. It doesn't matter how much time I put into sitting and theorizing, there's always things I didn't anticipate and assumptions that turned out to be incorrect. This usually means that rewrites are significant improvements across the board, e…

Yeah, I find that the desire to rewrite often comes from the final (working) solution having poor code ergonomics. It's not necessarily that it's wrong, it's that it's awkward or clumsy to understand/use, because my mental model of how it worked didn't take into account the actual practical day to day usage of the code.

I get around that by writing the API first, with usage code examples and all, Or in a GUI app, the UI first. I'll iterate there if needed, and only rewrite internals if it's truly bad or I think it will cause a problem later.

A lot of situations where the code is so nasty I actually have wanted to rewrite... I wind up just throwing it away instead.

Like, one of my happiest days in coding was throwing out some code to support JACK and going all in on Pipewire. Another happy day was replacing some DIY code with a GPL licensed library, deciding that I really didn't need the option to do proprietary stuff anywhere near as much as I wanted less thinking about gstreamer.

"If it's hard to explain, it's probably a bad idea".... If I try a bunch of API variations and I can't come up with anything that doesn't require learning 3 new algorithms to use... Maybe I'm not making a library or an abstraction, I'm making a proof of work hashing scheme that users have to do manually to access an encrypted version of the complexity I'm hiding, and I need to stop before I make z80 assembly in JSON to autogenerate Vue templates that render to cobol.

Re: Throw away your first draft of your code

#193

Earlier quoted context omitted.

Game companies implicitly do this, throwing out old versions of their code (sort of). You make a game. Ship it. Start on a new game. Your previous game is now sort of a practice run for making a new game from scratch. Continue, ad infinitum. It's weird: you rarely have to maintain something for 20+ years, and you get to always improve and iterate on how you did things last time. But, are you training yourself to writ…

Minecraft is reaching that 15+ year mark

That's the most successful game of all time, hardly a typical case.

Re: Throw away your first draft of your code

#194
post #129

As an ML-focused python dev I have never been able to break the habit of REPL-driven development, but I find it works really well for "building code that works" rather than coming up with a tower of abstractions immediately. A typical python development workflow for me is: * Start with a blank `main` file and proceed linearly down the page, executing as I go. * Gradually pull out visually awkward chunks of code and p…

I don't understand why you consider loops an abstraction. They are some of the most basic building block.

People are getting caught up on the loops thing. All I meant was in my line of work I often end up with many special cases of general processes. Writing a loop prematurely always bites me - I end up writing control flow for handling the one-offs, it somehow always becomes more obtuse than just listing things out literally.

Re: Throw away your first draft of your code

#195
post #132
post #129

As an ML-focused python dev I have never been able to break the habit of REPL-driven development, but I find it works really well for "building code that works" rather than coming up with a tower of abstractions immediately. A typical python development workflow for me is: * Start with a blank `main` file and proceed linearly down the page, executing as I go. * Gradually pull out visually awkward chunks of code and p…

by REPL here you mean jupyter notebook?

I usually use VS code and the "interactive" python functionality (not jupyter). I highlight code and execute just that code with a hotkey. Works just as well with any kind of vim-slime like functionality.

Re: Throw away your first draft of your code

#196
post #132

Earlier quoted context omitted.

by REPL here you mean jupyter notebook?

Not OP but I often code in the REPL for python as well. Sometimes I'll stub out my code and just drop into an interactive debugger where I'm writing the next section. In the python debugger, if you type `interact`, it'll give you the normal python repl. This combined with the `help` and `dirs` are super useful for learning new frameworks/libraries and coding with your actual data.

Good idea to code in the debugger. Going to try that.

Re: Throw away your first draft of your code

#197
post #129

As an ML-focused python dev I have never been able to break the habit of REPL-driven development, but I find it works really well for "building code that works" rather than coming up with a tower of abstractions immediately. A typical python development workflow for me is: * Start with a blank `main` file and proceed linearly down the page, executing as I go. * Gradually pull out visually awkward chunks of code and p…

> * Gradually pull out visually awkward chunks of code and put them into functions with no arguments at the top of the file.

I have seen scientific code written in this manner written in both Python and Fortran. This may be some intuitive way to start off, and even complete the task at hand.

But for people trying to read, understand, and realistically, debug your code, this complicates things.

Because each no-argument function can only work via its side effects. Your script becomes a succession of state transitions, and to understand it, you have to keep the intended state after each step in your head.

And in case of a mistake, you can't even call these functions individually via passing their intended arguments using the REPL. You have to set up all the state beforehand manually, call your no-arg function, observe the state afterwards. Which becomes more awkward the further down you are in your script, since all your dependencies are implicit and possibly even completely undocumented.

Re: Throw away your first draft of your code

#198
post #155

Earlier quoted context omitted.

I also primarily write ML-focused Python. For me, having originally learned R and C at the same time, nothing has ever surpassed RStudio as a dev environment. For the past several years my preferred setup has been tmux and Vim with vim-slime in one pane and IPython in the other. (Personally, and speaking only for myself, I hate Jupyter notebooks with a burning passion. I think they are one of the worst things ever to…

Why do you hate Jupyter notebooks so much that it reaches “worst thing to ever have happened“ status? Why do you love R Studio so much? (I’ve never used it, so no judgment)

If like to know too. I learned python in jupyter notebooks. It makes experimenting and incremental development much easier (IMO) provided you remember to account for the current state of the notebook, which sometimes has me pulling my hair out.

Re: Throw away your first draft of your code

#199
post #10

The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an inherent attractiveness in the idea of starting fresh from a clean slate. Except, more likely than not, you'll soon find yourself in a similar situation to the one you started from. The fundamental problem is that it is easy to underestimate the edge cases. Sur…

RTFA

Re: Throw away your first draft of your code

#200

Earlier quoted context omitted.

Why do you hate Jupyter notebooks so much that it reaches “worst thing to ever have happened“ status? Why do you love R Studio so much? (I’ve never used it, so no judgment)

If like to know too. I learned python in jupyter notebooks. It makes experimenting and incremental development much easier (IMO) provided you remember to account for the current state of the notebook, which sometimes has me pulling my hair out.

> provided you remember to account for the current state of the notebook

Notebook style development is considered an anti pattern in most situations for this reason. It is too easy to execute out of order. Even the original parent of this thread said they recite the entire notebook every time to ensure they catch these issues. But, it’s not perfect and you can have leftover state this way too if you’re not careful.

My guess is that this is the reason the GP here is so against them. I find them helpful for data exploration, but that’s it.

Post reply on HN