Return to Answer

SO has had a long-standing policy about judging questions on their merits, instead of the job description of the person asking. I agree with this policy, however, let's consider some of the differences between common SO topics and SF topics:

• SO: HTML and JavaScript
• SO: Compiled languages: C, C++, C#, Java, go
• SO: Scripted languages: Perl, Ruby, Python, PHP, shell

I see a few notable differences between SO and SF questions:

• On SO, it's quite possible to replicate the OP's problem without hours of labor; particularly since there is an emphasis on creating a minimal, complete, valid example. People might not be terribly good at doing it, but it's at least feasible in many cases.
• On SF, it's quite challenging to expect people to build the same minimal example, because many questions are specific to the OP's work environment. For instance,
• I can clone someone's git branch and experiment with their code if I need to, but how exactly does one clone their linux server, SAN traffic, hadoop cluster, or network congestion?
• System administration also has a higher barrier to entry than programming. Even if I was inclined to spend hours building a virtual or physical mock up of an average SF problem, there are non-trivial licensing issues involved with replicating many environments (i.e. Windows, Solaris, HPUX, Juniper, Cisco...). By way of contrast, a lot of software can be written with free / open-source tools available to the masses (gcc, Eclipse, git, scripting languages, etc...).

SO has had a long-standing policy about judging questions on their merits, instead of the job description of the person asking. I agree with this policy, however, let's consider some of the differences between common SO topics and SF topics:

• SO: HTML and JavaScript
• SO: Compiled languages: C, C++, C#, Java, go
• SO: Scripted languages: Perl, Ruby, Python, PHP, shell

I see a few notable differences between SO and SF questions:

• On SO, it's quite possible to replicate the OP's problem without hours of labor; particularly since there is an emphasis on creating a minimal, complete, valid example. People might not be terribly good at doing it, but it's at least feasible in many cases.
• On SF, it's quite challenging to expect people to build the same minimal example, because many questions are specific to the OP's work environment. For instance,
• I can clone someone's git branch and experiment with their code if I need to, but how exactly does one clone their linux server, SAN traffic, hadoop cluster, or network congestion?
• System administration also has a higher barrier to entry than programming. Even if I was inclined to spend hours building a virtual or physical mock up of an average SF problem, there are non-trivial licensing issues involved with replicating many environments (i.e. Windows, Solaris, HPUX, Juniper, Cisco...). By way of contrast, a lot of software can be written with free / open-source tools available to the masses (gcc, Eclipse, git, scripting languages, etc...).

SO has had a long-standing policy about judging questions on their merits, instead of the job description of the person asking. I agree with this policy, however, let's consider some of the differences between common SO topics and SF topics:

• SF: Unix / Linux system administration
• SF: Windows administration
• SF: Database administration
• SF: Network administration

I see a few notable differences between SO and SF questions:

• On SO, it's quite possible to replicate the OP's problem without hours of labor; particularly since there is an emphasis on creating a minimal, complete, valid example. People might not be terribly good at doing it, but it's at least feasible in many cases.
• On SF, it's quite challenging to expect people to build the same minimal example, because many questions are specific to the OP's work environment. For instance,
• I can clone someone's git branch and experiment with their code if I need to, but how exactly does one clone their linux server, SAN traffic, hadoop cluster, or network congestion?
• System administration also has a higher barrier to entry than programming. Even if I was inclined to spend hours building a virtual or physical mock up of an average SF problem, there are non-trivial licensing issues involved with replicating many environments (i.e. Windows, Solaris, HPUX, Juniper, Cisco...). By way of contrast, a lot of software can be written with free / open-source tools available to the masses (gcc, Eclipse, git, scripting languages, etc...).

The higher barrier to entry, and complex systems make it all the more important to get good documentation from people asking on SF; however, getting them to figure out how to document something is a chicken and egg problem.

My SF Feature Request:

Feature Request: Give every SF question a scorecard, which indicates what is lacking from the question, and a good example of what it might look like. Every person who views the question can vote for whether the person needs to add information to the question.

SO has had a long-standing policy about judging questions on their merits, instead of the job description of the person asking. I agree with this policy, however, let's consider some of the differences between common SO topics and SF topics:

• SF: Unix / Linux system administration
• SF: Windows administration
• SF: Database administration
• SF: Network administration

I see a few notable differences between SO and SF questions:

• On SO, it's quite possible to replicate the OP's problem without hours of labor; particularly since there is an emphasis on creating a minimal, complete, valid example. People might not be terribly good at doing it, but it's at least feasible in many cases.
• On SF, it's quite challenging to expect people to build the same minimal example, because many questions are specific to the OP's work environment. For instance,
• I can clone someone's git branch and experiment with their code if I need to, but how exactly does one clone their linux server, SAN traffic, hadoop cluster, or network congestion?
• System administration also has a higher barrier to entry than programming. Even if I was inclined to spend hours building a virtual or physical mock up of an average SF problem, there are non-trivial licensing issues involved with replicating many environments (i.e. Windows, Solaris, HPUX, Juniper, Cisco...). By way of contrast, a lot of software can be written with free / open-source tools available to the masses (gcc, Eclipse, git, scripting languages, etc...).

The higher barrier to entry, and complex systems make it all the more important to get good documentation from people asking on SF; however, getting them to figure out how to document something is a chicken and egg problem.

My SF Feature Request:

Feature Request: Give every SF question a scorecard, which indicates what is lacking from the question, and a good example of what it might look like. Every person who views the question can vote for whether the person needs to add information to the question.