Supporting the team like this is great. Be careful you don't burn out by taking too much on yourself. This a warning about mistakes I have seen from myself and others more than anything indicated in your post. It sounds like you have it pretty well under control, taking it one process at a time.

Some thoughts on unit tests in case they are interesting/helpful for you or someone else.
- Keep a bug count or similar metric posted to show process benefit
- Make it easy to create tests, especial for the first time the coder has to write one
- Introduce it to larger teams who work in each others code
- Explain how it can improve code quality not just test code

What follows is a more conversational and detailed presentation of the points above.
One of the best things to do to support any metric is to track something like # of open bugs during the project. It can really draw attention to the impact of improving the process. When a new project adopts a process it helps everyone to realize the benefit of a process.

I found unit tests was somewhat more challenging to get buy in than code review. I think this because the time it takes do write the test as well as the time until you real feel the benefit. One person who usually works in side projects and not part of team is still to be convinced. With a bigger team working in a more agile manner where they are often working on code started by someone else it is a lot easier to see the benefit.

Setting up the system so that it is as easy as possible to write a new test is a big help. Making the entry barrier small is very helpful for adoption. Relieving just a small amount of process can also make a big difference.

One of the benefits gained in unit tests is that it helps reinforce good code structure; such as using interfaces and creating classes that only perform one function. Without these things code becomes hard to test. Not doing these things become obvious as problems when you go to test and discover it is very difficult. Showing examples of this can help support adoption. At the start of adoption it can be viewed as making you change code for the sake of the test rather than improving the code. So it needs to be communicated properly.

I assume the response is saying that looking at the code is not required to be a good manager.

I agree that look at the code is not a key point of evaluation. I agree certainly agree with the parent post, that looking at a few metrics is not a good way to evaluate anyone or anything.

Information I use to evaluate an employee.
Do other employees praise or complain about them? The number one rule is making the team better.
Do they do what is expected? Can I count on them to complete something when asked, to handle small obstacles and let me know if they are not going to succeed in the expected amount of time?
Do they find and resolve problems on their own? Some problems have to be brought to my attention because of either their severity or action needed to resolved them. If an employee never brings things to my attention they are either unconcerned about serious problems or are not working well as a team
We use code review so the developer improve their own code. It does not take long before it is pretty common knowledge if a coder is problematic here.

I agree. This is something good football coaches talk about. Denis Green put it succinctly and eloquently "I won't treat you all equally, but I will treat you fairly." People are not all motivated the same and are not all in the same circurmstances.

> A newbie or an incompetent *needs* micromanaging
I think you may want to say "mentoring" or "training" so they grow. Of course it also important to manage expectation so the individuals no what is expected and are not surprised there are consequence. Again expectations are different for different people. Each should know what is expected of them personally.

I agree. Great advice. If the poster is following his own advice, it is no surprising the people on his team consider him one of the best managers he/she has ever had. The advice is very specific and practical and can be adopted by anyone.

I don't think so:
The manager usually does not have control of compensation.
Compensate is not a strong motivator. https://hbr.org/2013/04/does-m... Personally, I do feel more of a commitment when I realize I have a high salary but it is small relative to other motivations
The main reason people quit is because of bad managers http://fortune.com/2015/04/02/...
A good manager is competent and has good people skills https://hbr.org/2014/03/why-go...

I disagree with the post. Don't do everyone the developers don't like. It is not your job to write documentation. Get buy from the team to understand what they are doing. That being said, you do need to make sure that things don't fall through the gap.

From my experience as a manage here are my top best practices:
1) Get buy in
a) Answer questions with, "what do you think we should do?" Then let them do it. If you supply an answer the employees will never believe they have control. You will not get buy in and you will answer the same type of questions forever. You can offer opinion. Be clear on whether it is opinion or a order. Phrasing as question can help, "what if we implemented x?"
b) Monthly review of what is good and what could go better can be a great tool. It can get to an issue before it festers among the team. This is critical in my view. Sometimes the team will not agree with one persons complaint. This can get the complainer to realize it is not such a big deal and not think you are ignoring them because the issue is really not that series. As much as you are allowed, tailor the process for the team. What matters is what works for the team. Get the team to buy in to the process.
c) Other ways to think of getting buy is delegating and not micromanaging.
d) listen and be honest
e) My best accomplishments as a manager was when I succeed in getting buy in

2) Dampen the pressure from above. One of the most successful people I have ever met said his job was to be the "fear eater". He would tell his employees, you can't fail at this. I am the one who said we should do it. If we don't succeed it is my failure. I have a hard time succeeding at this and probably one of my bigger failings as a manger. I can't help but show the pressure. I am pretty good at not blaming people which is a critical aspect.

3) Play to the strengths of the team. People naturally have strengths and favorite areas. Give people a little leeway. Let them experiment a little. So contrary to my first statement, sometime it is good to do the things the developers don't like. Just make sure it is really what they are trying to avoid and not just something they are not doing because you are doing it already.

As I understand it, string theory does actually make some predication that are likely testable. Most notable is super symmetry.
http://www.pbs.org/wgbh/nova/b...
A major issue is the number of variations that mean you can knock down one and proponents of the other will cite it as evidence.

