You'd probably not be swatting away for some douche at a University, trying to finish you thesis or get tenure. You'd probably scrape together every last penny you had and become a first round VC.
It does you no good to have a genius developer if he's the only person that can work on the code. Just because Josh solves something quickly, how do you know his solution is tested, reliable, or doesn't introduce new bugs? I've worked with Josh types and generally they don't produce quality code. They produce a lot of code and they produce it quickly, with little thought.
More often than not, once you actually start to look at the code it's rife with other problems. Sure, they fixed the one issue or added that one feature, but they did it at the cost of a some other, perhaps even more serious, issues. Of course, that's once you get past the fact they rely on XYZ undocumented "feature" that got patched, which caused the hack to break 3 months after Josh left, which is why you're now reviewing Josh's code.
But let's assume Josh wrote good code and everyone else was just too dumb to follow it. From the company's perspective this is almost as bad as not having Josh in the first place. Now, if Josh were to leave, they would face the problem of not being able to maintain their code until they find another Josh. (Who will probably s**t all over the work of the first Josh in order to prove how smart he is.)
In other words, if you can't play well with others then you are not an asset to the company. Your value to the company is less than someone who, although not as smart, documents their work and explains it to other team members. A "genius" developer like Josh shouldn't have a corner office because you don't merit it any more than the guy who can't code to save his life. Although Josh looks good in the short term, eventually he will become the bottleneck since only he can maintain his own code.
I've met guys who are insanely productive but almost always can explain what they're doing and why they're doing it. You could step into their code with little or no trouble. Those guys are worth the big bucks because what they do is not a one-off solution or a quick hack. Those are highly productive, high-value engineers. They're also much more rare than often self-appointed hacks that claim to be genius developers. The tough part for companies is to find these guys, reward them, and keep them. Most companies, however, get dazzled by Josh or by Jack (the popular guy that doesn't seem to do any work but everyone likes).
The sign you have a snake oil salesman like Josh is that once people start to question what they do, they bolt. Once their scam comes due, and it always does, they realize people will start to really evaluate their value. If they bolt early on, while their reputation is still intact, they might be able to continue their scam at the next company.
If there's anything that most business fail to do well, is realize who is a productive engineer. If an engineer does it in a couple of days, but only he understands the solution, is he more productive? What if the engineer takes two weeks but then any other engineer in the department knows exactly what they did and can maintain their work?
What about the engineer who is a framework guru that needs six weeks to build the frameworks for the project, so they need to only spend two weeks on actual problem specific coding? Is that more productive than the engineer that looks at the same problem as a "one-off" and does it in three weeks without building the frameworks?
So Josh is productive, but what happens what Josh leaves? We used to use a metric called the bus count. How many people would have to get hit by a bus before we lost all institutional knowledge of how something works. The bus count of 1 means you are up s**t creek if the one developer leaves.
I've met people who were rock stars and could document everything they did. They could play well with others and be smart. Having someone with serious skillz but unable to communicate and work with others (keeping the bus count at 1) is about as useful as a likable person that can't code.
The difference is that we tend to, on a gut level, respect competence more than incompetence, but working with others is a kind of competence. So, at some level, we have more sympathy for someone like Josh, as does management. In the long run, however, Josh can't fix all the problems, Josh can get hit by a bus, or Josh could just decide to go off and do his own thing. In any case, letting Josh get that much control was a management, not Josh's, failure.
I agree. The person will not have much power over disparate agency budgets. They will, for the most part, be powerless in the direct sense of the word. However, I expect this person to set direction and make some ideas okay or not okay.
It might be nice to have someone that forces the various agencies to think about other approaches to their problems. Given the size and complexity of the executive agencies, where systems range from lots of embedded devices (like the DoD) to more traditional IT systems and mainframes. I don't think they're going to be in a position (nor would we want them to) to say "no more fire control systems built with rad-hard PowerPC boards running VxWorks - we're Windows CE on Intel from here on in because we're a 1 vendor shop!"
(Or, just replace Windows CE with Linux - if that's what gets your goat).
Given the position will be at a very high level, someone who's more visionary than practical (at navigating the government side of it) would be a good choice. In fact, someone who's mired in the day to day problems of managing technology in government (whether on the contractor side or the government CTO/CIO side) might see limits more than opportunities. So hire someone from government IT management and you will get government IT management.
However, there are enough people in government that come up with pie-in-the-sky solutions, insisting that all solutions be buzz-word compliant without really understanding the ramifications in terms of time or cost, or if some solutions are even ready for prime time. Visionary can translate into unrealistic (especially in environments that are governed by a slew of regulations that are not common in the private sector.)
In the end I think it's the actual person hired that will be effective or ineffective. What I don't want to see is someone who has the same answer all the time for the same problems. In other words all they know is buy from this vendor, implement with this contractor, insist on these "standards" and you're done.
The most disturbing pattern I've seen in some agencies is to use IT contract management as a dumping ground for people who can't do the core job of the agency. I would like to see someone who cleans up IT contract management (and let's face it - almost all government IT is managing a contract while an outside contractor does the actual work).
In a Y2K migration I did bout 10 years ago I had to slog through COBOL reports to convert them to a Cognos tool. They were part of the regular batch of reports churned out on massive impact printers and [sic] mailed to state branches of the organization I was working with. Given that some of those were above the legal drinking age when I looked at them (and a couple I had to migrate from output because they lost the source code), I would bet there's COBOL code on a mainframe somewhere that's been steadily chugging away since dirt was new. Had a similar problem a couple of years later with more ancient COBOL code. Anything older than that is probably Fortran or assembler. I wouldn't write off Fortran, either. About 15 years ago I was working on my masters with a guy from NOAA who had ancient System 360 and code they were still running which for some bizarre safety or contractual reason couldn't be moved to a PC. Even though the PC version by that time was several times faster.
You see a lot of stories about people using products like http://www.comwaretech.com/PDP-11/DEC-PDP-11-emulator.html to replace ancient and decrepit hardware. Or emulated VAXen because they 1) lost the source code 2) the company that wrote it is gone or 3) it just cheaper to keep it running. There's a number of hobbyist emulator systems for old hardware, but there are also a surprising number of commercial emulators for old hardware, suggesting there's something of a market for running old, old programs. I recently read an article about a Navy Shaking Table that was upgraded with somebody's PDP-11 on a FPGA solution, replacing the existing PDP-11 hardware. That would put it at about 30 years.
Yes, you could pay out the nose for a 200k mobile broadband account (on a good day) or you could pop in to your local sandwich shop for free and use their broadband (which might be tied into a 5/2 Mbps cable modem). Hmmm...
After looking over several models I settled on one by Phillips. The most annoying part is that, when recording, the audio can't keep up with the video. It results in programs where the delay is so bad, it starts to become garbled. Although this doesn't always happen, it happens often enough that the DVR was a better option.
People think Computer Science = Learning How to Program. Actually Programming is akin to learning how to frame a house. It's a trade that you learn, a craft that developed with practice. You learn what works and what doesn't (sometimes it's what works and what doesn't work for you, individually). You can even follow strict standards on how you should program from various methodologies or certification programs. However, this is not Computer Science any more than building a house to code is Civil Engineering.
So, what is Computer Science? For the most part Computer Science is applied math. Even Computer Science majors don't think of it this way, especially the ones that dread math. However, let's break it down. At the lowest level you have a CPU, memory and devices, which you are controlling with a stored program as opposed to physical wiring. The nature of the CPU and the instructions, their flow, and how the execute can be described by abstract machines (turing style) and boolean equations. At this level you could talk about computers on pen and paper without actually having to worry about silicon and wires. In fact, those who really love computer science love taking the architectures class where they basically build a CPU.
As we move up from the lowest levels into the operating system, we see issues like dead-locking handled through mathematical proofs of why a deadlock can or can't happen. We prove why certain communications patterns can or can't result in certain states (i.e. why 2-phased commit works). Implementation is performed to actually test the theory in real life. However, you could spend all your time working on the theory. This is also true of graphics, communications, artificial intelligence and databases. You can pick up journals in all these areas and find articles that are nothing more than a proof of why a given algorithm will work. Implementation is a way to check to see if the theory works in the real world, and in a sense tests the assumptions more than theory. The area of software engineering is an odd bird in that it straddles code and people issues. Really, it can fall between a management problem and an engineering problem. However, even some software engineering approaches are grounded in math.
Now, with that said, why do we require programmers to have a Computer Science degree? My thinking is that we shouldn't. In the late 70's and early 80's a number of schools opened up that taught people COBOL programming as a trade. I think we should do that for Java, and it may be high time. Microsoft could open Microsoft education centers teaching Windows and.NET the same way companies teach plumbing. We don't require the electrician wiring your house to have a degree in Engineering, but they still manage to get it wired. Same thing with whipping together some JSP pages for an online store. We have lots of tools to take the programming burden off the programmer, just like the electrician has tools and training without having to resort to 4 years of classwork in physics, chemistry and math. We can teach them the basic language, the IDE, and how to take requirements and translate them to code according to (pick your methodology). They then take a certification exam and they're good to go.
What would happen to the computer scientists? First off, if we had a ready source of skilled programming labor, we would come to the conclusion we graduate too many computer scientists. If you had a company of 100 programmers you might have 5 or 10 computer scientists on staff the same way you might have an engineers on staff at a construction firm. Of course that depends what you're doing. If you build bridges you might have more engineers than if you just frame single family homes. Some companies would have no computer scientists and would just body shop out programmers. Others might have 1 computer scientist for every 5 programmers.
Second we would see fewer people going to get a degree just to work in IT. In fact, it might become more of a training after a BS in Ma
Maybe we need to train the 500,000 web back end developers the same way we train other trades. Hammering out ColdFusion page after ColdFusion page is a trade, as far as I'm concerned. Even Java can be boiled down to a trade school type discipline, where you spend a few months learning the language and a typical IDE. On a construction site you need a number of guys that can swing hammers, but you don't need them to be Civil Engineers. The point of the theory is to teach people how to think about the problems they encounter. Coming from a school like Stanford, as an employer, I would assume the following. You're probably smart. You're certainly competitive. And you've been challenged by being around smart people. Okay, whatever I throw at you, you will probably figure out. This is especially good if I have a complex system that requires a lot of high order brain power. Say, for example, I was building a UAV and a simulator to teach people how to pilot the vehicle. However, if I needed someone to crank out JSP pages for an on-line sock store and I have to do it for $50 an hour or less, and I need them done before the penalty phase of my contract kicks in, you're not my man. Just like if you were a Civil Engineer I wouldn't hire you as a framer.
I agree with your characterization of CS whole heartedly. Programming is to computer science as assembling circuit boards is to electrical engineering. However, as the cost of a college education is now routinely in the six figures, people want to see a "return on investment." By people I mean mostly the kid and their parents. So people start talking in terms of "marketable skills" as being a byproduct (or the primary product) of their educational offerings. It's a mistaken view of education period, much less computer science. They would be better off with two years at the local college and getting certified by Sun. However, we put them through a CS program and they have to learn (gasp) ancient unused languages like C or even LISP, which are not "used in the real world." (Meaning they can't wander into the average Job fair with a resume).
In the perfect world you wouldn't have to teach incoming freshmen any languages, they'd just pick up "OCaml for Dummies" and perform their assignments in whatever language they choose. However, people come into a program with varying levels of expertise (and profs don't want to grade assignments in OCaml, Perl, SPIM Assembler, and Objective-C). So you have to pick something to start with. Java is a valid choice, but it is becoming the only choice. For example, I just learned my Alma-Mater is teaching graphics using JOGL - a Java wrapper around Open GL. Soon your entire world is the safe, detached, abstract virtual machine world where all you do is connect pieces written by somebody else. Except for those two horrible semesters where you took Operating Systems (and you had to use C) and you took Architectures (where you had to use Assembler).
After 4 or 5 years your entire view of the world is Java/virtual machine oriented. If someone offered you a job coding in C, you could probably muddle through it, leaking memory like a sieve and the odd core dump. Moreover, when Language X replaces Java, you now write Java code in Language X. (I have to wade through Java code written by COBOLers that write COBOL code in Java.) If you push them to learn two or three languages (ideally C and LISP) they will have an appreciation for thinking about problems with a different syntax. They will look at Language X and say - it's kind of like Java here, but it's very LISPy in this way. Having been pushed to learn LISP, they might write decent code in Language X because they can think about the world is something besides Java syntax.
I see a lot of posts talking about how useless math and C are in "the real world." Well, it depends on the "real world" in which you live. Most of us will find ourselves writing code to help a company do stuff on the interwebs. That's where most of the jobs are and little of it really requires anything more advanced than the basics of programming and a little bit about databases. Thanks to frameworks like Rails, you really don't have to know much about databases, either. You also don't need a computer science degree to do this. In fact, after CS 101 just get a degree in business or get an MIS degree. Getting a CS degree because you want to work at Accenture doing in Java what many have done before you in COBOL is a perfectly fine thing to do. Getting a CS degree to do it is like getting a biology degree to sell fish at the local pet store.
If your "real world" involves interfacing computers with physical devices, then you need more math and more low-level stuff. For example, even if you're working in Java, you may need to talk to devices over serial lines (which Java stinks at) or you may even need to write your own devices to read/write to device memory. Not many CS grads actually wind up doing this. A lot of people who got degrees "CS" and work in "IT" feel like this is useless knowledge, but someone had to write the software for their car's GPS, or braking system, or that reads the various sensors all throughout their car and posts warning information. Things like braking systems are sometimes written in "dead languages" like Ada because they need to be real time and safety critical. There is a real time Java, but programming in it is quite different that regular Java.
The point is, don't think about your narrow slice of the "real world" and then think that's all there is. By training nothing but Java programmers, with only a vague understanding of what actually happens inside the physical computer, we loose our ability to generate the people that will write software for braking systems, avionics suites, robotics and plant control. Also, the people who do that kind of work can often step into a web application environment and pick up whatever language they need. I've seen that transition occur often, but I've never seen people who are just Java hacks make their way into "real" programming. Maybe we don't need as many of those guys as we need ColdFusion experts;) but it is good training for just about anything else you want to do with computers. So, I think their hack at Java is a very valid criticism of relying on Java and not having students learn something about what a computer is/does at a low level that only languages like C can provide.
Spending several hours trying to find the problem only to learn you forgot to initialize a pointer is part of programming. I've watched people struggle for hours only to find they had a simple logic error. But that's part of learning the craft of programming. Strictly speaking programming as as much to do with computer science as soldering wires has to do with electrical engineering. However, at some point you need to implement these great ideas and it's done on a computer. That means its limited by the things a computer can and can't compute, the amount of time it takes to compute it, and the underlying software structures (operating systems and libraries). An in-depth understanding of these issues, reinforced by work in a programming language sensitive to these issues (C and Assembler) yields someone who really "groks" computers. As time passes, and with a good understanding of what a computer actually does, those mistakes become fewer and fewer. Some day you might actually be a good programmer, at which time you will be promoted into another job.:)
It's interesting you don't see much use for math in programming, but you think games are a good start. I've worked for a while on a simulator for an armored vehicle, which was essentially a big 3-D tank game. We had two aerospace engineers working on the math of how the tank was supposed to react. Granted, we were going for hyper-realism, but even in games that don't stress realism there's a good bit of math behind the physics model. The graphics required fairly sophisticated models of how the other units were supposed to respond. Even simple 2-D shooters probably will require matrix algebra (at least you'll need it to work with the underlying drawing libraries such as Open GL or DirectX). In addition, a lot of interesting games have a soft-real time component, where you need to complete your drawing code, game a/i decisions, etc. every 33 or 16 ms (depending on 30 or 60 fps).
If you want to connect the customer database to CRM system, no, you do not need a lot of math. However, you also do not need a CS degree. Go get an MIS degree (where they used to teach COBOL until recently). That's what it's there for. And, as an employer, I know the difference between a "fresh-out" and someone who has 10 years of industry experience. Some fresh-outs are stunning in their productivity and they're usually the ones who did something low-level and challenging. The guy that did a new scheduler for Linux as his senior project, and has had a good grounding in C, architectures, and Lisp, can pick up Java and whatever libraries. I'm not worried about that. If he's good, he's worth the investment. The fact that he's not as productive as someone who's been in the workforce 10 years is reflected in his salary and the degree to which he's able to operate without supervision. But that only makes that person "unhireable" if I don't hire fresh-outs as a rule of thumb.
I'm the "market" side of that equation. I hire programmers for my company. I also manage projects and sell projects to customers. I can teach any idiot Java, but I cannot teach people to think or give them what they should have learned in undergrad. Let me give you a concrete example. I had one fellow who told me something was "wrong with the system." He was having a problem where a native library was not in the search path and the Java wrapper library was causing the VM to tank from the link error. He didn't see the need for C or C++ and wanted to focus on Java because that's what he learned in school and that's what the market wanted. He didn't understand anything about why his program was dying and how to fix the problem. Slack-jawed, he brought me in and was amazed when I updated his environment and his program worked fine. He was a competent Java programmer, good with clients, but didn't actually know how his computer worked. He didn't known the first thing about dynamic linking, or linking in general, because he didn't understand what a computer is and thought Java was all you need to know.
If you're going to treat a CS degree like a trade school please teach the students architectures, C and assembler. That way they know something about the actual computer and not just how to string together Java code to get what they want. That way, when something breaks, they actually can diagnose and fix the problem. I've seen a shrinking pool of people who really "know their shit." It makes some of the more challenging business ideas harder to implement not because they don't know how to program in a language, but they have no idea what actually happens inside a computer.
If you do the math and start with two equal populations. Give one population a slightly higher chance of producing offspring. Assume mortality rates are about equal. Eventually, now matter how small the advantage, the population with the advantage will dominate. In fact, the rate at which they dominate will be exponential. Our only hope, as a species, is the mortality rates on lower IQ individuals are high enough to offset the advantage in reproduction.
At the age of 15 I would have gladly traded IQ points for pussy. However, due to the lack of women in the morning chess club meetings (that's right - we met an hour before school started to play chess), and the fact my HP pocket calculator wasn't as cool as a letter jacket, might have been a modest disadvantage. In addition - and I mean this in the best sense - smart kids think they can better understand and manage risk unlike the "average person" for whom all the laws were written. Hence some of the complete and utter stupidity we engaged in, that wasn't sexual in nature, could have easily lead to severe injury or death. I can certainly say that I never weighed the risk and decided sex wasn't worth it, and I'm sure I can speak for the bulk of my high school companions. Mostly because we never managed to get ourselves into the situation where we could decide, despite our best laid plans. Being a nerd (in the good at physics, plays chess, but bad social skills, and really crappy car sense) did not lead to many opportunities for sex. There were some kids who were very smart, went to parties we never heard of until after, with great social and girlfriends. I'm pretty sure they had sex. We were also big Woody Allen fans (long before he creeped out the world by dating is daughter) and as the man said: "Sex without love is an empty experience, but as empty experiences go - it's one of the best."
It's my very humble and limited understanding that the big reason we don't see electric cars is the battery technology. Not that the basic technology isn't there, but it's my understanding that a battery specific to autmotive applications still isn't on the market. Didn't the Tesla just string a bunch of NiMH or lithium ion batteries together from laptops?
I often like the u-kernel/hybrid kernel idea of running stuff in userspace as opposed to kernel space for security, extensibility, etc. etc. However, I never would have thought licensing issues. However, what if we did start running more parts of Linux in user-space, creating a hybrid kernel, to get around licensing? Don't want to play with GPL? That's fine, just user-space it. Of course, the down-side is some XYZ Linux distro with all sorts of stuff running in user-space because of licensing restrictions. The idea of trading performance for legality (as opposed to a "real" issue like security or reliability) is somewhat unappealing.
The least of which is the movie they just saw or the video game they just played. He probably displayed other anti-social behavior in the past. (Not silly things like black trench coats but actually physical assault, fascination with violence, and possibly killing pets or other small animals). The VA Tech shooter was a text book example of "missed warning signs." While that's not my favorite genre of games I think that claiming the game made him do it is up there with witches' spells and demonic posession. Perhaps if he had masturbated more he would have been better adjusted. Or why not blame the chemical additives in the food he eats (which I actually would be more prone to believe). Maybe he's just a psycopath and he killed another person because he lacks emotional development. Maybe suffers from mental illness. Or maybe he just cares more about his enjoyment than other peoples' suffering. All those are more likely explanations that a video game touched something in his psyche and turned him from a "such a sweet kid," into a murderer.
And if it does, they should be served with subpeonas and investigated. However, we don't just give up trying to enforce laws because our political adversaries might have done or could do the same thing. If that's the case why have laws in the first place? Why not just say do whatever you want. That was called the "spoils system" and we got rid of it because it lead to horrible curruption in the government. (That was when you could fire almost everyone in the government and then put your own people in, some of whome actually paid for their appointments.) That didn't work out so well.
Wrong answer, Bob. They used several accounts at the RNC, at political campaigns, and other orgs. That's one reason it's so hard to track. When it first broke, two servers (both controlled by Republican party organizations) disappeared off the internet. Both of which supposedly carried Whitehouse staff e-mail.
Slashdot Mirror
You'd probably not be swatting away for some douche at a University, trying to finish you thesis or get tenure. You'd probably scrape together every last penny you had and become a first round VC.
It does you no good to have a genius developer if he's the only person that can work on the code. Just because Josh solves something quickly, how do you know his solution is tested, reliable, or doesn't introduce new bugs? I've worked with Josh types and generally they don't produce quality code. They produce a lot of code and they produce it quickly, with little thought.
More often than not, once you actually start to look at the code it's rife with other problems. Sure, they fixed the one issue or added that one feature, but they did it at the cost of a some other, perhaps even more serious, issues. Of course, that's once you get past the fact they rely on XYZ undocumented "feature" that got patched, which caused the hack to break 3 months after Josh left, which is why you're now reviewing Josh's code.
But let's assume Josh wrote good code and everyone else was just too dumb to follow it. From the company's perspective this is almost as bad as not having Josh in the first place. Now, if Josh were to leave, they would face the problem of not being able to maintain their code until they find another Josh. (Who will probably s**t all over the work of the first Josh in order to prove how smart he is.)
In other words, if you can't play well with others then you are not an asset to the company. Your value to the company is less than someone who, although not as smart, documents their work and explains it to other team members. A "genius" developer like Josh shouldn't have a corner office because you don't merit it any more than the guy who can't code to save his life. Although Josh looks good in the short term, eventually he will become the bottleneck since only he can maintain his own code.
I've met guys who are insanely productive but almost always can explain what they're doing and why they're doing it. You could step into their code with little or no trouble. Those guys are worth the big bucks because what they do is not a one-off solution or a quick hack. Those are highly productive, high-value engineers. They're also much more rare than often self-appointed hacks that claim to be genius developers. The tough part for companies is to find these guys, reward them, and keep them. Most companies, however, get dazzled by Josh or by Jack (the popular guy that doesn't seem to do any work but everyone likes).
The sign you have a snake oil salesman like Josh is that once people start to question what they do, they bolt. Once their scam comes due, and it always does, they realize people will start to really evaluate their value. If they bolt early on, while their reputation is still intact, they might be able to continue their scam at the next company.
If there's anything that most business fail to do well, is realize who is a productive engineer. If an engineer does it in a couple of days, but only he understands the solution, is he more productive? What if the engineer takes two weeks but then any other engineer in the department knows exactly what they did and can maintain their work?
What about the engineer who is a framework guru that needs six weeks to build the frameworks for the project, so they need to only spend two weeks on actual problem specific coding? Is that more productive than the engineer that looks at the same problem as a "one-off" and does it in three weeks without building the frameworks?
So Josh is productive, but what happens what Josh leaves? We used to use a metric called the bus count. How many people would have to get hit by a bus before we lost all institutional knowledge of how something works. The bus count of 1 means you are up s**t creek if the one developer leaves.
I've met people who were rock stars and could document everything they did. They could play well with others and be smart. Having someone with serious skillz but unable to communicate and work with others (keeping the bus count at 1) is about as useful as a likable person that can't code.
The difference is that we tend to, on a gut level, respect competence more than incompetence, but working with others is a kind of competence. So, at some level, we have more sympathy for someone like Josh, as does management. In the long run, however, Josh can't fix all the problems, Josh can get hit by a bus, or Josh could just decide to go off and do his own thing. In any case, letting Josh get that much control was a management, not Josh's, failure.
I agree. The person will not have much power over disparate agency budgets. They will, for the most part, be powerless in the direct sense of the word. However, I expect this person to set direction and make some ideas okay or not okay.
It might be nice to have someone that forces the various agencies to think about other approaches to their problems. Given the size and complexity of the executive agencies, where systems range from lots of embedded devices (like the DoD) to more traditional IT systems and mainframes. I don't think they're going to be in a position (nor would we want them to) to say "no more fire control systems built with rad-hard PowerPC boards running VxWorks - we're Windows CE on Intel from here on in because we're a 1 vendor shop!"
(Or, just replace Windows CE with Linux - if that's what gets your goat).
Given the position will be at a very high level, someone who's more visionary than practical (at navigating the government side of it) would be a good choice. In fact, someone who's mired in the day to day problems of managing technology in government (whether on the contractor side or the government CTO/CIO side) might see limits more than opportunities. So hire someone from government IT management and you will get government IT management.
However, there are enough people in government that come up with pie-in-the-sky solutions, insisting that all solutions be buzz-word compliant without really understanding the ramifications in terms of time or cost, or if some solutions are even ready for prime time. Visionary can translate into unrealistic (especially in environments that are governed by a slew of regulations that are not common in the private sector.)
In the end I think it's the actual person hired that will be effective or ineffective. What I don't want to see is someone who has the same answer all the time for the same problems. In other words all they know is buy from this vendor, implement with this contractor, insist on these "standards" and you're done.
The most disturbing pattern I've seen in some agencies is to use IT contract management as a dumping ground for people who can't do the core job of the agency. I would like to see someone who cleans up IT contract management (and let's face it - almost all government IT is managing a contract while an outside contractor does the actual work).
In a Y2K migration I did bout 10 years ago I had to slog through COBOL reports to convert them to a Cognos tool. They were part of the regular batch of reports churned out on massive impact printers and [sic] mailed to state branches of the organization I was working with. Given that some of those were above the legal drinking age when I looked at them (and a couple I had to migrate from output because they lost the source code), I would bet there's COBOL code on a mainframe somewhere that's been steadily chugging away since dirt was new. Had a similar problem a couple of years later with more ancient COBOL code. Anything older than that is probably Fortran or assembler. I wouldn't write off Fortran, either. About 15 years ago I was working on my masters with a guy from NOAA who had ancient System 360 and code they were still running which for some bizarre safety or contractual reason couldn't be moved to a PC. Even though the PC version by that time was several times faster.
You see a lot of stories about people using products like http://www.comwaretech.com/PDP-11/DEC-PDP-11-emulator.html to replace ancient and decrepit hardware. Or emulated VAXen because they 1) lost the source code 2) the company that wrote it is gone or 3) it just cheaper to keep it running. There's a number of hobbyist emulator systems for old hardware, but there are also a surprising number of commercial emulators for old hardware, suggesting there's something of a market for running old, old programs. I recently read an article about a Navy Shaking Table that was upgraded with somebody's PDP-11 on a FPGA solution, replacing the existing PDP-11 hardware. That would put it at about 30 years.
Yes, you could pay out the nose for a 200k mobile broadband account (on a good day) or you could pop in to your local sandwich shop for free and use their broadband (which might be tied into a 5/2 Mbps cable modem). Hmmm...
After looking over several models I settled on one by Phillips. The most annoying part is that, when recording, the audio can't keep up with the video. It results in programs where the delay is so bad, it starts to become garbled. Although this doesn't always happen, it happens often enough that the DVR was a better option.
People think Computer Science = Learning How to Program. Actually Programming is akin to learning how to frame a house. It's a trade that you learn, a craft that developed with practice. You learn what works and what doesn't (sometimes it's what works and what doesn't work for you, individually). You can even follow strict standards on how you should program from various methodologies or certification programs. However, this is not Computer Science any more than building a house to code is Civil Engineering.
.NET the same way companies teach plumbing. We don't require the electrician wiring your house to have a degree in Engineering, but they still manage to get it wired. Same thing with whipping together some JSP pages for an online store. We have lots of tools to take the programming burden off the programmer, just like the electrician has tools and training without having to resort to 4 years of classwork in physics, chemistry and math. We can teach them the basic language, the IDE, and how to take requirements and translate them to code according to (pick your methodology). They then take a certification exam and they're good to go.
So, what is Computer Science? For the most part Computer Science is applied math. Even Computer Science majors don't think of it this way, especially the ones that dread math. However, let's break it down. At the lowest level you have a CPU, memory and devices, which you are controlling with a stored program as opposed to physical wiring. The nature of the CPU and the instructions, their flow, and how the execute can be described by abstract machines (turing style) and boolean equations. At this level you could talk about computers on pen and paper without actually having to worry about silicon and wires. In fact, those who really love computer science love taking the architectures class where they basically build a CPU.
As we move up from the lowest levels into the operating system, we see issues like dead-locking handled through mathematical proofs of why a deadlock can or can't happen. We prove why certain communications patterns can or can't result in certain states (i.e. why 2-phased commit works). Implementation is performed to actually test the theory in real life. However, you could spend all your time working on the theory. This is also true of graphics, communications, artificial intelligence and databases. You can pick up journals in all these areas and find articles that are nothing more than a proof of why a given algorithm will work. Implementation is a way to check to see if the theory works in the real world, and in a sense tests the assumptions more than theory. The area of software engineering is an odd bird in that it straddles code and people issues. Really, it can fall between a management problem and an engineering problem. However, even some software engineering approaches are grounded in math.
Now, with that said, why do we require programmers to have a Computer Science degree? My thinking is that we shouldn't. In the late 70's and early 80's a number of schools opened up that taught people COBOL programming as a trade. I think we should do that for Java, and it may be high time. Microsoft could open Microsoft education centers teaching Windows and
What would happen to the computer scientists? First off, if we had a ready source of skilled programming labor, we would come to the conclusion we graduate too many computer scientists. If you had a company of 100 programmers you might have 5 or 10 computer scientists on staff the same way you might have an engineers on staff at a construction firm. Of course that depends what you're doing. If you build bridges you might have more engineers than if you just frame single family homes. Some companies would have no computer scientists and would just body shop out programmers. Others might have 1 computer scientist for every 5 programmers.
Second we would see fewer people going to get a degree just to work in IT. In fact, it might become more of a training after a BS in Ma
Maybe we need to train the 500,000 web back end developers the same way we train other trades. Hammering out ColdFusion page after ColdFusion page is a trade, as far as I'm concerned. Even Java can be boiled down to a trade school type discipline, where you spend a few months learning the language and a typical IDE. On a construction site you need a number of guys that can swing hammers, but you don't need them to be Civil Engineers. The point of the theory is to teach people how to think about the problems they encounter. Coming from a school like Stanford, as an employer, I would assume the following. You're probably smart. You're certainly competitive. And you've been challenged by being around smart people. Okay, whatever I throw at you, you will probably figure out. This is especially good if I have a complex system that requires a lot of high order brain power. Say, for example, I was building a UAV and a simulator to teach people how to pilot the vehicle. However, if I needed someone to crank out JSP pages for an on-line sock store and I have to do it for $50 an hour or less, and I need them done before the penalty phase of my contract kicks in, you're not my man. Just like if you were a Civil Engineer I wouldn't hire you as a framer.
I agree with your characterization of CS whole heartedly. Programming is to computer science as assembling circuit boards is to electrical engineering. However, as the cost of a college education is now routinely in the six figures, people want to see a "return on investment." By people I mean mostly the kid and their parents. So people start talking in terms of "marketable skills" as being a byproduct (or the primary product) of their educational offerings. It's a mistaken view of education period, much less computer science. They would be better off with two years at the local college and getting certified by Sun. However, we put them through a CS program and they have to learn (gasp) ancient unused languages like C or even LISP, which are not "used in the real world." (Meaning they can't wander into the average Job fair with a resume). In the perfect world you wouldn't have to teach incoming freshmen any languages, they'd just pick up "OCaml for Dummies" and perform their assignments in whatever language they choose. However, people come into a program with varying levels of expertise (and profs don't want to grade assignments in OCaml, Perl, SPIM Assembler, and Objective-C). So you have to pick something to start with. Java is a valid choice, but it is becoming the only choice. For example, I just learned my Alma-Mater is teaching graphics using JOGL - a Java wrapper around Open GL. Soon your entire world is the safe, detached, abstract virtual machine world where all you do is connect pieces written by somebody else. Except for those two horrible semesters where you took Operating Systems (and you had to use C) and you took Architectures (where you had to use Assembler). After 4 or 5 years your entire view of the world is Java/virtual machine oriented. If someone offered you a job coding in C, you could probably muddle through it, leaking memory like a sieve and the odd core dump. Moreover, when Language X replaces Java, you now write Java code in Language X. (I have to wade through Java code written by COBOLers that write COBOL code in Java.) If you push them to learn two or three languages (ideally C and LISP) they will have an appreciation for thinking about problems with a different syntax. They will look at Language X and say - it's kind of like Java here, but it's very LISPy in this way. Having been pushed to learn LISP, they might write decent code in Language X because they can think about the world is something besides Java syntax.
I see a lot of posts talking about how useless math and C are in "the real world." Well, it depends on the "real world" in which you live. Most of us will find ourselves writing code to help a company do stuff on the interwebs. That's where most of the jobs are and little of it really requires anything more advanced than the basics of programming and a little bit about databases. Thanks to frameworks like Rails, you really don't have to know much about databases, either. You also don't need a computer science degree to do this. In fact, after CS 101 just get a degree in business or get an MIS degree. Getting a CS degree because you want to work at Accenture doing in Java what many have done before you in COBOL is a perfectly fine thing to do. Getting a CS degree to do it is like getting a biology degree to sell fish at the local pet store.
;) but it is good training for just about anything else you want to do with computers. So, I think their hack at Java is a very valid criticism of relying on Java and not having students learn something about what a computer is/does at a low level that only languages like C can provide.
If your "real world" involves interfacing computers with physical devices, then you need more math and more low-level stuff. For example, even if you're working in Java, you may need to talk to devices over serial lines (which Java stinks at) or you may even need to write your own devices to read/write to device memory. Not many CS grads actually wind up doing this. A lot of people who got degrees "CS" and work in "IT" feel like this is useless knowledge, but someone had to write the software for their car's GPS, or braking system, or that reads the various sensors all throughout their car and posts warning information. Things like braking systems are sometimes written in "dead languages" like Ada because they need to be real time and safety critical. There is a real time Java, but programming in it is quite different that regular Java.
The point is, don't think about your narrow slice of the "real world" and then think that's all there is. By training nothing but Java programmers, with only a vague understanding of what actually happens inside the physical computer, we loose our ability to generate the people that will write software for braking systems, avionics suites, robotics and plant control. Also, the people who do that kind of work can often step into a web application environment and pick up whatever language they need. I've seen that transition occur often, but I've never seen people who are just Java hacks make their way into "real" programming. Maybe we don't need as many of those guys as we need ColdFusion experts
Spending several hours trying to find the problem only to learn you forgot to initialize a pointer is part of programming. I've watched people struggle for hours only to find they had a simple logic error. But that's part of learning the craft of programming. Strictly speaking programming as as much to do with computer science as soldering wires has to do with electrical engineering. However, at some point you need to implement these great ideas and it's done on a computer. That means its limited by the things a computer can and can't compute, the amount of time it takes to compute it, and the underlying software structures (operating systems and libraries). An in-depth understanding of these issues, reinforced by work in a programming language sensitive to these issues (C and Assembler) yields someone who really "groks" computers. As time passes, and with a good understanding of what a computer actually does, those mistakes become fewer and fewer. Some day you might actually be a good programmer, at which time you will be promoted into another job. :)
It's interesting you don't see much use for math in programming, but you think games are a good start. I've worked for a while on a simulator for an armored vehicle, which was essentially a big 3-D tank game. We had two aerospace engineers working on the math of how the tank was supposed to react. Granted, we were going for hyper-realism, but even in games that don't stress realism there's a good bit of math behind the physics model. The graphics required fairly sophisticated models of how the other units were supposed to respond. Even simple 2-D shooters probably will require matrix algebra (at least you'll need it to work with the underlying drawing libraries such as Open GL or DirectX). In addition, a lot of interesting games have a soft-real time component, where you need to complete your drawing code, game a/i decisions, etc. every 33 or 16 ms (depending on 30 or 60 fps).
If you want to connect the customer database to CRM system, no, you do not need a lot of math. However, you also do not need a CS degree. Go get an MIS degree (where they used to teach COBOL until recently). That's what it's there for. And, as an employer, I know the difference between a "fresh-out" and someone who has 10 years of industry experience. Some fresh-outs are stunning in their productivity and they're usually the ones who did something low-level and challenging. The guy that did a new scheduler for Linux as his senior project, and has had a good grounding in C, architectures, and Lisp, can pick up Java and whatever libraries. I'm not worried about that. If he's good, he's worth the investment. The fact that he's not as productive as someone who's been in the workforce 10 years is reflected in his salary and the degree to which he's able to operate without supervision. But that only makes that person "unhireable" if I don't hire fresh-outs as a rule of thumb.
I'm the "market" side of that equation. I hire programmers for my company. I also manage projects and sell projects to customers. I can teach any idiot Java, but I cannot teach people to think or give them what they should have learned in undergrad. Let me give you a concrete example. I had one fellow who told me something was "wrong with the system." He was having a problem where a native library was not in the search path and the Java wrapper library was causing the VM to tank from the link error. He didn't see the need for C or C++ and wanted to focus on Java because that's what he learned in school and that's what the market wanted. He didn't understand anything about why his program was dying and how to fix the problem. Slack-jawed, he brought me in and was amazed when I updated his environment and his program worked fine. He was a competent Java programmer, good with clients, but didn't actually know how his computer worked. He didn't known the first thing about dynamic linking, or linking in general, because he didn't understand what a computer is and thought Java was all you need to know. If you're going to treat a CS degree like a trade school please teach the students architectures, C and assembler. That way they know something about the actual computer and not just how to string together Java code to get what they want. That way, when something breaks, they actually can diagnose and fix the problem. I've seen a shrinking pool of people who really "know their shit." It makes some of the more challenging business ideas harder to implement not because they don't know how to program in a language, but they have no idea what actually happens inside a computer.
If you do the math and start with two equal populations. Give one population a slightly higher chance of producing offspring. Assume mortality rates are about equal. Eventually, now matter how small the advantage, the population with the advantage will dominate. In fact, the rate at which they dominate will be exponential. Our only hope, as a species, is the mortality rates on lower IQ individuals are high enough to offset the advantage in reproduction.
I don't get it, I even wrote a program on my HP calculator demonstrating the relative efficacy tinfoil over other materials.
At the age of 15 I would have gladly traded IQ points for pussy. However, due to the lack of women in the morning chess club meetings (that's right - we met an hour before school started to play chess), and the fact my HP pocket calculator wasn't as cool as a letter jacket, might have been a modest disadvantage. In addition - and I mean this in the best sense - smart kids think they can better understand and manage risk unlike the "average person" for whom all the laws were written. Hence some of the complete and utter stupidity we engaged in, that wasn't sexual in nature, could have easily lead to severe injury or death. I can certainly say that I never weighed the risk and decided sex wasn't worth it, and I'm sure I can speak for the bulk of my high school companions. Mostly because we never managed to get ourselves into the situation where we could decide, despite our best laid plans. Being a nerd (in the good at physics, plays chess, but bad social skills, and really crappy car sense) did not lead to many opportunities for sex. There were some kids who were very smart, went to parties we never heard of until after, with great social and girlfriends. I'm pretty sure they had sex. We were also big Woody Allen fans (long before he creeped out the world by dating is daughter) and as the man said: "Sex without love is an empty experience, but as empty experiences go - it's one of the best."
There's someone to help me find pr0n? Oh happy day!
appointed, whatever program comes to a screeching failure. Think Drug Czar, Iraq War Czar, etc.
It's my very humble and limited understanding that the big reason we don't see electric cars is the battery technology. Not that the basic technology isn't there, but it's my understanding that a battery specific to autmotive applications still isn't on the market. Didn't the Tesla just string a bunch of NiMH or lithium ion batteries together from laptops?
I often like the u-kernel/hybrid kernel idea of running stuff in userspace as opposed to kernel space for security, extensibility, etc. etc. However, I never would have thought licensing issues. However, what if we did start running more parts of Linux in user-space, creating a hybrid kernel, to get around licensing? Don't want to play with GPL? That's fine, just user-space it. Of course, the down-side is some XYZ Linux distro with all sorts of stuff running in user-space because of licensing restrictions. The idea of trading performance for legality (as opposed to a "real" issue like security or reliability) is somewhat unappealing.
You missed my point. I was saying they have equally low morals, not equal intellect.
The least of which is the movie they just saw or the video game they just played. He probably displayed other anti-social behavior in the past. (Not silly things like black trench coats but actually physical assault, fascination with violence, and possibly killing pets or other small animals). The VA Tech shooter was a text book example of "missed warning signs." While that's not my favorite genre of games I think that claiming the game made him do it is up there with witches' spells and demonic posession. Perhaps if he had masturbated more he would have been better adjusted. Or why not blame the chemical additives in the food he eats (which I actually would be more prone to believe). Maybe he's just a psycopath and he killed another person because he lacks emotional development. Maybe suffers from mental illness. Or maybe he just cares more about his enjoyment than other peoples' suffering. All those are more likely explanations that a video game touched something in his psyche and turned him from a "such a sweet kid," into a murderer.
And if it does, they should be served with subpeonas and investigated. However, we don't just give up trying to enforce laws because our political adversaries might have done or could do the same thing. If that's the case why have laws in the first place? Why not just say do whatever you want. That was called the "spoils system" and we got rid of it because it lead to horrible curruption in the government. (That was when you could fire almost everyone in the government and then put your own people in, some of whome actually paid for their appointments.) That didn't work out so well.
Wrong answer, Bob. They used several accounts at the RNC, at political campaigns, and other orgs. That's one reason it's so hard to track. When it first broke, two servers (both controlled by Republican party organizations) disappeared off the internet. Both of which supposedly carried Whitehouse staff e-mail.