So I tasked some of my gnomes and elves to do a little more work on the problem of the editor gutter. I gave them all the feedback received from this post just to see what they would come up with. So here's the result:
And optionally:
Hmm.... Actually I kinda like it. Who says you can't teach old dogs new tricks! Of course this is still subject to change if my gnomes or elves start getting cocky..
So, yesterday, Steve Trefethen, stopped by my office and had asked whether or not I'd gotten any internal feedback on what to do about the left gutter in the editor. You see, we have an internal blog and an internal wiki that we use to communicate newsworthy items and to float around technical specs among the various teams. Because we have teams spread across the globe, development is happening on Delphi almost 24-7, so it is usually much easier to dissiminate information via the internal blog than to spam everyone's email box. The Delphi Welcome Page for developer's builds automatically points to the RSS feed for the internal blog so most folks don't miss the blog information. Oh, things like meeting minutes, new feature status, build breakages, etc... are all published there, but I digress. You're here for a discussion on the left gutter in the editor.
As Steve and I were talking about the dearth of feedback we'd gotten internally, we spent a few moments and brainstormed (OK. I did get one bit of feedback, thanks Jesper!). I think we hit on an epiphany. We determined that the main cause of “fear and loathing” regarding the Delphi 2005 gutter was that it was actually packed with too much information. It was cluttered which lead to the general feeling of being disorganized. Myself being somewhat ADD, that clutter is easily overlooked, or at least minimalized. I knew something just didn't “click” with it, but couldn't quite put my finger on it. So as we brainstormed, Steve hit upon an what could be characterized as a “duh!”. What if we only painted every 10th line number and then placed little dots for the lines in between? The same information is conveyed, but every 10th was too far apart to quickly see what lines were in between. I didn't realize how much I relied on the line numbers in the gutter until we started changing things. So we tried to paint only every 5th line lumber... nope, still too cluttered. At first we painted '-' characters on the lines between the numbers... ick.. that made it look like a ruler. So we went with the dots. That was better, but every 5th line was still too many line numbers cluttering things up. So, again, Steve, suggested we paint a '-' on the 5th line between the numbers and dots on all the rest. Wow! That is actually starting to look good. Here's what we've go so far:
That's far less cluttered, don't you think? The “-” character clearly deliniates the 5th line. With just a little more effort, we think it will quickly become second nature to be able to glance at that and see what line number a particular line is.
Now that the line numbers are not so prominent and “out there,” let's tackle the “overlapping icons” issue... The problem we're trying to solve here is that there is a lot of information we want to convey visually from the left gutter. Things like breakpoints, bookmarks, breakpointable lines, current execution point, etc.. All of this information takes precious real estate from the really important information, the source code. So we compromised and placed the icons over the line numbers and also tried to change the intensity of the line number to be less prominent. The problem with playing with luminance and saturation is that many times those value tend to wrap around and actually create a much brigher color. The reason for “dimming” the line number was an attempt at reducing the clutter I talked about above. So we disabled that “feature.” Now that the gutter is far less cluttered, lets look at what it would look like now with the infamous “blue balls.”
Hm.. That's getting there. The breakpointable line icon is clearly visible and easily overshadows the line numbers making them very visible. They also don't steal any more real estate. So what about bookmarks and the current execution point?
Notice that the breakpoint glyph doesn't overlap the bookmark glyph. However the excution point arrow does overlap. This is on purpose. Those are related items. The breakpoint glyph and the execution point arrow glyph are all about debugging. Notice that the blue ball is also covered up. Why continue showing that when it is clear that the breakpoint has been set there? You can still see the breakpoint under the arrow, so there is no need to take up more real estate. Notice that the line number has taken a complete back seat to all of this. They're not as an important piece of information as the bookmark, breakpoint and execution point glyphs are. Also since there are no line numbers painted on the adjacent lines, there is far less surrounding clutter to detract from where the real information lies.
Finally, lets look at what happens when the gutter is too narrow to display those two glyphs side-by-side without also spilling into the code folding information. At this point, the glyphs will begin to overlap, but only to a certain point so that all the glyphs will be at least partially visible. But we've rearranged the priority of them so that the bookmark is always on the bottom, then the breakpoint/breakpointable glyphs, finally the execution point is alway on the top.
As most source files tend to be more than the mere 30 lines we see here, the gutter will generally be wider and thus there'll be far less overlap between the glyphs. Hopefully we'll see some derivative of the above changes in the next Delphi release. Since this is only a start, I'm sure we'll be refining this even further, and since I have no delusions of pleasing everyone, I think we're on the right track.
I thought I'd take a moment to dispell any myth regarding whether or not we take the current (or past) Delphi survey seriously and they really don't end up in some black hole. In between Mods E and F here at the Scotts Valley, CA campus, there's an entire wall that is one huge dry erase board (whiteboard). Just yesterday, the latest preliminary survey results were printed and taped up on that board for all to see (internal to Borland that is). It is quite interesting to read over all the results. Now one item of note is that while we do take these surveys very seriously, they are just a part of the overall picture. We also take into account a lot of information from our field sales teams, the Product Line Sales Managers for the various regions, and customer site visits, etc... The following photos (taken with the now infamous phone cam...;-) are just the results from the Delphi 2005 users only, so there's a lot more data to mine. This was also only after the first day the survey was posted. No, I'm not going to provide higher resolution photos because we generally don't publish the results of these surveys. Mainly because of what I said above; they are only a part of the overall picture (no pun intended ;-). As we mix in data from all the other sources, things could vary substantially from the raw survey results. Besides, raw or cooked, internal marketing data is a critical business datapoint and should be held very close... why hand free marketing research to your competitors?
If you look closely at the picture on the left, you can see the written text “1st Day results...” Also, nevermind the tic-tac-toe game to the left ;-)...
Mark Russinovich, of SysInternals fame, posted this blog entry about the new Windows XP 64bit Edition. Why do I mention it? Well, for one thing, Mark mentions using Delphi 2005. Unfortunately, his reference to Delphi isn't too flattering.
“The Borland Delphi 2005 debugger has a more serious issue: when you launch a process under the debugger it believes that the process exits immediately when the process actually starts properly. A workaround is to attach the debugger to the process after its launched.”
This blog post was brought to our attention, so I posted a comment asking for some clarification and some steps to reproduce this problem. This was in addition to the internal flurry of emails and immediate investigation into the problem on one of the 64bit systems in the QA lab. However, based on the above description, we tried to reproduce the problem and found that we could not. Obviously, we're not trying to debug a 64bit application (Delphi isn't quite there, yet ;-). Mark responded quickly with more information regarding what he was actually trying to do. It turns out that he was trying to debug an MMC (Microsoft Management Console) snap-in written in Delphi. After another internal flurry of emails and work in the QA lab by a member of the QA team, we looked and found out that mmc.exe is in fact a 64bit application. OK... now the SysInternals guys are some smart cookies, and I could not for an instant think that Mark would make such a silly and obvious error. It turns out that there are two versions of mmc.exe, a 64bit version and a 32bit version.
So after I post a rather sheepish response (in which I inquire as to the “bitness” of mmc.exe... I was a little embarrased to even mention it) to Mark's explination of what he was doing, Mark responds with what is actually going on. Yes, of course, he's launching the 32bit version of mmc.exe from the Delphi 2005 IDE. But what happens is that the 32bit MMC then immediately turns around and launches the 64bit MMC and then exits. Ok this makes sense. But, he mentions that he's able to attach to the process after it is launched. This is easily explained as well as Mark states in his response comment:
“I've investigated further and its a Windows problem, not Delphi's: when you launch the 32-bit mmc.exe it launches the 64-bit mmc.exe and exits. If you are loading a 32-bit snapin the 64-bit mmc.exe launches the 32-bit mmc.exe again and exits.”
So the mystery is solved. And Delphi 2005 runs and debugs 32bit applications on the new Windows XP 64bit Edition. So thanks, Mark, for bringing this to our attention and being so proactive in figuring out this odd behaviour. And finally, it is really awesome to know that the folks at SysInternals use Delphi!
Follow up: It looks like Mark figured out the issue and how to launch the 32bit MMC. He explained in his comment:
“ Ah, I figured it out: you can launch the 32-bit mmc.exe directly if you specify its path (windowssyswow64mmc.exe) and include the /64 command-line option.”
When we look to hire a new junior/entry level engineer, there are several key qualities I look for in the candidate. The first and foremost quality I want to see, obviously, is talent. Do they really know the stuff they said that they did on their resume(CV)? Another quality that is one of the hardest to see in a short interview, although I have seen it come out in the really exceptional ones, is enthusiasm and excitement. Don't be afraid of being wrong. How else do you learn? A corollary to this one is teachability. How well do you respect both your peers and the senior developers?
Clearly, the most successful and talented engineers tend to meet those above qualities. I'd rather hire an engineer that was less experienced but was a fireball of energy and enthusiasm. Also they are ones that would be willing to charge ahead and take risks, even if it is the totally wrong direction. They are kinda like a pinball. The times when the game is the most exciting is when the ball is bouncing around in all different directions. And you can think of the senior engineers as the paddles. They are constantly redirecting and sending the ball back into play, which is how you score the most points.
Yes, that metaphor will break down at some point because eventually that pinball will need to become a paddle. My point is that an engineer may have memorized Donald Knuth's books but is so afraid of making a mistake or “not measuring up” in the eyes of their peers or the senior staff, that they are paralysed by this fear. Yes, they will complete a task... eventually... and it will be correct and relatively bug free. The problem is that you don't know when it will be complete. And sometimes, it may not get done at all. Someone who is willing to make mistakes and can take direction and critiques, will usually outperform someone who tends to be paralyzed by some fear.
Of course, this person can become a liability, but that is usually when they fail the final item in my initial list; teachability. So taken altogether, a junior engineer with the above qualities has the most chances for success. Coming onto the team with agendas, and preconceived ideas on how things should work, and refusing to accept that the more experienced team members may have already thought about all the various angles, is a sure recipe for disappointment and discouragement. In my direct experience of being on the Delphi team since its inception, I've seen both types come and go from the team. I'd have to say that for all the junior engineers that have come and gone on the Delphi team the ones that met the above conditions have contributed to the team far above some of the more reticent members have done. I've enjoyed watching some of these junior team members move up into the senior ranks. They are given larger, more critical tasks. They also don't require as much guidance and direction... but what is an interesting trait they tend to develop is they now actively seek out feedback and criticism from their peers and the top-staff members. They usually have spent a good amount of time thinking about the problem critically, and mulled over several solution scenarios. By the time they begin seeking feedback, all the “stupid” questions are out of the way and the real “meat” of the problem can be discussed.
Now before you start reading between the lines and think that I'm trolling around for new hires, this is just a few thoughts I've had recently and thought I'd get them out before they evaporated. Which probably explains why some of my metaphors are a little odd at times... then again when you consider the source... ;-)
