Probably the biggest advantage is the time it could save for employees to have a system configured to do what they want to do, rather than what the IT department wants it to do. I work in a company with 500+ employees, and I think we spend the equivalent time of about 20 full-time jobs on waiting until our computers are willing to respond. That's more than there are people in our IT infrastructure team! If it sounds like a lot, then remember that a working day has only about 500 minutes, so if everybody has to wait one minute, that adds up to one full working day for us. You could argue that many people spend more time chatting over coffee, but chatting over coffee can actually be useful, whereas drumming on the table with your fingers until your computer responds again is not. Anyway, savings in IT time could very well be infinitesimal compared to savings in user time.
Having leaner, simpler configurations better tuned to do actual work, instead of meeting IT management functions, could be of major benefit to a company. It would not only save time, but also result in happier employees.
Even when it comes to setting up new systems, my experience is that skilled users have systems that are leaner, faster, cheaper, and more stable than professional IT teams. I don't know why, but I would guess that it is because users are inclined to take something that works out of the box and just use it, while IT people would start to tinker with it until it meets a dozen extra requirements, put it on a shared server with five other systems, and install it according to the internal SOP. When an user needs disk space, he buys extra disk at $1 per gigabyte, or thereabouts. When he needs to ask IT, then IT will buy an approved system at $2 per gigabyte, add $8 extra for maintenance and administration costs, and charge the user $10. Yes, some of that extra work is actually very useful, such as taking backups; but much of it isn't.
As for security, my experience is that cover-all security procedures that lock everything down tight and try to maintain fixed configurations, mostly serve to cover the ass of the IT responsible. Half of the time they don't really work anyway, or have gaping holes in them. Some of our IT people do maintain a high level of security in their area, but that's because they are very flexible and adaptable, and always seek to work out the best solution that serves both security and functionality -- so users respect them, and try to cooperate. Overall, it might be better for the IT department to adopt a reactive strategy, by scanning for real security risks and intervening when they occur, instead of fostering the illusion that they have everything covered.
I suggest looking for an opportunity in a small start-up. Perhaps you don't want to associate with the proverbial two nerds in a garage, but you can learn much more in a small firm, that perhaps has a dozen people dividing all the work between them. You'll learn to do much more than programming, and working in a small firm is more fun. And besides, a small cash-strapped start-up is more likely to hire a college kid to do some coding, than a large established firm.
There may also be good opportunities in companies that aren't in the IT sector, but in research & development, for example a biotech company. Usually these companies don't have very strong IT departments (and again, you will learn more in a small team), and they will hire people on short term contracts to complete specific projects. Even a medium-sized biotech might not employ a single skilled C++ programmer on a permanent basis (the density of C/C++ programmers in this environment is around 0.3%), so they might be willing to hire you.
Or, if it interests you, look for small firms that develop hardware, such as instrumentation, robotics, or consumer electronics; or small engineering outfits that produce custom development and automation. There isn't that much C/C++ in a typical IT job these days, rather a lot of the work is now in web development, database applications, Java and.NET. But people who interact with hardware, especially if it's time-critical, still have a need for the level of detail and control that C can offer.
And probably it's best to work through an agency or consultancy firm. I don't know US practice, but on this side of the pond it IT directors who need and extra person on the team won't place adverts or look through job applications. Instead, they will send out a request to specialized agency or consultancy firm.
In my eyes the fundamental problem is the lack of ambition of many IT managers and IT departments. This isn't the same as nerdiness, but it is a consequence of it. It does not occur to most IT managers that they should strive to make the company better -- more efficient, more profitable. It does not occur to them that they should try to change and improve the way in which people work. As a matter of fact, I've heard IT managers blithely and explicitly state that they don't want to contribute to better business processes; they just want to regard the business processes as a given, write a full set of specifications around it, and write some software to support it.
If Apple had been governed by this spirit, they would have produced a handy mini-computer to help people manage their gramophone records, not the iPod. If Amazon had had this mindset, their website would be accessible only from bookshops. Some people have vision, and others do not. If knowledge is power, then information could be money, but some people don't recognize money even if they step on it every day.
Instead, such IT managers tend to focus on making a computer run better. Perhaps a new printer server, and a safer anti-virus scanner. Replace all telephones by a new type, which nobody understands. Rewrite all the old COBOL software in.NET, but keep the same screen layout, to avoid confusing the users. Demand that no software installations are done, however small, if someone in Brazil did not write an automated installation script. Deliver all new PCs with Windows Vista, regardless of which applications people want to run on them. Usually all the good IT people walk away from such tedious and surreal jobs, but worse, the business leaderships walks away from it as well. If it's plumbing and routine maintenance, they don't want to think about it; and why should they? And why spend money on something which doesn't promise any real improvement to the bottom line?
As I wrote, nerdiness plays a role in this. Too many IT people just don't seem to have a serious interest in what happens outside their own department; they just want to do hardware or software. They don't understand business, they don't understand other forms of engineering, and they don't understand R&D -- and they don't want to! For business users, these are horrible people to deal with. I have gone as far as recommending that we shouldn't hire more professional IT people for the IT department, but engineers and scientists and economists with an interest in IT. That is, no doubt, unfair; there are IT professionals with wider ambitions and skill sets. Unfortunately, the average IT department doesn't see, to be able to hire or retain them.
The final tailspin usually comes when this curious, stoical detachment from the core business is formalized. The IT people think it over and say, we don't talk to the people in the business groups anyway, so why not all sit together and enjoy our own company, in one big IT department? And why not outsource all the support functions to the Comores? If you don't have any meaningful contact anyway, then distance indeed doesn't matter.
But in reality, that isn't a sustainable model. Some people in the business department still need some innovative, creative IT work done, and because the IT department doesn't seem interested in or capable of solving the problem (and at this moment the IT department often seems as mythical as the Kraken), they will do the work themselves. Getting together a few gifted amateurs, and start over from scratch as if the IT department never existed (while cursing it at the same time, of course). Then a manager will have the bright idea of formalizing this into a new IT group, and so the wheel turns round again...
Re:From reading the summary....
on
Reading Comics
·
· Score: 1
Agreed, reading the table of contents and browsing the index, this seems very much an American centric view, like a book on whisky written by an Irishman. There is a reference to Herge and one to Asterix, but no mention of for example Hugo Pratt, Franquin, Tardi or E.P. Jacobs, which is really baffling in any book about comics! And of course no mention of at all of gods of lesser influence such as Jije, Andreas, Schuiten, Rosinski, Charlier, Hubinon, Manara, Gazotti, Tillieux, Toonder, Morris,... to mention a random selection.
But there are and always have been distinct traditions between the Anglo-American and the European comic market, and with exceptions such as Eisner and Herge (and unfortunately, Peyo's worst creations) few have achieved any success or even respect in both markets. To an outsider like me the US comic seems very much an "action" genre, at its best and worst. From "noir" comics dealing with a more or less violent struggle for life, to brains-on-zero superhero comics turned out like sausages. The European market, on the other hand, has its share of action but does a lot more storytelling and satire, often relatively slow paced.
I wonder whether this is because of different inputs; i.e. American comic tradition fed on movies, and more recently on television. The European comic tradition grew more out of traditional books, perhaps simply because visual culture arrived later here, and in the case of some authors, even poetry. So they started out with very different sets of unwritten rules about content, pace and storytelling, and they stuck to that.
I have no insights to offer on how to become an IT manager. Frankly, it seems such a thankless and boring job that I would presume a severe shortage of candidates. But I freely offer the following advice on how to stay an IT manager and not get fired:
Keep your department firmly aligned on the same set of business goals as the other managers, and be transparent about what you do to achieve them. IT has a tendency to develop into a "black box department" with its own arcane rules, bureaucracy, and mysterious business objectives. It is seductive to run it that way, but your CFO won't ask whether you have implemented extreme programming. He will ask what your contribution to the bottom line is.
Listen to your hands-on workforce, and make sure you maintain a good understanding with your technical staff and make a positive contribution to the success of projects. Technical success matters, and people management matters. At the end of the day, managers are far more expendable than technical leaders. If projects fail, CEOs will do what owners of sports teams do -- replace the coach. And you wouldn't be to first IT manager to be ousted after a conflict with a senior consultant software developer.
Learn to budget properly: Money, resources, and time. For one reason or another IT managers always seem to underestimate the cost of projects, and then have to report huge overruns and beg for money from other groups. It's much better to be realistic, even when that involves scary amounts of money. A Swedish businessman once said: There are three ways to burn money: Horses are the easiest, women are the most fun, and engineers are the fastest.
Above all, resist the urge to be kingpin of your own little world. Like the knights of King Arthur, IT managers exist to serve. Your engineers and developers do not work for you. They work for the company, and actually you work for them. The day that your engineers feel that their main task in working life is to make pretty powerpoint presentations for you, you've lost it.
It's fair enough to say that any job involves risks, and it certainly sounds as if this Ebola replicon is reasonably safe. On the other hand I would require convincing evidence that the virus cannot mutate to replicate without VP30, which apparently is mainly a transcription activator. Because this virus maintains its genome as RNA without ever encoding it in DNA, it has a very high mutation rate. Or that it cannot pick up a suitable gene by hybridization; co-infection with another negative strand RNA virus might be enough.
In any case, I can image that people who work with Ebola viruses might find that they have to lunch alone. And I wonder what the neighbours would think of it.
Let alone the IT people, of course. I know from experience how difficult it can be to make an IT guy enter a HIV laboratory to set up the network connections... For a BSL3 with Ebola virus we probably would have to pay them Blackwater rates.
Belgium has a 99% cable distribution network, you have to be eccentric or live in a caravan not to have cable. But we have a fairly high distribution level of DVD recorders, as well. (Judging from what I see -- I don't have any statistics.)
Of course the economics of cable television are different. Our channels do not (need to) recycle shows at the very frequent rate of US channels; they may repeat the same broadcast twice in a year, and that's it. (But they do make popular shows available on pay-per-view over digital television to satisfy fans who can't cope with having missed it.) That encourages recording.
On the other hand, I would assume that the astronomical high frequency of commercial breaks on US television would stimulate the sale of recorders, because they at least (for the time being!) allow one to fast-forward the commercials.
Yet at the same time the commercial break may discourage recording on DVD. To put something on DVD in a decent format, you would have to spend an excessive amount of time editing it to make a continuous story out of it. Better to buy it on DVD.
Another reason I could think of is the generally poor quality of NTSC encoding compared even to PAL. Buying the DVD gives people a much better image quality.
(1) Close Gitmo and the CIA's secret prisons. Ensure that everyone who committed or organized crimes, such as abduction, torture, and illegal listening operations, under the previous administration(s) is duly prosecuted. Don't give ANY pardons, not even to Dubyah himself. The good reputation of the US needs to be restored.
(2) Scale down the presence in Iraq, as there is no other option, but stay there as long as the Iraqis want it. The USA messed up the country badly, it now has a duty to see it through. Listen to commanders on the ground. Respect the sovereignty of the Iraqi government.
(3) Slash military budgets by 20% or so -- there is no need to outspend the rest of the world combined, and there is sufficient pork and useless prestige projects in the budget to make that cut without endangering the safety of the USA. Spend the rest of the money on useful things, such as body armour, suitable vehicles and decent care for wounded soldiers.
(4) Seriously reform the legal system, to make it run faster and fairer, and restrict unethical behaviour of prosecutors and defense lawyers. Everybody deserves an actual fair trial, and currently most cases are ended by plea-bargaining because the US legal system can't handle the case load.
(5) Start a serious program to reduce global warming and the dependence of the USA on (imported) expensive oil.
(6) Reform the health care system on the principle that people are free to choose their insurer, but must all have one. Cut out excessive profits, huge advertising budgets, and ambulance-chasing lawyers. Invest in prevention.
It depends on what the IT department is doing for the company. If the company is selling hot dogs or pursuing some equivalent activity, then IT is not going to generate value. IT then just supplies administrative tools to keep track of things, and having your own IT department may make as much sense as making your own paper.
If the company is in high tech, research & development, or in an environment where logistics are critical, then IT could make a real difference in the efficiency and profitability of the company. Then outsourcing it amounts to being satisfied with second-rate solutions and a business handicap, because no external supplier is going to understand your business well enough to make a competitive difference.
On the other hand, if that is the case, the company probably should not have an IT department. It should have an engineering department which considers IT just as one of the many available tools to improve the profitability of the company. In many cases IT developments only make sense in harmony with other forms of engineering; a robot needs both hardware and software.
So in a sense, I would back the idea that the IT department as such is dead. If the IT group is just doing IT and not involved in the rest of the company's business, then it might as well be outsourced. If it is an active, fully involved player in the company business, then it is there to stay, but then it is much more than just an IT department.
Actually, I doubt that the simple jammer installed on an airliner would be able to defeat the seeker heads of a modern AIM-9 variant that easily. But presumably a fighter jet would first get close enough to the target to do a visual inspection, which would mean that it would be well within gun range. And besides that, most US fighters carry AIM-120 as well, which does not use IR for guidance or fusing, so would be reasonably effective.
The other side of the issue is that, of course, not all man-portable air defense missiles (MANPADs) are infrared guided, and a smart terrorist would respond to this measure by picking one that isn't. Stocks of Blowpipe have been found in Afghanistan -- It wasn't good enough to fight the Soviets, but would still be able to down an airliner.
I agree with your comment about the Overlords. However, I think that they do have a point that having IT skills alone is not good enough. You should know what you need to produce as well as how to produce it. In the ideal world, IT customer and IT supplier would be the same person (or at least share a brain) which would presumably ensure perfect understanding of what the customer needs (not the same as what the customer wants). In reality, it is enormously important that IT people have the ability to understand the customer's problems and relate to them.
Of course they should have good IT skills as well, I've seen far too much crass amateurism to deny the need for good IT skills. And I intensely dislike the fact that we have IT managers without IT skills, who are nevertheless trying to promote the technical standards of their choice. Nevertheless, giving the choice in my role as a customer, I would always prefer an IT-er with whom I can have a constructive debate, can develop an intuitive understanding of what I need to have, and can be an effective contributor to a team that also has other tasks beside setting up and maintaining IT systems. To curse in the church: I think IT should be a skill and not a job. The job is doing whatever needs to be done.
Quite possibly this is what went wrong with Vista. Vista seems to have started out as "Windows As IT People Thinks Windows Should Be"; cleansed of Windows' notoriously compromised kernel design, more secure (or at least with fewer gaping loopholes), and the kind of nifty user interface features that programmers are proud of when they achieve them. The problem was that that was very much an abstract IT ideal; it is not what the customers want or need, it does not seem to make any business sense, and worst of all, it could not even be achieve its own goals.
Back to Overlords: I've been in R&D for long enough to recognize that large companies tend to be dominated by authoritarians with tramline thought processes, especially when they are "professionalized" and managers from other sectors are brought in. Board-level decision processes often betray an appalling lack of floor-level business knowledge. That's not exclusive to IT, or to Microsoft. Microsoft as Bill started it, probably was a very different and much more effective organization than the Microsoft of today.
What such organizations need to shake them up are men like the late Admiral of the Fleet John Arbuthnot "Jackie" Fisher, Baron of Kilverstone (1841-1920), who after he joined the Admiralty as director of Naval Ordnance, "asked for a list of things I was not allowed to have and have got them all but one."
(1) Be Mr. Know-it-all. Help-desk time allocation does not permit help desk people to spend long hours gnawing on some troublesome issue -- or even to spend fifteen minutes searching the knowledge base. Don't pressure your help desk representative to find a solution for you if it is not obvious; you will only make him or her miss the set monthly quota of tickets solved. Solve your problems yourself, then send the solution to the help desk for future reference.
(2) Know nothing. Be deaf, blind and stupid, whenever appropriate. The managers of support organizations are always eager to lighten their own budget by transferring work to the people they are supposed to support; it makes them look good and the costs of this neat operation are invisible in the budget. It may be in everybody's best interest that you are too stupid to connect a cable.
(3) Be entitled. Fact of life: Nobody below the rank of vice-president really gets quick, responsive IT support. There is never enough support to give everybody a fair share. Always make the highest-ranked person in the room put in the support call. Bosses are routinely put in Cc: on every request to the help desk because of the widely held belief that this speeds up service. However, remember that pulling rank is like buying expensive cars: If you need to ask, you can't afford it.
(4) Point fingers. It is very important to point fingers from time to time, but do it wisely. If people didn't point fingers at ridiculously cumbersome policies and unproductive tools, company policy would still require the use of Roman numerals for all official calculations. Of course you can't trust these new-fangled Saracen numbers -- and what does this 'zero' mean, anyway?
(5) Whiz, but whiz discreetly. Remember that professional IT support organizations are nearly always set up to maintain, not to develop. If you need to create some new software system, you'll do it considerably faster, cheaper, and better if you don't involve IT at all. At the very least it will save you five hours a week that you would otherwise spent in meetings with them.
I suspect that if you are involved in "projects that drift", then the basic problem is not coding quality. I have recent got involved in some absolutely terrible projects myself, and my impression is that the #1 problem is giving too little priority to design. Software engineers should understand the problem they have to solve as well as the customer -- actually, they should understand it better than the customer. Or alternatively the customer, and not some external IT guy who has first to be taught the basics, should be able to do the top-level software design. (Because understanding the task the software should accomplish, is usually more important than knowing the technical details of the implementation.)
Unfortunately, customers usually assume that software design is a trivial problem that any typist should be able to do after a few hours of explanation. And as for so-called IT professionals --- don't get me started on the crass amateurism that I have witnessed. The result is often that the programmers create gordian knots in an attempt to make the best of a chaotic design. That's not their fault. You'll go mad if you start worrying about it.
But if you have a good design, then achieving good coding quality should not be that difficult, if you are technically competent. I've noticed myself that when I am writing bad code, overcomplicated, unstructured, intertwined, and full of bugs, then the reason is often that I don't properly understand what I am trying to do. Because the design is wrong. If the design is correct, then it should be clear what a piece of code should do, and writing it should be relatively straightforward, and you should not introduce complicated bugs -- because you know how it is supposed to work.
So my first advice is: If you have the feeling that you should to be ashamed of the code you are producing, then stop right there. Probably your design stinks and you don't understand what you are doing. Re-analyze the problem, break it down in components again, make sure that you properly understand every step. Think it over thoroughly. If possible, go for a walk; that usually helps more than staring at your screen. Then first redesign, then rewrite.
As for coding style, I think it is most important to be consistent. I once got back a mathematics paper back from my teacher with a bad grade, not because the answer was wrong, but because there was no method to it. "Use a method" was what he wrote on it. I still hate to admit it, but he was right.
Most people don't use the full vocabulary of their programming tools, which in case of languages such as C++ is not a particularly good idea anyway. Instead they develop patterns which they understand and routinely re-use. It is best to adopt some set of patterns as your own; which one does not matter that much as long as you are aware that you rely on them, that you understand how they work, and are familiar with their pros and cons. From time to time step back to analyze your code for repetitive patterns; and think of what you should do with them -- retain them, build on them, forget about them.
The one advice I would give is that if you are using a coding style that aims for saving on the number of letters and braces you type, that is probably not a good idea. Saving on typing should be at the very bottom of your list of priorities. You should nearly always go for highlighting the structure, if you can.
Personally I also tend to over-comment, documenting every private field and method. And I write my comments first, and the code later, on the principle that you shouldn't be writing a class or a method if you can't explain what it is supposed to do. Of course I usually have to update the comments later, because one always modifies the flow a bit to optimize it, but that is fine.
In reality you have to identify/control the lifespan of objects anyway, so I personally never understood what the big deal is about freeing memory manually.
Many, maybe even most, objects of which you would handle the lifespan manually in a Java application, are resources that exist on a single thread. Dialogs and various I/O objects, for example. And yes, I've also made the mistake of giving a dialog a reference to 30 Mb of data, and then forgetting to dispose of the dialog (instead of only closing it). Mistakes do happen. Nevertheless managing objects on a single thread is relatively easy and involves little overhead.
But the objects that are shared between different threads are very often the kind that can be safely left to the GC to handle. Of course, you can exchange objects between different threads in C++ and still manage the memory, but frequently enough you'll find yourself incrementing and decrementing references all over the place, adding management code and complexity. Or you have to rely on libraries that do it for you, but impose limitations that completely mess up your neat design. If there is a GC that can accurately figure out whether an object is referenced or not, that saves a fair amount of coding in a multi-threaded application, and eliminates hard-to-debug errors. It also simplifies the design.
Yes, there may be resources that are shared between threads and cannot be left to the garbage collector to properly clean up. Database connections, for example. But it's less costly to handle a few objects manually, than all of them. And for a single-threaded piece of code there may indeed be little to choose between GC and manual memory management; the latter is likely to be a bit more efficient. But how many serious applications are really single-threaded these days?
I admit that I have enough C++ background to feel uncomfortable, from time to time, with the idea of allowing the GC to handle things. You wonder what the lifespan of an object will be, and have no sense of closure. But actually, often enough not worrying about things is the right solution.
A nice idea. I must be one of the rather few people who have worked with ultrashort pulsed lasers, Raman scattering, and viruses; and I really appreciate the interest of the concept. But I doubt very much that it will ever be a practical tool. Destroying M13 virus in pure water is a far cry from a real application.
If I understand it correctly, the technique exploits the fact that ultrashort laser pulses are not monochromatic but have a significant band width, to excite a vibrational frequency of the virus through resonant Raman excitation. Or, the vibrational mode of the viral capsid is about 8 cm^-1, and the excitation laser contains both 23,529 cm^-1 (i.e. 425 nm) and 23,521 cm^-1 (the Stokes-shifted matching frequency). If you excite the vibrations of the capsid hard enough it will break, as in the old trick of the singer breaking a glass.
But actually, a 100 fs laser pulse has a rather broad spectrum, and therefore is going to excite much more than just that single vibrational mode. Effect on viruses is claimed at a peak power of 50 MW/cm2 -- that is megawatt per square centimeter -- which is rather respectable, even if the average power is low. So I fear that this technique is not going to be very selective. I suppose that in theory you could also excite the virus with two longer-pulse (i.e. picosecond) lasers tuned to have a specific frequency difference, but then the average power required to get a threshold peak power of 50MW/cm2 is likely to be a problem.
Of course, if you are going to use this on a virus like HIV, you will need to target the immature form (which has a shell of gag protein under the envelope) and the mature form (in which gag has been processed into matrix and capsid). You also need to cope with the irregular structure of the virus, which does not have the icosahedral symmetry of many other viruses, its considerable genetic variability, and its variable morphology. HIV capsids occurs in at least two forms, cone-shaped (most of them) and tubular (less frequent). So its Raman frequency spectrum is likely to be complex and a broadband killer may be what you want -- may be.
The reported excitation is a frequency-doubled pulsed beam at 425 nm, which is violet. Blood strongly absorbs light at such wavelengths; hemoglobin even has an absorption peak there. You would have to tune to the red to do anything useful in blood without killing the blood cells, but a standard frequency-doubled titanium-sapphire laser will really struggle to generate red light -- a yellow-tinged green at 550 nm is about the limit. A different laser technology or a much more complex system (with a parametric oscillator) would be required to get there. And even a red laser might be absorbed enough to make blood boil in the focus of the beam.
Last but not least, even if your could destroy all viral particles in a blood sample, that would by no means make that blood safe! The raison d'etre of viruses is inserting their genome into cells to be replicated there. Destroy all viral particles, and there might still be viral genomes in the cells, as RNA or DNA, ready to replicate in the host; even viral proteins ready for assembly into new viruses. It would still be unacceptably dangerous to use that blood.
Frankly, I think this is a misuse of the technology. If it has any applications at all that will be in the study and detection of viruses, not in decontamination. It might be developed into a simpler, cheaper alternative to CARS microscopy.
Yes, there are too many security efforts evaluate risks badly; that aim to rigorously closing systems to guard against supposed known threats, piling security measure on security measure, while leaving the back doors wide open. The equivalent of people who are afraid of flying, but drive recklessly while drunk.
However, I think that many misguided security measures are inspired at least as much by self-protection as by bad evaluation of risks. People often know that they are not addressing all the real risks. But they assume that as long as they stick to policy, and "even better" ridiculously over-design to cover every possible risk explicitly mentioned in the policy, they can't be blamed when things to go wrong. Some junior technician is not going to challenge policy laid down from above, just because it has giant gaping loopholes. He or she is just going to follow it, and apres nous le deluge. And the policies in turn are often written by people who focus on past incidents, not future risks, because what's behind you is more likely to bite your ass.
Governments regulate aviation safety very tightly because they can get a lot of criticism when there is a fatal accident. But car accidents that cause more casualties overall, are considered a normal part of life, and people rather resent additional safety measures, so governments are much less inclined to take strict measures to reduce them. That's not caused by short-sighted risk evaluation (at least not necessarily on part of the government) but by plain politics.
You can see it any form of modern engineering; measures designed not to reduce risk, but to reduce liability. Of course I don't know whether the same principle was applied in communities of pre-historic hunter-gatherers, but my somewhat pessimistic view of humanity induces me to assume that it did. And I would not be surprised if the same behavior was discovered in chimpanzees.
It is even possible that that behavior actually has a background in the evolution of our brains. The ability to blame someone else when things go wrong, must be of considerable advantage to the spread of your genes.
For aircraft developers, the advantage of hydrogen has always been that it delivers more energy per weight unit than traditional hydrocarbon fuels. The matching disadvantage is that because of its low density, it is much bulkier, so requires bigger and heavier fuel tanks.
Temperature is also an issue with pro and cons. On the one hand, LH2 is very cold, so ice formation on the skin of the aircraft can be an issue. On the other hand, LH2 is still chemically stable at high temperatures that would turn fossil fuels into a nasty sludge, or even break down hydrocarbon molecules before they can be properly burned.
All that always made LH2 a very suitable fuel for a big rocket or for the hypothetical Mach 4 space plane. Its use on a slow high-altitude UAV poses very different challenges.
Boeing can only blame it on themselves. Not that long ago, Boeing supporters were putting out the story that Airbus airliners were unsafe because they used composite materials. Carbon fibre tailfins on Airbus airliners were singled out for special criticism (until Boeing also began to use them).
After decades of denouncing innovation as unsafe and unnecessary, Boeing's management has finally found it necessary in new technology. It is about time, but they should not moan to much if their old propaganda comes back to bite them.
Contrary to what you seem to think, I am not a statistician.
And one of the problems I have with biotech researchers, is that they are only too willing to believe what a statistician tells them, even if somebody with a little data analysis skills can see that the analysis is conceptually flawed and the conclusions meaningless. And it is no use protesting against it, for biotech researchers assume that if somebody has 'statistician' on his business card, his or her conclusions must be right.
As for my attitude, my colleagues know that they can come to me if they have a difficult problem, and I will do anything I can to help them. My track record on this has never been seriously criticized. But they also know that I will tell them in their faces if their analysis is crap, and they'll have to live with it.
I have worked in a biotech / pharmaceutical environment for over five years now, and I don't trust the average medical researcher or biologist to accurately calculate the weight of a kilogram of stuff. I would say that their data analysis is habitually poor, if I were not convinced that it is actually habitually awful.
I have been trying to change this for five years. My success in this has been such that it contributed strongly to my recent decision to start searching for another job. The reality is that biomedical researchers simply do not believe in doing mathematical analysis of data properly. They consider it an eccentric habit, forgivable but socially objectionable, like smoking. By common consensus, it is considered much too complicated to expect that any of them can be expected to understand. Your average biologist is innumerate to the nth degree, and proud of it.
I blame their education, which seems to stress naive and antediluvian (excuse the word) analysis practices, if at all. I have seen course materials which in their expression of basic mathematical formulas, betrayed that they had been left unchanged since the days when people used slide rules and logarithmic tables for calculations. Most of their other training is strictly qualitatively, not quantitatively, and focussed more on memorizing that on understanding.
If necessary, they will find a crutch to help themselves to stumble along: Find a paper that defines a formula that looks relevant, and then fill in the numbers. They would not bother doing their own analysis, or trying to understand how the calculation works or whether it is relevant at all. The notion that a good statistical analysis of mathematical modeling can actually contribute to the scientific understanding of an issue, is well beyond most of them.
I am frankly, sick and tired of their attitude, and I still have to work with these people every day. And in my experience, my colleagues are actually better than most. I strongly suspect the WSJ is correct on this one.
I think the biggest stumbling block for above-average developers is the attitude of managers who indeed think of programmers as 'cogs in the machine'. And a sausage-machine at that. I have seen too many projects without a serious design phase at all. Typically they start with a team of managers and tutti quanti dreaming up a specification (usually to vague to be useful, but still specific enough to be unworkable) and then expecting that the software will simply be written.
When you try to explain to them that actually, there is nobody in the IT department who is actually capable of designing and building such a system of the required complexity, you meet blank stares and incredulity. How is that possible, when that place is filled with programmers? Trying to explain the difference between routine GUI programming, systems administration, database administration, and designing a company-wide system of interlinked applications is no use. Managers would apparently trust any competent car mechanic to design a Formula-1 car. Well, they must, because they are not willing to pay for the skilled engineers that it takes to do the real job, or to invest in serious training for the people that they have.
Of course, if they don't have the people, managers are willing to contract them. So they pay to bring in programmers from consultancy firms, and expect them to hit the ground running, seamlessly integrating in teams with people they have never met before, and writing business logic for a business they don't understand. You would need to be really lucky to find all the right people right away, more often you need to get rid of about half the consultants you hired at first, because they are no good or because they experience is too far removed from the needs of the projects.
So far, I've met just one or two really highly skilled and creative developers. Flexible thinkers who quickly grasp problems, readily adopt to whatever technology they need, plan realistically, and deliver quality work. They are a delight to work with, and you can achieve as much with them in one hour as you would else do in whole month of meetings and deliberations. But they are usually self-employed or running their own little firms, and they can afford to pick and choose the projects they are interested in. If they don't want to do it, or don't have the time, they won't. Management regards often them as 'difficult' and expensive, considering that other programmers are a dime a dozen... So the pleasure is rare.
The normal condition is to have a mix of more or less skilled people who will learn on the job and might be quite competent at the end of the project, and inevitably a few idiots you have to entrust parts of the project to with appropriate feelings of resignation and foreboding. (When in IT waters, I live on my wits. I have no authority there.)
It's a damn shame that a nice launch vehicle also happens to make a nice ICBM...
Saturn V would be a ridiculously poor choice to use as basis of an ICBM. It stood 110 m tall, weighed over 3,000 tons fueled, and used liquid hydrogen and oxygen as fuels.
A good ICBM needs to be compact, so that is easily hidden, and above all it must be storable in a ready-to-fire form. That meant using storable liquid fuels instead of condenses gases for first generation missiles, and solid fuels in the later designs. To give an idea, Minuteman III is a mere 18 m long, weighs 32 tons at launch mass, and uses solid fuels. Even the big Soviet R-36 aka SS-18 Satan did not exceed 210 tons, and while it used liquid fuels, it used liquid fuels that could be stored at room temperature.
Rationally, Saturn V never had a military application, and certainly today its technology is no longer of any military value.
Because the other 95% saw that you take too long to write code and your code executes too slowly and you are going to be fired because of it.
Don't be silly. It is perfectly possible to write robust, efficient C++ code at a decent speed. And it is certainly much more efficient than generating buggy crap and then spending weeks, months and years trying to find the elusive bugs. Not to mention the complete rewriting of large blocks of unintelligible, bad-quality code as 'bug fix'.
I fully agree with the original author. Buffer overruns? Dangling pointers? I haven't had them in years, and my code is written on time and meets performance targets. Nor am I even that skilled a C++ writer; I do something from time to time to keep in good mental form, and when I need to integrate some fast processing code in Java code or enterprise software. I have no respect for people who allow buffer overruns or dangling pointers to pollute their code, and who leak memory from all their gills. All it takes to prevent such errors is a little care, the adoption of reasonable design patterns, and a bit of mental exertion.
There are plenty of more-or-less excusable bugs, let's start by learning to avoid to inexcusable ones.
And I am especially annoyed at the so-called 'safe' versions of standard library functions that MS introduced in Visual C++ to compensate for this kind of libertine amateurism, even deprecating strncpy()... in favor of a version that is best avoided unless you are well aware what it is doing to the rest of your buffer. But then the Microsofty version of C++ has always been a definite example of a language that has gone over to the dark side.
The reality is that clinical trails are being done in the USA, also for treatments for HIV. For many diseases, the USA both has a large population of patients who have exhausted every existing treatment option, and a large population of patients who cannot afford existing treatments. That makes it a good recruiting ground for clinical studies. The disadvantage is the high cost of the trials.
(I have heard rumors of at least one incident in which FDA officials suggested that before trials in the USA could be permitted, a new treatment should be tested on foreigners first --- I assume that that is not official policy.)
Clinical trials in 'third world' countries are a booming industry in places like India, which possess sufficient numbers of trained health professionals, but also have a lot of patients who cannot afford normal treatment options, and where cost of trials is substantially lower than in the USA or Europe. The technical procedures still have to meet the same standards as if the trials would have been done in the USA, that is not the problem. The real problem is explaining to often very poorly educated people who are in bad straits, that they are participating in the evaluation of experimental drugs -- the principle of "informed consent" tends to be a bit illusionary in such cases. That indeed makes such trials controversial.
Payments by the pharmaceutical industry to the FDA are something that Congress, in its wisdom, has institutionalized. The logic behind this must have been that almost anything is better than raising taxes, although in this case the almost seems highly questionable. It is quite possible that the objectivity if the FDA is not in the least affected by this, but the appearance of propriety also counts for something.
As for the cost of drugs in the USA, keep in mind that the simple economic law of demand and supply applies in the pharmaceutical world as well. The industry develops treatments that are very expensive to administer, such as for example some cancer treatments, because there are a sufficient number of patients who can (directly or indirectly) afford them. There are still many more diseases than treatments, so the industry opts to develop cures for those diseases that are financially interesting. If the patients could or would not pay, then the development of a cure would make no economic sense. A $200k treatment for the cancer of an American is financially viable; a $200 treatment for the life-threatening parasitic infection of a patient in sub-Saharan Africa is not.
There are limits to the wisdom and efficiency of the free market.
Disclaimer: I am prejudiced. I don't have a CS or IT degree, I am a scientist by training. And if I look at the fate of most people with IT degrees in our organization, I can only have pity on them.
If you want to have a real career, then by all means retain your broad range of interests. "Dabbling" is okay, but perhaps you want to specialize a bit -- to consider for a moment to what field you would want to apply these computing skills. If you would enjoy writing financial software, you'll better know something about finance. If you want to do computer graphics, some arts and design classes might be in order. If you think scientific software is your niche, then don't forget to study some science. Studying some science, mostly mathematics and physics, is a good idea in any case.
You see, "pure IT" people are minions. Pawns. Gun-fodder. If you don't understand what a piece of hardware or software is for, nobody of sound mind is going to entrust you with its design. They'll give you a clear specification and a set of policies to implement, and tell you to get on with it. Unless you are capable of grasping the scope and nature of the business you need to support, and do it really quickly (for as often as not these are consultancy jobs), you won't get much further than that -- and it is not a particularly rewarding or pleasant job. 99.9% of it is pure routine. If you have a broad range of interests and skills, then by all means avoid that fate.
My advice, for what it is worth: If you have the required energy and intelligence, then either choose CS (and don't forget to develop some actual programming skills while you are doing that), or opt for some science or engineering degree that includes a strong informatics course. Avoid pure IT.
CS probably still offers a good career. Somebody who is looking for a good programmer might equally well (or perhaps even better) hire an engineer, a physicist or a mathematician instead of someone with an IT degree, but so far few people without formal CS training can match their particular set and level of skills.
Slashdot Mirror
Probably the biggest advantage is the time it could save for employees to have a system configured to do what they want to do, rather than what the IT department wants it to do. I work in a company with 500+ employees, and I think we spend the equivalent time of about 20 full-time jobs on waiting until our computers are willing to respond. That's more than there are people in our IT infrastructure team! If it sounds like a lot, then remember that a working day has only about 500 minutes, so if everybody has to wait one minute, that adds up to one full working day for us. You could argue that many people spend more time chatting over coffee, but chatting over coffee can actually be useful, whereas drumming on the table with your fingers until your computer responds again is not. Anyway, savings in IT time could very well be infinitesimal compared to savings in user time.
Having leaner, simpler configurations better tuned to do actual work, instead of meeting IT management functions, could be of major benefit to a company. It would not only save time, but also result in happier employees.
Even when it comes to setting up new systems, my experience is that skilled users have systems that are leaner, faster, cheaper, and more stable than professional IT teams. I don't know why, but I would guess that it is because users are inclined to take something that works out of the box and just use it, while IT people would start to tinker with it until it meets a dozen extra requirements, put it on a shared server with five other systems, and install it according to the internal SOP. When an user needs disk space, he buys extra disk at $1 per gigabyte, or thereabouts. When he needs to ask IT, then IT will buy an approved system at $2 per gigabyte, add $8 extra for maintenance and administration costs, and charge the user $10. Yes, some of that extra work is actually very useful, such as taking backups; but much of it isn't.
As for security, my experience is that cover-all security procedures that lock everything down tight and try to maintain fixed configurations, mostly serve to cover the ass of the IT responsible. Half of the time they don't really work anyway, or have gaping holes in them. Some of our IT people do maintain a high level of security in their area, but that's because they are very flexible and adaptable, and always seek to work out the best solution that serves both security and functionality -- so users respect them, and try to cooperate. Overall, it might be better for the IT department to adopt a reactive strategy, by scanning for real security risks and intervening when they occur, instead of fostering the illusion that they have everything covered.
I suggest looking for an opportunity in a small start-up. Perhaps you don't want to associate with the proverbial two nerds in a garage, but you can learn much more in a small firm, that perhaps has a dozen people dividing all the work between them. You'll learn to do much more than programming, and working in a small firm is more fun. And besides, a small cash-strapped start-up is more likely to hire a college kid to do some coding, than a large established firm.
There may also be good opportunities in companies that aren't in the IT sector, but in research & development, for example a biotech company. Usually these companies don't have very strong IT departments (and again, you will learn more in a small team), and they will hire people on short term contracts to complete specific projects. Even a medium-sized biotech might not employ a single skilled C++ programmer on a permanent basis (the density of C/C++ programmers in this environment is around 0.3%), so they might be willing to hire you.
Or, if it interests you, look for small firms that develop hardware, such as instrumentation, robotics, or consumer electronics; or small engineering outfits that produce custom development and automation. There isn't that much C/C++ in a typical IT job these days, rather a lot of the work is now in web development, database applications, Java and .NET. But people who interact with hardware, especially if it's time-critical, still have a need for the level of detail and control that C can offer.
And probably it's best to work through an agency or consultancy firm. I don't know US practice, but on this side of the pond it IT directors who need and extra person on the team won't place adverts or look through job applications. Instead, they will send out a request to specialized agency or consultancy firm.
In my eyes the fundamental problem is the lack of ambition of many IT managers and IT departments. This isn't the same as nerdiness, but it is a consequence of it. It does not occur to most IT managers that they should strive to make the company better -- more efficient, more profitable. It does not occur to them that they should try to change and improve the way in which people work. As a matter of fact, I've heard IT managers blithely and explicitly state that they don't want to contribute to better business processes; they just want to regard the business processes as a given, write a full set of specifications around it, and write some software to support it.
If Apple had been governed by this spirit, they would have produced a handy mini-computer to help people manage their gramophone records, not the iPod. If Amazon had had this mindset, their website would be accessible only from bookshops. Some people have vision, and others do not. If knowledge is power, then information could be money, but some people don't recognize money even if they step on it every day.
Instead, such IT managers tend to focus on making a computer run better. Perhaps a new printer server, and a safer anti-virus scanner. Replace all telephones by a new type, which nobody understands. Rewrite all the old COBOL software in .NET, but keep the same screen layout, to avoid confusing the users. Demand that no software installations are done, however small, if someone in Brazil did not write an automated installation script. Deliver all new PCs with Windows Vista, regardless of which applications people want to run on them. Usually all the good IT people walk away from such tedious and surreal jobs, but worse, the business leaderships walks away from it as well. If it's plumbing and routine maintenance, they don't want to think about it; and why should they? And why spend money on something which doesn't promise any real improvement to the bottom line?
As I wrote, nerdiness plays a role in this. Too many IT people just don't seem to have a serious interest in what happens outside their own department; they just want to do hardware or software. They don't understand business, they don't understand other forms of engineering, and they don't understand R&D -- and they don't want to! For business users, these are horrible people to deal with. I have gone as far as recommending that we shouldn't hire more professional IT people for the IT department, but engineers and scientists and economists with an interest in IT. That is, no doubt, unfair; there are IT professionals with wider ambitions and skill sets. Unfortunately, the average IT department doesn't see, to be able to hire or retain them.
The final tailspin usually comes when this curious, stoical detachment from the core business is formalized. The IT people think it over and say, we don't talk to the people in the business groups anyway, so why not all sit together and enjoy our own company, in one big IT department? And why not outsource all the support functions to the Comores? If you don't have any meaningful contact anyway, then distance indeed doesn't matter.
But in reality, that isn't a sustainable model. Some people in the business department still need some innovative, creative IT work done, and because the IT department doesn't seem interested in or capable of solving the problem (and at this moment the IT department often seems as mythical as the Kraken), they will do the work themselves. Getting together a few gifted amateurs, and start over from scratch as if the IT department never existed (while cursing it at the same time, of course). Then a manager will have the bright idea of formalizing this into a new IT group, and so the wheel turns round again...
Agreed, reading the table of contents and browsing the index, this seems very much an American centric view, like a book on whisky written by an Irishman. There is a reference to Herge and one to Asterix, but no mention of for example Hugo Pratt, Franquin, Tardi or E.P. Jacobs, which is really baffling in any book about comics! And of course no mention of at all of gods of lesser influence such as Jije, Andreas, Schuiten, Rosinski, Charlier, Hubinon, Manara, Gazotti, Tillieux, Toonder, Morris, ... to mention a random selection.
But there are and always have been distinct traditions between the Anglo-American and the European comic market, and with exceptions such as Eisner and Herge (and unfortunately, Peyo's worst creations) few have achieved any success or even respect in both markets. To an outsider like me the US comic seems very much an "action" genre, at its best and worst. From "noir" comics dealing with a more or less violent struggle for life, to brains-on-zero superhero comics turned out like sausages. The European market, on the other hand, has its share of action but does a lot more storytelling and satire, often relatively slow paced.
I wonder whether this is because of different inputs; i.e. American comic tradition fed on movies, and more recently on television. The European comic tradition grew more out of traditional books, perhaps simply because visual culture arrived later here, and in the case of some authors, even poetry. So they started out with very different sets of unwritten rules about content, pace and storytelling, and they stuck to that.
I have no insights to offer on how to become an IT manager. Frankly, it seems such a thankless and boring job that I would presume a severe shortage of candidates. But I freely offer the following advice on how to stay an IT manager and not get fired:
It's fair enough to say that any job involves risks, and it certainly sounds as if this Ebola replicon is reasonably safe. On the other hand I would require convincing evidence that the virus cannot mutate to replicate without VP30, which apparently is mainly a transcription activator. Because this virus maintains its genome as RNA without ever encoding it in DNA, it has a very high mutation rate. Or that it cannot pick up a suitable gene by hybridization; co-infection with another negative strand RNA virus might be enough.
In any case, I can image that people who work with Ebola viruses might find that they have to lunch alone. And I wonder what the neighbours would think of it.
Let alone the IT people, of course. I know from experience how difficult it can be to make an IT guy enter a HIV laboratory to set up the network connections... For a BSL3 with Ebola virus we probably would have to pay them Blackwater rates.
Belgium has a 99% cable distribution network, you have to be eccentric or live in a caravan not to have cable. But we have a fairly high distribution level of DVD recorders, as well. (Judging from what I see -- I don't have any statistics.)
Of course the economics of cable television are different. Our channels do not (need to) recycle shows at the very frequent rate of US channels; they may repeat the same broadcast twice in a year, and that's it. (But they do make popular shows available on pay-per-view over digital television to satisfy fans who can't cope with having missed it.) That encourages recording.
On the other hand, I would assume that the astronomical high frequency of commercial breaks on US television would stimulate the sale of recorders, because they at least (for the time being!) allow one to fast-forward the commercials.
Yet at the same time the commercial break may discourage recording on DVD. To put something on DVD in a decent format, you would have to spend an excessive amount of time editing it to make a continuous story out of it. Better to buy it on DVD.
Another reason I could think of is the generally poor quality of NTSC encoding compared even to PAL. Buying the DVD gives people a much better image quality.
(1) Close Gitmo and the CIA's secret prisons. Ensure that everyone who committed or organized crimes, such as abduction, torture, and illegal listening operations, under the previous administration(s) is duly prosecuted. Don't give ANY pardons, not even to Dubyah himself. The good reputation of the US needs to be restored.
(2) Scale down the presence in Iraq, as there is no other option, but stay there as long as the Iraqis want it. The USA messed up the country badly, it now has a duty to see it through. Listen to commanders on the ground. Respect the sovereignty of the Iraqi government.
(3) Slash military budgets by 20% or so -- there is no need to outspend the rest of the world combined, and there is sufficient pork and useless prestige projects in the budget to make that cut without endangering the safety of the USA. Spend the rest of the money on useful things, such as body armour, suitable vehicles and decent care for wounded soldiers.
(4) Seriously reform the legal system, to make it run faster and fairer, and restrict unethical behaviour of prosecutors and defense lawyers. Everybody deserves an actual fair trial, and currently most cases are ended by plea-bargaining because the US legal system can't handle the case load.
(5) Start a serious program to reduce global warming and the dependence of the USA on (imported) expensive oil.
(6) Reform the health care system on the principle that people are free to choose their insurer, but must all have one. Cut out excessive profits, huge advertising budgets, and ambulance-chasing lawyers. Invest in prevention.
It depends on what the IT department is doing for the company. If the company is selling hot dogs or pursuing some equivalent activity, then IT is not going to generate value. IT then just supplies administrative tools to keep track of things, and having your own IT department may make as much sense as making your own paper.
If the company is in high tech, research & development, or in an environment where logistics are critical, then IT could make a real difference in the efficiency and profitability of the company. Then outsourcing it amounts to being satisfied with second-rate solutions and a business handicap, because no external supplier is going to understand your business well enough to make a competitive difference.
On the other hand, if that is the case, the company probably should not have an IT department. It should have an engineering department which considers IT just as one of the many available tools to improve the profitability of the company. In many cases IT developments only make sense in harmony with other forms of engineering; a robot needs both hardware and software.
So in a sense, I would back the idea that the IT department as such is dead. If the IT group is just doing IT and not involved in the rest of the company's business, then it might as well be outsourced. If it is an active, fully involved player in the company business, then it is there to stay, but then it is much more than just an IT department.
Actually, I doubt that the simple jammer installed on an airliner would be able to defeat the seeker heads of a modern AIM-9 variant that easily. But presumably a fighter jet would first get close enough to the target to do a visual inspection, which would mean that it would be well within gun range. And besides that, most US fighters carry AIM-120 as well, which does not use IR for guidance or fusing, so would be reasonably effective.
The other side of the issue is that, of course, not all man-portable air defense missiles (MANPADs) are infrared guided, and a smart terrorist would respond to this measure by picking one that isn't. Stocks of Blowpipe have been found in Afghanistan -- It wasn't good enough to fight the Soviets, but would still be able to down an airliner.
I agree with your comment about the Overlords. However, I think that they do have a point that having IT skills alone is not good enough. You should know what you need to produce as well as how to produce it. In the ideal world, IT customer and IT supplier would be the same person (or at least share a brain) which would presumably ensure perfect understanding of what the customer needs (not the same as what the customer wants). In reality, it is enormously important that IT people have the ability to understand the customer's problems and relate to them.
Of course they should have good IT skills as well, I've seen far too much crass amateurism to deny the need for good IT skills. And I intensely dislike the fact that we have IT managers without IT skills, who are nevertheless trying to promote the technical standards of their choice. Nevertheless, giving the choice in my role as a customer, I would always prefer an IT-er with whom I can have a constructive debate, can develop an intuitive understanding of what I need to have, and can be an effective contributor to a team that also has other tasks beside setting up and maintaining IT systems. To curse in the church: I think IT should be a skill and not a job. The job is doing whatever needs to be done.
Quite possibly this is what went wrong with Vista. Vista seems to have started out as "Windows As IT People Thinks Windows Should Be"; cleansed of Windows' notoriously compromised kernel design, more secure (or at least with fewer gaping loopholes), and the kind of nifty user interface features that programmers are proud of when they achieve them. The problem was that that was very much an abstract IT ideal; it is not what the customers want or need, it does not seem to make any business sense, and worst of all, it could not even be achieve its own goals.
Back to Overlords: I've been in R&D for long enough to recognize that large companies tend to be dominated by authoritarians with tramline thought processes, especially when they are "professionalized" and managers from other sectors are brought in. Board-level decision processes often betray an appalling lack of floor-level business knowledge. That's not exclusive to IT, or to Microsoft. Microsoft as Bill started it, probably was a very different and much more effective organization than the Microsoft of today.
What such organizations need to shake them up are men like the late Admiral of the Fleet John Arbuthnot "Jackie" Fisher, Baron of Kilverstone (1841-1920), who after he joined the Admiralty as director of Naval Ordnance, "asked for a list of things I was not allowed to have and have got them all but one."
(1) Be Mr. Know-it-all. Help-desk time allocation does not permit help desk people to spend long hours gnawing on some troublesome issue -- or even to spend fifteen minutes searching the knowledge base. Don't pressure your help desk representative to find a solution for you if it is not obvious; you will only make him or her miss the set monthly quota of tickets solved. Solve your problems yourself, then send the solution to the help desk for future reference.
(2) Know nothing. Be deaf, blind and stupid, whenever appropriate. The managers of support organizations are always eager to lighten their own budget by transferring work to the people they are supposed to support; it makes them look good and the costs of this neat operation are invisible in the budget. It may be in everybody's best interest that you are too stupid to connect a cable.
(3) Be entitled. Fact of life: Nobody below the rank of vice-president really gets quick, responsive IT support. There is never enough support to give everybody a fair share. Always make the highest-ranked person in the room put in the support call. Bosses are routinely put in Cc: on every request to the help desk because of the widely held belief that this speeds up service. However, remember that pulling rank is like buying expensive cars: If you need to ask, you can't afford it.
(4) Point fingers. It is very important to point fingers from time to time, but do it wisely. If people didn't point fingers at ridiculously cumbersome policies and unproductive tools, company policy would still require the use of Roman numerals for all official calculations. Of course you can't trust these new-fangled Saracen numbers -- and what does this 'zero' mean, anyway?
(5) Whiz, but whiz discreetly. Remember that professional IT support organizations are nearly always set up to maintain, not to develop. If you need to create some new software system, you'll do it considerably faster, cheaper, and better if you don't involve IT at all. At the very least it will save you five hours a week that you would otherwise spent in meetings with them.
I suspect that if you are involved in "projects that drift", then the basic problem is not coding quality. I have recent got involved in some absolutely terrible projects myself, and my impression is that the #1 problem is giving too little priority to design. Software engineers should understand the problem they have to solve as well as the customer -- actually, they should understand it better than the customer. Or alternatively the customer, and not some external IT guy who has first to be taught the basics, should be able to do the top-level software design. (Because understanding the task the software should accomplish, is usually more important than knowing the technical details of the implementation.)
Unfortunately, customers usually assume that software design is a trivial problem that any typist should be able to do after a few hours of explanation. And as for so-called IT professionals --- don't get me started on the crass amateurism that I have witnessed. The result is often that the programmers create gordian knots in an attempt to make the best of a chaotic design. That's not their fault. You'll go mad if you start worrying about it.
But if you have a good design, then achieving good coding quality should not be that difficult, if you are technically competent. I've noticed myself that when I am writing bad code, overcomplicated, unstructured, intertwined, and full of bugs, then the reason is often that I don't properly understand what I am trying to do. Because the design is wrong. If the design is correct, then it should be clear what a piece of code should do, and writing it should be relatively straightforward, and you should not introduce complicated bugs -- because you know how it is supposed to work.
So my first advice is: If you have the feeling that you should to be ashamed of the code you are producing, then stop right there. Probably your design stinks and you don't understand what you are doing. Re-analyze the problem, break it down in components again, make sure that you properly understand every step. Think it over thoroughly. If possible, go for a walk; that usually helps more than staring at your screen. Then first redesign, then rewrite.
As for coding style, I think it is most important to be consistent. I once got back a mathematics paper back from my teacher with a bad grade, not because the answer was wrong, but because there was no method to it. "Use a method" was what he wrote on it. I still hate to admit it, but he was right.
Most people don't use the full vocabulary of their programming tools, which in case of languages such as C++ is not a particularly good idea anyway. Instead they develop patterns which they understand and routinely re-use. It is best to adopt some set of patterns as your own; which one does not matter that much as long as you are aware that you rely on them, that you understand how they work, and are familiar with their pros and cons. From time to time step back to analyze your code for repetitive patterns; and think of what you should do with them -- retain them, build on them, forget about them.
The one advice I would give is that if you are using a coding style that aims for saving on the number of letters and braces you type, that is probably not a good idea. Saving on typing should be at the very bottom of your list of priorities. You should nearly always go for highlighting the structure, if you can.
Personally I also tend to over-comment, documenting every private field and method. And I write my comments first, and the code later, on the principle that you shouldn't be writing a class or a method if you can't explain what it is supposed to do. Of course I usually have to update the comments later, because one always modifies the flow a bit to optimize it, but that is fine.
Many, maybe even most, objects of which you would handle the lifespan manually in a Java application, are resources that exist on a single thread. Dialogs and various I/O objects, for example. And yes, I've also made the mistake of giving a dialog a reference to 30 Mb of data, and then forgetting to dispose of the dialog (instead of only closing it). Mistakes do happen. Nevertheless managing objects on a single thread is relatively easy and involves little overhead.
But the objects that are shared between different threads are very often the kind that can be safely left to the GC to handle. Of course, you can exchange objects between different threads in C++ and still manage the memory, but frequently enough you'll find yourself incrementing and decrementing references all over the place, adding management code and complexity. Or you have to rely on libraries that do it for you, but impose limitations that completely mess up your neat design. If there is a GC that can accurately figure out whether an object is referenced or not, that saves a fair amount of coding in a multi-threaded application, and eliminates hard-to-debug errors. It also simplifies the design.
Yes, there may be resources that are shared between threads and cannot be left to the garbage collector to properly clean up. Database connections, for example. But it's less costly to handle a few objects manually, than all of them. And for a single-threaded piece of code there may indeed be little to choose between GC and manual memory management; the latter is likely to be a bit more efficient. But how many serious applications are really single-threaded these days?
I admit that I have enough C++ background to feel uncomfortable, from time to time, with the idea of allowing the GC to handle things. You wonder what the lifespan of an object will be, and have no sense of closure. But actually, often enough not worrying about things is the right solution.
A nice idea. I must be one of the rather few people who have worked with ultrashort pulsed lasers, Raman scattering, and viruses; and I really appreciate the interest of the concept. But I doubt very much that it will ever be a practical tool. Destroying M13 virus in pure water is a far cry from a real application.
If I understand it correctly, the technique exploits the fact that ultrashort laser pulses are not monochromatic but have a significant band width, to excite a vibrational frequency of the virus through resonant Raman excitation. Or, the vibrational mode of the viral capsid is about 8 cm^-1, and the excitation laser contains both 23,529 cm^-1 (i.e. 425 nm) and 23,521 cm^-1 (the Stokes-shifted matching frequency). If you excite the vibrations of the capsid hard enough it will break, as in the old trick of the singer breaking a glass.
But actually, a 100 fs laser pulse has a rather broad spectrum, and therefore is going to excite much more than just that single vibrational mode. Effect on viruses is claimed at a peak power of 50 MW/cm2 -- that is megawatt per square centimeter -- which is rather respectable, even if the average power is low. So I fear that this technique is not going to be very selective. I suppose that in theory you could also excite the virus with two longer-pulse (i.e. picosecond) lasers tuned to have a specific frequency difference, but then the average power required to get a threshold peak power of 50MW/cm2 is likely to be a problem.
Of course, if you are going to use this on a virus like HIV, you will need to target the immature form (which has a shell of gag protein under the envelope) and the mature form (in which gag has been processed into matrix and capsid). You also need to cope with the irregular structure of the virus, which does not have the icosahedral symmetry of many other viruses, its considerable genetic variability, and its variable morphology. HIV capsids occurs in at least two forms, cone-shaped (most of them) and tubular (less frequent). So its Raman frequency spectrum is likely to be complex and a broadband killer may be what you want -- may be.
The reported excitation is a frequency-doubled pulsed beam at 425 nm, which is violet. Blood strongly absorbs light at such wavelengths; hemoglobin even has an absorption peak there. You would have to tune to the red to do anything useful in blood without killing the blood cells, but a standard frequency-doubled titanium-sapphire laser will really struggle to generate red light -- a yellow-tinged green at 550 nm is about the limit. A different laser technology or a much more complex system (with a parametric oscillator) would be required to get there. And even a red laser might be absorbed enough to make blood boil in the focus of the beam.
Last but not least, even if your could destroy all viral particles in a blood sample, that would by no means make that blood safe! The raison d'etre of viruses is inserting their genome into cells to be replicated there. Destroy all viral particles, and there might still be viral genomes in the cells, as RNA or DNA, ready to replicate in the host; even viral proteins ready for assembly into new viruses. It would still be unacceptably dangerous to use that blood.
Frankly, I think this is a misuse of the technology. If it has any applications at all that will be in the study and detection of viruses, not in decontamination. It might be developed into a simpler, cheaper alternative to CARS microscopy.
Yes, there are too many security efforts evaluate risks badly; that aim to rigorously closing systems to guard against supposed known threats, piling security measure on security measure, while leaving the back doors wide open. The equivalent of people who are afraid of flying, but drive recklessly while drunk.
However, I think that many misguided security measures are inspired at least as much by self-protection as by bad evaluation of risks. People often know that they are not addressing all the real risks. But they assume that as long as they stick to policy, and "even better" ridiculously over-design to cover every possible risk explicitly mentioned in the policy, they can't be blamed when things to go wrong. Some junior technician is not going to challenge policy laid down from above, just because it has giant gaping loopholes. He or she is just going to follow it, and apres nous le deluge. And the policies in turn are often written by people who focus on past incidents, not future risks, because what's behind you is more likely to bite your ass.
Governments regulate aviation safety very tightly because they can get a lot of criticism when there is a fatal accident. But car accidents that cause more casualties overall, are considered a normal part of life, and people rather resent additional safety measures, so governments are much less inclined to take strict measures to reduce them. That's not caused by short-sighted risk evaluation (at least not necessarily on part of the government) but by plain politics.
You can see it any form of modern engineering; measures designed not to reduce risk, but to reduce liability. Of course I don't know whether the same principle was applied in communities of pre-historic hunter-gatherers, but my somewhat pessimistic view of humanity induces me to assume that it did. And I would not be surprised if the same behavior was discovered in chimpanzees.
It is even possible that that behavior actually has a background in the evolution of our brains. The ability to blame someone else when things go wrong, must be of considerable advantage to the spread of your genes.
For aircraft developers, the advantage of hydrogen has always been that it delivers more energy per weight unit than traditional hydrocarbon fuels. The matching disadvantage is that because of its low density, it is much bulkier, so requires bigger and heavier fuel tanks. Temperature is also an issue with pro and cons. On the one hand, LH2 is very cold, so ice formation on the skin of the aircraft can be an issue. On the other hand, LH2 is still chemically stable at high temperatures that would turn fossil fuels into a nasty sludge, or even break down hydrocarbon molecules before they can be properly burned. All that always made LH2 a very suitable fuel for a big rocket or for the hypothetical Mach 4 space plane. Its use on a slow high-altitude UAV poses very different challenges.
Boeing can only blame it on themselves. Not that long ago, Boeing supporters were putting out the story that Airbus airliners were unsafe because they used composite materials. Carbon fibre tailfins on Airbus airliners were singled out for special criticism (until Boeing also began to use them).
After decades of denouncing innovation as unsafe and unnecessary, Boeing's management has finally found it necessary in new technology. It is about time, but they should not moan to much if their old propaganda comes back to bite them.
Contrary to what you seem to think, I am not a statistician.
And one of the problems I have with biotech researchers, is that they are only too willing to believe what a statistician tells them, even if somebody with a little data analysis skills can see that the analysis is conceptually flawed and the conclusions meaningless. And it is no use protesting against it, for biotech researchers assume that if somebody has 'statistician' on his business card, his or her conclusions must be right.
As for my attitude, my colleagues know that they can come to me if they have a difficult problem, and I will do anything I can to help them. My track record on this has never been seriously criticized. But they also know that I will tell them in their faces if their analysis is crap, and they'll have to live with it.
I have worked in a biotech / pharmaceutical environment for over five years now, and I don't trust the average medical researcher or biologist to accurately calculate the weight of a kilogram of stuff. I would say that their data analysis is habitually poor, if I were not convinced that it is actually habitually awful.
I have been trying to change this for five years. My success in this has been such that it contributed strongly to my recent decision to start searching for another job. The reality is that biomedical researchers simply do not believe in doing mathematical analysis of data properly. They consider it an eccentric habit, forgivable but socially objectionable, like smoking. By common consensus, it is considered much too complicated to expect that any of them can be expected to understand. Your average biologist is innumerate to the nth degree, and proud of it.
I blame their education, which seems to stress naive and antediluvian (excuse the word) analysis practices, if at all. I have seen course materials which in their expression of basic mathematical formulas, betrayed that they had been left unchanged since the days when people used slide rules and logarithmic tables for calculations. Most of their other training is strictly qualitatively, not quantitatively, and focussed more on memorizing that on understanding.
If necessary, they will find a crutch to help themselves to stumble along: Find a paper that defines a formula that looks relevant, and then fill in the numbers. They would not bother doing their own analysis, or trying to understand how the calculation works or whether it is relevant at all. The notion that a good statistical analysis of mathematical modeling can actually contribute to the scientific understanding of an issue, is well beyond most of them.
I am frankly, sick and tired of their attitude, and I still have to work with these people every day. And in my experience, my colleagues are actually better than most. I strongly suspect the WSJ is correct on this one.
I think the biggest stumbling block for above-average developers is the attitude of managers who indeed think of programmers as 'cogs in the machine'. And a sausage-machine at that. I have seen too many projects without a serious design phase at all. Typically they start with a team of managers and tutti quanti dreaming up a specification (usually to vague to be useful, but still specific enough to be unworkable) and then expecting that the software will simply be written.
When you try to explain to them that actually, there is nobody in the IT department who is actually capable of designing and building such a system of the required complexity, you meet blank stares and incredulity. How is that possible, when that place is filled with programmers? Trying to explain the difference between routine GUI programming, systems administration, database administration, and designing a company-wide system of interlinked applications is no use. Managers would apparently trust any competent car mechanic to design a Formula-1 car. Well, they must, because they are not willing to pay for the skilled engineers that it takes to do the real job, or to invest in serious training for the people that they have.
Of course, if they don't have the people, managers are willing to contract them. So they pay to bring in programmers from consultancy firms, and expect them to hit the ground running, seamlessly integrating in teams with people they have never met before, and writing business logic for a business they don't understand. You would need to be really lucky to find all the right people right away, more often you need to get rid of about half the consultants you hired at first, because they are no good or because they experience is too far removed from the needs of the projects.
So far, I've met just one or two really highly skilled and creative developers. Flexible thinkers who quickly grasp problems, readily adopt to whatever technology they need, plan realistically, and deliver quality work. They are a delight to work with, and you can achieve as much with them in one hour as you would else do in whole month of meetings and deliberations. But they are usually self-employed or running their own little firms, and they can afford to pick and choose the projects they are interested in. If they don't want to do it, or don't have the time, they won't. Management regards often them as 'difficult' and expensive, considering that other programmers are a dime a dozen... So the pleasure is rare.
The normal condition is to have a mix of more or less skilled people who will learn on the job and might be quite competent at the end of the project, and inevitably a few idiots you have to entrust parts of the project to with appropriate feelings of resignation and foreboding. (When in IT waters, I live on my wits. I have no authority there.)
Saturn V would be a ridiculously poor choice to use as basis of an ICBM. It stood 110 m tall, weighed over 3,000 tons fueled, and used liquid hydrogen and oxygen as fuels.
A good ICBM needs to be compact, so that is easily hidden, and above all it must be storable in a ready-to-fire form. That meant using storable liquid fuels instead of condenses gases for first generation missiles, and solid fuels in the later designs. To give an idea, Minuteman III is a mere 18 m long, weighs 32 tons at launch mass, and uses solid fuels. Even the big Soviet R-36 aka SS-18 Satan did not exceed 210 tons, and while it used liquid fuels, it used liquid fuels that could be stored at room temperature.
Rationally, Saturn V never had a military application, and certainly today its technology is no longer of any military value.
Don't be silly. It is perfectly possible to write robust, efficient C++ code at a decent speed. And it is certainly much more efficient than generating buggy crap and then spending weeks, months and years trying to find the elusive bugs. Not to mention the complete rewriting of large blocks of unintelligible, bad-quality code as 'bug fix'.
I fully agree with the original author. Buffer overruns? Dangling pointers? I haven't had them in years, and my code is written on time and meets performance targets. Nor am I even that skilled a C++ writer; I do something from time to time to keep in good mental form, and when I need to integrate some fast processing code in Java code or enterprise software. I have no respect for people who allow buffer overruns or dangling pointers to pollute their code, and who leak memory from all their gills. All it takes to prevent such errors is a little care, the adoption of reasonable design patterns, and a bit of mental exertion.
There are plenty of more-or-less excusable bugs, let's start by learning to avoid to inexcusable ones.
And I am especially annoyed at the so-called 'safe' versions of standard library functions that MS introduced in Visual C++ to compensate for this kind of libertine amateurism, even deprecating strncpy()... in favor of a version that is best avoided unless you are well aware what it is doing to the rest of your buffer. But then the Microsofty version of C++ has always been a definite example of a language that has gone over to the dark side.
The reality is that clinical trails are being done in the USA, also for treatments for HIV. For many diseases, the USA both has a large population of patients who have exhausted every existing treatment option, and a large population of patients who cannot afford existing treatments. That makes it a good recruiting ground for clinical studies. The disadvantage is the high cost of the trials.
(I have heard rumors of at least one incident in which FDA officials suggested that before trials in the USA could be permitted, a new treatment should be tested on foreigners first --- I assume that that is not official policy.)
Clinical trials in 'third world' countries are a booming industry in places like India, which possess sufficient numbers of trained health professionals, but also have a lot of patients who cannot afford normal treatment options, and where cost of trials is substantially lower than in the USA or Europe. The technical procedures still have to meet the same standards as if the trials would have been done in the USA, that is not the problem. The real problem is explaining to often very poorly educated people who are in bad straits, that they are participating in the evaluation of experimental drugs -- the principle of "informed consent" tends to be a bit illusionary in such cases. That indeed makes such trials controversial.
Payments by the pharmaceutical industry to the FDA are something that Congress, in its wisdom, has institutionalized. The logic behind this must have been that almost anything is better than raising taxes, although in this case the almost seems highly questionable. It is quite possible that the objectivity if the FDA is not in the least affected by this, but the appearance of propriety also counts for something.
As for the cost of drugs in the USA, keep in mind that the simple economic law of demand and supply applies in the pharmaceutical world as well. The industry develops treatments that are very expensive to administer, such as for example some cancer treatments, because there are a sufficient number of patients who can (directly or indirectly) afford them. There are still many more diseases than treatments, so the industry opts to develop cures for those diseases that are financially interesting. If the patients could or would not pay, then the development of a cure would make no economic sense. A $200k treatment for the cancer of an American is financially viable; a $200 treatment for the life-threatening parasitic infection of a patient in sub-Saharan Africa is not.
There are limits to the wisdom and efficiency of the free market.
Disclaimer: I am prejudiced. I don't have a CS or IT degree, I am a scientist by training. And if I look at the fate of most people with IT degrees in our organization, I can only have pity on them.
If you want to have a real career, then by all means retain your broad range of interests. "Dabbling" is okay, but perhaps you want to specialize a bit -- to consider for a moment to what field you would want to apply these computing skills. If you would enjoy writing financial software, you'll better know something about finance. If you want to do computer graphics, some arts and design classes might be in order. If you think scientific software is your niche, then don't forget to study some science. Studying some science, mostly mathematics and physics, is a good idea in any case.
You see, "pure IT" people are minions. Pawns. Gun-fodder. If you don't understand what a piece of hardware or software is for, nobody of sound mind is going to entrust you with its design. They'll give you a clear specification and a set of policies to implement, and tell you to get on with it. Unless you are capable of grasping the scope and nature of the business you need to support, and do it really quickly (for as often as not these are consultancy jobs), you won't get much further than that -- and it is not a particularly rewarding or pleasant job. 99.9% of it is pure routine. If you have a broad range of interests and skills, then by all means avoid that fate.
My advice, for what it is worth: If you have the required energy and intelligence, then either choose CS (and don't forget to develop some actual programming skills while you are doing that), or opt for some science or engineering degree that includes a strong informatics course. Avoid pure IT.
CS probably still offers a good career. Somebody who is looking for a good programmer might equally well (or perhaps even better) hire an engineer, a physicist or a mathematician instead of someone with an IT degree, but so far few people without formal CS training can match their particular set and level of skills.