Philosopher William James [brother of writer Henry] http://en.wikipedia.org/wiki/W..., wrote that certain question needed to be answered. These were the ones that would effect your actions. For him this included belief in god, because belief in a reward and punishment system in the after life would change what you do in this life [presumably]. I agree with you believing the universe is a simulation is not likely to change behavior because you are living in it and experiencing indistinguishable from reality. The exception might be trying to hack reality.

William James also had interesting thoughts about believing those who experience a mystical experience or otherwise specific reality. He said to believe something, you would have to open to the belief. Having been raised in the west he said he was not open to Eastern theologies. Also, there was not reason to believe someone who had an experience of god. There certain came from an experience but they could not transfer the experience. This relates to what Quine [http://en.wikipedia.org/wiki/Willard_Van_Orman_Quine] said, who I mention in a previous response in this post.

Quine [http://en.wikipedia.org/wiki/Willard_Van_Orman_Quine] has said the "experience under-determines reality" There are many internally consistent theories of realities that can't be "proved". Examples include, belief in an all powerful god, paranoid belief that everyone is conspiring against you, we are living in a dream and of course the simulation idea I posted about.
So of course you are right.

However a test might be formulated that would be convincing to someone who believed in scientific reality.

I like this. The simulation theory predicts that we can generate energy from nothing. This is contrary to most theory. If shown this would be an excellent indicator of a simulation.

More and more physics seems to be relying on simulations. In a case in which a theory has been discarded because it can't account for certain observed phenomena there can be a benefit in show that the theory can't be discarded. However it seems like there are more cases in which a simulation seems to be used as evidence that a theory is correct. http://arxiv.org/abs/1503.0481...

String theory has been somewhat predictive and new experiments in particle physics can be compared to expectation with string theory without needing to modify the theory.

However a lot of theories do not seem to be very testable or have any likelihood of being testable. Here is some "evidence" I came up with for the theory that we are living in a simulation. I use minecraft to illustrate. Probably others have provided the same evidence, I am just not aware of them. It has the same problem of some of theories coming out, it does not seem to be predictive and testable.

1) Quantum mechanics/uncertainty principle.
Assume that any construct must have limited resources.It would require substantially less "memory" and "cpu power" to estimate particles and groups of particles using equations rather than track the particulars of every particle and its interaction. Only when a query for the state of a specific particle occurred would the value be determined. Once the actually value were determined, the behavior would no longer match the shorthand equations that governed undetermined particles.
Minecraft analogy: Minecraft is an unlimited world in which each "block" [piece of earth or other material] can be manipulated. So unlike most game there are no walls or objects that can't be destroyed or moved, etc. Blocks objects are not instantiated until someone interacts with it. In this way many properties are not fully determined until the interaction occurs.

2) Speed of light
The speed of light limits the amount of interaction. It is extremely computationally intensive to have everything interact with everything else simultaneously. With the speed of light, interaction is limited to a single direction from source to object. While two objects might interact together, say by reflecting each other on their surfaces, the reflection is actually showing the other object from a point early in time that was "computed" on the prior "cycle". Aggregates can be used for distance objects. For example the light of a distance galaxy would not need to be computed with every individual particle.
Minecraft analogy: There is a render distance. Based on the graphical and network power the user can adjust the render distance. Objects beyond that distance are not visible and the display does not need to account for them.
Interestingly the speed of light indicates, to some extent, the type of construct. In a typical simulation of a reality, all values are computed simultaneously and then the next time cycle is calculated. This is used when attempting to model of a "real" system in which accuracy is more important than performance.

3) Planck time
This is the equivalent of CPU cycle or a singe "tick" in Minecraft

4) Unusual physics at "extreme" values
Strange things happen and "extreme" values like Bose-Einstein condensates, singularities and perhaps plasma. A construct of a system would be more concerned about behaviors within a "sweet spot" of interest.
Minecraft analogy: Minecraft uses double precision values for everything, including coordinates which are based on an integer number of blocks. There is a place in minecraft called "the far lands". If you travel far enough from your point of origin when the game is created, doubles no longer accurately represent integers. So blocks no longer form a continuous surface and there are occasional missing blocks and the player can get stuck between blocks or fall through "holes" in solid earth.
[Interesting aside: people can get to "the far lands" with mods etc. However once the creator announced the existence of "the far lands" a video blog was created called "Far Lands or Bust" http://farlandsorbust.com/ in which someone started out on an expedition to reach them on foot. So far it has earned over a quarter million in charity since 2011.

Question:
Are there any hypothesis that can later be tested that would provide some proof or disproof of this theory?
Since dark matter and dark energy are still not well explained, is there some predictions one would make based on the theory of the evidence above?

Here are my best ideas for testable hypothesis, however lack of being able to show them does not exclude the theory so they really are not testable.
1) Mutable constants.
Depending on goals of the originator changes to a fundamental property such as the mass of an electron, the strength of gravity or the speed of light might be expected. This could be in different location or different time periods.
2) Hackable reality
At the extreme values we maybe able to manipulate reality. We might even be able to create a various or similar effect. The question is what would be considered a "alteration" or reality. Right now I would say if we can change the speed of light or other constant of the universe it might actually constitute proof of a virtual construct.

In my experience, getting modded is more about getting in the conversation early. Probably few moderators come back to topics, so posting a day later makes for very few mods. That is if they are will to read deep into the comment.

Maybe the change in the number of mods has to do with more posts or how quick you are to read a story. I don't know the formula of number of moderators either. Lots of factors could play into it, including "dying" depending on what you think it means for it to die.