people who are good at IT operations make their job look too easy. A fool looking at the lack of drama in a well-run data center is apt to mistake that for the job being easy.
This is so true. The Instant Hero gets all the credit, where all the small preventative actions that keep the system oiled, consistent, and clean get mostly ignored. Make a list of preventative actions and mention them at your next performance review. You have to sell the idea that prevention is powerful.
And sometimes keeping a clean system requires saying "no" when somebody wants something custom or special without any real justification beyond "we like it that way" or "don't question my authority". Those who dole out special favors and ego-enhancing customization are often rewarded even if they complicate the system in the longer run.
Our org allowed Chrome because IE had too many bugs. Having an alternative reduced help-desk calls. Chrome has bugs also, but the chance of both Chrome and IE having the same bug is small. If an app or feature doesn't work on one, it will likely work on the other. It's a screwy state of affairs, but it's practical.
I will partly agree and give him credit for at least actively acknowledging itches that BOTH parties failed to scratch: leaky borders* and lopsided trade.
That doesn't necessarily mean he can or will do anything about them. Talk only takes you so far. I believe his inattention to detail will eventually politically sink him, but we'll see.
As far as H being an allegedly bad candidate, remember that T also thumped each and every GOP candidate. H was politically lack-luster, but mostly competent to run the ship, unlike T.
I worked under an executive like him once, and BS and exaggeration eventually runs out of steam when neglect of too many details makes the ship too leaky to stay afloat. Details matter in aggregate.
* GOP gives borders lip service, but biz bribes them to fake it and look the other way so that biz has cheap labor. They punted several times when they had the chance, including a Dem bill to fund more border guards.
This woman replied that she thought it was gross of me to refer to the woman in my life using the term ["my wife"] which implied that she was a possession...
One of my favorite sayings is "don't complain without having an alternative ready".
I'll agree that phrase is a bit awkward, but what's an alternative that doesn't introduce new forms of awkwardness and/or confusion? "The lady I'm married to" is long-winded: "That's a good idea, I'll run the plan by the lady I'm married to and get back to you."
What if being pecked by a chicken has different risk & diseases than being pecked by a turkey? And if the difference is not tracked, how will anyone know the risk is different?
The code could "require" a parameter which is the animal type, but then each typist will enter it differently, making statistical analysis more difficult. One will enter "chicken", another "poultry", another "rooster", etc.
Specificity by itself is not necessarily bad. Although, accurate encoding may require quite a bit of time from doctors, clerks, and patients. The trick is either finding a happy medium or improving encoding assistance/UI technology,.
(Farm animal injuries are probably fairly common in rural areas. Us suburban folk may overlook the frequency.)
Tired meme. Venezuela failed because they married their economy to oil. Narrow product focus can also mess up capitalism. In fact, Adam Smith's "Comparative Advantage" encourages putting too many eggs in too few baskets. It can be quite profitable in the shorter term, but bite hard later. Focusing on "big ticket" manufacturing slammed the USA "rust belt", for example, because it stopped being their comparative advantage.
Personnel are not even so much the problem...It's more about the total opaqueness of all pricing: nobody knows what anything costs.
There was a push to codify all billable medical expenses for better billing and cross-org comparing, but many in the industry complained about the complexity and learning curve of the systems. There's either too darn many treatments to categorize, or the categorization method/philosophy(s) needs a rethink.
People like you are the bane of my existence... when your undocumented, unsupportable [bleep] is causing *my team* to field support calls at 2 AM on a Sunday morning.
That's a common problem. "Semi" IT people "in the field" get something practical up and going, but it's a potentially huge maintenance headache down the road.
The snag is that the "central" IT office usually doesn't have the resources to "do it right" from the start. They get more requests than they can handle, in part because many requests are bogus, but it takes analysis to know that.
And when the rogue app breaks, SOMEBODY has to try to fix it, and that somebody is often the central IT people when the lone-wolf builder is on vacation or leaves the org.
But one advantage of this is that the lone-wolf builder has the domain knowledge and direct contacts to make the customers/user happy, at least while it all works. They are doing much of the analysis, prototyping work, and proof of concept. If and when a formal project is started, much of the domain-study foot-work is already done.
One guy at our org cranked out bunches of apps in MS-Access that users loved. But he retired, and database file corruption issues and lack of documentation created problems for those trying to fill his shoes. However, his apps road-tested his concepts and many were ported to formal apps when the time came.
The "panic fixes", like your 2am call is still a friggen bummer, though. I don't know of a good solution. Perhaps a compromise can be made whereby the lone-wolf dev is required BY POLICY to answer a series of questions about support and do basic documentation. The questions and requirements may also encourage them to consider maintenance issues. Example questions:
Is this project critical to the organization?
What are likely problems if it stops functioning correctly?
Are you the only one who knows how to fix it?
Is there a "manual" alternative procedure in case the automated one fails?
Is there app documentation? If so, where?
Are there regular backups of the software and data? If so, where?
The liability will be too great. Every accident will be the "car's fault" and result in litigation.
I suspect self-driving cars will be on average more reliable than human drivers once the kinks are worked out. Humans drivers are often inattentive, emotional, hyper, and/or drunk. I've seen way too much crap.
Thus, there's an overall insurance savings to be had. The hard part is the politics and business side of distributing the savings. Thus, it's probably more of a "social" issue than a technical issue.
We don't have a free market medical system. We have a cronyist monopoly enforced by laws written by hospitals and pharma company. If the medical system produced computers, a PC would cost about the same as a Lamborghini.
Explains Microsoft Windows: the complexity of a Lamborghini but the performance of a Yugo.
Monopolies and oligopolies almost always end up sucking. Newly arrived x-opolies may be okay, but over time they grow sloppy, evil, slow, and/or anti-competitive due their size (influence power) and lack of competition.
The problem is that medical services may require economies-of-scale such that having say 7 competitors in a given market, especially rural areas, is just not realistic. Medical services are just not the same market profile as manufacturing light-bulbs.
There are so many liver specialists within driving distance. Having 7 liver specialists for 7 different insurance companies within driving distance for rural areas probably means many liver specialists would be sitting idol (or trolling slashdot). Sure, fewer could contract out to share their services, but they'd probably be able to charge high or be lackluster because they are just about the only game in town. Thus, lack of competition comes right back into play. The problem of lack of competition hasn't been solved even with 7 insurance co's.
Slashdot Mirror
This is so true. The Instant Hero gets all the credit, where all the small preventative actions that keep the system oiled, consistent, and clean get mostly ignored. Make a list of preventative actions and mention them at your next performance review. You have to sell the idea that prevention is powerful.
And sometimes keeping a clean system requires saying "no" when somebody wants something custom or special without any real justification beyond "we like it that way" or "don't question my authority". Those who dole out special favors and ego-enhancing customization are often rewarded even if they complicate the system in the longer run.
Our org allowed Chrome because IE had too many bugs. Having an alternative reduced help-desk calls. Chrome has bugs also, but the chance of both Chrome and IE having the same bug is small. If an app or feature doesn't work on one, it will likely work on the other. It's a screwy state of affairs, but it's practical.
Right up there with the dude who invented neckties.
Because oligopolies control the payment market. Break them up and you'll get faster systems.
{sarcasm} It's a good thing other religions are honest and unbiased. {/sarcasm}
I will partly agree and give him credit for at least actively acknowledging itches that BOTH parties failed to scratch: leaky borders* and lopsided trade.
That doesn't necessarily mean he can or will do anything about them. Talk only takes you so far. I believe his inattention to detail will eventually politically sink him, but we'll see.
As far as H being an allegedly bad candidate, remember that T also thumped each and every GOP candidate. H was politically lack-luster, but mostly competent to run the ship, unlike T.
I worked under an executive like him once, and BS and exaggeration eventually runs out of steam when neglect of too many details makes the ship too leaky to stay afloat. Details matter in aggregate.
* GOP gives borders lip service, but biz bribes them to fake it and look the other way so that biz has cheap labor. They punted several times when they had the chance, including a Dem bill to fund more border guards.
That's okay, I spend 40% of my time working around app response and usage problems created by overly-aggressive McAfee settings put there by Security.
Um, you're not helping.
He can only stuff so many judges in 4 years. I sure hope it's only 4.
I for one welcome our.....screwit--the bots are coming, run!
So far Checks and Balances are working fairly well to keep him in check. Chalk one up to the forefathers' design. Viva C&B!
3rd world countries being 3rd world countries.
I don't know, but it's only a misdemeanor to beat the metallic shit of them.
Does the source really matter much in this case? If so, please explain.
One of my favorite sayings is "don't complain without having an alternative ready".
I'll agree that phrase is a bit awkward, but what's an alternative that doesn't introduce new forms of awkwardness and/or confusion? "The lady I'm married to" is long-winded: "That's a good idea, I'll run the plan by the lady I'm married to and get back to you."
So now both corporations and pitbulls are people.
You have scientific proof more discrimination will end violence? Otherwise, STFU, FoxBoy!
-5 angry political rant
What if being pecked by a chicken has different risk & diseases than being pecked by a turkey? And if the difference is not tracked, how will anyone know the risk is different?
The code could "require" a parameter which is the animal type, but then each typist will enter it differently, making statistical analysis more difficult. One will enter "chicken", another "poultry", another "rooster", etc.
Specificity by itself is not necessarily bad. Although, accurate encoding may require quite a bit of time from doctors, clerks, and patients. The trick is either finding a happy medium or improving encoding assistance/UI technology,.
(Farm animal injuries are probably fairly common in rural areas. Us suburban folk may overlook the frequency.)
Tired meme. Venezuela failed because they married their economy to oil. Narrow product focus can also mess up capitalism. In fact, Adam Smith's "Comparative Advantage" encourages putting too many eggs in too few baskets. It can be quite profitable in the shorter term, but bite hard later. Focusing on "big ticket" manufacturing slammed the USA "rust belt", for example, because it stopped being their comparative advantage.
There was a push to codify all billable medical expenses for better billing and cross-org comparing, but many in the industry complained about the complexity and learning curve of the systems. There's either too darn many treatments to categorize, or the categorization method/philosophy(s) needs a rethink.
That's a common problem. "Semi" IT people "in the field" get something practical up and going, but it's a potentially huge maintenance headache down the road.
The snag is that the "central" IT office usually doesn't have the resources to "do it right" from the start. They get more requests than they can handle, in part because many requests are bogus, but it takes analysis to know that.
And when the rogue app breaks, SOMEBODY has to try to fix it, and that somebody is often the central IT people when the lone-wolf builder is on vacation or leaves the org.
But one advantage of this is that the lone-wolf builder has the domain knowledge and direct contacts to make the customers/user happy, at least while it all works. They are doing much of the analysis, prototyping work, and proof of concept. If and when a formal project is started, much of the domain-study foot-work is already done.
One guy at our org cranked out bunches of apps in MS-Access that users loved. But he retired, and database file corruption issues and lack of documentation created problems for those trying to fill his shoes. However, his apps road-tested his concepts and many were ported to formal apps when the time came.
The "panic fixes", like your 2am call is still a friggen bummer, though. I don't know of a good solution. Perhaps a compromise can be made whereby the lone-wolf dev is required BY POLICY to answer a series of questions about support and do basic documentation. The questions and requirements may also encourage them to consider maintenance issues. Example questions:
Is this project critical to the organization?
What are likely problems if it stops functioning correctly?
Are you the only one who knows how to fix it?
Is there a "manual" alternative procedure in case the automated one fails?
Is there app documentation? If so, where?
Are there regular backups of the software and data? If so, where?
Irony, per guy who fouled up the slashdot quoting (me). Viva Mondays.
Do you know a Mike Rowsoft by chance?
Explains Microsoft Windows: the complexity of a Lamborghini but the performance of a Yugo.
Monopolies and oligopolies almost always end up sucking. Newly arrived x-opolies may be okay, but over time they grow sloppy, evil, slow, and/or anti-competitive due their size (influence power) and lack of competition.
The problem is that medical services may require economies-of-scale such that having say 7 competitors in a given market, especially rural areas, is just not realistic. Medical services are just not the same market profile as manufacturing light-bulbs.
There are so many liver specialists within driving distance. Having 7 liver specialists for 7 different insurance companies within driving distance for rural areas probably means many liver specialists would be sitting idol (or trolling slashdot). Sure, fewer could contract out to share their services, but they'd probably be able to charge high or be lackluster because they are just about the only game in town. Thus, lack of competition comes right back into play. The problem of lack of competition hasn't been solved even with 7 insurance co's.