For the better part of my career, I've straddled the fence between pure software development roles and consulting roles. My first job after graduating in 1997 was at a hardware firm developing embedded software for process control hardware. Over the three years I was working there, I was on point for everything from register-level device drivers running on the custom hardware to a device configuration GUI running on a PC. By the time I left the firm, I even had the opportunity to write a small programming language, complete with compiler and 'VM'. This was a perfect job for a guy with a freshly-minted Computer Science degree and a hankering to write some cool code. At least it was perfect at first.

What ultimately drove me to leave that role is something that I think most technical jobs, particularly those in product development, have in common: a severe risk of detachment from your clients. Software developers, myself included, tend to be an introverted lot; Even if they weren't, it's oftentimes percieved to be in the best interests of a software house to keep software developers on task developing software. In other words, there are both personal and corporate pressures to keep developers hacking away at the code instead of talking to customers. The risk here is that the people who best understand the products are the people that potentially least understand the customers. I can tell you from firsthand experience that, while I knew in detail the sampling characteristics of the device I was building, I had no idea how it might be used in a chemical plant to measure a temperature sensor and control a pump or a heater. It's easy to develop a product in that kind of vacuum and then get it totally wrong for your market. If you're not careful, it's also easy to get your product totally wrong for your own company, which is what arguably happened to the group I was in.

Organizations counter this risk of specialization by having other job roles that can be more focused on customer needs and less focused. From the perspective of someone sitting in an R&D lab, these other jobs represent the steps a product takes out the door towards doing useful work for a customer. A researcher discovers a new technology or technique, a developer turns it into a product, a marketer figures out how to promote it, a salesperson sells the product, and finally, a consultant integrates it into the customer's system. As work moves down this path, it gets progressively more applied and progressively less abstract. The reverse is true too: the further away from pure research you get, the closer you get to customer requirements. As much as a development lab has the responsibility to push product out to customers, customer-facing staff has the responsibilty to push information on customer requirements back to the lab to drive product development priorites. If a developer isn't talking to a customer and a consultant is, then it's a safe bet that the consultant has a better idea of what a product needs to do to sell.

This is the reasoning that led me out of pure software development and into a consulting role at a different firm. In this new role, I was on projects developing configuration websites for computer resellers. If you envision Dell's online computer configuration tool, you're not far off from the kind of websites I was developing. While consultants at this company still did a bit of programming, the theory was that the heavy lifting of actually building the software was done in the company's R&D lab. Consultants were to focus on more basic customization and integration work. On my projects, most of my software devlopment work was limited to customizing the layout of web pages and writing interfaces to databases and authentication providers. Interesting stuff, but not close to the same technical league as what I was doing in my previous job.

The risks in this kind of internal consulting role are different than the risks in a purely development role. Unlike a developer sitting in an R&D lab, someone who might get to see a customer once a month or two at best, a consultant quite often is working on-site with the customer on a daily basis. In fact, It's easy for a consultant to see customer staff far more often than other employees of their own company. Of course, this potential isolation also includes the R&D lab and the sales group. In the worst case scenario, you end up with three independant silos in your organization: sales selling whatever they want, developers developing whatever they want, and the poor consultants caught in the middle, between an over-ambitious contract and a under-done base product. I shared an office with a guy working on a project that was sold as a one month customization of one of our other base products. When I joined the firm, this project was in its 18th month of (mostly non-billable) consulting time. There was obviously a lot that had gone horribly wrong on that project, but foremost was a total disconnect between what the salespeople thought they had ready to sell and what the developers had actually produced to sell. (Not that the consultants were blameless on that project either: there were huge estimation and process problems in the customization work plan.)

I do not know of a role that is completely free of these types of risks, but my experience has tended to be that the difference between success and failure in any role is more related to communication with those around you than it is to technical skills. It is as much about giving your stakeholders what they want when they want it as it is anything else (including giving them something 'great'). This can be a difficult pill to swallow since it places emphasis on skills that do not come naturally to many developers. If you're a developer used to setting the development agenda it's even worse, since it might involve ceding at least some of this power to people downstream and closer to customers. However, if you're really good, you will do whatever it takes (even it it's 'not your job') to know your customer's business well enough to anticpate what they need before they request. Either way, success is ultimately about pressing your boundaries beyond your comfort zone to get what you need to do the thing you love in a way that satisfies those that care about your work.

