Fog Creek Software
Discussion Board




Reading Habits

In a past life, I was an electrical engineer.  I got bored with it and decided to start over in software a while back. 
I remember that the EE folks I used to work with would read a lot about stuff out on the horizon.  Most of the material was in professional journals and white papers and other things like that, very rarely in books.
The software folks I work with seem to read reactively.  They come across a problem at work and they go find something to read on it, often times big fat red books.  Is this more or less common across the software industry, or at least among this group?  How do you choose what you spend time reading?  Proactive or reactive?  Is it even possible to *be* proactive, in this industry?

e.e.ph.d
Sunday, March 09, 2003

I can't predict the future so I read what is interesting. I never read the big technology-of-the-day books or syntax books; they are manuals and just boring. I tend to go with the Programming Pearls and Code Complete types. Also, books I think would be good are self-marketing (aka power BSing).

Tony Little
Sunday, March 09, 2003

I have worked as a contract developer for more than 10 years and often I find myself working in fields where I know little about it, sometimes the technology used by my client can be something I've never encountered before, so yes, as you said most of my reading is definately reactive.

I need to know the subject matter and the technology to do it, probably only once in my lifetime, as more than likely my next jobs will be in different fields altogether.

I think the difference in reading habits is defined by whether or not you are a specialist or a generalist.

Realist
Sunday, March 09, 2003

I used to read a lot of software books, but when I go to the bookstore now, most of the computers books either for "dummies" or are too manual-ish to be interesting. I've read two non-manual-ish software books I've read recently that I really liked.

"The School of Niklaus Wirth: The Art of Simplicity" is a collection of papers by students of Niklaus Wirth (the creator of Pascal, Modula 2, and more).

http://www.amazon.com/exec/obidos/tg/detail/-/1558607234/103-8279428-4437441

