@FrailLeaf @LordMordred @bwk literally everyone.. There are not hard restrictions on who can be hired to work on an open-source projects.

@kreyren @LordMordred @bwk I do not understand why you keep ignoring my point, Not everyone working in software development/engineering are there because they enjoy it, you cannot help them love the job, they do it for the sake of it.

@FrailLeaf @LordMordred @bwk like they can always change an industry.. So what's your point?

@kreyren @LordMordred @bwk What? How does a person working a job, writing absolutely horrible code change the industry?......

@FrailLeaf @LordMordred @bwk

> How does a person working a job, writing absolutely horrible code change the industry?

The gross majority of people working on open-source projects write a horrible code it's by design done this way.

So again the important thing is abstracting and documenting the code preferably writing down what you are doing, how and why

@FrailLeaf @LordMordred @bwk e.g. what @lupyuen is doing with https://qoto.org/web/statuses/107793119639236951

@kreyren @LordMordred @bwk @lupyuen Its great that your experience in life with people learning to code have done well. I'm speaking from experience where the senior-most developers are doing a bad job at it, making no effort to maintain source-level docs, making it a nightmare for me to debug through the large codebase so I can maintain it.

@FrailLeaf @LordMordred @bwk Like footprinting is generally time efficient so what's the issue?

@kreyren @LordMordred @bwk what is footprinting?

@FrailLeaf @LordMordred @bwk

The practice of figuring out how the software works and why.

My way of doing it is by adding "WTF" comment tags all over the code as comments to things that i do not understand and then commenting out random codeblocks and changing them to see how it affects the outcome to write docs.

e.g.

fn main() {
println!("Hello, world!");
}

fn main() {
// WTF(Krey): what is this supposed to do?
println!("Hello, world!");
}

fn main() {
// WTF(Krey): what is this supposed to do?
println!("Hello, worldSSSSssss!");
}

Oh this block is the one that prints in the console!

fn main() {
// Outputs 'Hello, world!' in the console
println!("Hello, world!");
}

@kreyren @LordMordred @bwk Great, now consider a huge codebase where there's magic numbers everywhere, random conditional checks; all with no comments. It is ridiculous to expect me to work on this codebase when the pay doesn't match the work it requires.

@FrailLeaf @LordMordred @bwk Large codebase without documentation is not sustainable so i don't think that this scenario exists in the wild and even if it was it's still time efficient to footprint.. i would say 100K Lines taking <1 hour

@kreyren @LordMordred @bwk

>i don't think that this scenario exists
You are saying I'm lying? I work with 3M SLOC ESB system written in Java EE; with no documentation because "a lone developer worked it when the company was small". And another 30 Microservices with source level docs for the same reason.

@FrailLeaf @LordMordred @bwk

So what's the issue? footprinting of open-source software is very time efficient..

I do agree that java is a torture instead of a language so i can would imagine that lack of documentation is the least of your problems there.

@kreyren @LordMordred @bwk
None of this was ever about Open source software, I have laid it down that this is in Proprietary systems. You fail to understand the context.

@kreyren @FrailLeaf @LordMordred @bwk The best way to analyze a large unknown codebase is to add logging statements. If you start removing random parts of code, you create so many unpredictable random chaos and failures that any behaviors you see as a result of that are more likely *misleading* rather than actually helpful.

"Experimental Development" is what I call that. Also if you determine your code is correct, because it behaves correctly, that's precisely the same mistake. You can only understand code from the inside, not from the outside, and the best way to analyze the inside is logging. Period. Full stop. There are essentially zero exceptions to that rule.

@clay @LordMordred @bwk @kreyren There's more efficient solution to just leaving logging statements; debugger. It is far more efficient and you can analyze scope at runtime.

@FrailLeaf @clay @LordMordred @bwk Debugger output will just confuse you most of the time..

When i do footprinting i just fully ignore it.

@FrailLeaf @LordMordred @bwk @kreyren Debugger is ideal for a precise search for a precise bug, but depending on how complex the code is and what it's doing, sometimes the only viable alternative is logging. Logging is 'repeatable' instantly. Debugging can take hours and hours...and is very labor intensive.

@clay @FrailLeaf @LordMordred @bwk

Alternatively if you are limited on time resources i usually just add `println!("SSSssssssSSss");` to the codebase at random places to understand the runtime evaluation and then regex it out when i am done.

@kreyren @FrailLeaf @LordMordred @bwk Exactly right. That's a good trick.

@clay @LordMordred @bwk @kreyren You can capture a lot of stuff you could miss out on logging with a debugger, Set breakpoints and step over/into pieces of code, print out the variable you're analyzing. Its easier to capture many edge-cases this way than logging. With logging, you go back and forth a lot.

@FrailLeaf @LordMordred @bwk @kreyren The debugger is for when you need a microscope. Logging is for when you need a telescope. One is a broad overview and the other is highly detailed.

@clay @LordMordred @bwk @kreyren Okay, but you can choose to turn the microscope into a telescope if need be. You could choose to capture or not. A logging statement is very similar to breakpoint in that sense

@FrailLeaf @LordMordred @bwk @kreyren Sometimes you need to run a scenario a large number of times to collect logging data for post-analysis. When you run into that scenario using debugging approach instead of logging will take you 10 years (i.e. never) to solve certain classes of problems that can be solved easily thru logging approach.

@clay @LordMordred @bwk @kreyren I'm interested, what are the situations where you need to run a program these many times?

@clay @FrailLeaf @LordMordred @bwk

If you are ever in a situation where you need to collect a
"logging data for post-analysis" then logging is just about the worst thing to use that for as it has a major impact on the efficiency of the program and you always do this once you understand the code and have established a clean room as without it your logging data will have bunch of noise in them.

Thus the case for benchmark tests preferably using criterion.

@clay @FrailLeaf @LordMordred @bwk

telescope analogy for logging is wrong and i hate that so many people are looking at it like that..

The output is expected to be very descriptive and understandable without depending on skill requirement so i argue for "clear map" instead.

@FrailLeaf @clay @LordMordred @bwk I am aware, but it never helps me when i am footprinting as i don't have established a clear working environment to rely on the output.

@clay @FrailLeaf @LordMordred @bwk

I didn't say removing random parts of the code, i said _COMMENTING OUT_ random parts of the code..

meaning comment them, run the program to see what it does and uncomment and repeat until you understand what the changes are doing to document the code.

Adding logging takes a huge amount of resources in comparison to this, but i agree that if the software is projected to be used in a production or mission critical environment then adding logging is well worth the time.

@kreyren @FrailLeaf @LordMordred @bwk Yes, I knew you meant commenting and not permanently deleting. I still say all that will do is create chaos that's counterproductive to any goal.

@clay @FrailLeaf @LordMordred @bwk

There is no way that it will create a chaos if you run it bootstrapped (unless you are yolo dev to run it on bare metal) and fatal failures are expected to understand the code.

@FrailLeaf @LordMordred @bwk to follow-up like last time i checked in finland they let criminals convicted of murder to work on open-source projects and there are pedophiles and nazis contributing to Linux development etc..