I wrote this list of good software books a few years ago, in an effort to write down books that I've found to be interesting and/or useful. None of these books are of the 'X in Y days' variety, and very few qualify as reference books likely to be useful in your day to day work. That said, move of them will still make you a better developer.

Software Structure and Algorithms

• Code Complete: A Practical Handbook of Software Construction - Steve McConnell - This book is a classic reference on how code should be constructed, when working at the level of program statements and functions. While it does not cover some of the newer programming constructs or languages, this book should be considered essential reading for any working programmer.
• Programming Pearls, 2nd Edition - Jon Bentley - As the author puts in the preface, this book talks about the more glamourous aspects of programming. Culled from a series of articles in Communications of the ACM, Bentley presents a series of insights on solving common programming problems.
• The Art of Computer Programming, Vols. 1-3 - Donald Knuth - This is the series on the common algorithms used in software. Knuth presents, in gory detail, a series of algorithms and the mathematics on which they depend. You probably should not expect to read (or understand) everything that's here, but if you're in a bind, these books can be invaluable references. Robert Sedgewick also has an alternative that might be more accessible.
• Compilers: Principles, Techniques, and Tools - Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman - The definitive reference on compiler design. If you have to do anything with expression parsing, analysis, or translation this is a good introduction.

C and C++

• C Traps and Pitfalls - Andrew Koenig - C is a language notoriously full of little oddities that can make programmers' lives more difficult. This book documents a lot of them, explaining a little about why the language works the way it does. Reading it is a good way to help become a more seasoned user of C (and by implication C++). Expert C Programming by Peter van der Linden also appears quite good too, although I've not read it all the way through.
• The Design and Evolution of C++ - Bjarne Stroustrup - Ever wonder why C++ works the way it does? This book, documenting the history of C++ and C with Classes, talks a lot about the design decisions made while the language was being developed. It's a dry read at times, but understanding the intent of the designers of a tool can really help while using the tool.

• Advanced C++: Programming Styles and Idioms - James Coplien - In the C++ world, this book is old: It predates the ANSI standard, and many of the features introduced later on in the standardization effort (like STL). Despite that, Coplien describes techniques that give C++ programs a level of flexibility approaching that of languages like Lisp and Smalltalk. He covers garbage collection, multi-method dispatch, and replacment of code at runtime, among other techniques. If you need those capabilities, I'd reccomend another language. If you have to use C++, I'd reccomend this book.

Win32 Programming

• Win32 Programming - Brent Rector and Joseph Newcomer - This is one of the most detailed books on the core Win32 API I've ever seen. If you need to work with Win32, you need good documentation, and this is the book to get. Not only does it talk in great detail about API functions, it also talks about some of the differences between the various platforms extant in 1997. I can't reccomend it enough, but I do hope it gets updated to include Windows 2000 and XP.
• Windows++ - Paul DiLascia - First things first: this book is centered around Windows 3.1. While a lot has changed, a lot has stayed the same about the Windows API. Keeping that in mind, DiLascia's narrative through the process of encapsulating the Win16 API in C++ is a perfect example of how to manage the complexity of a difficult API using an object oriented programming environment. Even if you never write a Windows framework yourself, it's still good reading on the issues involved in both Windows programming and framework design in general.

Graphics and Visualization

• Computer Graphics: Principles and Practice in C - Foley, van Dam, Femer, Hughes - A good introduction to a wide variety of graphics algorithms and techniques. Serious work in the field will require more specialized books, however.
• The Visual Display of Quantitative Information - Edward R. Tufte - A good, and beautiful, discussion on how to graphically depict numerical information, and do so reliably and clearly.
• Practical Reusable Unix Software - Edited by Balachander Krishnamurthy - Not really a visualization or graphics book, except for the material covering the AT&T GraphViz (dotty and lefty) toolset. If you're programming with data structures more elaborate than lists, this tool can be an easy way to interpret data structures dumped to disk. With lefty, it's even possible to program specific user interfaces to edit graphical displays.

"Advanced" Languages

