Advertisement

Philosophy and Practice of Technical Leadership

  • J. Hank Rainwater

Abstract

As I discussed earlier, you may have been promoted to management because you’re a brilliant technical person. While technical skills don’t necessarily translate to management expertise, for the purposes of this chapter you’re sitting pretty. Much of what I talked about in previous chapters may have been new to you—the material in this chapter will more than likely not be. Of course, you still need to read this stuff; otherwise, I wouldn’t have included it! Also, you may appreciate the look at technical issues from your new perspective as technical leader. No longer are you just the “technical lead” on a team, you’re the leader with a capital “L” for the whole department. When choices have to be made, you’re the one in the hot seat. In addition, you’ll have to live with the longterm consequences of your choices upon the software you’re responsible for building, so making the best choices is of paramount importance.

Keywords

Software Development Code Police Roller Coaster Code Review Capability Maturity Model 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    Andrew Hunt and David Thomas, The Pragmatic Programmer ( NewYork: Addison-Wesley, 2000 ), p. 184.Google Scholar
  2. 2.
    See works by the authors of the pattern and antipattern movement, such as Brown and others who are referenced in the Bibliography.Google Scholar
  3. 3.
    Marc T. Sewell and Laura M. Sewell, The Software Architect’s Profession ( Upper Saddle River, NJ: Prentice Hall, 2002 ), p. 68.Google Scholar
  4. 4.
    Raphael C. Malveau and Thomas Mowbray, Software Architect Bootcamp ( Upper Saddle River, NJ: Prentice Hall, 2001 ).Google Scholar
  5. 5.
    Notice how easy it is to slip back into old ways of thinking. If I had said “chrw(133)older technologies are used for plantingchrw(133)” would you have known what I was talking about?Google Scholar
  6. 6.
    See how well the organic metaphor works!Google Scholar
  7. 7.
    I’ve been using VB since version 1.0, so don’t think I’m prejudiced against VB. For those who need help with VB-related architectural and design issues, see Billy S. Hollis, Visual Basic 6 Design, Specification and Objects ( Upper Saddle River, NJ: Prentice Hall, 1999 ).Google Scholar
  8. 8.
    Stuart Kauffman, At Home in the Universe ( NewYork: Oxford University Press, 1995 ), p. 179.Google Scholar
  9. 9.
    James A. Highsmith III, Adaptive Software Development ( New York: Dorset House Publishing, 2000 ), p. 40.Google Scholar
  10. 10.
    Programming standards“ are two words that speak volumes. They range from how to build a good procedure to insisting on only one exit point from a subroutine. The list could go on and on. My main point is this: Have standards and live by them.Google Scholar
  11. 11.
    A nightmare for a programmer is to be awake all night fixing your code because you changed one thing in one object and it broke three other things in several other objects.Google Scholar
  12. 12.
    T.S. Elliot, Collected Poems 1909–1962 ( NewYork: Harcourt Brace Jovanovich, 1971 ), p. 82.Google Scholar
  13. 13.
    See Humphrey, op. cit., p. 5, or The Software Engineering Institute’s Capability Maturity Model for examples.Google Scholar
  14. 14.
    Capers Jones, Applied Software Measurement ( NewYork: McGraw-Hill, 1991 ), p. 1.MATHGoogle Scholar
  15. 15.
    Adrienne Rich, “Cartographies of Silence” from The Dream of a Common Language ( New York: W.W. Norton, 1978 ), p. 17.Google Scholar
  16. 16.
    For VBers I recommend James D. Foxall, Practical Standards for Microsoft Visual Basic (Redmond, WA: Microsoft Press, 2000). For other languages, you have many resources from which to choose, including the following “classic” for C: Steve Maguire, Writing Solid Code (Redmond, WA: Microsoft Press, 1993 ). See the Bibliography for more listings.Google Scholar
  17. 17.
    See Hunt and Thomas, op. cit., for a great metaphor related to software entropy called “Don’t Live with Broken Wmdows.” I’m trying to persuade you here to buy their book—it’s one of the good ones.Google Scholar
  18. 18.
    Guess what, I did read this self-help book. Michael J. Gelb, How to Think Like Leonardo da Vinci ( New York: Dell Publishing, 1998 ), p. 9.Google Scholar
  19. 19.
    See the excellent book on the unfolding of the power of ambition. James Champy and Nitin Nohria, The Arc of Ambition ( New York: Perseus Books, 2000 ).Google Scholar
  20. 20.
    I guess it is a good marketing ploy, because I bought them.Google Scholar

Copyright information

© J. Hank Rainwater 2002

Authors and Affiliations

  • J. Hank Rainwater

There are no affiliations available

Personalised recommendations