5 ms·

> Anyways, I plan to eventually open source it. There's a lot of stuff in the code I want to clean up (things like setting up the build environment, some of the

by dankle 5y ago

> Anyways, I plan to eventually open source it. There's a lot of stuff in the code I want to clean up (things like setting up the build environment, some of the uglier hacks, etc.) before I feel comfortable releasing it to the public I hate seeing this. We all write some ugly hacks. Just release it and work on it in public, it's fine.

robscallsign 5y ago
I second this. If your goal is to release it publically, 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 in which case the community can help, or it's in a part of the code that migth not be a core competency of yours, and so the community can also help.
- dotancohen 5y ago
  > 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 To add to this point, I would love to see the commits that do resolve these issues. I could learn from them too.
- berkes 5y ago
  It's really just guessing though. 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."
Vvic 5y ago
I found it odd seeing this too. Isn't it the goal of open-sourcing, using git and this software?
blowski 5y ago
I guess people make projects like this to show off on their CV, and they’re worried that bad code could have the opposite effect. That said, in hiring, I don’t mind seeing bad code - it gives us a talking point about the constraints involved, and how you’d improve it.
- berkes 5y ago
  I'd much rather hire someone who shows how to manage a mess, than someone who tries to avoid that mess. 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.
  - dgb23 5y ago
    I tend to overthink and hyperreflect when it comes to organisation and structure. Most of the time this doesn’t really help. One of my goals in the last year or so was to reduce that. 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.
    - berkes 5y ago
      And a third benefit: leave refactoring to the time when you have enough information to refactor. 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 http://wiki.c2.com/?ThreeStrikesAndYouRefactor
siva7 5y ago
There is this immense pressure if your code isn’t perfect it will have negative side effects for your career when open sourcing it. So understandably people choose not to.
- hoseja 5y ago
  This sounds like a nightmare I'm glad I'm not aware of. In what sort of degenerate subculture does this take place? SV?
- Jarwain 5y ago
  But is this pressure truly external? Or is it just stem from perception or a belief that published things must be perfect?
webreac 5y ago
If I understand well, when you will publish it, the first merge requests you will receive will be improvements of your build system. People will compete to provide the best fix for this obvious deffect. As a result, the main brake for publication will disappear quickly.
- dspillett 5y ago
  > People will compete to provide the best fix for this obvious deffect. 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.
satysin 5y ago
I get what you're saying but I only like to release to the public something that actually works. 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.
- dTal 5y ago
  They're releasing binaries, so presumably it does work.
  - mattowen_uk 5y ago
    I have plenty of utilities that I've written over the years that work perfectly on my machine, but I know they'll probably fail on some else's due to hardcoded file paths and assumptions as to what libraries are installed. The thing is, there's a big difference between writing something for your use case, and writing something for others.
    - dTal 5y ago
      Uh huh, and did you release binaries of those utilities for public consumption?
      - 5y ago
jffhn 5y ago
>I hate seeing this. 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 https://www.youtube.com/watch?v=uhCqO0CztwE&t=630s).
PeterStuer 5y ago
"We all write some ugly hacks. Just release it and work on it in public, it's fine." That, and the "cleanup" will never be "good enough" once you go down that route.
jedimastert 5y ago
> We all write some ugly hacks. Just release it and work on it in public, it's fine. 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?
- AshamedCaptain 5y ago
  Why do you care about people emailing you at all ? It doesn't matter what you publish or in which state you do it, you will always get a shitton of emails ranging from "but, will this work on my Xbox?" (for a desktop program) to "I see you are expert in $RANDOM_TOPIC, would you kindly help with my homework coding assignment?" 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.
  - jedimastert 5y ago
    Signal-to-noise ratio (I'm talking about bug tracking specifically). If you want to any kind of feedback, you have to take all of it, and if publish in a "rough" state then that noise ratio will be high.
    - AshamedCaptain 5y ago
      My point is that the feedback will be mostly crap anyway, and actually releasing it in an unusable state (which is far from the truth) would not change that, or may even increase the quality of the feedback as a filter. Why would you even have bug tracking?
AshamedCaptain 5y ago
Actually just don't release, period. Point to a repository and be done with it. Anyone who expects support setting up Visual Studio 6 or the like to use this is either knowing what they are doing (so they won't actually ask inane questions but rather useful ones) or not knowing what they are doing (in which case answering their questions is probably not a useful use of your time anyway). The fact they're trying to set up a website or something hints that either they're in there for the fame (so they have a "surprise the people" mind-framework which makes them want to do releases and hide the source for as much as possible), , that they already know someone who may want to spend big $ on this, or that it's just their first project and are still a bit truly ashamed/naïve. I have seen both happen many times and it always end with no source ever released, or the source released way too late for it to make any impact.
xg15 5y ago
There is also plain ol' technical debt: Code that is overengeneered, unstructured or hacky because, when you wrote it, you were still exploring the problem space. 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.