• Shared Source CLI Essentials - David Stutz, Ted Neward, and Geoff Shilling - This book is dense, but essential reading. With the two biggest emergent platforms (Java and .Net) depending on advanced runtime support, these more advanced runtime engines are now a fact of life. While this book focuses on the shared source implenentation of the .Net runtime, it is an excellent introduction to the ideas behind Java, .Net, and even languages like Smalltalk, Scheme, and Lisp.
• The Art of the Metaobject Protocol - Gregor Kiczales, Jim des Rivieres, and Danial G. Bobrow - This book documents something called the Metaobject-protocol as found in the object oriented part of some Common Lisp implementations. If you need to use metaobjects, it's of course a useful book, but it's also informative in general about the implementation of dynamic languages. I particularly liked the coverage on method dispatch and selection.

• Common Lisp: The Language, 2nd Edition - Guy Steele - While it's been superceded by the ANSI Hyperspec for Lisp, as a reference for Common Lisp, this is still a good reference to the language. For programmers in general, and particularly language implementors, this book is also full of good ideas on algorithms and software design.
• On Lisp - Paul Graham - Macros (code-rewrite rules) are one of the hardest things to understand in Common Lisp, and other similar languages. Graham goes into a lot of detail about how they can be used in real-world development, and includes a bunch of good examples. It is available free of charge online.

• Structure and Interpretation of Computer Programs - Harold Abelson, Gerald Jay Sussman, and Julie Sussman - This is one of those books that has the potential to seriously change the way you think. Written as a textbook for an introductory programming course at MIT, this book talks a lot about varying styles of computation and how they can be used.

Last October, I upgraded my Sony Ericcson T637 with a Cingular 2125 Smartphone. While the 2125 has since been discontinued, it's very closely related to the current Cingular 3125. The major differences between the two are that the 3125 has more memory and a different form factor; the 3125 is a flip phone rather, and the 2125 is 'candybar' style phone. Either phone has dramtically more capability than the t637.

When I bought the 2125, I had a couple main goals in mind for the upgrade. The first was e-mail integration with my employer's Microsoft based e-mail account. My second goal was to get mobile internet access for my laptops, meaning access to the web as well as to ssh and Windows remote desktop sessions. The 2125, priced at $100 with a subsidy and a rebate, was one of the cheapest ways to get at that set of features. It is a Windows Mobile 5.0 Smartphone, with a USB interface, 200MHz ARM9 class processor, 64MB RAM, QVGA display, and an EDGE network connection. Even at the time the specifications were not best in class, but it did provide the essentials, and the display was (is) gorgeous. By and large, the phone has done a good job of doing most of what I expected it to.

For me, the best aspect of the 2125 is its integration with Microsoft Outlook e-mail. Since my employer supports Microsoft's [Direct Push](http://www.microsoft.com/windowsmobile/articles/directpush.mspx) e-mail, the phone can be easily (five minutes or less) be configured to synchronize with my corporate e-mail account. Once the connection is configured, the phone maintains an active HTTP connection to the host Exchange server. As incoming e-mails arrive, the server immediately sends them back up to the phone via this connection. Once the phone receives a message, it does what you'd expect and adds them to a list, displays a notification icon on the home screen, and optionally vibrates or makes a noise. In short, it's almost idiot-proof to setup, and works exactly like every other form of text messaging on the phone. If you don't like the idea of continually being bombarded with incoming mails (or the idea of a continually open HTTP connection bothers you) the phone can be configured either to periodically poll for new mail or wait for an manual request to synchronize. Better still, there are seperate configuration options availble for user-definable 'on-peak' and 'off-peak' times. In my case, I generally leave the phone set to automatically accept incoming mails from 7:00AM to 7:00PM, and then manually synchronize otherwise.

For me, e-mail synchronization is the single best feature of the phone. I'd even go so far as to say that the jump to having mobile e-mail access has been as important a difference to me as the jump to having a mobile phone in the first place. While telephone connectivity is both immediate and universal, most of my important work-related communications happens over e-mail. Maybe it's just my job, but I get work related mails at least twenty to thirty times more often than I get work related phone calls. Not having mobile e-mail access basically means a choice between either being tied to a computer or entirely giving up access to that flow of information. In a sense, mobile e-mail access has been for me a liberating thing, a way to stay 'in the loop' but not stuck in front of a desk. The control the phone offers over its synchronization schedule then makes it easy to get 'out of the loop', assuming you have the self-discipline to not request manual synchronization too often. In practice, this has not been much of an issue for me to date. (I do not think my wife would disagree... most of the time.)

