News from National -- Current Articles

5/31/2002 9:01:06 AM
World Application Expert: Rod Stephens
Interview by S. Ibaraki, I.S.P.

This week, Stephen Ibaraki, I.S.P., has an exclusive interview with Rod Stephens. Rod is one of the world’s foremost experts in application development in languages such as Visual Basic, and a highly respected author of more then 10 programming books and hundreds of articles.

****
Q: Rod, you are considered by many as the foremost expert in application development. It’s a real privilege to have you with us. Thank you for agreeing to this interview and sharing your experiences, wisdom, and vast skills with our audience.

A: I'm glad to be here. I hope I can give people at least a few useful bits of information.

Q: Can you describe your days as a mathematician and at MIT?

A: I had originally planned to focus on logic at MIT. I took a selection of mathematics courses including several algorithms classes that were cross-listed in the computer science and mathematics departments. After a while, I decided they were a lot more fun than logic so I switched my focus to algorithms and computability. Some of the algorithmic topics I studied included general algorithms, parallel computation, systolic algorithms, operations research, cryptography, robot control algorithms, and graphical simulations.

As a teaching and research assistant, I taught a few different levels of calculus and a couple of computer classes. The first real commercial system I worked on was a transshipment project for Gillette done with Professor George Kocur who's still at MIT. That project used operations research algorithms to determine the most efficient methods for shipping different amounts of product to different locations.

By my current standards, it was a very small project but it still taught me a few key lessons. In particular, it taught me the importance of dividing a project into clearly separated and manageable pieces. I worked on the user interface while George and another graduate student worked on the algorithmic piece. The separation was clean enough that we were all able to do our work without interfering with each other. It was so easy at the time that I didn't even realize how important it was. Since then I've worked on a couple projects with less clearly differentiated tasks and they really drove the point home.

Q: What sparked your interest in programming?

A: My father was a programmer back in the early days when there were no computer scientists, just engineers. I'd always been interested watching him work. I remember trying my hand at simple games (without much success) as a teenager.

As an undergraduate, I considered double majoring in mathematics and computer science but didn't make up my mind soon enough. I did take a few classes in algorithms, graphics, and cryptography, though, and that kept my interest relatively fresh until the advanced algorithms classes at MIT really got me going.

I've always had a feel for what a program is doing and I found it very satisfying when things actually worked the way they were supposed to. I find complex algorithms and graphics programming particularly gratifying. It never ceases to amaze me when you dump a pile of constraints into a scheduling algorithm and get back a perfect work assignment, or when you shove a bunch of numbers into a ray-tracing application and a realistic three-dimensional picture pops out.

Q: How did you get into writing articles and books?