by dankle 5y ago

robscallsign 5y ago

I second this. If your goal is to release it publically, 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 in which case the community can help, or it's in a part of the code that migth not be a core competency of yours, and so the community can also help.

dotancohen 5y ago
> 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 To add to this point, I would love to see the commits that do resolve these issues. I could learn from them too.
berkes 5y ago
It's really just guessing though. 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."

Vvic 5y ago

I found it odd seeing this too. Isn't it the goal of open-sourcing, using git and this software?

blowski 5y ago

I guess people make projects like this to show off on their CV, and they’re worried that bad code could have the opposite effect. That said, in hiring, I don’t mind seeing bad code - it gives us a talking point about the constraints involved, and how you’d improve it.

berkes 5y ago
I'd much rather hire someone who shows how to manage a mess, than someone who tries to avoid that mess. 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.
- dgb23 5y ago
  I tend to overthink and hyperreflect when it comes to organisation and structure. Most of the time this doesn’t really help. One of my goals in the last year or so was to reduce that. 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.
  - berkes 5y ago
    And a third benefit: leave refactoring to the time when you have enough information to refactor. 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 http://wiki.c2.com/?ThreeStrikesAndYouRefactor

siva7 5y ago

There is this immense pressure if your code isn’t perfect it will have negative side effects for your career when open sourcing it. So understandably people choose not to.

hoseja 5y ago
This sounds like a nightmare I'm glad I'm not aware of. In what sort of degenerate subculture does this take place? SV?
Jarwain 5y ago
But is this pressure truly external? Or is it just stem from perception or a belief that published things must be perfect?

webreac 5y ago

If I understand well, when you will publish it, the first merge requests you will receive will be improvements of your build system. People will compete to provide the best fix for this obvious deffect. As a result, the main brake for publication will disappear quickly.

dspillett 5y ago
> People will compete to provide the best fix for this obvious deffect. 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.

satysin 5y ago

I get what you're saying but I only like to release to the public something that actually works. 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.

dTal 5y ago
They're releasing binaries, so presumably it does work.
- mattowen_uk 5y ago
  I have plenty of utilities that I've written over the years that work perfectly on my machine, but I know they'll probably fail on some else's due to hardcoded file paths and assumptions as to what libraries are installed. The thing is, there's a big difference between writing something for your use case, and writing something for others.
  - dTal 5y ago
    Uh huh, and did you release binaries of those utilities for public consumption?
    - 5y ago

jffhn 5y ago

>I hate seeing this. 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 https://www.youtube.com/watch?v=uhCqO0CztwE&t=630s).

PeterStuer 5y ago

"We all write some ugly hacks. Just release it and work on it in public, it's fine." That, and the "cleanup" will never be "good enough" once you go down that route.

jedimastert 5y ago

> We all write some ugly hacks. Just release it and work on it in public, it's fine. 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?

AshamedCaptain 5y ago
Why do you care about people emailing you at all ? It doesn't matter what you publish or in which state you do it, you will always get a shitton of emails ranging from "but, will this work on my Xbox?" (for a desktop program) to "I see you are expert in $RANDOM_TOPIC, would you kindly help with my homework coding assignment?" 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.
- jedimastert 5y ago
  Signal-to-noise ratio (I'm talking about bug tracking specifically). If you want to any kind of feedback, you have to take all of it, and if publish in a "rough" state then that noise ratio will be high.
  - AshamedCaptain 5y ago
    My point is that the feedback will be mostly crap anyway, and actually releasing it in an unusable state (which is far from the truth) would not change that, or may even increase the quality of the feedback as a filter. Why would you even have bug tracking?

AshamedCaptain 5y ago

Actually just don't release, period. Point to a repository and be done with it. Anyone who expects support setting up Visual Studio 6 or the like to use this is either knowing what they are doing (so they won't actually ask inane questions but rather useful ones) or not knowing what they are doing (in which case answering their questions is probably not a useful use of your time anyway). The fact they're trying to set up a website or something hints that either they're in there for the fame (so they have a "surprise the people" mind-framework which makes them want to do releases and hide the source for as much as possible), , that they already know someone who may want to spend big $ on this, or that it's just their first project and are still a bit truly ashamed/naïve. I have seen both happen many times and it always end with no source ever released, or the source released way too late for it to make any impact.

xg15 5y ago

There is also plain ol' technical debt: Code that is overengeneered, unstructured or hacky because, when you wrote it, you were still exploring the problem space. 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.