First do it - then do it right - then do it better.
Throw away your first draft of your code
221–230 of 230 posts
Re: Throw away your first draft of your code
#222Earlier quoted context omitted.
Throwing away an established code base is a completely different thing from throwing away a few-days-old prototype, and not what the article is suggesting. The points you mention don't apply to the prototype case.
This is such a HN phenomenon it infuriates me. Read article. Then read comment that misconstrues article to be something completely different, accompanied with loud critique. Read replies all in violent agreement to obviously self-evident strawman.
The misunderstanding you have is that often the article isn't the point. Just like a football match in a pub isn't always the point. People just want to chime in - the comment section is like an ephemeral pub.
If that bugs you because you consume information on the web rather than socialize, the solution is simple: don't read comment sections and make up your own mind about the article.
Re: Throw away your first draft of your code
#223As 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…
[dead]
Re: Throw away your first draft of your code
#224As 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-argumen…
Sure that's like the worst case scenario, but in practice the entire point is that as soon as it becomes difficult to reason about, that's when you start cleaning up the functions and add some obvious OO. You don't leave it as a mess.
Re: Throw away your first draft of your code
#225Earlier quoted context omitted.
This is such a HN phenomenon it infuriates me. Read article. Then read comment that misconstrues article to be something completely different, accompanied with loud critique. Read replies all in violent agreement to obviously self-evident strawman.
It is a something-man. Maybe a strawman? Or a weakman?
He-Man? Superman? Batman? Captain Planet… wait.
Re: Throw away your first draft of your code
#226The 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…
A possible alternative is to use a different programming language for doing the prototyping than the one which will be used in production. The urge to hang on to prototype code can be removed, because you are going to do a rewrite in a different language, regardless.
By using 2 different languages, there is more freedom to just make a demo, discuss, and then decide what to keep or what direction to go.
Re: Throw away your first draft of your code
#227Earlier 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)
> Why do you hate Jupyter notebooks so much that it reaches “worst thing to ever have happened“ status?
It's the "with a passion" part. A certain sub-population is prone to deciding that they love or hate something, based on some early experience or social context, and then every future experience with the thing is then strong-armed into supporting that supposed strong opinion. There is no rational reason for this. It's a very extreme form of confirmation bias.
It's pretty fascinating actually, as it's often times employed by rather intelligent people. With a slight tendency towards the autistic end of the spectrum, but there is certainly more research into this needed. Perhaps somebody working on a degree in sociology is interested i digging further?
Re: Throw away your first draft of your code
#228Earlier 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.
What interactive debugger IDE are you using that lets you enter “interact”?
Re: Throw away your first draft of your code
#229Earlier quoted context omitted.
Yeah, this thread is a somewhat strange read. People don't seem to understand what "draft" or "prototype" means. Odd.
Just like management. I can't tell you how many times I've written a "Proof of Concept" that became production code.
I feel this. What I do now is increase the points of the PoC (real estimated PoC time + optimization).
I get the PoC down asap then as soon as it’s proven (privately to myself) I move onto optimizing. If it fails then I communicate early to discuss a change of scope.
Assuming it succeeds, by the time I present it I have already done significant work making it production ready. So to request an extra 10-25% time to “smooth out the edges” goes over easy after the demo.
In reality I end up with 50-75% time to get it prod ready. The rest is QA + prod bug fixes to take it over the (practically scoped) finish line.
Re: Throw away your first draft of your code
#230Earlier quoted context omitted.
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.
What interactive debugger IDE are you using that lets you enter “interact”?
pdb, the one shipped with python