A: Early on, I wrote a couple of magazine articles and some corporate publications more or less just for fun. Later I was working as an independent consultant (which I've done most of my career) and I was between projects so I sent a letter to the major computer publishers proposing a book titled "Visual Basic Workouts." The idea was to show how to perform some common tasks using Visual Basic 3. For example, building scrolled windows and certain kinds of classes, neither of which were included in VB 3.

These ideas actually predicted the popular "patterns" literature, though in less clearly defined terms. They also showed how to do a lot of things that are better accomplished by the ActiveX controls Microsoft later introduced.

Anyway, none of the publishers wanted "Visual Basic Workouts" but two of them liked my background in algorithms and asked if I would be interested in projects they had in mind. The resume is really one of the most important parts of an idea submission to a book publisher and they liked mine. The publisher wants to know whether you have the background to write something interesting and whether you have the skills to write a 100,000+ word book.

The John Wiley & Sons project was an algorithms book and "Visual Basic Algorithms" was the result. Wiley asked Karen Watterson to review my final book proposal and she liked it so much she asked me to write an algorithm column for her publication "Visual Basic Developer." All this lead to a dozen books and more than 180 articles.

Q: I have been reviewing your book on Visual Basic.NET and Database Programming and I highly recommend it. What are your most recent books and articles and can you provide five useful tips from each?

A: My most recent books are "Visual Basic .NET Database Programming" and "Visual Basic .NET and XML." These cover fairly specific topics so any tips taken from them will only be useful under certain circumstances. Unlike, for example, my book "Bug Proofing Visual Basic," which provides tips that are useful on a much wider range of Visual Basic projects.

Some tips taken from "Visual Basic .NET Database Programming" include:

Use MSDE (Microsoft Data Engine) to give yourself a cheap and easy upgrade path to SQL Server if you need better performance.
Use MSDE/SQL Server "roles" and individual privileges to control data access. Grant only the privileges users actually need.
Normalize database design to increase flexibility. Then selectively denormalize it to improve performance.
Perform updates, insertions, and deletions in the proper order to satisfy relational database constraints.
ADO .NET database connection strings are complex. Instead of composing them yourself, use the Data Link Properties dialog to configure a data connection object and then look at the connect string it uses.

XML (eXtensible markup language) is a mostly text-based language for storing data. It's really not a big deal by itself but the things you can do with it are. Some tips taken from "Visual Basic .NET and XML" include:
Use the DOM (Document Object Model) to manipulate the structure of an XML document. Use forward-only readers and writers (XmlTextReader, XmlTextWriter, and SAX - Simple API for XML) when you need better performance and don't need to work with the document's structure.
Use XML to store and recover complex objects in standard textual and binary formats. This is called "serializing" and "deserializing" the object.
Package standard functionality in classes so you can use them in DLLs and in the latest thing in network interoperability: Web Services.
Use XSL (eXtensible Stylesheet Language) to provide different views of the same XML data on the Web.
Use XML inside an ASP .NET page to build a "data island" that displays information that changes infrequently.

Two of my most recent articles are "A ComplexNumber Class" for Visual Basic Developer, and "Map Coloring" for Dr. Dobb's Journal. Depending on how soon this interview posts, those articles will probably not yet have been printed.

While these also cover focused topics, they provide a few interesting lessons that are more widely applicable. "A ComplexNumber Class" shows how to build a class that manipulates complex numbers. This class demonstrates several useful techniques if you're new to VB .NET including:

Overloaded constructors
VB .NET-style property procedures
"Operator functions" (in C++ you can overload operators such as + but in VB .NET you need to use a function named something like Plus)
Overriding base class methods

"Map Coloring" is even more tightly focused. It describes several different algorithms for coloring maps so no two adjacent regions share the same color. If a map is two-colorable (you can color the regions with only two colors), it's easy to find a two-coloring. Deciding whether a map is three-colorable is NP-complete so there are no known fast algorithms. In 1976, Appel and Haken proved that all maps can be four-colored in polynomial time. Unfortunately the algorithm that follows from their proof is extremely complex involving literally hundreds of special cases and I don't know of anyone who has actually implemented it. On the other hand, there is a very fast five-coloring algorithm.

If you just need to display pretty maps, five colors is probably good enough and it will be much faster. The moral is the theoretically "best" algorithm isn't always the best solution.

Q: Describe future book titles and articles can we expect from you?

A: All of the book publishers are moving to VB .NET these days. I might be persuaded to write .NET versions of some of my other books. "Visual Basic Algorithms" would be worth redoing to cover some of the new sorting and other algorithms integrated into .NET. I would also like to expand it to cover more business algorithms (network applications, work assignment, scheduling, resource allocation) or even make that a separate book if I can convince my editor and myself that there would be enough readers. If there's something you or your readers think would be particularly interesting, drop me an email.

"Visual Basic Graphics Programming" would also be fun to rewrite. Support for Direct3D has improved a lot since I wrote the previous edition of that book. There's still room for improvement in Direct3D but the basic drawing pipeline is sound.

While book publishers are all into .NET these days, lots of developers are still using VB 6 and the magazines are a bit more responsive to them. My Visual Basic Developer columns will still cover VB 6 techniques at least some of the time.

Q: Can you describe some of the projects that you have worked on and what tips you can pass on?

A: I've worked on some amazing projects. In one project, a billing center was ignoring a printout of overdue accounts because it took up a stack of paper three feet tall every other day and the accounts were listed in random order. Some customers owed a few dollars and others owed thousands. We wrote a simple application to capture the printout and sort the accounts by balance due. Only the first two pages contained customers with large enough balances to take action.

The lesson here is that small things can sometimes make huge differences. The billing center people didn't know we could capture the printout and sort it. After we had studied their operations for a while, we found something easy to do that made a huge difference in their ability to do their jobs.

In another application for the same billing center, we wrote a more complex "screen scraping" application to automatically review accounts and disconnect service for those that were seriously overdue. One morning the mainframe developers changed the location of a field on the screen. The new location was obvious to a human but our program couldn't find it and incorrectly disconnected about 400 customers before we realized what was happening. Working quickly with the billing center staff, we wrote a program to put the customers back in service and had it all fixed in a couple of hours. Only two customers noticed they were out of service before we had things fixed.

This project highlights the importance of different groups working on related projects keeping in touch with each other. If the mainframe people had told us about the change, it would have been no big deal.

Some of the other projects I've worked on include a fuel tax application for the State of Minnesota, training software for professional football players, and switch programming for telephone switches.

One of the strangest things that ever happened to me on a project occurred on a dispatch system that assigned several hundred repair people to a few thousand jobs each day. Twice during the pilot tests the system assigned a repairman to work a job at his ex-wife's house. Fortunately the repairmen in question recognized the addresses and called in for different jobs. If we had thought of this during development, we would have thought the odds of such a thing happening were too close to zero to worry about. And here it had happened twice!

There are two lessons here. First the users will eventually find every conceivable way the software can mess up. Second, it's good to leave a human in the loop to correct the "impossible" mistake that will eventually occur.

Q: Your VB helper web site at www.vb-helper.com, receives more than a million hits per month. Can you describe the evolution of this web site, its purpose, and what you foresee in the future for this key resource for developers worldwide?

A: The site started as a place for me to provide support for my books: post descriptions, updates, corrections, discussion, and samples. I immediately started adding example programs, tips, and tricks and now it contains more than a thousand examples.

Originally the site only contained example titles and you had to download a Zip file to see the code. Newer examples show you key code and a more detailed description of how the examples work on a Web page. You can still download the example source files if you like.

Eventually I would like to convert all of the older examples into the newer format. The site will also contain more and more VB .NET code, though I know a lot of developers will be using VB 6 for quite a while.

I'd also like to do more with games, Direct3D, Palm OS and Windows CE, and all sorts of other topics but realistically anything too elaborate will take a while. I am looking hard at Palm OS development lately so I might actually get something together on that topic.

Q: How would you contrast or compare the Java world versus .NET? What’s the future of these environments in the near and long term?

A: Each has its advantages and disadvantages. Java has the nice concept of the "sandbox" where your application is only allowed to do certain things. For example, it cannot use Outlook to install viruses. On the other hand, it's relatively slow and not a very natural language unless you're a C++ programmer (but I'm biased towards Visual Basic these days).

Microsoft is pushing Web Services hard as its solution for Web connectivity. Web Services are a lot easier than some of Microsoft's previous attempts, but the steps to install them are still a bit arcane.

In the long run, I think the cultural differences will play a bigger role than the technical pros and cons. Java programmers love Java (some partly because Java is not Microsoft) and will probably never give it up. Microsoft has a huge amount of muscle in the development community so I would be shocked if .NET disappeared any time soon. I suspect we're going to have them both around for quite a while.

I personally hope future versions of .NET place a little less emphasis on the Web. All of the big projects I have worked on have been mostly centered on the desktop (sometimes with Web components as extras). This version of VB .NET makes a lot of Web programming easier at the expense of desktop development. While it's clear that there's plenty of room for new Web applications, neglecting the desktop would be a mistake.

Q: What are the five top traps or pitfalls that developers should be wary of and avoid?

A: A tough question. My "Bug Proofing" book spends more than 400 pages on this topic so it's hard to pick just five. If I had to make a short list, however, I would focus on higher-level issues. Most developers know they should comment their code (although many don't), explicitly declare variables, and avoid unnecessary complication. However, many don't place enough emphasis on the processes controlling the development effort itself. A mistake in a subroutine can mess up that subroutine and cost you some time debugging. A mistake in the fundamental design can lead to a completely worthless product.

So a list which may not be the TOP five but which certainly contains five important issues is:

Don't rush into programming. Build a solid design before you start writing code. Developers naturally tend to push towards coding because it's more fun than design but a few hours of preparation can save you hundreds of hours of debugging.
Avoid monolithic, closely integrated designs. Compartmentalize the design. Breaking the application into clearly separated pieces allows developers to work on the pieces in parallel, independently, and without interfering with each other.
Don't skimp on debugging, testing, and documentation. Developers tend to allow insufficient time for these tasks because, again, writing code is more fun. Then when the schedule slips, they often take more time away from these tasks. If you don't debug your code, it won't work. Guaranteed. If you don't test it, how do you know if it works? If you don't document it, how can anyone use it whether it works of not?
Don't think you can "make up time" later. You cannot. It's amazing how often developers see that every task has run long by 20 percent so far but they still think they can make it up somehow later. If you are not tracking to the schedule, make some changes to the way you are doing the work (add people, redesign, recompartmentalize, reduce features, do something!) or you will either continue slipping or you will need to take shortcuts (probably in debugging, testing, and documentation).
Don't optimize your code until you know it's necessary. This is probably the tip that's hardest for developers to swallow. First make the program run correctly and simply. Then make it run faster if necessary. Many parts of the application will probably be fast enough from the start and you can save the time and complication you might have added otherwise if you had optimized them prematurely. Save your efforts for the small fraction of the code that really needs work.

Q: Can you share your 10 leading career tips for those thinking of getting into the computing field?

A: A good place to start is your skill set. Obviously you are more valuable to an employer if you have lots of relevant skills. In your free time, expand or update those skills. Build a Web site and experiment with ASP, ASP.NET, Java, and Web Services. Download the free demo for a language or development environment and experiment with it until you have at least some proficiency. Build some games or other applications you can use yourself just for fun. That will give you some goals to help keep you focused on learning the new technology. Don't list these secondary skills as your primary talents unless you have a very thorough understanding of them, but you can at least say you have some experience with them.

With recent trends towards networked computing, many applications integrate more than one major programming discipline. For example, an order processing system might include desktop, database, Web, and PDA components. Gain some familiarity with as many different pieces of the puzzle as you can. If I'm hiring someone who will primarily do desktop development, it still helps to know that they understand the challenges of database design and Web forms.

Breaking into a new field is always tough. Everyone wants someone with experience. One technique for getting experience is to join a temporary agency. That can give you some basic experience with a variety of different industries and programming disciplines. Many developers meet their future permanent employers through temporary work.

Join your local programming user's groups. They provide a good setting for networking with other developers. They often sponsor talks and hands-on lab sessions where you can learn new skills. Many groups also keep lists of people looking for jobs and jobs looking for people.

Don't neglect the mechanics of the job search. Buy several books on job hunting and read them. Write a good resume and have someone else look it over. You'd be amazed at how many barely literate resumes are submitted to businesses every day. Resubmit your resume periodically, particularly to big corporations that get tons of resumes each month. Practice your interview skills and dress appropriately when you go to the interview. Follow up after the interview with a note or phone call.

Probably the single most important tip for any job seeker is to hang in there. Keep submitting your resume to different companies, network with other developers, make new contacts and persist until you find the job that's right for you.

Look for the right group of people to work with. I've found that the right group of people is more important than finding a cool project. A really good team of developers can make ANY project fun and interesting. A bad development team can make your life so miserable you'll be phoning recruiters within a month.

1. Expand your skill set
2. Update your skill set
3. Get experience through temporary contracts or agencies
4. Read job hunting books
5. Write a good resume
6. Practice interviews
7. Dress for the interview
8. Follow up
9. Hang in there
10. Look for the right people, not the right project

Q: You have a reputation for being plugged into the stream of computing consciousness. What are the hottest topics that all IT professionals must know to be successful in the short term and long term?

A: Sometimes I'm not all that certain that I'm plugged in. Often I see something that technically is no big deal but that takes the programming community by storm. On the other hand, something that is technically wonderful is completely ignored.

For example, XML is little more than a slightly baroque method for storing data in text files. It was pushed hard by several large companies (notably Microsoft in the .NET environment) right when developers were trying to find ways to cope with a proliferation of platforms (mainframe, desktop, Web, PDA, pager). The fit was right so it looks like XML will become a very important part of distributed computing.

Similarly Java is really not a revolutionary concept. The idea is to write code that can run on many different platforms. That's basically what a compiler does and we've had those for decades. However, Java was pushed by big corporations (notably Sun) right when developers were trying to generate content on all these new devices. The breakthrough is not in the technology, but in getting all these different operating system vendors to agree to support the same language.

In general, these sweeping trends seem to follow the corporate and developer culture more than technical achievement.

In the short term, these needs are filled by XML/XSL, and by Java or Web Services. Whether these are the best solutions in the long run, only time will tell. You should at least have some familiarity with them, however, so you understand the issues and you can take advantage of whatever features they offer.

Another topic worth monitoring is XP (eXtreme Programming). This is yet another attempt to capture the Holy Grail of software management: the ability to produce reliable software quickly. I've had a lot of luck in the projects I've been on using the techniques described in the recent books. With topics like this, however, you need to be careful to separate the experimenters from the experiment. Many of the groups working on these sorts of projects contain highly experienced developers. It's not always clear whether the same techniques will work with just anyone.

To predict trends in the longer term, look for an unsatisfied need (distributing content on multiple platforms, executing on multiple platforms). Then look for a relatively incremental improvement in technology that fills that need. You usually don't need to look for a huge revolution.

Producing quality code quickly has always been a need. Perhaps XP can satisfy it. Perhaps something else can. Source code control systems and project management software should be able to help but they've been around for a long time without solving all of our problems so that's probably not the solution.

One issue that may eventually slap the development community in the face is software complexity. When I started programming professionally, I worked at a lab where 300 scientists shared a computer that ran about 1 million instructions per second. Now my personal desktop system runs hundreds of times faster but it's barely powerful enough to boot the operating system in a reasonable amount of time. The reason for this poor performance is that today's software is much more complex than it used to be. The operating system in particular is hugely complicated and uses a tremendous amount of resources. Huge increases in hardware performance are being eaten by huge increases in software complexity.

Hardware speed has been increasing steadily for years but it is starting to reach limits imposed by the physics of these devices. Unless users suddenly decide they have enough performance (which seems unlikely), something must change.

One way chip manufacturers increased hardware speed was to move to reduced instruction sets. Supporting fewer CPU commands allows RISC chipsets better optimization and pipelining. We can streamline software in a similar manner. When I moved from C++ to Visual Basic, I was amazed at how much more productive I was. One reason was that Visual Basic is far simpler. It hides most of the ugly details of Windows programming from the developer. Yes, it's harder to do some things like dig into the Windows event loop, but it was easy to learn to live without those features. At some point you may be willing to trade powerful language constructs for speed.

With VB .NET, Microsoft has added a new layer of complication to Visual Basic programming. Now you can build inheritance hierarchies. Using them, you can build new ways to confuse yourself (the only project I've worked on that I consider a true failure died largely because of an over-complicated object hierarchy).

It may be too late to remove features from VB .NET, but I would love to see some reduction in the complexity of operating systems. I don't need half of the latest features and could sure use an increase in performance. Lately I've been programming for Palm OS and I find the limited capabilities and memory restrictions on PDAs to be strangely refreshing.

Saying an operating system has fewer features than the last version is probably not smart marketing, but I'd bet a lot of users would jump at the chance to get a lean, mean, fast booting machine.

Massively distributed processing also shows great promise in the medium-term. A couple groups have already used idle CPU cycles on desktops to analyze SETI data, identify promising vaccines for anthrax, and find large prime numbers. I wouldn't be surprised if companies with large computing needs start discovering the huge reserves of untapped power they already have.

Other technologies that are definitely cool but probably won't be useful in the near future include optical computing and quantum computing. They have the potential to provide new increases in processing speed, but probably not for quite a while.

Q: What would be your recommended top ten references for the serious developer?

A: Even developers who don't manage software projects should have an understanding of the development process so you should read a few books on the subject. Books like "Code Complete" and "Debugging the Development Process" explain strategies for controlling development rather than letting development control you. My books "Bug Proofing Visual Basic" and "Prototyping with Visual Basic" explain how to do this in the context of Visual Basic. All of these books take slightly different approaches and each author has more to add so, it's worth reading several.

"Writing Solid Code" talks about techniques you can use to make code more robust at a slightly lower level than some of these other books. Its examples are written in C but the concepts apply to other languages as well.

I've always found that studying complex algorithms helps you learn new programming techniques that you can apply in many different situations. They show how to use linked lists, binary searching, hashing, and lots of other useful methods for getting your work done. They give you new tools and expand your ability to devise your own tools. It's not coincidence that algorithms are often the second core sequence (after the intro courses) in university computer science programs.

Algorithms have been around for a relatively long time so there are lots of good books available. I own a dozen or two including some that are rather specialized (operations research, artificial intelligence, cryptography), and my book "Visual Basic Algorithms." Donald Knuth's "The Art of Computer Programming" series is considered by many to be essential reading. Thomas Corman's "Introduction to Algorithms" and Robert Sedgewick's "Algorithms in C++" are also quite good. If you do a lot of numerical programming, you need a copy of one of the "numerical recipes" books: "Numerical Recipes in Fortran," "Numerical Recipes in C," and so forth.

More recently several design patterns and anti-patterns books have become popular. "Design Patterns" by Erich Gamma is pretty good. Some of the others (particularly the anti-patterns books) spend more text on formal definitions than on code so some of them contain only a few useful topics.

Many programmers have no idea how to build usable software interfaces so I strongly recommend a course in user interface design. Finding great books on this topic is hard, however, and most have very different things to add to the discussion. "Art of Human-Computer Interface Design" is a good collection of essays on the subject. Alan Cooper's book "About Face" adds an interesting view on many topics.

My favorite design book is "The Design of Everyday Things" by Donald Norman. It talks about the design decisions that shape our everyday lives. Things like why telephones are shaped the way they are and how doors can help you decide whether to push or pull. It doesn't talk about programming at all, but it helps you see things from the user's point of view and provides a nice break from hardcore computer books.

Finally, I would toss in a copy of "How to Write for the World of Work." This book gives the goal of clear communication its rightful place at the top of the list for work-related writing. It explains how to avoid the techno-babble, jargon-filled, memoese that fills the programming industry.

Q: You have so many accomplishments. What do you do to relax?

A: We have two young children so who has time to relax? Seriously, I do a lot of things including volleyball, reading, and writing. The kids give us lots of new recreational pursuits such as going to playgrounds, swimming, and changing diapers.

Q: If you were doing this interview, what two questions would you ask of someone in your position and what would be your answers?

A: One question I'm occasionally asked is, "How do I become an expert programmer. In particular, how can anyone learn enough about so many different languages and technologies."

The pithy answer is "one day at a time." You don't need to learn it all at once. If you spend a half hour or so each day reading, looking through examples on the Web, and studying questions in discussion groups (answering them when you can), you'll discover that you know an awful lot before you know it.

A second question that is very popular right now is, "What is the future of Visual Basic?" Microsoft clearly wants developers to move to VB .NET or possibly C#. Book publishers and tool providers have jumped on the bandwagon but the development community is far from convinced even at this late date. In one poll of more than 500 developers, 37% said they were not planning to move to .NET and 21% more were undecided.

I know several developers who still use VB 5 because they feel it is more stable than VB 6. I even know a few who use VB 3 because they have legacy systems running in 16-bit Windows. As someone recently pointed out to me, he has learned practically all of what he knows about VB 6 from the Web, examples posted online, and books. A little thing like Microsoft stopping support for VB 6 isn't going to force him to give it up right away.

Personally, I see VB .NET as another new tool that I need to learn about. I'm using VB .NET and writing books about it, but I still use VB 6 a lot and certainly won't ignore my readers and Website visitors who continue to use older versions of Visual Basic.

Q: It’s a blank slate, what added comments would you like to give to enterprise corporations and organizations?

A: For development organizations I'd like to reiterate that you can control software development. Books like "Debugging the Development Process," "Writing Solid Code," "Prototyping with Visual Basic," and "Bug Proofing Visual Basic" tell you how. You just need to read them, adapt their techniques for your use, and stick by them. That's not always easy. When the schedule slips and deadlines loom, it's tempting to throw the plan away and "make up for lost time." Unfortunately just saying you'll work faster won't make it happen. Your project will be incomplete, buggy, late, or some combination of all three. If you make a realistic plan and stick to it, you can produce high-quality software on your schedule and not the whims of fate.

For developers I'd like to say, "Keep learning." The programming field has probably experienced the most prolonged period of intense change seen in any field in history and it's not likely to stop changing any time soon. There will always be new problems, new ways to think about old problems, and new hardware to exploit. It may not be necessary (or even possible) to keep up with every single development on a day-to-day basis, but you do need to constantly improve and expand your skills if you don't want to be left behind. Occasionally ask yourself, "What have I learned lately?"

Q: Rod, thank you for sharing your valuable insights with us today and we look forward to reading your books, and articles.

A: It was certainly interesting for me. Putting ideas like these into words always helps me think about them more clearly so I learn a lot, too. Perhaps that's one reason I enjoy being an author.