151–160 of 230 posts
Often the problem with refactors is that don't come with enough of these new ideas , there's no real progress, it's mostly moving things around.
I’d sat down all night and written some C for a graphics class. Everything was great, yay, victory. Proceeded to tar it up per class guidelines and did something like this:
tar cvf assignment.c assignment.h data.txt readme whatever.cuz
And as many of you no doubt recognize, I’d forgotten to supply a destination name before listing the source files.
So the code was gone. My brain was gone, too, so I explained what happened and sent what I had, including a working executable, to the TA. He gave me an extra day to finish.
So the next day I sat down and wrote it all again and as mentioned above, it was some of the best code I’d written. Doing it again from the top saved all sorts of dead ends and mistaken approaches.
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?
(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 have happened to software development, and definitely the worst thing ever to have happened to ML/data science.)
This would sound like questionable advice except that the best code I wrote in college resulted from an accident… I’d sat down all night and written some C for a graphics class. Everything was great, yay, victory. Proceeded to tar it up per class guidelines and did something like this: tar cvf assignment.c assignment.h data.txt readme whatever.cuz And as many of you no doubt recognize, I’d forgotten to supply a desti…
Out of curiosity, was it really fast for you to do it in that extra day or did it take all day?
I like to build my first version in one file with as few abstractions as possible. No helper functions, unless absolutely necessary, just straight-forward code. Building good abstractions later on is a lot easier than starting with wrong ones in the first place.
This is an underrated way of doing things that I've come to appreciate over time. Heck, I'll even go live with the all-in-one-file thing until there's a reason to split it up. It's all peanuts anyway compared to bigger decisions like what API, DBMS, DB schema, other deps, libs, etc you use.
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…
Earlier 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.
Of course clean and readable means very different things to different people, but I don't thing I ever regretted cleaning up code, while I can think of a lot of instances where not doing it wasted a lot of time.
My boss doesn't allow me.