I'd have to be very new to something to throw away the first draft of my code. My goal is to have to change the code I write as little as possible.
Throw away your first draft of your code
211–220 of 230 posts
Re: Throw away your first draft of your code
#212Earlier quoted context omitted.
I don't really feel that attraction to complete rewriting. I wonder if the people who do are very smart, and thus able to hold more state in their head, so ugly code bothers them more even if it's not actively a problem, because they are able to have background tasks in their mind to worry about it? And at the same time, perhaps their code is less encapsulated, because they didn't optimize for abstraction, they optim…
Smart people can ignore ugly code. It's the people who get easily confused that need to see clean and easy to understand code.
If other people need to read your email/doc/code, then any effort to make it more readable will save them time, regardless of how smart they are.
"If I had more time, I would have written a shorter letter."
Re: Throw away your first draft of your code
#213Or refactor it
Re: Throw away your first draft of your code
#214What a load of nonsense.
Iterative code refactoring is the only right approach.
Why spend time writing code and then throw it away?? That makes no sense at all.
Best approach would be to spend some time thinking and conceptualizing BEFORE writing the first line of code.
Re: Throw away your first draft of your code
#215Earlier 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)
I can't justify it - it's pure preference and opinion, irrationally held. A big part of it is probably that type of programming I generally need to do is closer to using an overgrown calculator (with DataFrames) than doing proper Software Development to build a thing.
I much prefer having the code over _here_, and then having the results in a separate pane over _there_. Jupyter style mixing of inputs and outputs tends to confuse me, and in my hands gets very messy very quickly.
The slides in this light hearted talk from JupyterCon in 2018 probably give a better explanation than I could.
https://conferences.oreilly.com/jupyter/jup-ny/public/schedu...
Re: Throw away your first draft of your code
#216As 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…
The correct way is:
1. Use comments to split visual awkward part into chunks.
# a lot of code...
## ===
# more a lot of code...
2. Use inner functions if that chunk need to be reused
3. Only move the chunk to top-level function if you think it's worth to take time to make its required state into parameters/return value
Re: Throw away your first draft of your code
#217Earlier quoted context omitted.
> The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. I want an editor plugin which allows me to mark sections of code as reviewed or "perfect" (depending on how honest I'm being). Then, when I'm tempted to rewrite everything, I can go through and mark what I think is good, and then focus on refactoring the rest until I think it is good as well. I'm tempted to rewr…
I would think a combination of git, unit tests, and comments would solve this problem? Unit tests prove the code works as intended, and are basically examples of what the code is doing. Whether the code is actually "good" is a bit more subjective -- but tests give you the freedom to modify it without breaking it. Checking into git frequently is also a way to give yourself some freedom. Commit at every milestone, like…
The theory and the practice of unit tests are often different things. In theory you’ll make changes to the code, and the unit tests will show whether they had the intended effects.
In practice, because often the unit tests are mocking out all the classes they interact with (as is the recommended style for isolated tests) you’ll either have all the tests explode constantly because the interface being mocked has changed, or you’ll have tests that confidently tell you things are working despite the methods they call no longer existing.
Re: Throw away your first draft of your code
#218What a load of nonsense. Iterative code refactoring is the only right approach. Why spend time writing code and then throw it away?? That makes no sense at all. Best approach would be to spend some time thinking and conceptualizing BEFORE writing the first line of code.
For me, writing code is a way of thinking, and often the best way of thinking about a problem or question, or to start conceptualizing an entire project, is to write some running code as a sketch, a rough draft, a prototype.
If it has any merit, the running code informs the planning and decision-making process, stimulates thought and discussion. Parts of the draft, or even the whole thing, can be transformed, rewritten or refined, and become the basis of the solution and product.
Of course it depends on the goal and nature of the question. Sometimes it's better to talk and think things through in human language, deeply and thoroughly, before writing any code. It could be that the best solution is no code at all, to use an off-the-shelf product or service.
About "throwing away" code.. Imagine a musician with thousands of hours of playing, practice, informal or private performances and recordings - including piles of sketches and rough drafts that will never see the light of day. Only the best selection will be curated for the public, to make it into the final product. But the 99% that are "thrown away" was not a waste of time, they were a necessary part of the creative process to achieve the good stuff.
Re: Throw away your first draft of your code
#219This is an idea I've preached for a while now. Software requirements, goals, deadlines- all that stuff can be planned. Even the architecture can be sketched out. But, for any sophisticated piece of software, you'll never get the actual code right the first time. If you think it's right, dig deeper. Find everything that's wrong with it, and do it again with those problems fixed. Great software and great art have one thing in common: the best version is never the first.
Re: Throw away your first draft of your code
#220As 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…
Wow, not a ML person, but controls and robotics. Yet, this describes my workflow for a lot of things almost to a tee. Even down to the avoiding loops. I tend to do that when I want to run the same simulation or analysis for a couple variables or datasets. It's interesting, because in the past I was a lot more prone to turn that into a loop early on. But this makes your code brittle. You'll want to do something slightly different for the two datasets, which means a bunch of conditionals in your loop. It's actually really similar to the problems you get with boolean flags when you try to abstract into a function too soon. It actually takes disciple to for me to commit to copy past but I think it pays it off.