As part of my Baker's Dozen Productivity Series articles in CoDe Magazine, I've sometimes written editorial/opinion pieces. In true Baker's Dozen form, each opinion article contained 13 items. Sometimes they followed a theme, and sometimes they just represented 13 random opinions on different aspects of our industry.
Going forward, I'm going to post these opinion pieces here on my blog. If anyone wants to view prior "Baker's Dozen of Reflection" articles (which I'll refer to as BDR from now on), here are the links. Some of the items are a bit dated, but most of the opinions I've expressed still have some relevance today.
Article Link | Article Issue |
Sep/Oct 2011 issue (special editorial on leadership | |
Jul/Aug 2008 issue | |
Jul/Aug 2007 | |
Nov/Dec 2006 |
So what's on my mind today? Well, at least 13 items! Two summers ago, I wrote a draft BDR that focused (in part) on the role of education and the value of a good liberal arts background – not just for the software industry but even for other industries as well. One of the themes of this particular BDR emphasized a pivotal and enlightened viewpoint from renowned software architect Allen Holub regarding liberal arts.
I'll (faithfully) paraphrase his message: he highlighted the parallels between programming and studying history, by reminding everyone that history is reading and writing (and I'll add, identifying patterns), and software development is also reading and writing (and again, identifying patterns). And so I wrote an opinion piece that focused on this and other related topics.
But until today, I never got around to either publishing/posting it. Every so often I'd think of revising it, and I'd even sit down for a few minutes and make some adjustments to it. But then "life in general" would get in the way and I'd never finish it. So what changed?
A few weeks ago, fellow CoDe Magazine columnist and industry leader Ted Neward wrote a piece in his regular column, "Managed Coder", that caught my attention. The title of the article is On Liberal Arts, and I highly recommend that everyone read it.
Ted discusses the value of a liberal arts background, the false dichotomy between a liberal arts background and success in software development, and the need to write/communicate well. He talks about some of his own past encounters with HR personnel management regarding his educational background.
He also emphasizes the need to accept and adapt to changes in our industry, as well as the hallmarks of a successful software professional (being reliable, planning ahead, and learning to get past initial conflict with other team members).
So it's a great read, as are Ted's other CoDe articles and blog entries. It also got me back to thinking about my views on this (and other topics) as well, and finally motivated me to finish my own editorial. So, better late than never, here are my current Baker's Dozen of Reflections:
- I have a saying: Water freezes at 32 degrees. If you're in a training/mentoring role, you might think you're doing everything in the world to help someone – when in fact, they're only feeling a temperature of 34 degrees and therefore things aren't solidifying for them. Sometimes it takes just a little bit more effort or another idea/chemical catalyst or a new perspective – which means those with prior education can draw on different sources. Water freezes at 32 degrees.
- Some people can maintain high levels of concentration even with a room full of noisy people. I'm not one of them – occasionally I need some privacy to think through a critical issue. Some people describe this as "you gotta learn to walk away from it". Stated another way, it's a search for the rarefied air.
This past week I spent hours in half-lit, quiet room with a whiteboard, until I fully understood a problem. It was only then that I could go talk with other developers about a solution. The message here isn't to preach how you should go about your business of solving problems – but rather for everyone to know their strengths and what works, and use them to your advantage as much as possible.
- Some phrases are like fingernails on a chalkboard for me. "Use it as a teaching moment" is one. (Why is it like fingernails on a chalkboard? Because if you're in a mentoring role, you should usually be in teaching moment mode anyway, however subtly).
Here's another – "I can't really explain it in words, but I understand it". This might sound a bit cold, but if a person truly can't explain something in words, maybe they don't understand. Sure, a person can have a fuzzy sense of how something works – I can bluff my way through describing how a digital camera works – but the truth is that I don't really understand it all that well.
There is a field of study known as epistemology (the study of knowledge). One of the fundamental bases of understanding – whether it's a camera or a design pattern - is the ability to establish context, to identify the chain of related events, the attributes of any components along the way, etc. Yes, understanding is sometimes very hard work, but diving into a topic and breaking it apart is worth the effort. Even those who eschew certification will acknowledge that the process of studying for certification tests will help to fill gaps in knowledge. A database manager is more likely to hire a database developer who can speak extemporaneously (and effortlessly) about transaction isolation levels and triggers, as opposed to someone who "sort of" knows about it but struggles to describe their usage.
There's another corollary here. Ted Neward recommends that developers take up public speaking, blogging, etc. I agree 100%. The process of public speaking and blogging will practically force you to start thinking about topics and breaking down definitions that you might have otherwise taken for granted. A few years ago I thought I understood the T-SQL MERGE statement pretty well. But only after writing about it, speaking about, fielding questions from others who had perspectives that never occurred to me – that my level of understanding increased exponentially.
I know a story of a hiring manager who once interviewed an author/developer for a contract position. The hiring manager was contemptuous of publications in general, and barked at the applicant, "So, if you're going to work here, would you rather be writing books or writing code?" Yes, I'll grant that in any industry there will be a few pure academics. But what the hiring manager missed was the opportunities for strengthening and sharpening skill sets.
- While cleaning out an old box of books, I came across a treasure from the 1980's: Programmers at Work, which contains interviews with a very young Bill Gates, Ray Ozzie, and other well-known names. Every interview and every insight is worth the price of the book. In my view, the most interesting interview was with Butler Lampson, who gave some powerful advice. "To hell with computer literacy. It's absolutely ridiculous. Study mathematics. Learn to think. Read. Write. These things are of more enduring value. Learn how to prove theorems: A lot of evidence has accumulated over the centuries that suggests this skill is transferable to many other things."
Butler speaks the truth. I'll add to that point – learn how to play devil's advocate against yourself. The more you can reality-check your own processes and work, the better off you'll be.
- The great computer scientist/author Allen Holub made the connection between software development and the liberal arts – specifically, the subject of history. Here was his point: what is history? Reading and writing. What is software development? Among other things, reading and writing. I used to give my students T-SQL essay questions as practice tests. One student joked that I acted more like a law professor. Well, just like Coach Donny Haskins said in the movie "Glory Road", my way is hard. I firmly believe in a strong intellectual foundation for any profession. Just like applications can benefit from frameworks, individuals and their thought processes can benefit from human frameworks as well. That's the fundamental basis of scholarship.
There is a story that back in the 1970's, IBM expanded their recruiting efforts in the major universities by focusing on the best and brightest of liberal arts graduates. Even then they recognized that the best readers and writers might someday become strong programmer/systems analysts. (Feel free to use that story to any HR-type who insists that a candidate must have a computer science degree!)
And speaking of history: if for no other reason, it's important to remember the history of product releases – if I'm doing work at a client site that's still using SQL Server 2008 or even (gasp) SQL Server 2005, I have to remember what features were implemented in the versions over time. - Ever have a favorite doctor whom you liked because he/she explained things in plain English, gave you the straight truth, and earned your trust to operate on you? Those are mad skills, and are the result of experience and HARD WORK that take years and even decades to cultivate. There are no guarantees of job success – focus on the facts, take a few calculated risks when you're sure you can see your way to the finish line, let the chips fall where they may, and never lose sight of being just like that "doctor" who earned your trust. Even though some days I fall short, I try to treat my client and their data as a doctor would treat patients. Even though a doctor makes more money!
- There are many clichés I detest – but here's one I don't hate: "There is no such thing as a bad question". As a former instructor, one thing that drew my ire was hearing someone criticize another person for asking a supposedly, "stupid question". A question indicates a person acknowledges they have some gap in knowledge they're looking to fill. Yes, some questions are better worded than others, and some questions require additional "framing" before they can be answered. But the journey from forming a question to an answer is likely to generate an active mental process in others. There are all GOOD things. Many good and fruitful discussions originate with a "stupid question".
- I work across the board in SSIS, SSAS, SSRS, MDX, PPS, SharePoint, Power BI, DAX – all the tools in the Microsoft BI stack. I still write some .NET code from time to time. But guess what I still spend so much time doing – writing T-SQL code to profile data as part of the "discovery" process. All application developers should have good T-SQL chops.
- Ted Neward writes (correctly) about the need to adapt to technology changes. I'll add to that – the need to adapt to client/employer changes. Companies change business rules. Companies acquire other companies (or become the target of an acquisition). Companies make mistakes in communicating business requirements and specifications. Yes, we can sometimes play a role in helping to manage those changes – and sometimes we're "the fly, not the windshield".
These sometimes cause great pain for everyone, especially the I.T. people. This is why the term "fact of life" exists – we have to deal with it. Just like no developer writes bug-free code every time, no I.T. person deals well with change every single time. One of the biggest struggles I've had in my 28 years in this industry is showing patience and restraint when changes are flying from many different directions. Here is where my prior suggestion about searching for the "rarified air" can help. If you can manage to assimilate changes into your thought process, and without feeling overwhelmed, odds are you'll be a significant asset.
In the last 15 months I've had to deal with a huge amount of professional change. It's been very difficult at times, but I've resolved that "change will be the norm" and I've tried to tweak my own habits as best I can to cope with frequent (and uncertain) change. It's hard, very hard. But as coach Jimmy Duggan said in the movie A League of Their Own: "Of course it's hard. If it wasn't hard, everyone would do it. The hard, is what makes it great". A powerful message. - There's been talk in the industry over the last few years about conduct at professional conferences (and conduct in the industry as a whole). Many respected writers have written very good editorials on the topic. Here's my input, for what it's worth. It's a message to those individuals who have chosen to behave badly: "Dude, it shouldn't be that hard to behave like an adult".
A few years ago, CoDe Magazine Chief Editor Rod Paddock made some great points in an editorial about Codes of Conduct at conferences. It's definitely unfortunate to have to remind people of what they should expect out of themselves.
But the problems go deeper. A few years ago I sat on a five-person panel (3 women, 2 men) at a community event on Women in Technology. The other male stated that men succeed in this industry because the "Y" chromosome gives men an advantage in areas of performance. The individual who made these remarks is a highly respected technology expert, and not some bozo making dongle remarks at a conference or sponsoring a programming contest where first prize is a date with a bikini model.
- Our world is becoming increasingly polarized (just watch the news for five minutes), sadly with emotion often winning over reason. Even in our industry, recently I heard someone in a position of responsibility bash software tool XYZ based on a ridiculous premise – and then give false praise to a competing tool.
So many opinions, so many arguments, but here's the key: before taking a stand, do your homework and get the facts. Sometimes both sides are partly right…or wrong. There's only one way to determine: get the facts. As Robert Heinlein wrote, "Facts are your single clue – get the facts!" Of course, once you get the facts, the next step is to express them in a meaningful and even compelling way. There's nothing wrong with using some emotion in an intellectual debate – but it IS wrong to replace an intellectual debate with emotion and false agenda.
A while back I faced resistance to SQL Server Analysis Services from someone who claimed the tool couldn't do feature "XYZ". The specifics of "XYZ" don't matter here. I spent about two hours that evening working up a demo to cogently demonstrate the original claim was false. In that example, it worked. I can't swear it will always work, but to me that's the only way. - I'm old enough to remember life at a teen in the 1970's. Back then, when a person lost his/her job, (often) it was because the person just wasn't cutting the mustard. Fast-forward to today: a sad fact of life is that even talented people are now losing their jobs because of the changing economic conditions.
There's never a full-proof method for immunity, but now more than ever it's critical to provide a high level of what I call the "Three Vs" (value, versatility, and velocity) for your employer/clients. I might not always like working weekends or very late at night to do the proverbial "work of two people" – but then I remember there are folks out there who would give anything to be working at 1 AM at night to feed their families and pay their bills. - Always be yourself…your BEST self. Some people need inspiration from time to time. Here's mine: the great sports movie, Glory Road. If you've never watched it, and even if you're not a sports fan I can almost guarantee you'll be moved like never before.
And I'll close with this. If you need some major motivation, I'll refer to a story from 2006. Jason McElwain, a high school student with autism, came off the bench to score twenty points in a high school basketball game in Rochester New York. Here's a great YouTube video.
His mother said it all: "This is the first moment Jason has ever succeeded and is proud of himself. I look at autism as the Berlin Wall. He cracked it."