It seems from the article like the big selling point is that the coding is all done via tags (despite how much the author calls the "HTML tags", they're not HTML, since HTML describes the set of tags, not the syntax of tagging in the first place). Big woop, there are app server languages out there that have done this for years (such as Art Technology Group's Dynamo product). Is it XML compliant? HTML wasn't. Does it support namespaces? Internationalization? Can I define my own tags?
As always, the question is why would I want yet another language like this? Is the fact that you have to use a % sign more frequently in your JSP tags really THAT much of a big deal, given that you have all of Java at your disposal?
People always make an incorrect connection between true conversational AI (i.e. The Turing Test), and the typical "agent" that will do things like book airline tickets for you. The scope difference between the two is amazing. If I need a program where I can assume that I will always be giving the computer commands (aka imperative statements), then I can use this knowledge to greatly reduce my parsing skills. It really only takes a moderate grammar, a good thesaurus and an extensive knowledge base (that last part being the trick). What do I need to know to book a ticket? A concept of location and destination, a notion of limited resources (plane seats) and schedule -- a sense of time. Fine.
However, true conversational AI I think will elude us for a long, long time, because there is so much that goes into it that the computer will never be taught, and never pick up on its own. A computer has no senses equivalent to ours and therefore will have serious problems with statements like "Hot today, isn't it?" (Ok, that one could be done with a temperature probe...:)) I've often pondered the approach of teaching a computer the same way children are taught, such as by reading it kids' books. But what about the classics like "See Jack. See Jack run. Run, Jack, run." The computer can't see Jack, nor can it associate that rapidly moving your feet equals running, unless you hardwire all that stuff in.
"Book me a seat to Japan next month."
"DONE."
"Nice place, Japan. Ever been?"
"ERROR -- WHAT?"
"Have you ever been to Japan?"
"ERROR -- WHAT?"
Of course, there is also not much use for a true conversational AI in the "agent" world. You start to get into Eliza/Weizenbaum territory when you offer things like "Have the psych patient talk to a computer instead of a real person!" I suppose it's possible that could happen someday. But I don't need it to pass the Turing Test in order to book airline tickets.
...just a case of a guy who knows what he doesn't like about C/C++, and has the capability to do something about it, doing it. More power to him. Hey, if it generates traditional binary executable code so the end result is independent of the D language, and it really does have the advantages he says, then what does he have to prove to anybody? Create his own little company doing D development, crank out better product faster than anybody else, and take over the world. It could happen. If he's managed to create the language that he would prefer to work in, go for it. His only problem would be getting programmers. But it's not like D would be the first proprietary language out there.
If, on the other hand, all he wants to do is sell compilers, and therefore he needs to convince the rest of the world of the language's benefit, then fooey.
And for the record, damn, I feel old -- I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989 or so(?) and having problems. I think at one point or another I might have actually gotten email from Walter. Wow, names from the past. In a conference call yesterday I needed to come up with a secure hashing algorithm and I said "ROT13. If we need extra security we can do it twice." and absolutely no one got it.
Anyway, back on topic: No templates? Oooooo, I have a C++ friend who is gonna be pissed....
On that resolution of 320x200..? For years I've been under the impression that DOOM was one of the first games to use "Mode X" (made famous by Michael Abrash) which is what enabled the killer frame rate at a time when 320x200 plain VGA gave you really inefficient 1byte/pixel linear buffers. Mode X also gave you funky increased resolution like 320x340.
Yes, because people take it home and do things like start fires, or starve people, or get Lucy Lawless to strip:). Not exactly things you can do in the real world without difficulty.
Want something to do with 3D technology? How about a half decent map of, say, Washington D.C.'s monuments -- then let a classroom full of elementary school kids stage a scavenger hunt or something. Would be something, especially for kids who will likely never see it. Repeat for the various wonders of the world.
I once started sketching out a simulation of a solar car racing game. You had to know enough about the science behind it to put together a working car, then race it, then collect money and buy more parts, etc... Just like many racing games, but with a huge educational element.
I remember eons ago when we were first starting to see people do things like network up a bunch of Amigas and get them all playing Mechwarrior or some variant. I saw a quote in a magazine where one of the organizers of the game was asked why it was so violent. He replied "At this stage it's a very expensive game, and people will need to pay a high price for a relatively short game. Therefore we need to get their adrenaline going as soon as we can, and keep it there so they get their money's worth. The best way to do that is have someone shoot at them."
Of course, an alternate theory is that we, at heart, are a destructive bunch. The goal of Diablo wasn't to kill your fellow players, yet it happened nonetheless.
Lastly, as someone once said "The reason movies don't depict realistic situations is because people don't go to the movies to see what they could see outside their window every day." Same applies to games, I would think -- I don't want to play a game where I have to go to work and make money to feed my family.:)
I've wondered about this for years, having started with a PilotPro and listened to people whining about color, and wireless, and memory, and expandability...it's never enough. Nobody I know uses the color. Nobody I know fills their memory. I don't see too many people using the wireless (mostly because eto get it you had to sacrifice color, memory and size:)).
I think it was Stephenson in Diamond Age where he talked about having a foldable piece of electronic paper you carried with you. You'd just tell it "Today's sports" and presto, there they are. I suppose you could take this to it's natural conclusion and make it interactive -- "Schedule, please." When unfolded it could be stiff as a board so you could write on it, ala Newton recognition (NOT graffiti!) It's got a wireless connection so it's always sync'd up to your main workstation (including the ability to switch from work to home as your proximity goes from one to the other). That's what I'd like.
Looks like a self-modifying system -- person A uses phone to check traffic status, is told "all clear". Person A then smashes into person B because he wasn't paying attention to the f*cking road. Person C then checks traffic status and is told "Accident ahead." And so on.:)
First off, don't let non-coders run code reviews. I have a guy on our team who claims to run code reviews where he packs the whole team into a room for 8 hours and they go over what basically amounts to business cases, checking the code to make sure they are covered. That's not quite what I call code review, I dunno about you. Especially since the project managers and everybody are in there.
I've done "mini reviews" where I randomly grab code from the repository, and when I find something that looks interesting, I start a message thread to discuss the pros and cons of it with the team.
Code review for us meant inviting 5 people : the original code author, a moderator, and 3 reviewers (although the moderator can also be a reviewer). Everybody was told what code would be reviewed, and given printouts so they could read up. Then we took 2 hours where the moderator runs through the code and the reviewers offer comments to the author. I think we did somewhere between 1000-2000 lines of code that day. The end of the code review is a list of items that can be changed in the code, broken down by priority -- should be, might be, etc.. Don't feel like you have to put the whole team in a room! It will be impossible to schedule, and you won't get through any code at all because people will spend too much time arguing about the details.
Don't invite the boss until you've got a good process in place. Otherwise people will wait for the boss (who is probably not a fulltime coder) to lead the meeting, when in reality he probably just wants to listen. The idea is that it is a peer review, not a criticism by your superiors. Likewise, have a good mix of junior/senior programmers -- everybody's opinion counts. When I ran the above example I put names in a hat and drew them randomly.
Making it mandatory is important, in my book. You need enough reviewers to make the discussion interesting.
Also, decide in advance what the scope of your code review is! Some people will want to talk about indenting styles that they don't like, or schemes for naming variables. Is that what you want to talk about? Do you want to focus on things like uncaught exceptions and null pointers? Or something broader, like whether a particular path through the state machine has been handled properly? You have to tell them up front, otherwise you'll get a wide range of opinions on the level of detail that you should be discussing.
If people aren't used to code reviews, it's important to explain to them that the benefit comes in solving the problem before it happens! When you see a method that doesn't have a scope declaration on it, it looks completely trivial to point that out. But it's saving you time later (I really did have a case where we'd created a new package and were trying to extend some old code from a different one. The junior programmers on the case spent quite awhile (days?) figuring out why it didn't work, and finally decided to just not use a new package. Turns out that a good part of the code in the old package was using the default package-private scope and thus not extendable into a new package).
Unit test! If you can't get people to review the code, get them to review the unit tests.
Wherever possible, review new code. The biggest problem I have here is that we've got a 3 year headstart on writing code without reviews, and now I can't rally anybody into meetings to go back and review existing code. When I do, any changes that are needed don't become a high priority. Make it a point that when new code is being created, just make the code review a part of that process.
Duane
Always with Kubrick, it hits you later...
on
Review: A.I.
·
· Score: 2
I think I had the same reaction to A.I. that I had with Eyes Wide Shut in the theatre.
I had high hopes. I watched carefully for messages and symbolism. And the longer
it went, the more I started thinking "My god, when does it end?" And when it finally
did, I walked out thinking "Ug, that sucked."
But then I go home thinking. And continue thinking all through the next day. And at least at one point I think about going to see it again. Because I realize that taken as a whole (and not as beginning/middle/end), it is a complete picture, and it is very good.
The best part of the movie is the supertoy. I think every geek will want one.
Ok, so they're gonna open up about 5% of the knowledge base for free exploration, and license for the rest? I expect the majority of questions put to the free portion will be met with "I can tell ya, but it'll cost ya.":)
Seriously, I expect it will be compared to Ask Jeeves, and thus not taken seriously since the brief surge of natural language engines died out so mysteriously. Personally I think they'll have a better chance if they say "Look. All you corporations out there struggling with your "business rules" database? 90% of those rules are common sense. Cyc will take those off your hands, as well as bringing common sense to the table that you never even considered. That'll free you up to really focus on your business specific issues." The example I can think of is that for every business specific rule I have that says stuff like "If a customer in category X has transacted more than $Y worth of redemptions in a day, then alert a customer representative", I have 10 that say stuff like "If you sold all of your shares of a mutual fund you can't sell any more."
Can I toss an ebook reader in my pocket without worrying about sitting on it and breaking something?No, nor can you do that with any books other than paperbacks. Can you fit 3 of the biggest brand new hard covers into your carry on for when you're going on a long plane flight? No. But my ebook stays the same size no matter how many books I have with me.
With books I own, they get torn up... They're bent, torn in places, the spine is messed up. Can I do that with an ebook?Why do you want to? Just because you can?
What happens when the power goes out and I don't have any charge left in the tablet or whatever I'm using to view the digital text?What happens when the power goes out and you can't read your traditional book at all? My ebook is backlit so even when the subway car stalls in the tunnel and it's pitch black I'm still reading.
Can I dogear parts of a digital book and go back to them by simply picking it up and opening it?Sure. My ebook always starts on the page I left. That's actually better than dogearing, because I don't crease pages, and my pages won't un-dogear themselves accidentally.
Will I be able to read an ebook for hours like I can do with regular books and not have any form of eye strain?Good question. I read it for about an hour a day and don't seem to have too many problems. What usually causes the eyestrain people associate with ebooks is the fixed nature of a computer monitor, and not being able to move where the text is. The ebook is in your hands and you can move it around just like a regular book, changing the distance to your eyes, etc.
If I like the book enough that I loan it to friends or family, will they all have to pay additional licenses or transfer fee just to read it?Finally, a good question. No, the proper billing/licensing model has not yet been determined. That's the big issue right now. Personally I feel it's the exact same as the whole Napster thing, but I can't get people to agree with me.
The arguments against ebooks always start by saying "Let's think of features of books that ebooks don't have, then think of why those features are good, and presto, ebooks therefore must be bad." I mean, sure, crisp page turning and getting ink on your fingers is kinda neat, but is it really necessary? In the days of typewriters (before word processors), you'd see typos, crossouts and whiteout on a typical page. We don't miss that, though, do we? I agree that the billing model needs work. There's actually a more simple problem with billing right now, and that's price setting -- if the new Stephen King hardcover comes out for $22, the ebook costs $22. 6 months later when it's in paperback at $12, the ebook costs $12. That's hardly fair. I'd rather see them fix that problem first and get more people to buy the dang books, and THEN worry about how people are going to loan them to each other. Personally I have hundreds of books, but it's not like I'm a library. I might loan out a small handful a year. It's just not that big a deal to me.
An interesting thing happened to me in a meeting this morning. We are a day behind our launch date, and can't reproduce a certain bug that is happening on our stage and pilot instances, but not our development instance. As such, we have been making changes directly on stage and pilot, but not on dev. When a developer called us on that and complained that they should be in sync, a vision came to mind:
Imagine a mass of some sort, not particularly aerodynamic. Now, launch it in a given direction. Begin accelerating it. What's going to happen? The edges where it is resisting the wind are going to erode, or perhaps break off altogether, and you're going to go even faster. Repeat until you have the most aerodynamic, and hence fastest, shape for your mass.
This morning when I read that line about "Find the good stuff and discard everything else", that's what I thought of. You're probably not going to use good XP all the time, unless you are in a situation where you always have to be screaming through space in the most efficient way imaginable. I mean, you can make a space ship go faster by doing things like jettisoning fuel and cargo, but you don't always do that just because you can. Sometimes you have to decide how extreme you wanna get based on the ultimate goal of your efforts.
Get TiVo so you don't try to justify staying up until midnight or later just so you can see South Park or Battlebots or whatever. Now, go to bed 2 hours earlier.
If you're the type whose brain doesn't shut down just because his body is lying in bed, get one of those nature noise generators from Sharper Image or wherever. I find that having something other than complete silence helps distract me enough to get to sleep. Total silence and I keep writing code in my head. Remember to get one with a shutoff timer so it doesn't play all night. Also, don't go leaving the tv on, it'll inevitably keep you from getting into a really deep sleep.
When you get out of bed, if you are so inclined, turn around and make the bed. For some reason this always makes me feel more awake in the morning. It's like starting the day by actually doing something instead of shuffling into the kitchen for coffee and a newspaper. On a similar note, do the things you "have to" do first (such as shower, make lunch, make bed...) and the lounging arond stuff (reading slashdot) second.
Pay attention to your breathing. I've found it to be really neat that as I pay attention to my breathing I can actually feel myself falling asleep. Not the actual moment of losing consciousness, of course, but definitely feeling some signs that translate into "Hey, neat, I'll be asleep in about a minute."
DON'T STRESS. I know that almost all of my sleepless nights (and by that I mean waking up every ten minutes) are caused because of some important event the next morning. If you can get passed the stress of something like that, you'll sleep alot better.
When it is time to get up, get out of the bed. My worst habit was always staying in bed and telling myself I'd get up in 5 minutes.
An interesting thing I found is that late at night, with just the television for light, I will feel extremely sleepy and can't keep my eyes open. But when I turn off the tv and go into the bedroom, I'm not as sleepy. I suspect that it has something to do with the light from the tv causing my eyes to strain and thus want to be closed.
How do you determine what constitutes "work"? As Dilbert once said, "Here's my time sheet. You'll notice that it includes that half hour I wasted filling out the silly thing, but doesn't count the 15 minutes I spent designing our new product while in the shower this morning."
So is work only about writing code? Or when you go home and lie in bed for 3 hours with visions of UML diagrams dancing in your head, does that count? Surely not as billable hours (wellll, for most of us:)), but is it something that you personally consider to be part of what constitutes your own workload?
The problem with switching to dvorak is that you probably don't only use one machine, do you? I regularly have to sit at other people's machines. I'd hate for my qwerty typing to devolve into nothingness. Likewise, when people sit at my machine they're already confused (I have a Happy Hacking keyboard) which sometimes causes trouble (such as when the sysadmins need to sit at my terminal).
My solution to wrist problems has been to get up and walk away every 15 minutes or so. I don't code at 10hrs at a stretch like I used to.
Quite seriously. There are lots of debugging things you could do where first thought is "Ug, that would take me forever." True. It might. But if you start now you'll be done that much sooner.
Consistency, too.
The worst thing in the world for debugging is to sit back, go "Hmmmm, I wonder if this is it?", throw in a debug statement and see what happens. That's what you do when you don't really want to find the problem (I used to do that in the old days when I knew that firing up the system took 10 minutes each time). Be thorough and consistent. If you know that your program crashes in one of 12 methods, don't assume it happens in method foo() and only breadcrumb that one -- sit down and do them all. You can always take it out later.
(I have something of a reputation on my team that after a bug has stumped the developers for days, I am given it and I solve it in hours. Normally the first thing I do is turn debugging statements on for every component. Sure, it takes me a little while to do it, and when I'm done I get megs of output, but I almost always find the problem straightaway, too.)
if I see the resume of a CS with a PhD and only a handful of years of experience, I tend to think "He's just had time to get all full of himself and think he's god's gift." My experience bears me out on that one. I wouldn't hire you, on the expectation that you would expect to get considerably more money for those three letters, when I feel that if anything they would be a detriment to me having you on the team. (All recent PhD grads are now welcome to direct themselves to/dev/null. I'm entitled to my opinion, which comes only from my experience. I'm sure there are some wonderfully humble new PhDs out there that I just haven't met yet.)
If you come to me as a PhD with 20years of industry experience I'll see you as a wizened (wisened?) veteran who care share some real insight with myself and my team. Then again I might see any guy with 20yrs experience that way, the PhD would be extra in that case.
As for masters? I was at a college recently, doing some recruiting. When I saw bachelors kids I tended to think "Ok, entry level, we'll start him off as a junior programmer and give him the scut work." Masters students tended to make me think "Ok, here's a candidate to go right into our core team and be given some responsibility." Why the difference? In our case it's primarily about design skills. If you know how to code, I'll have you write code. If you know how to design a system, I'll have you doing that. In general I found that the masters guys had more experience to backup their claims of knowledge. The BS ones said "I have experience in Z" when they meant "I've downloaded the free Z compiler." Masters students who said that meant "I had an internship at Oracle where I implemented the following project in Z."
Just my experience. There have been entry level kids come in and wow me with their experience (although not many, there's less of you out there than you think). And there have been masters holders who don't know which end of the monitor is up. Make of it what you will.
An interesting question would be, what about somebody who gets a BS but has the experience of an MS? My answer would be "I'm not sure that's possible. If you really have equivalent experience, then why don't you have the degree to back it up? It's more likely the case that you think the cases are similar, but they're not.
In the interests of full disclosure : I have a bachelor's in CS. I spent 3 years at a small company as the only (hence, "lead") programmer, then 2 at the company that bought them where I became the team lead by nature of my expertise on that system. I had about 8-10 years experience in the field before circumstances turned me into the manager I am today.
Unless you are dealing with some form of hardware interface beyond the norm (for example, embedded systems) or massively multi-user, then odds are you are working in a deterministic system. It might be an incredibly complex one, but decide up front whether it is a deterministic system or not, and never let that thought leave your head. In a deterministic system, all bugs are reproducible, and there is always logic. You just haven't found it yet.
It's all ones and zeroes. Remind yourself of this occasionally. You know that removing a print statement should not cause a bug to disappear, but the compiler doesn't care. Think like the computer. I used to love tracking down null pointers in C because it's such a simple, raw error: "Some register has a 0 in it that should't. Find the 0, find the register, find who loaded the register with that 0. Done."
Minimalism is your friend. Start by removing everything. Then put pieces back until the bug shows up again. Then remove pieces from the other end. Trap the sumbitch in as small a hunk of code as you can.
Always remember that finding bugs is a good thing, because that means one less bug in your system. So if in your travels you discover something and go "Aha!", fix it, and then discover that it didn't solve your problem, fret not, you still fixed a bug.
My two favorite examples of past debugging:
In an embedded system (medical device) I had a loop that ran almost half a million times. Roughly every dozen runs of the system, I would get a weird math error. Extraordinarily hard to locate. Minimalizing the thing eventually showed me that once in a blue moon, a statement that said "If a < b..." was being evaluated wrong. Turns out that I had a non-threadsafe floating point library, and every now and then I would task switch after the comparison had been done, into a task that modified the compare bit, and then back -- before the result of the compare was acted on! So even though a < b, I would end up executing the else block.
Poor hardware guy was going crazy because his printf statement (C program) was causing his code to go into an infinite loop. Turned out that he was telling his format string to expect a short, but then feeding it an int (or something like that, cut me some slack it was almost 10 years ago). The extra bytes remained on the stack, and when the compiler tried to return from the procedure it saw those bytes and returned to the wrong offset! Which in this rare instance happened to be a perfectly valid piece of code, given the numbers that were being left on the stack. Instant loop. If the number being printed had been different, or if the code didn't line up in just the right way that the address was a valid statement to jump to, the bug would have been entirely different.
That was absolutely hysterical. Gilbert Godfried as the voice of the clip? And did everybody see the clip saying "All your base are belong to us"?? Credit to MS for (finally!) laughing at themselves.
And did you also notice how you can turn it back on if you miss it? Did anyone think for a second that when they said "take it out" they meant that the software would go down in size?
For good examples of similar thinking, check out Danny Hillis' 10,000 year clock project. The first thing he did was toss out all "modern" technology because none of it would last as long as he needs it to. He had to go back to the Bronze Age, I think?
Slashdot Mirror
have we learned nothing from USENET history?
ddm, feeling older than he should and surprised that no one's referenced it yet
P.S. Don't go modding me down if you don't get the reference.
As always, the question is why would I want yet another language like this? Is the fact that you have to use a % sign more frequently in your JSP tags really THAT much of a big deal, given that you have all of Java at your disposal?
However, true conversational AI I think will elude us for a long, long time, because there is so much that goes into it that the computer will never be taught, and never pick up on its own. A computer has no senses equivalent to ours and therefore will have serious problems with statements like "Hot today, isn't it?" (Ok, that one could be done with a temperature probe...:)) I've often pondered the approach of teaching a computer the same way children are taught, such as by reading it kids' books. But what about the classics like "See Jack. See Jack run. Run, Jack, run." The computer can't see Jack, nor can it associate that rapidly moving your feet equals running, unless you hardwire all that stuff in.
"Book me a seat to Japan next month."
"DONE."
"Nice place, Japan. Ever been?"
"ERROR -- WHAT?"
"Have you ever been to Japan?"
"ERROR -- WHAT?"
Of course, there is also not much use for a true conversational AI in the "agent" world. You start to get into Eliza/Weizenbaum territory when you offer things like "Have the psych patient talk to a computer instead of a real person!" I suppose it's possible that could happen someday. But I don't need it to pass the Turing Test in order to book airline tickets.
If, on the other hand, all he wants to do is sell compilers, and therefore he needs to convince the rest of the world of the language's benefit, then fooey.
And for the record, damn, I feel old -- I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989 or so(?) and having problems. I think at one point or another I might have actually gotten email from Walter. Wow, names from the past. In a conference call yesterday I needed to come up with a secure hashing algorithm and I said "ROT13. If we need extra security we can do it twice." and absolutely no one got it.
Anyway, back on topic: No templates? Oooooo, I have a C++ friend who is gonna be pissed....
duane
"In C++, you can look at your friend's privates."
On that resolution of 320x200..? For years I've been under the impression that DOOM was one of the first games to use "Mode X" (made famous by Michael Abrash) which is what enabled the killer frame rate at a time when 320x200 plain VGA gave you really inefficient 1byte/pixel linear buffers. Mode X also gave you funky increased resolution like 320x340.
Yes, because people take it home and do things like start fires, or starve people, or get Lucy Lawless to strip :). Not exactly things you can do in the real world without difficulty.
I once started sketching out a simulation of a solar car racing game. You had to know enough about the science behind it to put together a working car, then race it, then collect money and buy more parts, etc... Just like many racing games, but with a huge educational element.
Of course, an alternate theory is that we, at heart, are a destructive bunch. The goal of Diablo wasn't to kill your fellow players, yet it happened nonetheless.
Lastly, as someone once said "The reason movies don't depict realistic situations is because people don't go to the movies to see what they could see outside their window every day." Same applies to games, I would think -- I don't want to play a game where I have to go to work and make money to feed my family. :)
I think it was Stephenson in Diamond Age where he talked about having a foldable piece of electronic paper you carried with you. You'd just tell it "Today's sports" and presto, there they are. I suppose you could take this to it's natural conclusion and make it interactive -- "Schedule, please." When unfolded it could be stiff as a board so you could write on it, ala Newton recognition (NOT graffiti!) It's got a wireless connection so it's always sync'd up to your main workstation (including the ability to switch from work to home as your proximity goes from one to the other). That's what I'd like.
Looks like a self-modifying system -- person A uses phone to check traffic status, is told "all clear". Person A then smashes into person B because he wasn't paying attention to the f*cking road. Person C then checks traffic status and is told "Accident ahead." And so on. :)
I've done "mini reviews" where I randomly grab code from the repository, and when I find something that looks interesting, I start a message thread to discuss the pros and cons of it with the team.
Code review for us meant inviting 5 people : the original code author, a moderator, and 3 reviewers (although the moderator can also be a reviewer). Everybody was told what code would be reviewed, and given printouts so they could read up. Then we took 2 hours where the moderator runs through the code and the reviewers offer comments to the author. I think we did somewhere between 1000-2000 lines of code that day. The end of the code review is a list of items that can be changed in the code, broken down by priority -- should be, might be, etc.. Don't feel like you have to put the whole team in a room! It will be impossible to schedule, and you won't get through any code at all because people will spend too much time arguing about the details.
Don't invite the boss until you've got a good process in place. Otherwise people will wait for the boss (who is probably not a fulltime coder) to lead the meeting, when in reality he probably just wants to listen. The idea is that it is a peer review, not a criticism by your superiors. Likewise, have a good mix of junior/senior programmers -- everybody's opinion counts. When I ran the above example I put names in a hat and drew them randomly.
Making it mandatory is important, in my book. You need enough reviewers to make the discussion interesting.
Also, decide in advance what the scope of your code review is! Some people will want to talk about indenting styles that they don't like, or schemes for naming variables. Is that what you want to talk about? Do you want to focus on things like uncaught exceptions and null pointers? Or something broader, like whether a particular path through the state machine has been handled properly? You have to tell them up front, otherwise you'll get a wide range of opinions on the level of detail that you should be discussing.
If people aren't used to code reviews, it's important to explain to them that the benefit comes in solving the problem before it happens! When you see a method that doesn't have a scope declaration on it, it looks completely trivial to point that out. But it's saving you time later (I really did have a case where we'd created a new package and were trying to extend some old code from a different one. The junior programmers on the case spent quite awhile (days?) figuring out why it didn't work, and finally decided to just not use a new package. Turns out that a good part of the code in the old package was using the default package-private scope and thus not extendable into a new package).
Unit test! If you can't get people to review the code, get them to review the unit tests.
Wherever possible, review new code. The biggest problem I have here is that we've got a 3 year headstart on writing code without reviews, and now I can't rally anybody into meetings to go back and review existing code. When I do, any changes that are needed don't become a high priority. Make it a point that when new code is being created, just make the code review a part of that process.
Duane
But then I go home thinking. And continue thinking all through the next day. And at least at one point I think about going to see it again. Because I realize that taken as a whole (and not as beginning/middle/end), it is a complete picture, and it is very good.
The best part of the movie is the supertoy. I think every geek will want one.
Seriously, I expect it will be compared to Ask Jeeves, and thus not taken seriously since the brief surge of natural language engines died out so mysteriously. Personally I think they'll have a better chance if they say "Look. All you corporations out there struggling with your "business rules" database? 90% of those rules are common sense. Cyc will take those off your hands, as well as bringing common sense to the table that you never even considered. That'll free you up to really focus on your business specific issues." The example I can think of is that for every business specific rule I have that says stuff like "If a customer in category X has transacted more than $Y worth of redemptions in a day, then alert a customer representative", I have 10 that say stuff like "If you sold all of your shares of a mutual fund you can't sell any more."
- Can I toss an ebook reader in my pocket without worrying about sitting on it and breaking something?No, nor can you do that with any books other than paperbacks. Can you fit 3 of the biggest brand new hard covers into your carry on for when you're going on a long plane flight? No. But my ebook stays the same size no matter how many books I have with me.
- With books I own, they get torn up... They're bent, torn in places, the spine is messed up. Can I do that with an ebook?Why do you want to? Just because you can?
- What happens when the power goes out and I don't have any charge left in the tablet or whatever I'm using to view the digital text?What happens when the power goes out and you can't read your traditional book at all? My ebook is backlit so even when the subway car stalls in the tunnel and it's pitch black I'm still reading.
- Can I dogear parts of a digital book and go back to them by simply picking it up and opening it?Sure. My ebook always starts on the page I left. That's actually better than dogearing, because I don't crease pages, and my pages won't un-dogear themselves accidentally.
- Will I be able to read an ebook for hours like I can do with regular books and not have any form of eye strain?Good question. I read it for about an hour a day and don't seem to have too many problems. What usually causes the eyestrain people associate with ebooks is the fixed nature of a computer monitor, and not being able to move where the text is. The ebook is in your hands and you can move it around just like a regular book, changing the distance to your eyes, etc.
- If I like the book enough that I loan it to friends or family, will they all have to pay additional licenses or transfer fee just to read it?Finally, a good question. No, the proper billing/licensing model has not yet been determined. That's the big issue right now. Personally I feel it's the exact same as the whole Napster thing, but I can't get people to agree with me.
The arguments against ebooks always start by saying "Let's think of features of books that ebooks don't have, then think of why those features are good, and presto, ebooks therefore must be bad." I mean, sure, crisp page turning and getting ink on your fingers is kinda neat, but is it really necessary? In the days of typewriters (before word processors), you'd see typos, crossouts and whiteout on a typical page. We don't miss that, though, do we? I agree that the billing model needs work. There's actually a more simple problem with billing right now, and that's price setting -- if the new Stephen King hardcover comes out for $22, the ebook costs $22. 6 months later when it's in paperback at $12, the ebook costs $12. That's hardly fair. I'd rather see them fix that problem first and get more people to buy the dang books, and THEN worry about how people are going to loan them to each other. Personally I have hundreds of books, but it's not like I'm a library. I might loan out a small handful a year. It's just not that big a deal to me.This morning when I read that line about "Find the good stuff and discard everything else", that's what I thought of. You're probably not going to use good XP all the time, unless you are in a situation where you always have to be screaming through space in the most efficient way imaginable. I mean, you can make a space ship go faster by doing things like jettisoning fuel and cargo, but you don't always do that just because you can. Sometimes you have to decide how extreme you wanna get based on the ultimate goal of your efforts.
- Get TiVo so you don't try to justify staying up until midnight or later just so you can see South Park or Battlebots or whatever. Now, go to bed 2 hours earlier.
- If you're the type whose brain doesn't shut down just because his body is lying in bed, get one of those nature noise generators from Sharper Image or wherever. I find that having something other than complete silence helps distract me enough to get to sleep. Total silence and I keep writing code in my head. Remember to get one with a shutoff timer so it doesn't play all night. Also, don't go leaving the tv on, it'll inevitably keep you from getting into a really deep sleep.
- When you get out of bed, if you are so inclined, turn around and make the bed. For some reason this always makes me feel more awake in the morning. It's like starting the day by actually doing something instead of shuffling into the kitchen for coffee and a newspaper. On a similar note, do the things you "have to" do first (such as shower, make lunch, make bed...) and the lounging arond stuff (reading slashdot) second.
- Pay attention to your breathing. I've found it to be really neat that as I pay attention to my breathing I can actually feel myself falling asleep. Not the actual moment of losing consciousness, of course, but definitely feeling some signs that translate into "Hey, neat, I'll be asleep in about a minute."
- DON'T STRESS. I know that almost all of my sleepless nights (and by that I mean waking up every ten minutes) are caused because of some important event the next morning. If you can get passed the stress of something like that, you'll sleep alot better.
- When it is time to get up, get out of the bed. My worst habit was always staying in bed and telling myself I'd get up in 5 minutes.
- An interesting thing I found is that late at night, with just the television for light, I will feel extremely sleepy and can't keep my eyes open. But when I turn off the tv and go into the bedroom, I'm not as sleepy. I suspect that it has something to do with the light from the tv causing my eyes to strain and thus want to be closed.
That's my list.So is work only about writing code? Or when you go home and lie in bed for 3 hours with visions of UML diagrams dancing in your head, does that count? Surely not as billable hours (wellll, for most of us :)), but is it something that you personally consider to be part of what constitutes your own workload?
My solution to wrist problems has been to get up and walk away every 15 minutes or so. I don't code at 10hrs at a stretch like I used to.
Rodney Brooks' crew at www.irobot.com have got a remote "avatar" robot equipped with web cam for exactly this purpose. Highly neat!
Same guy that made that decision went on to declare that indents should be *3*. Not 2 or 4.
Quite seriously. There are lots of debugging things you could do where first thought is "Ug, that would take me forever." True. It might. But if you start now you'll be done that much sooner.
Consistency, too.
The worst thing in the world for debugging is to sit back, go "Hmmmm, I wonder if this is it?", throw in a debug statement and see what happens. That's what you do when you don't really want to find the problem (I used to do that in the old days when I knew that firing up the system took 10 minutes each time). Be thorough and consistent. If you know that your program crashes in one of 12 methods, don't assume it happens in method foo() and only breadcrumb that one -- sit down and do them all. You can always take it out later.
(I have something of a reputation on my team that after a bug has stumped the developers for days, I am given it and I solve it in hours. Normally the first thing I do is turn debugging statements on for every component. Sure, it takes me a little while to do it, and when I'm done I get megs of output, but I almost always find the problem straightaway, too.)
If you come to me as a PhD with 20years of industry experience I'll see you as a wizened (wisened?) veteran who care share some real insight with myself and my team. Then again I might see any guy with 20yrs experience that way, the PhD would be extra in that case.
As for masters? I was at a college recently, doing some recruiting. When I saw bachelors kids I tended to think "Ok, entry level, we'll start him off as a junior programmer and give him the scut work." Masters students tended to make me think "Ok, here's a candidate to go right into our core team and be given some responsibility." Why the difference? In our case it's primarily about design skills. If you know how to code, I'll have you write code. If you know how to design a system, I'll have you doing that. In general I found that the masters guys had more experience to backup their claims of knowledge. The BS ones said "I have experience in Z" when they meant "I've downloaded the free Z compiler." Masters students who said that meant "I had an internship at Oracle where I implemented the following project in Z."
Just my experience. There have been entry level kids come in and wow me with their experience (although not many, there's less of you out there than you think). And there have been masters holders who don't know which end of the monitor is up. Make of it what you will.
An interesting question would be, what about somebody who gets a BS but has the experience of an MS? My answer would be "I'm not sure that's possible. If you really have equivalent experience, then why don't you have the degree to back it up? It's more likely the case that you think the cases are similar, but they're not.
In the interests of full disclosure : I have a bachelor's in CS. I spent 3 years at a small company as the only (hence, "lead") programmer, then 2 at the company that bought them where I became the team lead by nature of my expertise on that system. I had about 8-10 years experience in the field before circumstances turned me into the manager I am today.
My two favorite examples of past debugging:
And did you also notice how you can turn it back on if you miss it? Did anyone think for a second that when they said "take it out" they meant that the software would go down in size?
For good examples of similar thinking, check out Danny Hillis' 10,000 year clock project. The first thing he did was toss out all "modern" technology because none of it would last as long as he needs it to. He had to go back to the Bronze Age, I think?