Live data from Hacker News

Throw away your first draft of your code

ntietz.com

131–140 of 230 posts

Re: Throw away your first draft of your code

#131
Oh FFS.

Writing code is like writing natural language.

It's editing that counts. Not the first draft.

Whether or not you should throw out your first draft is in proportion to its value at getting you to the final draft.

Not some axiom you thought of for a specific use-case and specific code base

Re: Throw away your first draft of your code

#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?

Re: Throw away your first draft of your code

#133
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?

REPL = Read-Eval-Print Loop. So could be iPython or just plain `python` in general, can’t say what OP is using of course

Re: Throw away your first draft of your code

#134
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?

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.

Re: Throw away your first draft of your code

#137
The article describes a potentially useful exercise that might be explored by an organization that has allotted development time for a hack-a-thon or some such. Depending on the size and scale of the projects that a software team typically develops, a more realistic approach might be to spend smaller and more manageable chunks of time as a team evaluating recently developed features/services/apps and directly applying improvements gleaned into the planning of subsequent projects.

Re: Throw away your first draft of your code

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

Agree 99% except this statement:

> Embrace duplication - don't unnecessary add loops or abstractions

I’ll usually make a function or perhaps tiny class as soon as I start reusing bits of code.

Apart from that, agree as stated. At my previous job (Python shop), a lot of the data engineers came from a Java background, and had a tendency to think top-down. Many things were over engineered ‘just because we might need it’:

- Factory classes used only once or twice in entire code base

- Lets make an AbstractReaderInterface because we might want to abstract the file type or location later (while 100% of files are Parquet on S3)

I’ve really enjoyed using dataclasses and Pydantics BaseModels prolifically, and adding type hints (coupled with type checks in CI).

Model the data, write a well structured imperative workflow, set up CI, write unit tests, enforce typing. Add OOP if needed, then close ticket.

Re: Throw away your first draft of your code

#140
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.
Post reply on HN