Awww. I'm glad you found time during all your rockstar full stack development to work out that good management is a myth.
Awww. I'm glad you love MBA-types so much. The biggest project I've worked on is an astounding success because it was created without "managers". And while I certainly don't make millions off it, the company probably generates more than a billion in revenue from it each year. And its not like we had a tight budget or didn't have staff available.
I recommend your next step should be to start a company where you don't bother hiring those non-existent good managers - I'm sure you'll be a millionaire in no time.
Yah sure. Lets have a bunch of MBAs discussing acceptance criteria for stuff they have no clue how to work and *if* it fullfills the business requirements. Lets have software rewritten every 6 months because project managers, product owners and most of the upper layers focus on deliver and not on maintainability. Lets do it your way - after all, there is no chance other people have different experience than yours, right?
Nope, worked with them, dismissed several of them because their behaviour was detrimental to the team (one got sacked because he went and told the book keepers that he was more important than they were and should do what he said).
That basically demonstrates you've worked with assholes, not rockstar devs. Its not the same thing.
The ones who actually make the team better dont consider themselves to be rockstars.
So, you never worked with a guy that is somewhat difficult to manage, but has above-average productivity AND is a problem-solver for your team? I'd say you have pretty limited experience. Or bad luck.
This is how they like to imagine they are, but not what they're like in reality. In reality they are childish and petulant. If their authority and awesomeness is not recognised they will make everyone else's life hell until it is.
You seem to have a pretty strong opinion about people you never met - from your own experience. I'd suggest that is the issue: you do have a comfort zone regarding managing devs, and answering defiance (or what you perceive as defiance) is outside of that zone. That is actually your "problem" (or characteristic), not the guys you get onboard.
Largest organisation I worked for in that capacity was 80 staff with 20 developers (most in a consulting capacity)
Freelancers? You're telling me you managed freelancers and, gosh, they didn't delivered as expected?
I had a pair of senior devs who could keep the team together and moving and were great at it, I considered it my job to keep things out of their way so they could do their jobs.
So, apparently you did have rockstars. To a point where you wouldn't even interfere. See?
This is not the job of a single, lone, "superstar" programmer but of a fluent, experienced, team of professionals who know how to work together.
Having been the "lone superstar" on a couple of global projects, I can assure you there is a time and a place for everyone. While I don't agree with the stupid "10x productivity", a "rockstar engineer" will save you money and trouble, and make sure the project meets or exceeds the criteria. If the only guys you've worked with are unsufferable code monkeys (and usually existing codebases tend to get *smaller* with me, not bigger), its your problem.
And, in my case, having both business experience on the sector and being a full-stack engineer, I spotted and fixed problems in the specifications that would take weeks to identify and fix, saving time, trouble and money. I'm not the most pleasing guy to work with, and as most guys like me, I'm not really attracted to long-term maintenance/bugfixing jobs, but I'd say there is definitely a place for people like me in most projects.
The key to fast project delivery is good management and perceptive staff selection
Good management is a myth, unless your management stack is comprised of individuals smarter than you on the specific field. It can help a lot (and I've worked with wonderful management), but that's it. Its not a silver-bullet.
Looking for a superstar programmer as some sort of silver-bullet is both naive and doomed to failure
Having a superstar programmer in your team will help push the envelope and inspire younger programmers. There is always so much to learn, and not everything is about lines of code. Its about tools, processes, thinking outside the box. If you measure the rate of a programmer by its code deliveries, well... you have flawed metrics and in the end you get what you paid for.
If RH never made another release, there would be similar disruption.
I doubt it. There is an OSS-based fork with many of the features RH clients actually use. Its called CentOS, and that alone is what drives the RH ecosystem. Very few customers actually *run* RH, and those who do usually do it for compliance and certfication issues (think about SAP and Oracle installs).
That doom theorycrafting is irrelevant to my question.
You made no question.
That's also irrelevant. They are distros from a business standpoint. CentOS being interchangeable with Fedora since forever. How they came to be is a footnote.
CentOS has a user base that is probably an order of magnitude bigger than RH. So proportionally, you're just agreeing with me. They are small fish.
My question was about relative usage and some way to measure that metric other than guesswork, as a challenge to the assertion that RH is "a marginal player". systemd adoption in RH is mentioned in 100% of the "discussions" on the topic. So someone here is showing bias.
RH is a company. There are already established metrics for that. Its a mix between revenue and net profit, usually. And as I've shown you, RH is a marginal player.
If you were going to address the issue in an objective manner, you might note Debian, tends to identify itself when you run fingerprinting on servers (e.g. Apache and Nginx). Debian tends to be the most common identifier! Nobody believes the bulk of the responses (with no OS identifiers) are all non-RH (some will be slack, some debian, some gentoo, whatever), so that's an interesting metric that isn't definitive.
No one cares about webservers, and I've never seen anybody buying linux (so, RH customers) to run Nginx. Webservers are a commodity, and can be run in whatever you want. There is nothing that makes debian or linux by itself more interesting than the rest. Many new-breed sysadmins are used to ubuntu, thats why they choose debian.
think I understood completely. Attempting to derail into some form of "RH can be replaced" discussion, is of no interest to me.
RH *can* be easily replaced. Its one of those companies that have no real added value in their stack, other than support. See the evolution of sales of RH and compare it to other players, and you'll easily find out that.
Calling RH a marginal player is simply disingenuous, as of today.
The numbers are there. Like it or don't - it is a marginal player.
Also, SAP and CA's sales income is irrelevant for comparison here, since they aren't in the operating system business.
No, they rely on operating systems as a critical part of their business. The day that operating system is a liability, well.. then business sizes matter a lot.
If RH made a change that impacted Oracle or CA - Oracle or CA would have to adapt.
Are you kidding me? RH is the cheap stuff. Oracle pitches the Solaris solutions for the high-end customers (and that is the big reason they bought Sun), and they maintain their own RH-based fork - Unbreakable Linux. So basically, a prime example of what I said.
The day RH choices disturb any big company from their own ecosystem, they will be eaten alive. And I've shown you the numbers that prove it.
RH *is* a business, Debian is a community effort. Business get bought all the time. Community efforts live while the community is healthy. Debian is quite common because is a simple and easy to install as a barebones version. Not because its better somehow. Its the same dogfood everybody else eats. Btw, and since you mention EC2, imagine Debian adopted something that would disrupt EC2 funcionalities - it would be replaced quite quickly.
I continue to hear this and see absolutely no evidence of it. I see evidence to the contrary, in the US, India and Europe, over the last 20 years. Generally, it's RPM/RH that is first listed. It's not alphabetical. This isn't because they are lucky. The simple explanation is that RH is the most frequently used and therefore put at the top as a simple matter of UI layout (most common choices go to the top of a list, within reason).
This is a fun game, pick me a list that shows more Debian love!
If you rank popularity from the links of the packages, you provably are missing something. I'm a FreeBSD/OpenBSD user, some of the development of Nginx was done in FreeBSD, and you don't even see packages for it in your list. See the flaw in your methodology?
It's what you'd find that you didn't like.
It still is a huge limitation, as you cannot easily sync a local dataset with a remote one.
I assume that's why you ignored Red Shift.
RedShift has a limitation of 16TB per node. Its nice, but not really "big data". Its more like RDS on steroids, and I think RDS is "so-so". Also, you either use sync from/to amazon interfaces, or you're stuck with JBDC, so basically the same limitation you mentioned apply.
I recommend against MSSQL not because it's not a good DB
I'm assuming this is based on your extensive MSSQL experience, right?
but because it's cumbersome to work with outside of the Microsoft ecosystem.
Well, at least MS has half-decent tools for it. Other than Oracle, they're the only player with a decent GUI interface.
You mainly interface with it using ODBC and that's a pain outside of Windows.
Or JBDC. It depends. Its not really Microsoft's fault if it doesn't work in your environment, is it?
You're stuck with windows boxes on the back end AND on the front end.
You just summarized 2/3rds of the corporate world.
You could start your project with Postgres and find out why you're unhappy with it and plan for a migration to something which is better for you post-hoc: Don't write SQL procs, and don't weave your SQL through a whole lot of code.
You could, and then figure out how to integrate it with your environment. And *WHICH* ODBC driver to choose. So, the pain you just described previously, its right there. With a half-assed, subpar connection driver.
The only OSS solution that comes somewhere *near* what MSSQL does is PostgreSQL, and its a second-class citizen in Windows. And even PgSQL is easily suprassed when looking at features and replication options.
Note: I'm a huge PostgreSQL fan, to the point of writing C# applications with the native PostgreSQL driver without LINQ support.I'd take PostgreSQL over MSSQL everyday of the week if reporting tools, support, features, replication and integration doesn't matter. But saying that MSSQL is bad, is just a silly mantra.