That's cool, but my understanding is that the limit on processor speed isn't the switching speed, we've had transistors that switch at 600GHz for a while now. The problem is making good wires to connect them together, while dissipating heat.
200 sounds like a lot, I wouldn't be surprised if they have only 50-100 engineers. Also 4 engineers per team is too small, it's more likely to be 10-20 per team.
What's so great about Exchange Server that other messaging systems don't have? Because from the client side, it doesn't seem all that special to me.......
They have a training program (for training other corporate teams), a store, a lot of integrations, and of course, a huge sales team. Most of their current open positions are on the sales team FWIW.
.And as much as I appreciate that Sourceforge has long-running CVS and Subversion projects, I genuinely wish they'd simply migrate and discard that technology.
You can use git with sourceforge. You've been able to for a long time, I think longer than github has existed. Some people actually prefer CVS, believe it or not. I don't understand those people, but different strokes for different folks, and sourceforge provides.
One way to handle it is to have some kind of cultural training program. In some places they give new employees some kind of Agile training course by default their first week (from one of the many Agile training consultants). The Arbinger institute has some interesting culture training ideas, too, though not related specifically to software.
Another way to handle it is to bring the new people on as underlings, and over a few months bring them up to full developers. One example for doing that would be to give them zero code review privileges at first, then when they have some experience, give them +1, and when they get even more experience, give them +2. Over that period of time they will get used to what it takes to have quality code.
Another way is to find a book that represents your company culture, and give it to each new arrival to read. There are plenty of such books, give one to your new hire and say, "This is what we are trying to accomplish here." "At this company we're trying to have Zero Bugs." "At this company we do SCRUM." Whatever. The key is to treat the new hire with respect, and realize just because they haven't heard of SOLID principles doesn't mean they are bad: there are plenty of ways to write good software, but it helps to have everyone on the same page.
Different cultures handle it differently. For example, at one company, every developer took a turn being scrummaster for a couple weeks. The leadership positions rotated around (and the actual managers only existed to handle exceptional cases, and make sure things went smoothly). This gave everyone a good solid understanding of how things work, so when new people arrived, it was easier for them to be assimilated. A more random organization might have more trouble.
I think it's more important to train people to be responsible, self-motivated workers than any particular code review or agile technique. As Fred Brooks taught: if you have good people, then any management methodology can work.
When a business is small, every employee can have a good general idea of how every part of the business is progressing and so can make decisions in their area of competence that benefit the business as a whole. The problem is that above a certain size it becomes unrealistic to expect everyone to be following everything going on in the business as well as getting on with their own work. Informal information flow becomes unreliable and a lot of resources can end up being wasted in uncoordinated work.
The solution isn't to hire managers to 'control' people. Of course the CEO has a view of everything and leads the company, and there are many subgroups in the company, and you are right that someone needs (or someones) to go around and communicate the direction to the subgroups, and coordinate things. They also need to make sure the team has the resources they need to keep going, or replace someone who quits.
But when you have managers who are planning out the individual tasks and hours of each sprint for each developer, micromanaging aspects, then you have too many managers and the programmers will slack off or leave because they feel stifled.
Sorry, it doesn't matter how smart each individual is, you have to have leadership and some structure to carry an organization forward.
It has nothing to do with smartness, it's "ability to self manage."
And "some leadership and structure" is not the same as "treating the programmers like they are less competent and can't manage themselves." As a practical heuristic: when the ratio of managers to programmers starts increasing, the quality of the product starts decreasing.
GitHub has hit "hypergrowth," growing from about 300 to nearly 500 employees in less than a year, with over 70 people joining last quarter alone.
Any time you have that kind of growth, you are going to have culture change, and it's going to make people upset if they liked the old culture.
In this case, management is responding to the new people by trying to maintain tighter control on this. This involves hiring a lot of middle managers (mainly so they have someone to order around) and generally treating the programmers like they are less competent and can't manage themselves (probably a lot of the new ones are less competent).
What will happen next is Github will start sucking, and a new competitor will come and replace them (possibly Sourceforge, if they manage to continue with the same enthusiasm they've started with recently, and manage to turn that enthusiasm in to their product).
take the look to independently investigate the research that has been done in this area. There is a lot of bullshit, but there is also work that has never been refuted—work whose significance level is such that it is above and beyond anything except it is adequate in any other area
Please link to this, I am not aware of such research.
That sounds like an invitation for corruption. A few large companies manage to take control of the FCC (or whatever), who then sets regulations that only large companies can follow. Or a similar problem.
It is enough to check if the cable has been certified by Underwriters Laboratories or something similar.
I'm sorry, but his "testing equipment" isn't all that great if it can't handle that.
As someone else mentioned, it wasn't all that great, just a chromebook and a traffic sniffer.
Still, USB 3 is capable of 5amps of current, so it can fry stuff fairly easily.......
Slashdot Mirror
That's cool, but my understanding is that the limit on processor speed isn't the switching speed, we've had transistors that switch at 600GHz for a while now. The problem is making good wires to connect them together, while dissipating heat.
Wow. I guess if it works for them, that's great, but I'm not going to copy them.
Well, someone has to hire the sucky managers.
I have no understanding of the significance of either of those things lol
200 sounds like a lot, I wouldn't be surprised if they have only 50-100 engineers. Also 4 engineers per team is too small, it's more likely to be 10-20 per team.
Exchange Server is one of the killer points, yes.
What's so great about Exchange Server that other messaging systems don't have? Because from the client side, it doesn't seem all that special to me.......
Fortunately, there was a lawsuit, and a lot of the internal emails related to Vista were released for public viewing. You can see for yourself.
Of course, the OEMs also released hardware that they knew wasn't ready. So plenty of people were to blame for that one.
They have a training program (for training other corporate teams), a store, a lot of integrations, and of course, a huge sales team. Most of their current open positions are on the sales team FWIW.
SQL Server, is another reason.
It's been a mistake everywhere I've seen it used.
True, it's nicer than MySQL, but you pay for it.
Wait till you find out they'll actually let you resize the terminal window.
So far, github has done very well at doing so and providing "5 9's" of reliable service.
Wow, they sure lost that one if it was ever a goal.
.And as much as I appreciate that Sourceforge has long-running CVS and Subversion projects, I genuinely wish they'd simply migrate and discard that technology.
You can use git with sourceforge. You've been able to for a long time, I think longer than github has existed. Some people actually prefer CVS, believe it or not. I don't understand those people, but different strokes for different folks, and sourceforge provides.
One way to handle it is to have some kind of cultural training program. In some places they give new employees some kind of Agile training course by default their first week (from one of the many Agile training consultants). The Arbinger institute has some interesting culture training ideas, too, though not related specifically to software.
Another way to handle it is to bring the new people on as underlings, and over a few months bring them up to full developers. One example for doing that would be to give them zero code review privileges at first, then when they have some experience, give them +1, and when they get even more experience, give them +2. Over that period of time they will get used to what it takes to have quality code.
Another way is to find a book that represents your company culture, and give it to each new arrival to read. There are plenty of such books, give one to your new hire and say, "This is what we are trying to accomplish here." "At this company we're trying to have Zero Bugs." "At this company we do SCRUM." Whatever. The key is to treat the new hire with respect, and realize just because they haven't heard of SOLID principles doesn't mean they are bad: there are plenty of ways to write good software, but it helps to have everyone on the same page.
Different cultures handle it differently. For example, at one company, every developer took a turn being scrummaster for a couple weeks. The leadership positions rotated around (and the actual managers only existed to handle exceptional cases, and make sure things went smoothly). This gave everyone a good solid understanding of how things work, so when new people arrived, it was easier for them to be assimilated. A more random organization might have more trouble.
I think it's more important to train people to be responsible, self-motivated workers than any particular code review or agile technique. As Fred Brooks taught: if you have good people, then any management methodology can work.
When a business is small, every employee can have a good general idea of how every part of the business is progressing and so can make decisions in their area of competence that benefit the business as a whole. The problem is that above a certain size it becomes unrealistic to expect everyone to be following everything going on in the business as well as getting on with their own work. Informal information flow becomes unreliable and a lot of resources can end up being wasted in uncoordinated work.
The solution isn't to hire managers to 'control' people. Of course the CEO has a view of everything and leads the company, and there are many subgroups in the company, and you are right that someone needs (or someones) to go around and communicate the direction to the subgroups, and coordinate things. They also need to make sure the team has the resources they need to keep going, or replace someone who quits.
But when you have managers who are planning out the individual tasks and hours of each sprint for each developer, micromanaging aspects, then you have too many managers and the programmers will slack off or leave because they feel stifled.
Sorry, it doesn't matter how smart each individual is, you have to have leadership and some structure to carry an organization forward.
It has nothing to do with smartness, it's "ability to self manage."
And "some leadership and structure" is not the same as "treating the programmers like they are less competent and can't manage themselves." As a practical heuristic: when the ratio of managers to programmers starts increasing, the quality of the product starts decreasing.
Let's be honest, the Github management has always been a mess, so it's more a question of 'when' they self-destruct rather than 'if.'
There are plenty of other places to host a project. Never fear.
:)
If you're cool like Linus, you can throw it on FTP and let the world mirror it.
GitHub has hit "hypergrowth," growing from about 300 to nearly 500 employees in less than a year, with over 70 people joining last quarter alone.
Any time you have that kind of growth, you are going to have culture change, and it's going to make people upset if they liked the old culture.
In this case, management is responding to the new people by trying to maintain tighter control on this. This involves hiring a lot of middle managers (mainly so they have someone to order around) and generally treating the programmers like they are less competent and can't manage themselves (probably a lot of the new ones are less competent).
What will happen next is Github will start sucking, and a new competitor will come and replace them (possibly Sourceforge, if they manage to continue with the same enthusiasm they've started with recently, and manage to turn that enthusiasm in to their product).
The test equipment wasn't designed to test for mis-wirings like this. Most equipment will fail if you plug in something like this, although the USB cable wasn't that bad, it merely had the power line connected to the wrong pin.
His equipment was a laptop and a dongle designed to sniff the USB port for protocol problems. It wasn't expecting something this bad.
take the look to independently investigate the research that has been done in this area. There is a lot of bullshit, but there is also work that has never been refuted—work whose significance level is such that it is above and beyond anything except it is adequate in any other area
Please link to this, I am not aware of such research.
Well said. Heroes aren't heroes because of their perfections, but because of what they do despite their imperfections.
Replace the workers with robots, just like they are doing to their Chinese factories.
Outsourced to Elbonia?
That sounds like an invitation for corruption. A few large companies manage to take control of the FCC (or whatever), who then sets regulations that only large companies can follow. Or a similar problem.
It is enough to check if the cable has been certified by Underwriters Laboratories or something similar.
We don't really see fragmentation, but rather specialization.
And the alternative to specialization is bloatware, so be glad for specialization.
I'm sorry, but his "testing equipment" isn't all that great if it can't handle that.
As someone else mentioned, it wasn't all that great, just a chromebook and a traffic sniffer.
Still, USB 3 is capable of 5amps of current, so it can fry stuff fairly easily.......