Functional programming isn’t exactly a fun topic anywhere outside of technical conferences and The Big Bang Theory. Even software engineers who love code often tune out when they hear terms like monad and referential transparency. But if you are a technical manager or executive, heads up. Functional programming will limit your technical debt so you build better software faster than you imagined and will earn you the Tesla you always wanted.
Anyone with a basic knowledge of Scrum, and certainly everyone who has taken Agile Software Project Management With Scrum, knows the role of the ScrumMaster–to be a servant leader, to act as guardian of the Scrum process, to remove obstacles for the delivery team, to negotiate any tension between the Product Owner and the delivery team, to encourage the team to self-organize and be cross-functional, and so on. These are so well understood they’re almost clichés.
At an event recently, someone was kind enough to introduce herself to me, and during the course of our pleasant conversation, she asked me, “So are you a programmer?” My first impulse was to acknowledge once again that I look really nerdy. I embrace that. But my second impulse was to be mildly offended. I wasn’t sure exactly why. As I have reflected a bit about that, I think my visceral reaction to being called a “programmer” arose from my perception of programmers as just people who write code, which is a science.
Please take a look at my latest column for Government Computing News where I discuss the strengths and weaknesses of relational databases and describe circumstances where document databases or graph databases may actually be a better fit. Just to give you an idea, here is the unedited introduction. One of my current projects is to review an application built by a contractor for a major federal government agency. The code relies heavily on queries and stored procedures against a relational database management system (RDBMS).