> pay-per-download site for *their* music

I guess I missed the word "their" and over interpreted. Since the problem she was addressing in the letter was royalty payments to artists in general and not herself, I was thinking of a generalized pay-per-download system. This would be a lot larger project requiring more complexity and vision in order to achieve its goals. This is what I think would be interest. I agree getting music directly from the artist is not a big thing.

This is a really interesting idea. I don't expect any single artist to do this as they investment of time and effort requires serious dedication. If artists wanted to be business people then they would not have become artist.

However if you could get maybe half of the top 20 artist to agree that it was in the best interest of the themselves and artists in general, they could pull there music form all the other services and form a new non-profit service (non-profit for the service no the artist). The top artists will drive people to the service. The service would use advertising and or fees and all the money would go to the artists / royalty owners.

Basically this is like a union with some very wealthy members such as the NFL's players union. The union would pay a health salary to president and others for the business aspect. The union could negotiate deals with other services if the membership thought it was in their best interest. It would have some of the drawbacks of such unions but in total it would be a lot better for the artists than current systems, if not so much for people who want to stream free music.

Thanks. That is great info. I am happy about my guess. I may be only an order of magnitude off on the # of nodes and I had 5-7 layers [input, 3-5, output] :)

When I was in college the 100 astrophysics class [rocks in space] taught estimation and actually asked how many trees in Chicago on the final. I thought this was probably one of the most valuable things you could teach liberal art students in a science class. One of my co-worker did very well on his hiring interview by doing a very good estimation of the number of veterinarians in NYC. He googled it when it he got home and was able to send a link that was about 10% from his answer. He was cherry picking, sure, but we were highly impressed. He is one of the most successful hires we ever made.

Here is my best answer. I am not active in the field so the answer is a combination of knowledge, extrapolation and intuition. I think it provides some of the kind of info you are curious about

Typically the first layer of nodes will receive input feature detectors run on the image. For example edge sharpness and orientation calculation. This will be at a range of scales that are small compared to the overall picture.

This first layer will connect and provided weighted values to another layer or two that is also probably spatially restricted in range

You would not actually need to have so many independent low level nodes because you can run pieces of the image be the low level node and then rout the output to the next aggregating layer.

On aspect of deep learning is that you would train input nodes based on the final output [or at least high level nodes] rather than back propagating through all the layers. This improves the results and simplifies the interaction, allowing for more nodes to be implemented due to reduce computing time

I tried to google for some practical values, but did not see anything that offered up number just guidelines. I am now quite curious about the value and will have to spend more than 15 minutes searching. If someone has some practical experience and some typical values, I would certainly be interested in the answer. A will now hazard a complete guess. For each 40x40 pixel square I would imaging roughly a hundred of two feature values going into the first layer of nodes on a one to one bases. I would imagine 3 to 5 intermediately layers that tapered down more minimally over the next 2 layers and then more dramatically as it goes to the final layer. This ends up with a ball park calculation for a 2000x2000 image of 2,500 patches [obviously they are overlapping areas but good enough for the estimation] and a first layer 500,000 nodes x 3 for 5 layers of reduced count to get 1.5 million nodes. I am confident that I am within 4 orders of magnitude with this guess.

In fact there are relationships, and how these reflect to human models of both behavior and biologically have been studied
http://www.ncbi.nlm.nih.gov/pm...
The long history of these techniques helps the other show the validity of their work because it is commonly known how reliable and variable the behavior.

The experiment is interesting in itself, it show that stimulation of the cells associated with a memory as it forms will affect their behavior. Additionally the effect supports the hypothesis on how the stimulation would affect the behavior.

Of course there are still ethical and moral consideration.. There may in fact be other better ways to investigate the same phenomina or it may be more ethical not to do the research at. However it is not fanciful sadism. It is a serious attempt to extend the understand of optigenetics, memory, behavior and depression

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.