You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.
Tuesday, Dec 10, 2002, 12:00 AM in The Spout
Of Eggs and Omelets
My life has been one long series of experiments. I tried to be a know-it-all jerk in high school and found that this tended to cut into my social life (drastically), so I stopped (or am still stopping, depending on how well you know me : ). I tried to be a "ground floor" employee for a small company, but that stopped being fun when the repetition and bureaucracy hit and it became clear that any profits that might someday happen would be kept at the owner level. I tried being an employee for a large company, but when my projects started getting axed based on political winds that, as a low-level grunt, I had no control over, I went looking elsewhere. Then I found DevelopMentor. The combination of working on lots of different things with lots of smart people was something that I loved more than anything I've since found.
But even that didn't stop my experimentation. After teaching and consulting for a while, I decided that instead of just talking about building software, that I would take one of my ideas and build a software development team. There I worked to build the best software development team that I've ever had the pleasure to work with and a learned a *ton* along the way. However, the fact that the product itself was a commercial failure didn't make for lasting employment.
So, late last year, I started another whole series of experiments, this time aimed at making myself solvent as an independent in a down economy. I've been doing all kinds of crazy things to see if I could use them to help build my brand, my business and my customer base. Some of them have been critically acclaimed and a few have even been commercially viable, at least to the point that I can continue to pay my mortgage (many of my friends weren't so lucky). I have been successful in that I've gotten to do a lot of cool things and work with a lot of smart people.
However, what I've found is that to remain independent, I have to spend a lot more time doing promotion and marketing, which goes against every fiber in my being. The problem is, although I've experimented a bunch, especially as related to this year's DevCons, I don't have any natural marketing aptitude and I don't know where to turn for help. So, I fall back on my old standby -- experimentation.
Over several years, I've experimented with several sales/marketing/PR folks and organizations and so far, haven't found what I'm looking for as far as "mentors" go (to be fair, my standard for comparison includes Don Box, Tim Ewald and John Robbins, so I'm not surprised I haven't found someone to meet that bar). Even if I did meet that person, or may have already met him/her, I don't know that I'd recognize it. I just have no standard for comparison. With software, it either works or it doesn't. With marketing, did it succeed or fail because of the quality of the product or the quality of the marketing? The whole thing is too damn squishy and it drives me nuts!
My most recent set of experiments is to let a friend of mine, a long-time marketing guy that I've known for years, run rough-shod over my newsletter subscribers, asking them all kinds of questions and for their help in various ways, offering my money and my time as incentives. Will it work? I have no idea. Is it risky? You bet. I've lost a dozen or more subscribers and who knows what some people think of me now that I've let marketing ideas into what I do (and I'd like to apologize again to the folks that I drove away or offended in this most recent campaign). Is it worth the risk? Yes it is, but not for the promised return (I still think my marketing friend was on happy pills the day he quoted his marketing targets). What makes it worth the risk is that I've identified a weakness in myself and I'm willing to perform the experiment and make the mistakes to see if I can come out better on the other side. Even if I fail, I've learned something. Eventually, I'll get that omelet made, no matter how many eggs need breaking.
And to those of you who suffer with me through my experiments, thank you very much. You have no idea how much you mean to me.
Wednesday, Nov 27, 2002, 12:00 AM in The Spout
My Coding Standards
Wednesday, November 27, 2002
Sometimes it's like I'm a war veteran in my head. I'll be going along, minding my own business, when *bang*! out of nowhere, a flashback from my days as the director of a software organization hits me right between the eyes. When it happened today, I thought it would be therapeutic to talk about it instead of trying to bury it when these "episodes" intruded on my normal life.
The nice thing about setting up your own software organization is that you get to set your own rules, and this time "do it right." I had always planned on getting my engineers together one day and coming up with a common coding standards document, just like every software organization had, but in the interim, we started with this one:
- All code will use spaces instead of tabs.
- All new code in an existing file will match the existing style.
Rule #1 nicely handles the case where different editors expand tabs to different spaces, causing code that was easy to read when it was written to go all crazy. Rule #2 says not to waste time reformatting existing code into your own style, but to mimic the coding style that was used by the original author. Rule #2 had the unexpected side effect of helping developers get into each others' heads, which helped transfer knowledge between us. I personally learned a bunch of cool tricks by fixing bugs in files in the style of the original author.
After a few attempts at adding other, more traditional rules to this short list, like where the braces go and how to name variables, we couldn't find anything that was worth ruining the simplicity of our two-rule coding standards with, so that's what I've used ever since. One other benefit of this simple set of coding standards was that it left us all kinds of time to debate the merits of various text editors, which is an argument that won't be solved until just after the Christianity vs. Judaism debate is ended...
Monday, Nov 11, 2002, 12:00 AM in The Spout
Hierarchy Doesn't Scale
Sun, November 11, 2002
I was just chatting with a friend of mine and he said that he really wanted to write a namespace extension so that he could expose a hierarchy of data in the shell. Back when namespace extensions were introduced with Win95, I thought that everything could be integrated into the shell, making the shell the last application. Sometime in the last seven years, I've come to hate that idea. As a hardcore computer geek, I've embraced the hierarchy organizational styles in three major applications:
- Email folders (I keep things filed in a multi-level hierarchy and use my Inbox as a to do list)
- The file system (I keep things filed in a multi-level hierarchy and use my Desktop as a to do list)
- Free-form outline program (I keep things filed in a multi-level hierarchy and use a file called todo.txt as a to do list)
As anal as I am about arranging and categorizing things into their various hierarchies (and as many places as I've spread my to do list to, apparently), the hierarchy only helps me about 50% of the time. I spend just as much time searching for things as I do going right to where it "should" be.
The hierarchy used to be lots more helpful, but as the data I keep around grows over the years, it becomes less and less possible to remember where something really "belongs" and to find it there. In fact, I've come to believe that a hierarchy is a terrible way to keep data organized at all. A hierarchy is really just a way to associate key words (called "folder" names) with hunks of data (called "files") and then only showing them in a very limited way. Searching is a possibility, but it either takes a long time (because file indexing is turned off) or it misses files (because file indexing is turned on -- what's with that, anyway?). Searching creates an ad hoc logical folder, but there's no way in the shell to create a permanent logical folder with custom content.
The basic hierarchy structure is easy to understand, but things become much more powerful if I can keep one hunk of data in multiple locations. Some versions of the Windows file system support this , but the shell doesn't (although it can be simulated with shortcuts). Also, the same kind of "pivot table" capability that Excel provides, mixed with a much faster, more flexibly searching capability of a database, is much closer to what I'm after. Hopefully Longhorn will provide something like this.
Also, being able to search all three of my hierarchical data sources at the same time would be pretty damn useful, but one thing at a time...
Saturday, Oct 26, 2002, 12:00 AM in The Spout
A Giant Sucking Sound
Sat, October 26, 2002
While I'm in favor of NAFTA, and free trade over all, it's certainly not helping US workers. Instead, it favors US corporations as they made use of cheaper labor. Of course, it's the corporations that also seem to make out on these deals, doesn't it? Similarly, the other "giant sucking sound" I've heard lately are my friends moving to Redmond to work for Microsoft. MS is using the recession to cherry pick the best and the brightest in the industry. I can think of almost ten people I know personally that have gone to Microsoft in the last six months. And these aren't folks that were laid off and had to go, either (even though everyone but Microsoft is laying off). These are good folks that had good jobs, either as employees or as independents. One even owned half of what was my favorite company in the whole world! So why are they doing it? Why are they giving up their old lives to work at MS, often moving to Redmond in the process?
I think they're going for a variety of reasons. One is definitely the safe harbor aspect. As an independent in the current economy, I have to work my butt off to attract funding using self-promotion techniques that I didn't have to use during the Internet boom. I'm successful and I love the work and the life, but it's still a lot of work that I know others are not willing to do. Another reason related to the "really hard work" problem is that Microsoft, for the caliber of my friends, is allowed to offer what used to be a laughable salary, but is now looking pretty good against what's generally available. If you can get 75% of what you used to make as an independent, great benefits and stock options that may do something someday, that's pretty compelling. And the stock price is pretty attractive right now. It's my belief that, as a government-sponsored monopoly, Microsoft is fundamentally sound, and the stock price is artificially low. If you were going to go to Microsoft any time in the last five years, now is the time. The stock is only going to go up.
But the big reason that makes people go, and this is the one that might tip me some day, is the raw, visceral experience. For better or worse, Microsoft is the mother ship from which everything we know now has sprung. And they're still setting the tone. I know I dream of moving to Redmond to work on the next technology that's going to kick ass in 2-3 years, like Don and Martin and Yasser did. I'd also love to live where I am now, commuting to Redmond a week/month to work with developer education, focusing on research and writing, like Tim did. Sometimes I want to just chuck the extra effort it takes to stay "outside," throw up my hands and let the assimilation process begin.
So, why haven't I thrown in the towel? I'm waiting. I'm waiting for the perfect balance of quality of life where I get to spend every day doing exactly what I want, working with a team on a long-term project that I really believe in, but without the politics or the management responsibilities that I deplore and without giving up my family or dropping significantly in income. Right now I've got that all nailed except for the team and the long-term project, so I've got it damn good, but I'm still looking. Who knows? Maybe I'll get caught in the mass geek migration to Redmond some day, but not yet...
Thursday, Oct 17, 2002, 12:00 AM in The Spout
Type Safety in a Loosely Coupled World
Tim Ewald gave a very rousing keynote address at the WinDev conference in Boston yesterday. During his talk, he did something I've never really heard anyone do convincingly before -- he defended the typeless recordset/rowset/dataset style of programming. His justification was that you don't always need type-safe object models and, when getting a subset of data, they're often more trouble than they're worth (do you really want a set of types for every query in your app?).
My standard objection to the "just the data, ma'am" style of programming is that I don't get compile-time type checking. Of course, I can write the code to check all the data I get at runtime, but I don't like to do that. Instead, I like things like the type safe dataset generator built into VS.NET. However, that damn tool fooled me. I looked at those type safe wrappers and considered that compile-time type checking. Of course, it's not. Instead, it's a hunk of code that pretends to offer compile-time type checking, but only really offers run-time type checking, because the data still needs to be coerced at *runtime*.
I have always turned up my nose at run-time type checking until I realized (and this is the insight I got from Tim's talk) that *all* marshaling-based type checking is done at run-time. Even the type-checking done in COM between apartments needs to coerce the data to and from a serialized format, which means that it's possible for the data to be mismatched between two endpoints, causing a type exception at runtime. Since I'm not willing to give up the loose coupling involved with components talking to each other across apartment/thread/process/machine/context/appdomain/whatever boundaries, I need to accept the fact that type checking needs to happen at run-time as well as at compile-time. As far as type checking is concerned, unmarshaling an RPC call stack is really no different than coercing/converting dataset columns or applying an XSD to an XML document.
Once I've accepted run-time type checking, I can take Don's advice to "free your mind" (he's moved on to other parts of The Matrix not involving medication) and embrace things like structural typing, which is much more flexible than the nominal typing that OO languages rely on. I told you that "nobody makes it the first time," Don, but I think I've finally made it across. : )
Wednesday, Oct 2, 2002, 12:00 AM in The Spout
The Fallout Begins
Two months ago, I noted a fall in morale in the IT industry amongst my friends and colleagues. I wondered whether the best people in the industry who'd been fighting for a sane development process, but living without it because people were handing out cars as signing bonuses, would rather not work in another industry when the cars were no longer available and the fight for what was right didn't seem to make as much difference any more. Yesterday, one of the people that I'd put into the "right up there" category, Justin Rudd, announced his intention to pack it in and go back to school to be a doctor.
This kind of thing shakes my own faith. Should I continue to bust my hump on the latest and greatest technologies or ditch it all and start that novel I've got in the back of my head? I still really love doing the former, but it seems that everyone has to work a lot harder for a lot less these days. Maybe I just need to readjust my thinking, but damn, being smack dab in the middle of an economic boom really does a number on you! I feel like the guy who found a silver mine in the middle of the gold rush. I don't have any trouble feeding my family and it's not fool's gold, but I still pine for those deep, yellow nuggets...
Friday, Sep 13, 2002, 12:00 AM in The Spout
Never Send An Email In Anger
I learned how to write good emails at the foot of the master -- Don Box. Whenever we'd decide we wanted something, he'd grab his computer and say, "Let's write the email" and it would be done.
One of the most important things that I've ever learned about high-tech communications is to never, ever write an email in anger. Or, to be more precise, never *send* an email in anger. I encourage you to actually write it. It always makes me feel better. But don't address it, because you want that email to first end up in your Drafts folder and go from there to your Deleted folder. If you address it and mean to press Ctrl+S to Save but manage to press Alt+S to Send by mistake, you might well be looking for work in another industry. If you don't address it, however, Outlook complains and you can breathe a sigh of relief. Frankly, I wish there was an add-in that protected me even if I ignore my own advice:
Of course, this spouting could only occurred after I've violated my own advise, as I've often done over the years, always to my determent. When you're angry, all you care about is making sure that your anger comes through. If I give myself an hour or two to think on it, when I come back to read that angry email, it always makes me flinch. Writing an email once I'm done being angry always yields the nicest, most thoughtful emails that I can write. Those I find to be *much* more effective.
Wednesday, Sep 4, 2002, 12:00 AM in The Spout
Attracting and Keeping Good Folks
A friend of mine requested an essay on my thoughts of attracting and keeping good employees. I've had the privilege of working with some of the best and the brightest over the years and seeing how companies hire and keep them. My take is that companies that attract the best do so with a reputation of excellence. As one example, Google has kick-ass technology, so I'm sure most of you want to work there (I know I do : ). On the other hand, there are plenty of companies that have a reputation for buggy, unusable software that turn us off, all without ever hearing about the salary and benefits package.
If you can attract good folks, you'll also attract lots of mediocre folks and some not-so-good folks. There are all kinds of ways to screen these folks out. My favorite is to ask them "why?" questions. If they can tell me the name of the operator that appears as a colon between the last paren of a C++ constructor signature declaration and the opening curly place, that's great. But if they can tell me why C++ has it, and why Java and C# doesn't, they're hired. Of course, I let the interview candidate pick their own area of expertise and ask them questions about what they know best to see how deeply they've gone in their explorations. The ability to figure out the "why" is a necessary skill for folks that you're going to trust to take vague requirements and come up with Google-like results in an environment where no two consecutive projects use the same set of technologies (or even similar ones, increasingly).
To select for personality, as well as technology, I like to whip behavior interviewing questions on folks. Instead of sketching a situation for an interviewee, e.g. "how would you deal with conflict in the work place?", behavioral interview questions ask people to remember real situations they've been in and how they reacted, e.g. "Imagine a time when you had conflict in the work place. How did you handle it?" Everyone knows the right way to handle conflict in the work place, but far fewer of them have handled it properly when it actually happened. The idea of behavioral interviewing is that past behavior indicates future behavior, so if you don't like that your candidate punched his last manager in the nose, that's something to find out up front.
Once a good person has been hired, keeping them is a matter of paying them what they're worth, letting them do what they're good at, helping them get better at what they're not so good at, making sure you don't waste their time on stuff that doesn't matter, showing appreciation for a job well done and otherwise staying the hell out of their way.
Friday, Aug 30, 2002, 1:18 PM in The Spout
Spout -- Development for Developers
Here. "I got an email today from David, who says, 'So, I am looking to see what I can do to develop my skills as a designer. The trouble that I have, is simple. Where does a programmer that is over 40 years old, with a good job, and a good family turn to to learn something like this?'"
Friday, Aug 30, 2002, 12:00 AM in The Spout
Development for Developers
I got an email today from David, who says, "So, I am looking to see what I can do to develop my skills as a designer. The trouble that I have, is simple. Where does a programmer that is over 40 years old, with a good job, and a good family turn to to learn something like this?"
David, developing in any career means taking risks, trying new things, making mistakes. Some specific things you can do to improve your developer/designer skills include:
- Examine your goals. Do you want to be a better coder, a better designer, a better tester? What's better to you? Fewer lines of code? More lines of code? Faster code? More readable code? More documentation of code/design? More thorough designs? More testable code? More unit tests? Set yourself a list of goals and examine it on a regular basis to keep yourself on track.
- Read some books and articles, like Writing Solid Code, and re-write some of your own code using the techniques you've read.
- Pick your favorite feature in your favorite application. Design it. Implement it.
- Read and review other peoples code to see what they do, especially in languages and task you're unfamiliar with to get a different point of view.
- Pick a bug out of the bug database. Find the real cause. Find the implementation mistake that caused it. Find the design mistake that caused it. Change the implementation and/or design to find other similar bugs in your code base. Change the design/implementation to make similar bugs impossible in the future.
- Run a code review to get your peers' feedback on your code.
- Get together with a group of developers at your job for weekly lunch lectures. Teaching someone is a great way to learn.
- Take the time to really do something "right." You can't always do this due to other real-world constraints, but if you never do it, you're much less likely to get things right in the future.
- Take the time to follow your "fetishes." I can't tell you how often I've followed up on something that didn't have anything to do with what I was doing, but I just couldn't leave it alone, and then it dove-tailed with something else I needed to do almost immediately. Most of this web site is a result of following this advice.
- Attend a conference and ask a lot of questions. Really drill the speakers to make sure you "get it" (especially if it's me : ).
- Write an article on something and send it around to your peers or put it up on the web. Writing about something is the only thing I can think of that's better than teaching as a way for you to learn.
- Hang out on the mailing lists and news groups, but only answer questions you don't know the answers to. Don't worry about being wrong and thank everyone who shows you when you are.
- Write a hunk of freeware/shareware/open source software and put your software up on the web along with an installer and documentation. Maintain it.
- Find yourself a mentor. Ask lots of questions and get them to review your work. I've had a number of mentors of my own over the years (Mike Woodring, Paul Crutcher, Don Box, Tim Ewald, John Robbins) and it's made a world of difference.
If you'd like some "hands on" guidance to improve your skills as a developer, I'm available as a mentor. I've mentored a number of folks over the years and they've had some nice things to say about the process. But don't feel you need me to take advantage of these tips. Take risks, try new things, make mistakes.
Wednesday, Aug 28, 2002, 12:00 AM in The Spout
Newsletters Are Hard!
As I write this, several thousand emails are being sent to the initial list of SellsBrothers News newsletter subscribers. My motive (to let folks know what was happening on the site without having to visit every day) was pure, but if I would have know how hard it was going to be to set the thing up, I don't that I would have started.
It began with a simple form on the web site to take people's email addresses, which were in turn emailed to me and sorted into a Outlook folder. When that reached a couple thousand without yet having sent out a single issue, I figured it was time to put it into a real database. So, which a bit of data cleaning through VS.NET and Excel to get the dates right, I plunked it into an Access that would serve as the repository on my ISP-managed site. That was all fine and dandy but for one problem: I had to send emails using the data from my own machine, not the machine with my live site (and therefore the latest subscriber data). Did I really want to download an Access database from my ISP every time I needed to send a newsletter? It won't be often, I admit, but that still seems wrong, doesn't it?
So, I paid the extra $10/month to get SQL Server support on my site and worked with a friend of mine (Paul Crutcher) to build the form to take name, email address and HTML vs. Text settings. Except it's not just one form. To make sure that folks aren't subscribing other folks, we send out a confirmation email with an URL in it that updates the database and shows another form indicating whether that worked or not. Then, in case anyone changed their mind, we needed another form to change subscription settings along with another form letting them know that their changes were made. Of course, before we could let them change their settings, we needed to let them log in, which was another form. And, if they forgot their password, they need another form so that they can enter their email address and we can send it to them. Further, if the worst happens and they tire of my musings, they need to be able to unsubscribe themselves.
Not only did Paul build all of these forms, but he built them in two parts, a form part and a control part, so that I could update the form part to have the sellsbrothers.com look 'n' feel, while leaving the real logic in the control part untouched (and potentially reusable). All in all, just letting folks manage their newsletter subscriptions was 46 hunks of HTML packaged as .htm, .aspx and .ascx files. 46! I would have downloaded something and integrated it, but I never found anything to do the job (and this is where I get a hundred emails showing me the error of my ways... : ).
Of course, all that user-managed subscription work was to avoid one thing: angry emails. I didn't want folks who'd forgotten they subscribed many months ago or, worse, folks that were subscribed implicitly from other activities like the DevCon, to find themselves on a list with no way to get off of it except for sending me angry emails. That's just how insecure I am. : )
So, after a few weeks of Paul and I working on the pages to do the administration for me, I thought that the hard part was over. I was wrong. While I did have an SQL database on my site, it was still nearly empty. There were some folks who were newly subscribed after the new code went live, but all of the folks who'd subscribed before then were stuck in an Access database. "That's OK," I thought. "SQL Server and Access were made by the same folks. I'm sure I won't have any problems moving the data." That was two weeks ago. It took tons of advice from my database friends (thanks BobB and ShawnW and BrianR!), along with a final push from my brethren on the Off Topic Mailing List to get the data moved to the right place. The good news is that I got to polish my T-SQL skills a bit and I got to play with DTS and the Enterprise Manager (both very nice pieces of software).
But that's not all. Once I had the subscribers in the database, I then had to send several thousand emails, sorted into folks that want HTML and folks that want Text, keeping track of bad email addresses. This time, I went looking for a commercial product to do the job. I figured that since my inbox was full of spam (SpamNet is my new best friend!), that there must be really great tools for sending emails by the boatload. And again, my friends on the Off Topic mailing list were there to help with a recommendation of the Advanced Direct Remailer. ADR is also a nice piece of software that comes out of the box configured almost right, but not quite and the documentation has to be read very carefully. ADR is an SMTP server that takes mail from your mail client and forwards it to a list of folks based on who you sent it to. For example, you can send it to foo@localhost where "foo" is a mailbox that resolves to a list of email addresses in a text file or you can send it to bar@localhost where "bar" is a mailbox that resolves to a select statement from a database. That all works great, except if you get any of the settings at all wrong, ADR starts acting like a real email server and just tries to send the email to foo@localhost. Well, actually, it can't be foo@localhost for me, since I'm using Outlook XP, a marvel of software engineering that in it's infinite wisdom prohibits me from sending an email to a server without a "." in it. So, I send an email to foo@127.0.0.1, which ends up in ADR, but the default settings only resolve requests sent to "localhost", so ADR won't do the queries. However, it is talking to the built-in SMTP server on my machine (which I need for testing my web site before publishing it), so it looks like it's doing something, making it even harder to figure out what's going on, since I've never seen what ADR does when it works correctly.
When I finally do get everything right and the emails are queued in ADR properly, I can tell it's going to take hours of 100% CPU utilization for the newsletter to get out, so I go on to something else. But I can't stay away for very long, so I'm constantly logging into the machine doing the sending via Terminal Services to check on the progress. With the CPU fully utilized, all the failed TS connections (I have to keep trying!) eventually crash the ADR machine, causing a panic as I reboot. I needed have worried. ADR has kept everything logged and picks up right where it left off before the crash. Truly an amazing piece of software.
Why do I feel like Jerry Pournelle all of a sudden?
Now, as I'm drawing this missive to a close, I'm getting half a dozen emails from subscribers that wish to unsubscribe but can't because of the peculiarities of the imported data vs. what I tested against. So, the angry emails have started. Here's a particularly angry one:
Subject: Get me off your spam list
You are too much of a hassle to remove, you lie about where you got my address, I do not trust you at all.
I will prosecute you my every means possible if you do not remove my address from your database.
If I find out you spread my address, I will go after you for that.
Oh, well. I tried...
Tuesday, Aug 13, 2002, 12:00 AM in The Spout
The Apple and the Tree
Yesterday my eight-year-old and I had the following conversation:
John: "Dad, do you know a lot about computers?"
Dad: "I know my share."
John: "But do you really know a lot?"
Dad: "I know pretty much."
John: "What buttons to you press to make that come up (pointing to
the Start button)?"
Dad: "Ctrl+Esc"
John: "And how to you make it do Run?"
Dad: "Ctrl+Esc+R"
John: "Cool."
Cool indeed. : )
Saturday, Aug 3, 2002, 12:00 AM in The Spout
Industry Burn-Out
Do you feel it? I do and I know that a bunch of my friends do. The whole IT industry is in recovery from the crashing lows that can only happen after impossible highs. In recent conversations, I hear terms like "burned out," "bitter" and "jaded" coming up again and again in our conversations. Since I got into this industry just as it was idling before take off, I have no frame of reference, but I'm guessing that things will level off at a bit better cash flow than right now, but much better morale.
The question is, how long will it take for the energy and excitement to come back? I know that I'm still healing from a three-year stint on my last big project, and even though I have an itch to try something else, I fantasize about trying my hand at another industry. I always figured that the shake-out would make the bottom feeders leave for something else, but now that we seemed to have settled on good, although not great, salaries and benefits and shaky processes at best, how many of the top folks will just bail from something else? I haven't actually seen anyone I respect leave for greener pastures, so I've got my fingers crossed that things will turn around.
Thursday, Jun 27, 2002, 12:00 AM in The Spout
Where Do You Find the Time?
I had lunch with a couple of colleagues on the lecture circuit today and after they asked me what I was working on (Genghis, the Web Services DevCon in October, ref-counting for Rotor, a few books, some consulting, etc), they asked where I found the time. Here's how:
- I work with a *ton* of very talented folks. The following are just
the ones I'm remembering off the top of my head that I've been working
with lately: Chris Tavares, Brad Wilson, Shawn Van Ness, Jon Flanders,
Don Box, Tim Ewald, all the Web Services DevCon speakers and staff,
all the Genghis contributors, Tim Tabor, Michael Weinhardt, Microsoft,
Dharma Shukla, Brian Harry, Chris Andersen, Mark Boulter, and, of course, all of my
former DevelopMentor
brethren.
- But most importantly, I don't attend meetings or request vacations or approve vacations or attend meetings or receive reviews or give reviews or attend meetings (did I already say that?) or do any of the other things that employees have to do. Skipping these activities easily doubles or triples my productivity. Of course, I had to give up the steady paycheck to make it happen and it's not the life for everyone, but it works for me just fine. : )
Real software engineering has so little to do with actual technology, it's kinda sad. I'm lucky. I only have to do the technology part. My question is, how do people with full-time jobs find the time to learn the technology?
Tuesday, Jun 25, 2002, 12:00 AM in The Spout
XML & Inclusion
guest editorial by Don Box, Tue, Jun 25, 2002
Chris, I just read your "Object vs. XML" post on the spout and I'd be pleased if you would allow me to respond with my own personal spoutlet. Here goes:
For much of the 1990's, I spent a lot of time writing COM code in C++. The combination of C++'s static type system + COM's dynamic type system was a very powerful combination that I am proud to have been involved with, even though my contributions to COM were from afar as a non-Microsoftie.
In March of 1998, I had the pleasure of working on the initial SOAP protocol with Microsoft and Dave. That experience was a turning point for me, as it forced me to acknowledge type systems that were not part of the classic OO family that I had come to know as the "one true way."
Unlike COM or Java, XML tends to attract developers of every stripe, each of which has a wildly different sense of esthetics with respect to language design, data vs. processing model, structural vs. nominal typing, functional vs. declarative vs. imperative styles, etc.
Because XML's raison d'etre is interop, XML needs to be neutral with respect to these choices, otherwise, the barrier to entry becomes too excessive for some communities to participate. The current pushback against XML Schemas is a great example of this effect.
XML Schema imposes a type system over XML Infosets that is very similar to the OO type systems you are familiar with. This makes XML Schemas well-suited for importing directly into Java or C# programs.
Unfortunately, the XML Schema type system has features that don't make sense if your world doesn't revolve around named user-defined types (e.g., several script languages, SQL, etc.). For that reason, some members of the XML community has been lobbying for something with a looser type model than XML Schemas. Had the XML Schema working group made it clearer how to do this sort of thing with XML Schemas, I believe the time for adoption would be that much shorter.
Getting back to your original post, I find your characterization of my colleagues and I as "so steeped in the new world that they forget where they came from" a bit misleading.
As an XML guy, I try not to focus too much on where I came from. Rather, I try to bend over backwards to be respectful of where other people came from.
I don't want the guy writing ML code in Dayton, Ohio to shove his world view down my throat.
I'm trying hard to reciprocate by keeping my OO/C++/COM sensibilities in perspective.
XML is about inclusion.
It's the ultimate Rorschach test.
We all make it into what we need it to be.
That's the "secret sauce" that makes XML what it is.