Do you find yourself debating about specs and architecture more than you actually write code? Do you find yourself trying to force colleagues to use the Unified Modeling Language (UML) even when you’re not a manager? Do you blog about functional programming whereas you used to blog about OO? Do you love patterns and long discussions about architecture (even with your wife or girlfriend who couldn’t care less)?
Now functional is the boooomb — you say to yourself. You say, “Scala will kill Java. Just wait.” Or you say, “Haskell is ready for prime time and should replace C very soon.” Do you find yourself quoting fancy, slick east coast software management consultants?
If some of those ring true about you, then you might not be a pragmatic programmer. First, about the consultants…a lot of these consultants come out of Carnegie Mellon University (CMU) and the Carnegie Mellon Institute think tank — sponsored, in large part, by Uncle Sam.
My MS degree was modeled after the Carnegie Mellon University (CMU) MS program in software engineering. In fact, I’m certified in something called Personal Software Process (PSP) from CMU (and a former employer/sponsor). Most of these consultants spend their time darting around the world presenting at conferences and staying at five-star hotels. They enjoy telling us peons how it is and how stupid we are.
They want us to believe without their guidance we would be like a ship without a rudder. Yeah right. They come armed with their fancy slide deck. The truth is they are giving upper management the opium fix they need. See upper management pays these big wigs to come in and solve all their problems — they hope.
The software industry went from no process hardly to speak of (ad hoc or little more) to the very rigorous processes (think Capability Maturity Model Integration — CMMI).
The CMMI is popular in regulated industries such as defense, aerospace, bio-med, etc.
A pragmatic programmer is trying to delight customers and please his boss. He doesn’t have time to fill out 20 checklists and have an audit every other week. He needs to focus on adding features and supporting the paying customer base.
OK. Listen, like I said, I have a master’s in software engineering, so I know what I’m talking about — just trust me (ha ha)! Most of these consultants come out of such programs and think they know something. You learn how to write software and manage teams by spending years in the trenches, not just getting some sheepskin.
They get published and speak at conferences because they have the creds and have something to say. Both generally good things. However, it is a one-sided debate. I recall one such conference I attended where the speaker described how to use the Kalman filter to improve on your software process (become more optimal) by using your software metrics data. Are you kidding me? Too impractical. Give me a break.
Let’s switch gears and talk books. I highly recommend Steve McConnell’s writings. His book Code Complete is a must for practitioners. I studied from it at a lunchtime study group at a former employer.
I recommend you or your team do the same. Each week, someone would lead the discussion, and we would all interject our thoughts — while eating our chimichangas that we got from the chow line. See, our manager gave everyone a free cafeteria lunch pass if we attended. We also got the book for free, too.
So consider reading Code Complete if you haven’t. Form a lunchtime study group. That would be a great way to take some leadership on your team. You don’t need a leadership title to start leading.
Most leaders start leading before the title even came about. Another book to consider is the book titled The Pragmatic Programmer. It’s also a bit old but well respected. So don’t stop reading about architectures, software processes and learning the newfangled languages, but keep it real. Be a pragmatic programmer. (For those wondering, it’s called an alliteration — the word choice, that is.)
Lastly, just to be clear, I consider Code Complete to be the most seminal book on software engineering for real practitioners — no over-the-top academic silliness. It’s all about the nuts and bolts of being a pragmatic programmer.