Re: [TUHS] earliest Unix roff

Larry McVoy writes: So I'm not really trying to be all that shameless, it's just that I've already written down my opinions on this sort of stuff and don't need to retype it all. There's an overarching question that you should keep in mind when working on a project: "Am I adding value?" I'm not talking about the intrinsic value of accomplishing some task here; I'm talking about increasing productivity. If you're programming for a living, you need to meet whatever goals your employer has set. But, of course, there's more than one way to meet those goals. You could just do what you need to do to get by. Or, you could put a little thought into things that might not have occurred to management. For example, you might realize that your code would be useful in another project and structure it so it's easily reusable. Or, you might sense that you were tasked to implement a special case of a more general problem and solve that general problem instead, paving the way for future enhancements. Of course, you should talk about this with management so that they're not surprised. You can add value to yourself by making sure that you're proficient in a variety of technologies. Side projects are a common way to get experience; it's equivalent to doing homework but more fun. One classic way in which people attempt to add value is by creating tools. This is trickier than it seems because sometimes adding value for yourself reduces value for others. People often create new tools because some feature that they think they need is missing from existing ones. A good example is the make utility (invented by Stuart Feldman at Bell Labs in 1976), which is used to build large software packages. As time went on, new features were needed. Some of these were added to make, but in many other cases, people created well-intentioned but incompatible new utilities that performed similar functions. (For example, I consulted for a company once that wrote their own solely because they didn't bother to completely read the make documentation and were unaware that it would do exactly what they needed.) Now there's make, cmake, dmake, imake, pick-a-letter-make, and other programs that all do similar things in incompatible ways. The result is that practitioners like you need to learn multiple tools in each category. It makes everyone's life harder, not easier. It doesn't add value—it detracts. Figure 15-1 sums up the situation nicely. [ Figure 15-1 is the xkcd how standards proliferate cartoon ]