Exploratory refactoring turns out to be very close to an exercise in creative writing, as I learned one day accidentally from my lit major friend.

Take the section you are stuck on, print it out, cut it up into sentences or phrases, and just rearrange them until either it makes sense, or you figure out where you went wrong.

Rearranging code statements until something makes sense is exactly what refactoring is.

I beg to differ.

Refactoring is not merely rearranging code statements. Refactoring is restructuring of the code starting from the architectural and abstract goal and then looking at how pieces of existing code would fit. Sometimes, that requires writing new code and tests. Refactoring by definition also means not breaking the user space.

I've never heard of any serious writer printing out their prose and cutting it and rearranging it. That just sounds absurdly unnecessary to me.

> code starting from the architectural and abstract goal

you are either using a different definition of architecture or this is wrong. Refactoring is bottom up construction. Most of the time when I see people frustrated or struggling (including myself) it's because they have forgotten this and need to take a break.

I am using the standard architecture difinition.

More information here: https://en.wikipedia.org/wiki/Code_refactoring

There are many goals in refactoring, specifically this section:

> Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

I was addressing OP's analogy to cutting pieces of written prose and rearranging.

A bad paragraph does not get the point across because it is doing things in the wrong order, or taking to long to get there. Hoisting code can be removing repetition, performance... So many things. Rearranging or deleting code so that a piece is not trying to do three things at cross purposes, for one.

Code is meant to be read by humans and only incidentally by computers.

A lot of architecture is just being clear about what is intrinsic complexity and what is accidental, be it cognitive or computational.

> I've never heard of any serious writer printing out their prose and cutting it and rearranging it.

Writers definitely do this. Maybe not at the prose level, but for sure at the plot level and chapter level.

I've found myself doing this in e-mail recently. I naturally try to set the stage/explain the situation, then ask for something (opinion/resources/prioritization/...). But I've been advised to lead with the request, and then explain. It often takes a minor rewrite to make it work, but I've become convinced it helps motivate the reader to read the explanation.

I’ve definitely heard of doing this when plotting something out, ie at compile time instead of runtime to stretch an analogy.

I think you can buy a box full of words: https://magneticpoetry.com/

Yeah, writing code without source control sounds horrible. Can't imagine what it must've been like for those who had to suffer through such time.

I know a contractor who has worked for a major company that I won't name. He has told me that their source control was, for a time, Google Drive. He knew it was a recipe for disaster but real work was nonetheless getting done, and the client was satisfied. They didn't know how the sausage was being made, but they liked the output.

I think a lot of people who haven't been around the scene wouldn't believe these stories, but this stuff happens a lot. Like major commercial projects with no tests whatsoever (unit, integration, or otherwise), that are still successful and making a lot of money.

Not surprised. A lot of this stuff doesn't get set up because people are lazy. Or developers don't want to, or are unable to, do sysadmin work.

I worked at a small "startup" inside a larger, several billion dollar company, back in the late 90's. Nobody set up source control for that division, despite the parent company being over two decades old and having people very experienced with that sort of thing. We were also integrating code from third party contractors, and it was a big mess. Files getting overwritten, people copying stuff off their local desktops, consultants FTPing in updates, etc. After a couple months of copying junk everywhere, I finally got fed up. As a 22 year old, basically straight out of college, I was training the entire team how to use CVS...

We’ve had effective source control since the 70s, latest 80s; for the most part working without it was self inflicted.

Exactly. When people say 'before we had version control' I want to ask, how old are you? And by the way, I am older than just about all of you.

Started with SCCS with versioned control lists to determine what got pulled from SCCS. The outer wrapper was all written in shell. 1980s.

Talking about a large system, eight or ten sub projects, each sub project in its own versioned source tree.

A release spec pulled the SCCS deltas of all the sub project control lists, and then SCCS was directed by those versioned control lists to pull all the source code for each sub project.

So yes, version control that I am aware of was firmly entrenched in 1980. And I am certain it goes back further than that.

Yes totally. It gives you freedom to try things you don’t fully understand in your IDE or framework too then decide whether you want to revert everything afterwards.

Modern IDEs often ave basic source control baked in. You don't even need to commit anything. I wonder whether there is any point in using Git for basic version control if those features are already available.

At least in IntelliJ, I find using the local file history stuff painful. With explicit source control, I'm making specific decisions to check in known states. When I have to resort to the local file history stuff, there's a lot more of "oh, here I undo'd a typo" and so on type of things.

That said, it can be a lifesaver when I didn't make an explicit commit, then started doing stuff, then realized "ok this got out of hand AND I wish I could go back five minutes but it's gonna be annoying."

The intellij local history works best when your code is a raging monolith. It punishes you when you find coupling in otherwise uncoupled code, and that punishment is there whether you leave the coupling or try to fix it.

One of the failure modes for people leaving a mess is if it's too hard to fix it they give up. So that's no good.

Committing aside, git also has stash. Many people prefer using one consistent tool (git) over the variety of IDE's equivalent features available.

I posted elsewhere. Stash is your friend. If you aren't using stash today, learn it. And learn the difference between 'stash pop' and 'stash apply'. Each has its place and time.

Yes: you like the interface for git already and are productive with it versus learning how to achieve the same productivity while learning the idiosyncrasies of your chosen IDE platform.

I'm butchering something someone said here about a month ago:

Some people cut a trail through the jungle, others just push the branches out of the way and expect everyone behind them to do the same.

Most IDEs that have basic source control baked in typically means it has a git client and UI. I know that years ago I used Netbeans local history but it's a per-file history and does nothing to keep a set of files at a specific "save point" together.