"Patterns of Software" by Richard P. Gabriel (ol' time Lisp guru) discusses programming language design and abstractions.

http://www.amazon.com/exec/obidos/tg/detail/-/019510269X/103-8279428-4437441

runtime
Sunday, March 09, 2003

I find my reading defined by both the proactive and reactive labels, and the specialist and generalist labels.  The generalist reading is usually proactive, and the specialist reading is usually reactive.  I try to keep a good mix of both types, since I need the generalist stuff to work smarter not harder, but my work requires the down-in-the-trenches "gotcha" details that only the specialist books give.

ODN
Sunday, March 09, 2003

That's interesting, ODN.  It seems logically reversed to me.  Seems like you'd want to develop the specialist skills proactively, since you know in advance what area you want to specialize in, while the generalist skills seem to be more the kind of thing you'd try to pick up on an as-needed basis.  Is this common?

My own reading habits (for software) seem similar to what's been said so far.  I typically read proactively about the big picture, invariant kind of stuff and reactively about the implementation details.  Seems to be kind of hard to always be proactive since by it's nature, software is "soft."  When I was a E.E. most stuff got standardized relatively quickly since it's really the only way to get work done.  The reading was mostly about incremental improvements to these standards or new ways to combine the standards.

e.e.ph.d
Sunday, March 09, 2003

e.e.ph.d, I agree with your second paragraph.  That's what I meant by my last post.  I'm not sure how you reconcile your first paragraph with your second though.

The generalist books I like are along the lines of the books Tony Little mentioned: Programming Pearls, and Code Complete.  I also like another one of Steve McConnell's books, Rapid Development which isn't so much about "rapid" as it is about manageable development.  Anything that discusses the relatively timeless, technology-neutral aspects of software development are well worth being proactive about studying.

I think of this the way Stephen Covey describes in the 7 Habits of Highly Effective People.  You can look at everything you need to do as falling into a two-by-two matrix of urgency and importance.  The fat red books often fall into one of the two urgent categories.  The generalist books often fall into the not-urgent but important category.  The only way you're going to actually accomplish those things (he calls these Quandrant II tasks) is to be proactive about pursuing them, because otherwise the urgent things will prevent you from ever getting to the not-urgent but important things.

Back to e.e's comments, I haven't yet had the luxury of knowing in advance what areas I need to specialize in.  Maybe if I worked in a larger company with more clearly defined roles, I would have that luxury.  With the wide variety of technologies I've had to work with on very short notice, the only way I could mentally afford to learn them was on an as-needed basis.  Don't get me wrong, I love to learn new technologies, and am able to learn them quickly, but even then it's a constant challenge to maintain the balance between growing in the general-purpose skills and spreading myself too thin in the specialist skills.  Both are required to do my job, and pursuing one to the exclusion of the other would either make me a head-in-the-clouds architect-wanna-be or a head-in-the-sand code monkey.

ODN
Monday, March 10, 2003

Check out the last two posts from Bored Bystander on the "Specialization of developers good for a business?" thread for some excellent commentary on the dangers of pursuing specialization.

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=33106&ixReplies=19

ODN
Monday, March 10, 2003

Hi ODN,

Sorry, I misunderstood what you were saying.  I was thinking by generalist you meant sort of picking up general, everyday knowledge, like how to execute a query against a database in language X. I see now you mean material with general applicability,  technology neutral material, for example.  Sorry for the misunderstanding.

I think specialization can happen safely at a higher level.  For instance, I may specialize in developing scientific applications and maybe you specialize in business systems.  There's probably enough demand at that level to support a reasonable career and it seems like it happens naturally anyhow.  I don't know too many folks building backoffice software that are also devoting a lot of time to control systems.

Thanks for the insight and the clarification.

e.e.ph.d
Monday, March 10, 2003

Realist mentions reading up on the details of the market his software will be addressing.  Do others do this a lot?  If you were, perhaps, to get a job at say, General Electric, would you take the time to learn about their manufacturing processes?  Read up on how light bulbs work?  Do many folks spend time studying the business their products will be used in?

I work for a manufacturing company, and I think that a lot of my study time has been spent trying to understand what goes on down on the factory floor.  Probably at least as much time as I spend boning up on .NET or J2EE.  A lot of the folks I work with, though, are careful to avoid the shop floor.  How common is this?

e.e.ph.d
Monday, March 10, 2003

e.e, that's a good point about specialization at a higher level.  That's something I put a fair bit of thought into when making career decisions.  If a particular path doesn't fit with my chosen business area very well, I try to avoid it.  If a particular path offers deeper specialization that's already within my chosen business area, I'll take it as long as it doesn't look like a cul-de-sac.  It's important to me that my choice of depth areas demonstrates that I've chosen them wisely.

As for learning the details of the business the software addresses, I believe it can be very important, depending on where your software sits in the grander scheme of things.  If you're in one of the "generic" parts of the business like HR or financial stuff it's not as important.  But from my limited experience, I wish developers had spent more time trying to understand the users of the system before they built it, especially the blue-collar workers.  So often it seems like business developers work to move information up the food chain, with little thought given to giving back to the lowly blue-collar workers who are feeding information into the system in the first place.  I've seen systems that must seem like a black hole to the blue-collar worker, with no real incentives to enter quality information.  As a result, the data is next to useless except for hand-waving purposes.  Yet it gets funneled up to the "knowledge worker" white-collar decision-makers, sometimes passing through several "executive information system" type transformations, and they take it as the gospel truth of what's happening out in the field.  It's my firm belief that unless a system gives back something of value to all its users, the quality of information will suffer, to everyone's detriment.  This often means finding creative ways for information to flow down to the blue-collar workers as well as the more traditional funnel-up to the white-collar workers.

ODN
Monday, March 10, 2003

ee,

I'm also on the manufacturing side, writing production test apps, data management apps (Access, bTrieve) and some R&D apps as well.

I've found it very rewarding career-wise to pay close attention to the needs of the production floor and the production staff, and to create software that helps them get their job done easier and faster. I sit down with them at their job, discussing what they want, how the process works now and how they think it can be improved. In truth, I receive much better input from what some condescendingly label "blue-collar" types than I do from fellow "white-collar" engineers and managers.

Making the production staff happy results in them telling their supervisors about me, who then tell my boss about the job I'm doing. Win-win!

Further, when crunch time comes, companies need people that understand the production process and can get the product out the door. It's worked for me for 19+ years.

Mark Newman
Monday, March 10, 2003

*  Recent Topics

*  Fog Creek Home