Recently, the JRuby team has gone through the motions of getting a definitive JRuby book underway. We've talked through outlines, some some chapter assignments, and discussed the overall feel of a book and how it should progress. I believe one or two of us may have started writing. However the entire exercise has made one thing abundantly clear to me:
Good authors do not have time to be good developers.
Think of your favorite technical author, perhaps one of the more insightful, or the one who takes the most care in their authoring craft. Now tell me one serious, nontrivial contribution they've made in the form of real code. It's hard, isn't it?
Of course I don't intend to paint with too wide a brush. There are, without a doubt, good authors that manage to keep a balance between words and code. But I'm increasingly of the opinion that it's not practical or perhaps even possible to maintain a serious dedication to both writing and coding.
What brings me to this conclusion is the growing realization that working on a JRuby book would--for me--mean a good bit less time spent working on JRuby and related projects. I fully intend to make a large contribution to the eventual JRuby book, but JRuby as a passion has meant most of my waking hours are spent working on real, difficult problems (and in some cases, really difficult problems). It physically pains me to consider taking time away from that work.
And I do not believe it's from a lack of interest in writing. I have long wanted to write a book, and as most of my blog posts should attest, I love putting my thoughts and ideas into a written form. I enjoy crafting English prose almost as much as I enjoy crafting excellent code. But at the end of the day, I am still a coder, and that is where my heart lies. I suspect I am not alone.
When I decided to write this post, I tried to think of concrete examples. Though many came to mind, I could not think of a way to name names without seeming malicious or disrespectful. So I leave it as an exercise for the reader. Am I totally off base? Or is there a direct correlation between the quality and breadth of an author's work and a suspicious (or obvious) lack of real, concrete development?
Wednesday, September 19, 2007
Are Authors Technological Poseurs?
Subscribe to:
Post Comments (Atom)
28 comments:
murpheee: But there is few orders of magnitude of differences between writing small, focused essay and a full technical book, I guess.
Elliotte Rusty Harold has written a bazillion books and XOM which is a great library IMO. (Along with being a university prof)
There is a lot of truth to what you have said. You have a limited amount of time. How should you spend it? Capturing details for posterity and *maybe* teaching someone something or solving problems in a tool that people can use to earn a living? Which is more important to you?
Ah... university prof: what about Terrence Parr of ANTLR fame? He just brought out the ANTLR 3.0 book @ the Pragmatic Programmers. Oh... Joe Armstrong and his Erlang book.
I'd call their code contributions to development "real and concrete".
@Vladimir:
Well, depends. Some of the folks in the Beautiful Code book are Authors of books, eg. Michael Feathers or Brian Kernighan and others.
But mario is right - this is more of a time problem. Mind you - I'm not sure what would go into a JRuby book right now - wouldn't that be outdated by the time it's printed?
How about "Donald Ervin Knuth", writer of "The Art of Computer Programming" and author of TeX.. but maybe he is no real coder, maybe he just likes programming ;)
I think that writing code without thought is as if talking nonsense all the time. And thus sometimes a small commit becomes extremely helpful, while the core developers are burdened with fixing bugs. Not that this is important too, it helps many people. But sometimes it does not give you the time to really think about a problem and solve it good. Sometimes writers of books and papers are contributing precious gifts to your work, because they have a different view and because they had time to really think about while they work.
I think it is very difficulty to code and to write at the same time.
Depending on your Book there might be a state where it is near completion, but the architecture is about to be changed making your book a bit bad looking. What do you do if you are the person doing the architecture change? Delay the book even though the review phase would start soon? Or would you delay the change, delaying a great idea for maybe months?
It does not mean you will automatically come to this - depends on your work. but writing a book amplifies the possibility, because you might for the first time ever really think about the work you have done in a greater context. All of a sudden you see possibilities you haven't thought of before and the coder inside you wants to try them, look if they are just woolgathering or of they could be realized.
Writing a book might change your view.
So all in all I think it is worth trying to write a book, maybe it will just lead to better documentation somewhere, maybe it will give you new impulses for future work, or maybe you will just simply write a good book... Who knows? ;)
No mention of Ola's book? I plan on ordering a copy.
Still, it would be great to have some comprehensive material with a clear learning path to make it easy for new adopters, but it might be worth considering making it an online reference rather than a printed book. Atleast that way it could keep up as JRuby evolves, and the community could contribute to grow it. You have a wiki, but im thinking something chapter oriented that reads like a book. I for one would be interested in contributing to such an effort.
Readily available, comprehensive guides that "Joe Developer" can understand is the way to win users.
Many are, and it may be the rule. But of course there are exceptions to that rule. Jeffrey Richter is a good example of an exception.
I think you're exactly right - but, as others have said, because it's a time tradeoff, not because you lack one talent or the other. I have the opposite problem.
Fifteen years ago, I was a coder. I spent all day in emacs, I could take someone else's "two weeks work" and crank it out overnight, and I had the 100KLOC to prove it.
I took a multi-year sabbatical, and recently got back into programming. But I spend some huge percentage of my time writing about coding - not a book, necessarily, but newsgroup posts, blog entries, and what not debating architecture philosophies, detailing interesting techniques, documenting odd failure scenarios, proposing solutions, etc., each one its own article in the magazine of my day. For every line of code I produce, five ideas spring forth that I feel compelled to write about. Maybe I've just turned into a writer.
I don't think it's impossible to be a good author and a good developer, but it must take a lot of discipline to balance the two roles, and an awful lot of time.
It's definitely not common to have a well-developed writing talent along with a well-honed coding craft (I say this as an editor of technical writings). Personally, I've found that my code-related contributions decrease as I spend more time writing and increase when I finish the writing project. I think that's more due to the time demands of each rather than any necessary conflict between the two abilities.
It takes a commitment to do both, but the three authors of the O'Reilly Subversion book are all long time committers to the Subversion project, and both the book and Subversion project are well regarded.
Rob Pike
Being a good author or developer has nothing to do with how you spend your time on any particular day, month, or year. In fact, your argument that writing a book sucks away your development chops also means that doing anything more than coding should do the same thing.
I think what you are seeing is that most people aren't good at either development or writing. It's even rarer to find someone who is good at both. But, as I noted, pick any two non-overlpaping skills and you'll find the same thing.
DHH?
Gavin King
As you might imagine, I've been approached over the years quite a few times about writing a book on either Struts or JSF. After looking at the work involved, I have concluded "writing code is fun, writing words is work" -- and I'll bet I am not the only one who feels that way :-)
Craig McClanahan
Unix and C - Brian Khernigan, Dennis Ritchie, Pike. Everything they wrote is top-shelf.
Unix and TCP/IP - Richard Stevens provided useful toolsets along with some of his outstanding books.
Perl - Larry Wall, Tom Christiansen, Randall Schwartz, Damian Conway. Excellent software and books.
TestNG's Cedirc Beust, maybe (I haven't seen the book yet, but his online writing is quite good).
And of course not all software efforts are open-source; many authors succeed in commercial development. Martin Fowler comes to mind.
Still, these are exceptions. Nutter raises a good point.
Rod Johnson?
It's not just because you can't do it that nobody can do it :P
And due respect to Richard M. Stallman's GNU Emacs. The manual is very much a 'manual', but a standout of the genre - clear, crisp English, well organized for its purpose.
Why do some technical authors think we care about their kayaking adventures or sci-fi stories?
Hi Charles,
I would be careful to not paint with too broad of brush. I think what your team is running into is that writing is a lot of really hard work. It is not something you can just spit out :). A lot of technology people who sit down to write a book the first time have no idea how time consuming it is.
I have authored and co-authored a number of technology books and it meant a signficant amount of time away from your friends, wife and children. It is late nights and early mornings.
I think the trick is to write about something you are passionate about and realize that you are going to be going without significant amounts of sleep while you are doing it.
I think that many authors/speakers are good coders. They are passionate about what they do and write because of it.
I think being a technology author/speaker means you have to become extremely good at balance and willing to sacrifice.
Bjarne Stroustrup once created a programing language and a wrote a few books about it.
Andrew Tanenbaum delivered Minix, a forerunner of the Linux kernel project.
Come to think of it, many people have done well in both domains. So is Nutter wrong?
1. Many software books are junk, precisely because the authors learn just enough to write a book on the subject. I'm especially suspicious of authors that cultivate a brand name and grind out books for each new buzzword. You know who you are!
2. No doubt it's very hard to do both at the same time. I hope Nutter sticks with JRuby development for now. For big book sales, first grow usage of the software. We already think JRuby is cool, but it's not a guaranteed success; Jython was stuck in neutral for years. Make JRuby an obvious choice for solving real problems. If you achieve that, many more people will buy books by the creators, whenever they arrive.
kent beck - tdd programming
andrew davison - killer java game programming
still not enough good?
Charles,
I think it's more like taking the intersection of two small subsets.
The fraction of all coders who are "great coders" is a small percentage... the far end of the bell curve.
The fraction of (potential) writers who become published authors is small. The fraction of those you'd consider great is, again, the far end of the bell curve.
"Great coders who are great authors" is the intersection of those two small populations.
Cheers,
-Mike Nygard
michael@michaelnygard.com
http://www.michaelnygard.com/
Author of "Release It!"
http://pragmaticprogrammer.com/titles/mnee/index.html
Most technical books being written these days are crap! These "authors" do not even have training as "technical writers" and yet they get 'book deals'.
I would second the K&R mention. And along with Andy Tannenbaum, what about Knuth? Is he just a talking head? I think he went furthar by generalizing the specific problem of programming the solution to a specific problem.
This is why I have always found the ravings about "pickaxe" lamentable. The book is rather shoddily put together, but since the ruby community hadn't seen anything like it in their realm they started raving about it, and still tend to do so even though compared to other introductory texts (python, C etc) it is quite poorly written.
Come to think of it, what exactly has Dave Thomas contributed to the programming side? I haven't seen anything done by him that would qualify as a beautiful piece of code etc. ??
One of the reasons for the low quality of books is that many consultants find a book title to be great PR.
I don't know if I'm a good author or a good developer. I try to be both, but I've learned not to try to be both at the same time. Writing a good book is very hard work. I can't do that and ship good software at the same time.
Just because you haven't seen the code written by many authors, doesn't mean they can't write good code or are "poseurs". Some of the best authors have honed their skills by writing proprietary code for a living. The best books are written by people with real world experience, and it shows in their writing.
My favorite?
Josh Bloch.
Next up?
Knuth, or maybe K&R.
Enough said!
Post a Comment