One of the pleasant suprises of the phone's e-mail features has been their integration into the other parts of the telephone. Like others, the e-mail client makes an effort to guess at 'important' content in a message: things like URL's and e-mail addresses, but also including phone numbers. Selecting a phone number in an e-mail message gives you the option to either dial the number or add it to your contact list. All of a sudden, all of those e-mail signature blocks containing phone numbers take on a whole new use. Phone number recognition also works with text messages, which pairs nicely with the part of AT&T's directory assistance service that sends text messages containing requested directory information. The phone can also use its connection to an Exchange server to provide access to the server's global phone directory. It's not integrated into the phone's standard address book and it requires an explicit search command, but that's probably a good thing considering the size of some corporate directories.

While the e-mail integration has been really useful, the other internet capabilities have been considerably less so. It is possible to tether the phone to a laptop. It is also possible to use that connection to access the web and ssh connections. However, between the fact that AT&T charges $60/month for the right to tether the phone to a laptop and the connection you then end up with is basically EDGE, it's really not as useful as I thought it'd be. For me, the low bandwidth of EDGE wasn't the problem, but the high latency was. While EDGE is two to three times faster than dial up, it takes on the order of 200-300 milliseconds for a packet to make a round trip. For interactive use of protocols like ssh, this means it can take half a second from the time you press a key on the keyboard to the time it appears in the terminal window. The net result is that an ssh session over EDGE is worse than how I remember 300 baud connections to BBS's. While I'll admit that my memory might be a bit cloudy, I can say this with certainty: despite the lower bandwidth, 56kbps dialup is far more usable than EDGE for this kind of application. More modern services like Sprint's EVDO network do not have this problem, and are probably closer to being worth $60/month. As things are now, I've dropped the $60/month tethering surcharge and stuck with a $20/month data plan that gives me unlimited data to the phone only. While I can still tether the phone to a laptop, this gives AT&T the theoretical right to charge me a per-byte amount for data the phone sends and receives when tethered to a laptop. While they do not seem to do this in practice, I confine my mobile internet access to the phone only. Thanks to the nicer display on the 2125, this is actually a usable way to read text-only web pages and blogs, which is an improvement over the Sony t637.

One other feature worth calling out on the 2125 is the fact that the directory and call history are both integrated into dialing. As you start dialing a number, the phone builds a list in real time of all matching contacts, by number and name, both in your phone book and in your call history. As the list is built, you can use the joystick to navigate through it, select a match, and either dial it or display its details. The only glitch in the logic is that the list presents matches from the call history with a higher priority than matches from the directory. If someone in your directory calls you and you miss the call, this means that the first entry in the list of matches will be the match from the missed call, and not the match from the directory. When you select the entry to see the details, what you'll see is the time the call was missed, and not the other numbers you have for that contact. If you want to call them back on a different number from the number from which they called you, this ends up adding a few steps to find the directory entry.

While a lot of the features I mention above stem from the fact that the phone runs Windows Mobile 5.0, this is not something I've really focused on in this post. I didn't care about the OS the T637 ran, and for the most part, it's been the same for this phone too. While it's theoretically possible to find all sorts of wonderful applications and games for Windows phones, I haven't found anything I can't live without, and neither AT&T nor Handango have done a good job helping me spend my money on mobile software. AT&T seems not to sell Windows Mobile software at all, and Handango makes you download a custom catalog application to see their software offerings for the phone; This catalog application did not work properly for the one application I tried to buy. I wish this situation was better, since I would be willing to at least buy a few games for the phone, and the one game I have installed right now, a clone of Scorched Earth, is good enough that it seems likely the platform could support some great applications and games. Even without games, this phone has been a nice upgrade, and it came at a reasonable price. Compare this with something like the iPhone, and it's hard to get all that excited about spending five times more money for a phone with no e-mail integration, the same lousy EDGE network, and even less opportunities for outside software.

I just saw this story on Oregon Trail over on Slashdot. I was born in 1975, which puts me in grade school in the early 1980's, the prime time for these early Apple ][ educational games. As much as I liked Oregon Trail, I liked Rocky's Boots even better. The basic premise of Rocky's Boots was that you had to use basic boolean logic circuits to build machines to solve particular tasks. You ran around a little maze using a very early 'point and click' style user interface to gather parts and put them together. Once you were done, you got to watch your creation do its thing. A fun little bit of trivia regarding Rocky's Boots is that it was developed by Warren Robinette, the creator of Atari 2600 Adventure, including the famous, ego-driven easter egg.