You can obviously read, because you can write. I'm sure you saw the announcements all over the internet when it came out, God knows everybody else did.
They called it the 4.0 release and said it wasn't ready for general use. Which were we supposed to believe? The version number and the non-beta, non-RC status were real, official, and quite clear. The only way to reconcile the release number/status with all of the disclaimers was to believe that the disclaimers were overstated, or that they were just hedging and ass-covering, or that it was a difference of opinion among the developers.
It's like if someone said, "I'm a virgin and I fucked the whole football team." Obviously both statements can't be true. Which statement is more ambiguous? She must have fucked the football team in a figurative way, maybe on a real estate deal or something. So it's perfectly safe to OH GOD MY WHY IS MY POINTER COVERED WITH PLASMIDS?!?
I think the handwringing about the deaths of astronauts and soldiers in Iraq is mostly motivated not by real sensitivity but by the belief (or fear) that other people are sensitive to the issue. That's why newscasters act so mournful and why anti-war and pro-war political activists make such a big deal out of it. Except for the people who have actually lost someone, it's all crocodile tears. If anything, people are surprised and amazed at the low number of casualties.
What people really take seriously is the cost. (And Iraqi civilian casualties are another matter, too, but that's beside the point.) Is there a better way we could be spending that money? For the space program, right now it seems like unmanned missions will accomplish a lot more for the same amount of money.
Flagged revisions do no more, and no less, than allow people to tag revisions which have been reviewed to be vandalism-free. They don't prevent anyone editing. They don't censor information.
It seems like a means to censorship for me. The intent seems to be to separate the approved, "reviewed" content, which will be viewed by the general public, from the bleeding-edge content that isn't as tightly controlled by admins. Unreviewed articles, and people who use and edit them, will be delegitimized, and the public will be one step removed from the process of contribution.
To put it another way, it's like erecting a bunch of velvet ropes at the Exploratorium. They may not be much of a barrier, but simply erecting them will cause most of the public to stay behind them. Anyone on the wrong side of the ropes who isn't authorized personnel will be viewed with alarm.
It would have helped if KDE4 was able to coexist painlessly with KDE3. I added KDE4 to my Kubuntu box to try it out and spent a week trying to get it working. Then when I switched back to KDE3, I discovered that a bunch of stuff was broken, presumably because of config file collisions. I don't know if it was Kubuntu's fault or KDE's fault, but while I was going through the pain and hassle of repairing my KDE3 environment, it crossed my mind that maybe I could just switch to Gnome for a while.
But like you said, nothing could make me choose Gnome over KDE3. KDE has always been a much better fit for me than Gnome, and I can't wait to try KDE4 when it's ready.
one school ends up with a much better or worse IT system than another. That is plain wrong. It's not fair on the kids.
We have been trying for decades to distill the knowledge and skills of effective teachers and teach it to less effective teachers, but anyone who has been through the educational system recently can testify that the results are wildly inconsistent. Some teachers remain vastly better than others, and every kid owes most of his educational success to a handful of excellent teachers out of the dozens he or she is exposed to.
Until we figure out how to replicate the success achieved by good teachers and good schools, standardization amounts to exterminating effective practices and driving talented teachers into despair or other lines of work. This is true of everything that occurs in the classroom, including use of IT resources. Some teachers will make extremely effective use of resources that would be wasted in the hands of other teachers.
Each student might only have a handful of outstanding teachers in his educational career, but if you rob him of just that handful, you hurt him immeasurably. The school system is already hostile enough to talented teachers without yet another form of standardization.
I don't think it's fair to say that any language with useful applications is incompatible with performance. Emacs Lisp is way too slow for the work that I do, but it performs just fine for me when I'm use Emacs. Putting that aside, I think your idea of OO is bigger than the C++ idea of OO. The C++ idea of OO is rooted in its history: people were slogging through a lot of problems writing object-oriented systems in C, and C++ was originally developed to make that task easier. (Bjarne Stroustrup was already looking for a fast OO language before he started working on C with Classes, but the early evolution of C with Classes/C++ was focused on serving its early adopters, which were dissatisfied C programmers who wanted support for OO but couldn't afford the overhead of traditional OO languages.)
So C++ has a concept of object-orientation that is very different from the OO ideal that came from the Smalltalk tradition. In C++, object orientation is more about the way a program is conceived and the way source code is expressed and organized than about runtime support, though C++ does provide efficient runtime support for common OO constructs if you want to use it.
The definition of OO you're using is probably more widely accepted, and many people say that C++ code isn't OO unless it uses dynamic dispatch and run-time type identification, which do have runtime costs, so you're basically right IF those costs actually affect performance in your work -- but you have to admit you're in a very small minority in that case.
As for "extreme speed", C++ will almost always be at least slightly slower than C, if nothing else because of data being copied whenever there's an inheritance or overloading
Ah, but inheritance in C++ is faster than faking it in C. If you can't afford OO features as implemented in C++, then you damn well can't afford to fake them in C.
Yet that's consistently what people do after rejecting C++ as "too slow" or "too bloated," which only proves that they may *aspire* to care about such micro levels of performance, but in practice they can't tell the difference.
Same thing for code complexity. People reject C++ as "too complex" or "too kludgy" and then use macro-based homebrew OO systems for C that are more complex, more obscure, and much harder to use correctly. Gee, if only I could think of a relevant example:-)
I think that a concerted effort to get the desktop away from native code is the right move
Away from native code or away from crappy, unsafe languages? It's true that those two things are firmly linked by history and culture, but it's not completely correct to conflate them.
I use Notebook, too, and I'm glad I can keep using it, but I think it is poorly designed for the most common usage. It was meant to be used to collect snippets of web pages, but it seems that isn't a very useful or popular thing to do, so people just use it for simple text notes.
I bet they could replace it with a simple note-taking gadget for Gmail and make 90% of the Notebook users (including me) happier than they were before.
Seconded. The GTK+ implementation of SWT is sloooooooow, and it's especially apparent when using Eclipse itself. Plus my Eclipse RCP app looks crappy (especially under KDE) compared to the Windows version. Eclipse RCP is practical and usable as a cross-platform GUI toolkit, but it bothers me to produce apps that look and behave better on Windows.
There is a lot of talk that IBM has been intentionally keeping SWT/Qt for themselves and using licensing as an excuse for not releasing it, but I hope IBM is invested enough in Linux that they see the necessity of improving user perception of Eclipse-based applications under Linux.
I only "think" you did exactly what you admitted in the interview. Writing adware itself is a little bit sleazy. Sure, some percentage of your users knew they were going to get ads popping up, but honestly, if you had relied solely on the users who understood what they were getting, how long would you have been in business?
The uninstaller is just laughable. Who in their right mind would RUN AN EXECUTABLE from a company that was already STOPPING them from uninstalling software by ordinary means? If you bought a "Rolex" from a guy selling out of a briefcase in Times Square, what would you do when you realized you got duped? Would you go back to the guy and ask him to exchange it for a genuine Rolex? Maybe hand him your credit card so he could credit your account for what he owed you?
Look, this kind of bwah-ha-ha-just-try-and-uninstall-me adware is just a minor annoyance for a single person. It's like letting your dog poop on their lawn. Add in the persistence stuff, and it's like once a week you collect all your dog's poop from your own lawn and dump it on their lawn in the middle of the night. Obnoxious, but pretty minor in the grand scheme of things.
Except that you did it to tens of thousands of people (at least) and got paid for it. Imagine if you knew a guy who, as his job, drove to the airport every day, hopped in a plane packed with tens of thousands of dog turds, and carpet bombed a suburb. And everybody in that suburb is wondering why their lawn has a bunch of dog shit every day. "I just don't understand where it's coming from." Just a few thousand people who can't enjoy their lawns and maybe waste a little time and money trying to fix the problem. A minor blot on each individual person's life, but add it together and you get a pretty big thing to atone for.
Frankly, you sounded much more reasonable in the interview -- you seemed to acknowledge that what you did was wrong, which is all anyone can ask of you at this point. Now you're saying that the anti-uninstall stuff was "much farther into dicey territory?" Is that really the worst you're willing to say about it?
Oh, and thanks for not stealing anyone's financial information and defrauding them. That was real big of you. Props.
Anyone who has any real competency or natural inclination to understand computers will mess with them and figure out how to make them do things outside of the "normal" range.
"Normal?" Not "honest" or "right" or "non-dickish?" Do you really have the balls to suggest there is some kind of honest difference of opinion about the morality of what these adware guys do?
As for what you did, we all have our shameful moments in life. We all, at some point in our lives, invented and couldn't resist using the really clever way to make fun of the retarded kid or the weak kid in class that nobody liked. We did it to show off, to take out our frustrated aggression, and to temporarily feel better than somebody else. It's called being a childish asshole and it isn't any different from a big kid beating up smaller kids because he hates his life and is desperate for any triumph, no matter how hateful it makes him feel.
By its very nature, software gets better when people push the boundries and tweak it. The person who writes code that leads to improvements in the most widely used operating system is not the same as the person who kills a bunch of people.
Bigger problems get more attention. The more people exploit a flaw, the bigger a problem it is. So yeah, if you go around making problems worse, they'll get patched faster. Childish, egocentric hackers use that logic to rationalize the havoc they cause. People with an honest desire to protect users act in a very different way. The difference is instructive.
I think it's a little more subtle than simply a lack of self-esteem. It doesn't matter if you have high self-esteem if you don't know how to make others treat you with respect. It's common for geeks to have high social confidence with their family or among their geeky friends but not with other kinds of people. Being treated well by others isn't simply a matter of self-esteem, because it depends on how others perceive you and how you interact with them.
Imagine a popular, well-adjusted Nicaraguan guy who immigrates to the United States, where he is relatively poor and doesn't speak the language. While he is adjusting to his new country, learning the language and customs, he will feel worthy and confident among his fellow Nicaraguan immigrants but nervous and embarrassed in American society at large. Does he have high or low self-esteem? It doesn't matter -- he lacks confidence, justifiably, because he knows that other people perceive him as unclean, uncouth, and uneducated.
Geeks need to learn and adjust, too. Their lack of confidence doesn't come from nowhere -- it comes from painful experience. Your solution of simply getting some confidence and letting loose your personality only works if you already have the skills but suffer from an unjustified lack of confidence. I can imagine that there are geeks who were socially traumatized early on, blossomed later, and now have skills that have outgrown their confidence, but honestly, most geeks lack confidence because they keep flubbing situations that they know most people handle with ease.
The good news is that you can keep developing your social skills your whole life. At twenty-five, people can handle situations that they couldn't handle when they were fifteen, and when they're thirty-five they can handle situations they couldn't handle at twenty-five.
As for owning the room at a party, that's charisma, and it's mostly irrelevant to professional respect, though they both depend on some of the same fundamental skills.
But you're doing "what it takes," right? I don't miss those insane conversations where I tried to figure out what my boss meant by that. What's the rationale? Let's run through some possibilities:
5. Mistakes, bugs, decay of the codebase, and decreased long-term productivity are "what it takes" to succeed in computing.
Nobody believes that.
4. Workers are pieces of shit that you use up and replace. Well, of course. Mr. PHB knows he would have done it right, if he knew anything about programming, which he doesn't because he has a "real person" job. Working long hours is just punishment for not getting things done in regular business hours. An important thing to remember: He moves your cheese. Never vice-versa. He is a manager, a nimble, unflappable, change-embracing paragon of adaptability, and he is NOT going to change his release date because of A BUNCH OF FUCKING SMELLY PROGRAMMERS whose wives don't go to the gym and whose children aren't popular. It's a wonderful coincidence (or the Lord's design?) that you can force out a shoddy product and torture the subhuman scum at the same time.
But that malicious mindset, while it exists, isn't all that common.
3. We're supermen who aren't susceptible to the well-studied effects of stress and sleep deprivation on cognition. A lot of people do believe this. Software bugs are hardly the biggest thing to worry about here -- it's doctors who are the biggest violators, being prone to egotism and to taking lots of drugs that make them feel like they're awake but (sadly) probably don't make them perform like they're awake. But programmers believe it, too.
Yet those programmers don't grow on trees and don't last long anyway, and most of the people working insane hours don't enjoy it.
2. What we really want is not success per se but our own personal narrative of manhood forged in the fires of shared hardship. Especially when the boss's share of hardship is to call you every half hour and ask why you aren't done. I mean, it's hard to stay up all night sipping coffee, glorying in self-sacrifice, and pestering your workers with irrelevant, patronizing advice. That's just as hard as writing C++ at two in the morning, knowing you aren't sharp, knowing that the boss will demand to hear about some progress in (checking watch) seven more minutes, and knowing that for every sleepy typo you make you'll end up scanning a dozen lines of obscure template error messages. Can't you just feel the camaraderie? What a satisfying story this will make when we're successful. Let's just think about that and not think about how to actually become successful. Romantic stories about hardship and camaraderie are only told by winners, so clearly the key to success is to suffer together and romanticize it.
Happens all the time, but it isn't the biggest cause. The biggest reason for counterproductive and/or unsustainable working practices is....
1. Just this once. Obviously it's the wrong way to do things, but this time we have no choice. We'll figure out a better process later. We're only doing this as a one-time thing because our estimates were bad/the requirements changed/we weren't assigned enough resources... we'll make sure none of that ever happens again. I know we did it last time, but that was exigent circumstances, too. Next time our luck will change and we'll be able to do things the way we know we should. I mean, we know what to do, right? It's just circumstances that force us to adopt these special emergency measures... every time we release a product.
And saying "no" is not something that geeks enjoy, because it takes a certain ability to withstand emotional games that geeks aren't good at. A common reason that geeks (including me) are attracted to scientific and technical endeavors is that we're socially a bit obtuse and aren't good at getting other people to appreciate us. We yearn for objective and scrupulously fair evaluation. We don't want to argue about our performance; we want it to speak for ourselves. It's even better to be alone with the computer: the computer is scrupulously fair.
We try to excuse ourselves from normal social maneuvering and rely entirely on our intelligence, competence, and ultimately, our good work. Unfortunately, that doesn't work when dealing with people who are angry, fearful, and willing to trample other people. And who isn't willing to trample on the lowly IT geek? Who isn't angry and fearful in an IT crisis?
When a geek encounters aggression, unfair accusations, and outrageous demands, his response to the social stress is to withdraw (leaving the accusations unchallenged) and fall back on his technical skills (by working overtime to fix the problem.)
The geek might try to stick up for himself by using facts and logic, but his aggressor will just become more aggressive and insulting. The aggressor understands the audience (bystanders and management) better than the geek and is able to snow them with indignation and misrepresentation, leaving the geek feeling shamed, embarrassed, and sorry that he stuck up for himself. What is his refuge? Demonstrating his ability with a scrupulously fair audience: the computer. So he works overtime to fix things for the guy who just abused him.
I've never worked an IT job, but I've experienced this as a software developer for a very small company. I no longer work there, and they still pay me a retainer and frequent consulting fees because they haven't managed to entirely replace me:-) Line up a better job and QUIT! Easier said than done, I know. Good luck to everyone stuck in that position. Read a few books like this one, work on sticking up for yourself, and keep it cool.
Eclipse: Who, at the end of the day decides what happens? I'm not as sure:), but an organization formed specifically for that codebase, arms length from anyone else
I dunno, when I interacted with the Eclipse community it seemed like everyone who made decisions had an IBM email address. IBM employees decided which bugs to work on, which features to add, and which bugs reports should be classified as enhancements. The Eclipse guys will jump through all kinds of semantic hoops to avoid closing a bug report as "valid but won't fix." I suspect that reality-bending, reality-denying mentality must come from the project's corporate nature. Maybe it is evidence that IBM cares enough about the Eclipse project to apply some dumbass management metrics to it.
Since plugins are OSGi bundes, the high-level aspects of plugin development are influenced by the industry consortium that controls OSGi, but 95% of what developers care about is decided in-house at IBM. Maybe the developers aren't technically making those decisions as IBM employees, but they know who pays their salary.
these guys aren't working on the same timeframe that the rest of us are
Good point. Personally, I'm limited to the length of a human lifespan, but at the pace they're going, they must think they're immortal. More evidence of Larry's arrogance;-)
The kind of fear you're talking about is great, but I rarely get it from games. I treasure the memory of playing an "Aliens" mod for Doom. "Keep it tight, people." "Check those corners... check those corners!" You can't see anything, but you can hear the aliens breathing. Then SHRIEK they're in your face. It got to the point where my heart was going a mile a minute the whole time, and it took me a long time to calm down afterwards so I could sleep.
Unfortunately my success at finding good horror games (and horror movies, for that matter) is so low that it isn't even worth trying anymore -- one good game in ten means paying hundreds of bucks to find a good game, plus the frustration of sitting through so much garbage.
So, yeah, I do like the second kind of horror you're talking about, but I've kind of given up on it.
As for immersion, I agree completely. Few modern games are really immersive. Note to game designers: There's nothing realistic about looking at a bush and not being able to figure out whether you can step over it, or looking at a tree and not knowing whether there's an invisible corridor that will prevent you from ducking behind it. Nobody in World War II died while trying to take cover behind a pile of sandbags that were un-jump-overable for the sole reason that they marked the edge of the battlefield. Level designers need to stop putting visual verisimilitude over everything else and once again start considering the verisimilitude of the whole experience.
One aspect that all immersive games share is that you can almost always predict how objects and terrain will affect your movement. Gosh, just like in real life! That's actually more important to immersion than making the terrain look realistic. If you're examining every rock and bush as a game construct instead of perceiving it as a "real" object, then you're going to see the monster, scary noise, or eerie apparition as just another game construct. You think, "Well, here's a new game object. Looks like a werewolf. Let's figure out how to interact with it. I'll start by walking towards it and seeing what happens. I'll probably get killed, but I might as well be systematic if I want to figure out how it works." That's not an immersive experience:-)
"Hmmm, there's a toddler sitting on the floor of my living room finger-painting with blood."
Immersive game reaction: "What... the... FUCK is a mysterious toddler doing in my house? Whose blood is that!!?"
Non-immersive game experience: "I wonder if I can jump over him?"
It also doesn't work if dying means you respawn one or two minutes earlier in the game. Call of Duty single-play mode is like this. I realized this when I realized that I never paused the game when I wanted to answer the door, talk on the phone, or get a drink from the fridge. I just left my guy standing there, and if he died, so what?
When save points are so frequent, dying doesn't even impede your progress through the game unless you do it five times in a row. As a result, to make the game challenging, there have to be individual segments that are INSANELY challenging, which just makes you angry. You only get scared if dying once is a big deal. If dying twelve times in a row is what it takes to get a gamer's attention, he doesn't get scared. He gets angry.
So, you go through the entire game never being scared. You're just bored, moderately engaged, or angry depending on whether the difficulty is too low, about right, or too high.
Games that let you choose your save points, like the original Doom and Doom II, were much scarier, because you would limit your saves out of pride, and you'd also get caught up in the game and forget to save and then GAAAH I'M ABOUT TO DIE AND THIS IS REALLY SERIOUS! You panic about dying because it took half an hour of good play to get where you are, and if you die, you lose it all.
If (like me) you were normally too proud to save in the middle of a level, it meant that there was a great buildup of suspense through the level, because you had more and more to lose the further you got. In checkpoint games, it doesn't matter where in the level you are, so there's no buildup and climax, no arc to the game at all except what they can build up artificially through tacked-on story elements.
If a status report contains anything interesting, it results in the manager walking over for a chat anyway. Plus, programmers hate to think about bureaucratic stuff. Producing a status report on a regular schedule means constantly thinking about it -- when's the next one due? Have I missed one? You can't imagine how angry and resentful it makes programmers if you make bureaucracy a constant presence in their minds. Bureaucracy is hateful knowledge and a hateful intrusion into their thinking. You might as well force the marketing guys to use Linux and create marketing brochures in Emacs using LaTeX.
On the other hand, if the manager takes responsibility for periodically soliciting status from developers, then everything is good. The manager is the one who needs the information, so he won't forget to ask for it. Developers are usually happy to chat about their work for a few minutes. Best of all, face-to-face two-way conversation means that a lot of potential misunderstandings get ironed out immediately.
There's an alternative theory of human social structure, in which men naturally organize themselves into a hunting band with one leader over a group of more-or-less-equals. The leader maintains his position because the other guys like him and trust that they will be successful under his leadership. The leader usually isn't even be the roughest, toughest guy. The biggest sin in this kind of group is overvaluing yourself relative to your contribution to the group: arrogance and selfishness are punished.
That's quite different from wolf pack model where there's a heirarchy from the strongest at the top to the weakest at the bottom. The only sin in a wolf pack is weakness: weakness is punished ruthlessly.
In a wolf pack model, the manager would have to be the best coder, the strongest personality, or the toughest hombre. But in real life the manager is usually a poor (or washed up) coder who is allowed to play a "superior" role because the people under him believe the group will be successful under his leadership. Managers who believe they are better than their underlings face constant undermining and insubordination.
These are creative people, and will resist things like status reports and hard work schedules.
Well, to be more accurate, they'll work as hard as they want to, and they probably shouldn't work any harder. Don't try to make them work harder, or you'll be a douche.
And if you want status reports, ask. Don't nag them with, "Why haven't you updated me with your status?" You're the manager; take responsibility for keeping up to date.
Inevitably they will sometimes go over schedule or screw something up. That is when you have to be very careful not to make them bitter and resentful. The first time it happens, trust them completely. Just say, "Okay, keep me informed, and let me know if I can do anything to help." Then slowly escalate your involvement, but...
Don't get involved in helping them out technically. If a developer is drowning, assign another developer to help him out -- don't stick your nose in.
The best way to maintain acceptable technical quality is not for you to review their plans and designs but for them to talk things over with each other. If they don't do it naturally, assign projects to teams or pairs of developers rather than individuals. Tell each pair they can divvy up work between themselves however they like, but they're both responsible for knowing and vetting the overall design and alerting you to possible slippage.
My message might not have been entirely clear. I think Java is great as an entrenched and highly popular language. In most ways it beats the popular languages that it displaced. I usually prefer it over C++ even though it's a lot less expressive.
However, Java makes lots of compromises that kids will pay for, but not benefit from. Like you said, kids don't care about the fact that every object is (notionally) a heap object with a built-in mutex to support "synchronized," but professionals do care, and the result is that professionals wanted non-Object types, resulting in a dual type system where ints, floats, and booleans are fundamentally different from Integers, Floats, and Booleans. For beginners, that's just confusing. Integers, Floats, and Booleans are related because they're all Objects, but ints, floats, and booleans are not related at all.
The experienced programmers that Java was aimed at were already familiar with those two ways of organizing types, so it was reasonable to ask them to juggle both in Java. In fact, I bet most professionals who were hesitant about Java were actually reassured by the presence of primitives. It made Java seem less "weird" and less like Smalltalk.
Asking kids to learn two type systems that were shoehorned into the same language as a performance hack, though, is an entirely different matter. There's no reason to distract beginners with unnecessary complexity when they're still learning the basics.
Slashdot Mirror
You can obviously read, because you can write. I'm sure you saw the announcements all over the internet when it came out, God knows everybody else did.
They called it the 4.0 release and said it wasn't ready for general use. Which were we supposed to believe? The version number and the non-beta, non-RC status were real, official, and quite clear. The only way to reconcile the release number/status with all of the disclaimers was to believe that the disclaimers were overstated, or that they were just hedging and ass-covering, or that it was a difference of opinion among the developers.
It's like if someone said, "I'm a virgin and I fucked the whole football team." Obviously both statements can't be true. Which statement is more ambiguous? She must have fucked the football team in a figurative way, maybe on a real estate deal or something. So it's perfectly safe to OH GOD MY WHY IS MY POINTER COVERED WITH PLASMIDS?!?
I think the handwringing about the deaths of astronauts and soldiers in Iraq is mostly motivated not by real sensitivity but by the belief (or fear) that other people are sensitive to the issue. That's why newscasters act so mournful and why anti-war and pro-war political activists make such a big deal out of it. Except for the people who have actually lost someone, it's all crocodile tears. If anything, people are surprised and amazed at the low number of casualties.
What people really take seriously is the cost. (And Iraqi civilian casualties are another matter, too, but that's beside the point.) Is there a better way we could be spending that money? For the space program, right now it seems like unmanned missions will accomplish a lot more for the same amount of money.
Isn't Slashdot a respected site with a reputation for fact-checking? And he's an AC at +3, so he's been peer-reviewed, too!
Flagged revisions do no more, and no less, than allow people to tag revisions which have been reviewed to be vandalism-free. They don't prevent anyone editing. They don't censor information.
It seems like a means to censorship for me. The intent seems to be to separate the approved, "reviewed" content, which will be viewed by the general public, from the bleeding-edge content that isn't as tightly controlled by admins. Unreviewed articles, and people who use and edit them, will be delegitimized, and the public will be one step removed from the process of contribution.
To put it another way, it's like erecting a bunch of velvet ropes at the Exploratorium. They may not be much of a barrier, but simply erecting them will cause most of the public to stay behind them. Anyone on the wrong side of the ropes who isn't authorized personnel will be viewed with alarm.
In case this goes through, the easiest way to filter Wikipedia pages from your Google results is to add this to your query string:
-site:wikipedia.org
What a sad end it would be for such a beautiful idea. Let's hope it never happens.
It would have helped if KDE4 was able to coexist painlessly with KDE3. I added KDE4 to my Kubuntu box to try it out and spent a week trying to get it working. Then when I switched back to KDE3, I discovered that a bunch of stuff was broken, presumably because of config file collisions. I don't know if it was Kubuntu's fault or KDE's fault, but while I was going through the pain and hassle of repairing my KDE3 environment, it crossed my mind that maybe I could just switch to Gnome for a while.
But like you said, nothing could make me choose Gnome over KDE3. KDE has always been a much better fit for me than Gnome, and I can't wait to try KDE4 when it's ready.
one school ends up with a much better or worse IT system than another. That is plain wrong. It's not fair on the kids.
We have been trying for decades to distill the knowledge and skills of effective teachers and teach it to less effective teachers, but anyone who has been through the educational system recently can testify that the results are wildly inconsistent. Some teachers remain vastly better than others, and every kid owes most of his educational success to a handful of excellent teachers out of the dozens he or she is exposed to.
Until we figure out how to replicate the success achieved by good teachers and good schools, standardization amounts to exterminating effective practices and driving talented teachers into despair or other lines of work. This is true of everything that occurs in the classroom, including use of IT resources. Some teachers will make extremely effective use of resources that would be wasted in the hands of other teachers.
Each student might only have a handful of outstanding teachers in his educational career, but if you rob him of just that handful, you hurt him immeasurably. The school system is already hostile enough to talented teachers without yet another form of standardization.
I don't think it's fair to say that any language with useful applications is incompatible with performance. Emacs Lisp is way too slow for the work that I do, but it performs just fine for me when I'm use Emacs. Putting that aside, I think your idea of OO is bigger than the C++ idea of OO. The C++ idea of OO is rooted in its history: people were slogging through a lot of problems writing object-oriented systems in C, and C++ was originally developed to make that task easier. (Bjarne Stroustrup was already looking for a fast OO language before he started working on C with Classes, but the early evolution of C with Classes/C++ was focused on serving its early adopters, which were dissatisfied C programmers who wanted support for OO but couldn't afford the overhead of traditional OO languages.)
So C++ has a concept of object-orientation that is very different from the OO ideal that came from the Smalltalk tradition. In C++, object orientation is more about the way a program is conceived and the way source code is expressed and organized than about runtime support, though C++ does provide efficient runtime support for common OO constructs if you want to use it.
The definition of OO you're using is probably more widely accepted, and many people say that C++ code isn't OO unless it uses dynamic dispatch and run-time type identification, which do have runtime costs, so you're basically right IF those costs actually affect performance in your work -- but you have to admit you're in a very small minority in that case.
As for "extreme speed", C++ will almost always be at least slightly slower than C, if nothing else because of data being copied whenever there's an inheritance or overloading
Ah, but inheritance in C++ is faster than faking it in C. If you can't afford OO features as implemented in C++, then you damn well can't afford to fake them in C.
Yet that's consistently what people do after rejecting C++ as "too slow" or "too bloated," which only proves that they may *aspire* to care about such micro levels of performance, but in practice they can't tell the difference.
Same thing for code complexity. People reject C++ as "too complex" or "too kludgy" and then use macro-based homebrew OO systems for C that are more complex, more obscure, and much harder to use correctly. Gee, if only I could think of a relevant example :-)
I think that a concerted effort to get the desktop away from native code is the right move
Away from native code or away from crappy, unsafe languages? It's true that those two things are firmly linked by history and culture, but it's not completely correct to conflate them.
I use Notebook, too, and I'm glad I can keep using it, but I think it is poorly designed for the most common usage. It was meant to be used to collect snippets of web pages, but it seems that isn't a very useful or popular thing to do, so people just use it for simple text notes.
I bet they could replace it with a simple note-taking gadget for Gmail and make 90% of the Notebook users (including me) happier than they were before.
Seconded. The GTK+ implementation of SWT is sloooooooow, and it's especially apparent when using Eclipse itself. Plus my Eclipse RCP app looks crappy (especially under KDE) compared to the Windows version. Eclipse RCP is practical and usable as a cross-platform GUI toolkit, but it bothers me to produce apps that look and behave better on Windows.
There is a lot of talk that IBM has been intentionally keeping SWT/Qt for themselves and using licensing as an excuse for not releasing it, but I hope IBM is invested enough in Linux that they see the necessity of improving user perception of Eclipse-based applications under Linux.
I only "think" you did exactly what you admitted in the interview. Writing adware itself is a little bit sleazy. Sure, some percentage of your users knew they were going to get ads popping up, but honestly, if you had relied solely on the users who understood what they were getting, how long would you have been in business?
The uninstaller is just laughable. Who in their right mind would RUN AN EXECUTABLE from a company that was already STOPPING them from uninstalling software by ordinary means? If you bought a "Rolex" from a guy selling out of a briefcase in Times Square, what would you do when you realized you got duped? Would you go back to the guy and ask him to exchange it for a genuine Rolex? Maybe hand him your credit card so he could credit your account for what he owed you?
Look, this kind of bwah-ha-ha-just-try-and-uninstall-me adware is just a minor annoyance for a single person. It's like letting your dog poop on their lawn. Add in the persistence stuff, and it's like once a week you collect all your dog's poop from your own lawn and dump it on their lawn in the middle of the night. Obnoxious, but pretty minor in the grand scheme of things.
Except that you did it to tens of thousands of people (at least) and got paid for it. Imagine if you knew a guy who, as his job, drove to the airport every day, hopped in a plane packed with tens of thousands of dog turds, and carpet bombed a suburb. And everybody in that suburb is wondering why their lawn has a bunch of dog shit every day. "I just don't understand where it's coming from." Just a few thousand people who can't enjoy their lawns and maybe waste a little time and money trying to fix the problem. A minor blot on each individual person's life, but add it together and you get a pretty big thing to atone for.
Frankly, you sounded much more reasonable in the interview -- you seemed to acknowledge that what you did was wrong, which is all anyone can ask of you at this point. Now you're saying that the anti-uninstall stuff was "much farther into dicey territory?" Is that really the worst you're willing to say about it?
Oh, and thanks for not stealing anyone's financial information and defrauding them. That was real big of you. Props.
Anyone who has any real competency or natural inclination to understand computers will mess with them and figure out how to make them do things outside of the "normal" range.
"Normal?" Not "honest" or "right" or "non-dickish?" Do you really have the balls to suggest there is some kind of honest difference of opinion about the morality of what these adware guys do?
As for what you did, we all have our shameful moments in life. We all, at some point in our lives, invented and couldn't resist using the really clever way to make fun of the retarded kid or the weak kid in class that nobody liked. We did it to show off, to take out our frustrated aggression, and to temporarily feel better than somebody else. It's called being a childish asshole and it isn't any different from a big kid beating up smaller kids because he hates his life and is desperate for any triumph, no matter how hateful it makes him feel.
By its very nature, software gets better when people push the boundries and tweak it. The person who writes code that leads to improvements in the most widely used operating system is not the same as the person who kills a bunch of people.
Bigger problems get more attention. The more people exploit a flaw, the bigger a problem it is. So yeah, if you go around making problems worse, they'll get patched faster. Childish, egocentric hackers use that logic to rationalize the havoc they cause. People with an honest desire to protect users act in a very different way. The difference is instructive.
I think it's a little more subtle than simply a lack of self-esteem. It doesn't matter if you have high self-esteem if you don't know how to make others treat you with respect. It's common for geeks to have high social confidence with their family or among their geeky friends but not with other kinds of people. Being treated well by others isn't simply a matter of self-esteem, because it depends on how others perceive you and how you interact with them.
Imagine a popular, well-adjusted Nicaraguan guy who immigrates to the United States, where he is relatively poor and doesn't speak the language. While he is adjusting to his new country, learning the language and customs, he will feel worthy and confident among his fellow Nicaraguan immigrants but nervous and embarrassed in American society at large. Does he have high or low self-esteem? It doesn't matter -- he lacks confidence, justifiably, because he knows that other people perceive him as unclean, uncouth, and uneducated.
Geeks need to learn and adjust, too. Their lack of confidence doesn't come from nowhere -- it comes from painful experience. Your solution of simply getting some confidence and letting loose your personality only works if you already have the skills but suffer from an unjustified lack of confidence. I can imagine that there are geeks who were socially traumatized early on, blossomed later, and now have skills that have outgrown their confidence, but honestly, most geeks lack confidence because they keep flubbing situations that they know most people handle with ease.
The good news is that you can keep developing your social skills your whole life. At twenty-five, people can handle situations that they couldn't handle when they were fifteen, and when they're thirty-five they can handle situations they couldn't handle at twenty-five.
As for owning the room at a party, that's charisma, and it's mostly irrelevant to professional respect, though they both depend on some of the same fundamental skills.
But you're doing "what it takes," right? I don't miss those insane conversations where I tried to figure out what my boss meant by that. What's the rationale? Let's run through some possibilities:
5. Mistakes, bugs, decay of the codebase, and decreased long-term productivity are "what it takes" to succeed in computing.
Nobody believes that.
4. Workers are pieces of shit that you use up and replace. Well, of course. Mr. PHB knows he would have done it right, if he knew anything about programming, which he doesn't because he has a "real person" job. Working long hours is just punishment for not getting things done in regular business hours. An important thing to remember: He moves your cheese. Never vice-versa. He is a manager, a nimble, unflappable, change-embracing paragon of adaptability, and he is NOT going to change his release date because of A BUNCH OF FUCKING SMELLY PROGRAMMERS whose wives don't go to the gym and whose children aren't popular. It's a wonderful coincidence (or the Lord's design?) that you can force out a shoddy product and torture the subhuman scum at the same time.
But that malicious mindset, while it exists, isn't all that common.
3. We're supermen who aren't susceptible to the well-studied effects of stress and sleep deprivation on cognition. A lot of people do believe this. Software bugs are hardly the biggest thing to worry about here -- it's doctors who are the biggest violators, being prone to egotism and to taking lots of drugs that make them feel like they're awake but (sadly) probably don't make them perform like they're awake. But programmers believe it, too.
Yet those programmers don't grow on trees and don't last long anyway, and most of the people working insane hours don't enjoy it.
2. What we really want is not success per se but our own personal narrative of manhood forged in the fires of shared hardship. Especially when the boss's share of hardship is to call you every half hour and ask why you aren't done. I mean, it's hard to stay up all night sipping coffee, glorying in self-sacrifice, and pestering your workers with irrelevant, patronizing advice. That's just as hard as writing C++ at two in the morning, knowing you aren't sharp, knowing that the boss will demand to hear about some progress in (checking watch) seven more minutes, and knowing that for every sleepy typo you make you'll end up scanning a dozen lines of obscure template error messages. Can't you just feel the camaraderie? What a satisfying story this will make when we're successful. Let's just think about that and not think about how to actually become successful. Romantic stories about hardship and camaraderie are only told by winners, so clearly the key to success is to suffer together and romanticize it.
Happens all the time, but it isn't the biggest cause. The biggest reason for counterproductive and/or unsustainable working practices is....
1. Just this once. Obviously it's the wrong way to do things, but this time we have no choice. We'll figure out a better process later. We're only doing this as a one-time thing because our estimates were bad/the requirements changed/we weren't assigned enough resources... we'll make sure none of that ever happens again. I know we did it last time, but that was exigent circumstances, too. Next time our luck will change and we'll be able to do things the way we know we should. I mean, we know what to do, right? It's just circumstances that force us to adopt these special emergency measures... every time we release a product.
Saying no is key to keeping your sanity.
And saying "no" is not something that geeks enjoy, because it takes a certain ability to withstand emotional games that geeks aren't good at. A common reason that geeks (including me) are attracted to scientific and technical endeavors is that we're socially a bit obtuse and aren't good at getting other people to appreciate us. We yearn for objective and scrupulously fair evaluation. We don't want to argue about our performance; we want it to speak for ourselves. It's even better to be alone with the computer: the computer is scrupulously fair.
We try to excuse ourselves from normal social maneuvering and rely entirely on our intelligence, competence, and ultimately, our good work. Unfortunately, that doesn't work when dealing with people who are angry, fearful, and willing to trample other people. And who isn't willing to trample on the lowly IT geek? Who isn't angry and fearful in an IT crisis?
When a geek encounters aggression, unfair accusations, and outrageous demands, his response to the social stress is to withdraw (leaving the accusations unchallenged) and fall back on his technical skills (by working overtime to fix the problem.)
The geek might try to stick up for himself by using facts and logic, but his aggressor will just become more aggressive and insulting. The aggressor understands the audience (bystanders and management) better than the geek and is able to snow them with indignation and misrepresentation, leaving the geek feeling shamed, embarrassed, and sorry that he stuck up for himself. What is his refuge? Demonstrating his ability with a scrupulously fair audience: the computer. So he works overtime to fix things for the guy who just abused him.
I've never worked an IT job, but I've experienced this as a software developer for a very small company. I no longer work there, and they still pay me a retainer and frequent consulting fees because they haven't managed to entirely replace me :-) Line up a better job and QUIT! Easier said than done, I know. Good luck to everyone stuck in that position. Read a few books like this one, work on sticking up for yourself, and keep it cool.
Eclipse: Who, at the end of the day decides what happens? I'm not as sure :), but an organization formed specifically for that codebase, arms length from anyone else
I dunno, when I interacted with the Eclipse community it seemed like everyone who made decisions had an IBM email address. IBM employees decided which bugs to work on, which features to add, and which bugs reports should be classified as enhancements. The Eclipse guys will jump through all kinds of semantic hoops to avoid closing a bug report as "valid but won't fix." I suspect that reality-bending, reality-denying mentality must come from the project's corporate nature. Maybe it is evidence that IBM cares enough about the Eclipse project to apply some dumbass management metrics to it.
Since plugins are OSGi bundes, the high-level aspects of plugin development are influenced by the industry consortium that controls OSGi, but 95% of what developers care about is decided in-house at IBM. Maybe the developers aren't technically making those decisions as IBM employees, but they know who pays their salary.
these guys aren't working on the same timeframe that the rest of us are
Good point. Personally, I'm limited to the length of a human lifespan, but at the pace they're going, they must think they're immortal. More evidence of Larry's arrogance ;-)
The kind of fear you're talking about is great, but I rarely get it from games. I treasure the memory of playing an "Aliens" mod for Doom. "Keep it tight, people." "Check those corners... check those corners!" You can't see anything, but you can hear the aliens breathing. Then SHRIEK they're in your face. It got to the point where my heart was going a mile a minute the whole time, and it took me a long time to calm down afterwards so I could sleep.
Unfortunately my success at finding good horror games (and horror movies, for that matter) is so low that it isn't even worth trying anymore -- one good game in ten means paying hundreds of bucks to find a good game, plus the frustration of sitting through so much garbage.
So, yeah, I do like the second kind of horror you're talking about, but I've kind of given up on it.
As for immersion, I agree completely. Few modern games are really immersive. Note to game designers: There's nothing realistic about looking at a bush and not being able to figure out whether you can step over it, or looking at a tree and not knowing whether there's an invisible corridor that will prevent you from ducking behind it. Nobody in World War II died while trying to take cover behind a pile of sandbags that were un-jump-overable for the sole reason that they marked the edge of the battlefield. Level designers need to stop putting visual verisimilitude over everything else and once again start considering the verisimilitude of the whole experience.
One aspect that all immersive games share is that you can almost always predict how objects and terrain will affect your movement. Gosh, just like in real life! That's actually more important to immersion than making the terrain look realistic. If you're examining every rock and bush as a game construct instead of perceiving it as a "real" object, then you're going to see the monster, scary noise, or eerie apparition as just another game construct. You think, "Well, here's a new game object. Looks like a werewolf. Let's figure out how to interact with it. I'll start by walking towards it and seeing what happens. I'll probably get killed, but I might as well be systematic if I want to figure out how it works." That's not an immersive experience :-)
"Hmmm, there's a toddler sitting on the floor of my living room finger-painting with blood."
Immersive game reaction: "What... the... FUCK is a mysterious toddler doing in my house? Whose blood is that!!?"
Non-immersive game experience: "I wonder if I can jump over him?"
It also doesn't work if dying means you respawn one or two minutes earlier in the game. Call of Duty single-play mode is like this. I realized this when I realized that I never paused the game when I wanted to answer the door, talk on the phone, or get a drink from the fridge. I just left my guy standing there, and if he died, so what?
When save points are so frequent, dying doesn't even impede your progress through the game unless you do it five times in a row. As a result, to make the game challenging, there have to be individual segments that are INSANELY challenging, which just makes you angry. You only get scared if dying once is a big deal. If dying twelve times in a row is what it takes to get a gamer's attention, he doesn't get scared. He gets angry.
So, you go through the entire game never being scared. You're just bored, moderately engaged, or angry depending on whether the difficulty is too low, about right, or too high.
Games that let you choose your save points, like the original Doom and Doom II, were much scarier, because you would limit your saves out of pride, and you'd also get caught up in the game and forget to save and then GAAAH I'M ABOUT TO DIE AND THIS IS REALLY SERIOUS! You panic about dying because it took half an hour of good play to get where you are, and if you die, you lose it all.
If (like me) you were normally too proud to save in the middle of a level, it meant that there was a great buildup of suspense through the level, because you had more and more to lose the further you got. In checkpoint games, it doesn't matter where in the level you are, so there's no buildup and climax, no arc to the game at all except what they can build up artificially through tacked-on story elements.
If a status report contains anything interesting, it results in the manager walking over for a chat anyway. Plus, programmers hate to think about bureaucratic stuff. Producing a status report on a regular schedule means constantly thinking about it -- when's the next one due? Have I missed one? You can't imagine how angry and resentful it makes programmers if you make bureaucracy a constant presence in their minds. Bureaucracy is hateful knowledge and a hateful intrusion into their thinking. You might as well force the marketing guys to use Linux and create marketing brochures in Emacs using LaTeX.
On the other hand, if the manager takes responsibility for periodically soliciting status from developers, then everything is good. The manager is the one who needs the information, so he won't forget to ask for it. Developers are usually happy to chat about their work for a few minutes. Best of all, face-to-face two-way conversation means that a lot of potential misunderstandings get ironed out immediately.
There's an alternative theory of human social structure, in which men naturally organize themselves into a hunting band with one leader over a group of more-or-less-equals. The leader maintains his position because the other guys like him and trust that they will be successful under his leadership. The leader usually isn't even be the roughest, toughest guy. The biggest sin in this kind of group is overvaluing yourself relative to your contribution to the group: arrogance and selfishness are punished.
That's quite different from wolf pack model where there's a heirarchy from the strongest at the top to the weakest at the bottom. The only sin in a wolf pack is weakness: weakness is punished ruthlessly.
In a wolf pack model, the manager would have to be the best coder, the strongest personality, or the toughest hombre. But in real life the manager is usually a poor (or washed up) coder who is allowed to play a "superior" role because the people under him believe the group will be successful under his leadership. Managers who believe they are better than their underlings face constant undermining and insubordination.
These are creative people, and will resist things like status reports and hard work schedules.
Well, to be more accurate, they'll work as hard as they want to, and they probably shouldn't work any harder. Don't try to make them work harder, or you'll be a douche.
And if you want status reports, ask. Don't nag them with, "Why haven't you updated me with your status?" You're the manager; take responsibility for keeping up to date.
Inevitably they will sometimes go over schedule or screw something up. That is when you have to be very careful not to make them bitter and resentful. The first time it happens, trust them completely. Just say, "Okay, keep me informed, and let me know if I can do anything to help." Then slowly escalate your involvement, but...
Don't get involved in helping them out technically. If a developer is drowning, assign another developer to help him out -- don't stick your nose in.
The best way to maintain acceptable technical quality is not for you to review their plans and designs but for them to talk things over with each other. If they don't do it naturally, assign projects to teams or pairs of developers rather than individuals. Tell each pair they can divvy up work between themselves however they like, but they're both responsible for knowing and vetting the overall design and alerting you to possible slippage.
My message might not have been entirely clear. I think Java is great as an entrenched and highly popular language. In most ways it beats the popular languages that it displaced. I usually prefer it over C++ even though it's a lot less expressive.
However, Java makes lots of compromises that kids will pay for, but not benefit from. Like you said, kids don't care about the fact that every object is (notionally) a heap object with a built-in mutex to support "synchronized," but professionals do care, and the result is that professionals wanted non-Object types, resulting in a dual type system where ints, floats, and booleans are fundamentally different from Integers, Floats, and Booleans. For beginners, that's just confusing. Integers, Floats, and Booleans are related because they're all Objects, but ints, floats, and booleans are not related at all.
The experienced programmers that Java was aimed at were already familiar with those two ways of organizing types, so it was reasonable to ask them to juggle both in Java. In fact, I bet most professionals who were hesitant about Java were actually reassured by the presence of primitives. It made Java seem less "weird" and less like Smalltalk.
Asking kids to learn two type systems that were shoehorned into the same language as a performance hack, though, is an entirely different matter. There's no reason to distract beginners with unnecessary complexity when they're still learning the basics.