Sometimes when I have just hacked something together it is full of hardcoded paths for my local system as I never planned for it to be anything more.

I made the mistake once of putting some code up that was full of machine specific and OS install specific stuff as several people asked. I ended up getting a tonne of emails moaning at me for "releasing" something that doesn't work for them. They didn't want to have to figure out every little hardcoded hack and demanded I fix it. Often very rudely.

That's the problem with "working on it in public" when it doesn't actually work anywhere other than your dev machine. People don't see it as a 'work in progress' and so will bitch and moan when it doesn't build for them.

And trust me developer users can be even worse than normal users as not only do they bitch about something not working then will often resort to name calling and such about the quality of the code.

Sure many understand it was a weekend hack project but there are always a few that will really pull you down and not everyone can handle such personal attacks when all they are trying to do is share some code for something they think is cool.

Apart from everything else you said, publishing local path could also pose a security risk.

When I talk about releasing something that "actually works" (as I put it) I mean a simple git clone, make, make install (or equivalent).

Not having to include a readme that explains you need to search and replace the files to remove hardcoded paths, install some old library because my machine wasn't up to date and it doesn't compile with the latest version as I was lazy and hardcoded specific version numbers in places for things as something else didn't work and I didn't want to spend half an hour trying to find some old Windows 2000 DLL, etc.

I am guessing based on my own experience here but developing plugins for Visual C++ 6 on Windows 2000 is a bit of a pain in the ass in 2021. It was a pain in the ass back in the early 2000s when I had access to everything on MSDN.

Sure you could make the point that this tool is designed for people using VC++6 so they must have a copy of that but they may not have any other ancient libraries this tool is built with which is often the biggest obstacle when working with old proprietary software like this.

I support the authors decision to keep things to themselves until they have been able to tidy it up then release something that is easier to build so they're not overwhelmed with "the build isn't working as it says I need x.y.z" issues.

The thing is, there's a big difference between writing something for your use case, and writing something for others.

Expanding on this further - I have a few apps I've written out there in the wild, and for one (which also found it's way onto a magazine cover CD-ROM back in the day) I had immense pressure to open source it, so against my better judgement I did. I then had to endure lots of negative feedback about the quality of my code. The whole experience put me off going open-source ever again[1].

I am a hobbyist coder, and my code quality will never be 'up there' with the professionals, but the moment you release something (even for free) people expect it to be perfect, which is unrealistic.

---

[1] Not quite true, I do have a GitHub with a few tiny repos, but nothing important.

Mess in code is inevitable. Taking on technical debt is fine, knowingly leaving certain parts messy is fine too. Provided you do so knowingly, and manageable.

So, indeed: I very much prefer to see someone who has horrible code but can explain why it wasn't a problem there, or how they refactored out of it into a beauty, than someone who has one "initial commit" that is that beauty immediately.

Edit: I've worked in places where there was a mess-paralysis. An in-grained fear for breaking stuff (but not the prowess to solve that with better CI, tests etc). Where we could not react to market or customer demands, where all progress was halted by that fear to have to go into "The Mess" and break stuff, or introduce New Mess.

A very simple but effective thing I started doing is writing „cleanup“ comments. Duplication, ad-hoc coupling and such.

In the comments I sometimes decribe how one could go about it, so I remember later what the issue might be.

There are several benefits to this. For one, prioritizing what matters in the moment. Letting things unfold for real, so the right structure becomes more obvious later. Also it sometimes sparks little discussions that are useful and reveal a pragmatic way forward.

As c2 wiki has it[1]

> * The first time you do something, you just do it.

> * The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.[...]

> * The third time you do something similar, you refactor.

E.g. I've seen a lot of Incidental Duplication being refactored out, leaving the code apparently cleaner, but in practice, really much worse.

[1] http://wiki.c2.com/?ThreeStrikesAndYouRefactor

1. You write some code.

2. You write a duplicate of #1.

3. You write another duplicate of #1, so you should refactor. But the PM doesn't understand why you're changing the code you made in #1 and #2 as part of ticket #3.

So the jaded devs are certain the duplication will occur, but believe their choice is either to pre-emptively fix the duplication at #1, or never to fix it at all.

If that is the case, the PM does not understand red-green-refactor, always-refactoring, or even just plain refactoring. I'd say the PM doesn't even understand the idea of technical debt, in that case.

The problem is certainly the PM's disconnect to how to keep a codebase (and their team) sane in the most common programming practices. And not the refactoring itself.

Even the people who want you to do a coding project would not take my existing code over rewriting from scratch for their purposes. (And yeah on the one hand that's fair, but also I did not go through with those interviews.)

I think we here underestimate the amount of people that assume that the code found on GH is production ready, or at least people assume the author thinks it's prod. You'll basically have to pre-populate an entire kanban of "yes I'm aware this is broken, don't make another bug about it", and making that digestible for the public may well just take as long as just cleaning everything up.

There really is a level of entitlement you find, often in the form of "I based a project on this thing, now this bug is blocking me, so you are blocking me until you fix this bug you made". And yeah, you can just say "sucks to be you" but is it worth the hassle?

If people would email me about "Hey, I couldn't built this on my system because of Y" or the like, I would actually be very happy.

Why would you even have bug tracking?

  > chances are most of your dirty laundry and uglier hacks are either pain points that are systemically
  > hard (installation, different OS versions/platform, dependencies, build environment) that everyone suffers with

Maybe that "dirty laundry", in this case, is security-through-obscurity (maybe even with a TODO: this is insecure, fix it) or hardcoded values such as keys or ids that might compromise stability or security.

E.g. I normally open source everything from day one, but keep my Ansible (and before Chef) stuff behind closed doors: it's full of commits that would compromise security. E.g. "quick hardcoded list of private IP-addresses that can access the reporting Database until we have the VPC coupled to a VPN."

That, and the "cleanup" will never be "good enough" once you go down that route.

On the contrary I like it, for it makes me more confident about the general quality of the work, even though I understand that it can increase cycle time.

Reminds me of Majorana not wanting to publish, due to considering that work is never completed enough to be worthy of publication (source: https://www.youtube.com/watch?v=uhCqO0CztwE&t=630s).

This may be part of the concern. Sometimes for a personal project you don't want that sort of input on the essentials. It is your thing, you want to do it right yourself either through pride or because you feel you'll learn more/better that way.

In those cases, while being perfectly willing to share the results by releasing the source at a particular point they might not want to be "distracted" at this stage by the sort of input you describe.

Not releasing immediately also delays the potentially discombobulating license choice issue, if this is your first such project and you have not given that much thought previously.

Now that you have a better idea of what problem to solve and how to solve it, you can restructure the code to be more concise and overall more efficient in reaching your goal.

I think it's advisable to clean up your code like that before publishing, just like it's advisable to clean up your git commits before pushing a merge request.