It’s always a pleasure to meet practitioner authors, in part because they have such varied backgrounds. What is surprising is how despite that, the unusual things they have in common. Two of the ContentLab IO authors started in accounting, one moved to programming by chance, the other by intention.
Introducing David Gray, whose strategy was to understand the language of business (money flow) first, and then the programming skills to create the platforms to facilitate how companies do business. He’s experienced business workflows before and after the explosion of APIs, serverless, and devops. He brings his wealth of experience to new tools, and he finds that it serves him well. His career as a developer and writer demonstrates the fallacy of the bias in the programming world against the older developer. He’s a great example of “been there, will do that.”
Meet the Person Behind the Keyboard
Tell me about yourself. Where did you grow up, where do you live, where do you work, and what is your role?
I grew up in a smallish town in Alabama, apart from the 2 ½ years during which I lived in El Paso, Texas.
When I finished studying for my MBA at The University of Alabama, I moved to the Dallas/Fort Worth area, which I had visited from time to time as a child, since we had close relatives who lived here.
Since 1979, I’ve worked for a variety of companies, all in the Dallas-Fort Worth area. Until 1985, I worked as an employee for several companies in the financial institution arena, the last being a company that sold software to such institutions. In 1985, I took the crazy step of launching an independent consultancy, turning my attention to the new IBM Personal Computer. Until 2015, I worked for clients of various sizes, from one-person companies to huge companies along the lines of Johnson & Johnson, a unit of the Trammell Crow Companies, and a unit of Chevron called Caltex Petroleum Corporation. Beginning in 2015, I began working largely through other agencies for the same general types of clients I had previously served directly.
My specialties include:
- Design: Relational database design, focusing on reporting; organization and presentation of large document collections such as MSDS libraries
- Development: Powerful, imaginative utility programs and scripts for automated systems management and maintenance.
- Industries: Property management, Employee Health and Safety, Services.
What got you interested in your technical career?
My first exposure to electronic computers happened in my sophomore year of high school. That led me to the conclusion that there were the programmers of those computers and the people who needed them programmed, neither group of which spoke the other group’s language. Early in college, I was determined to become a translator. Since the most important knowledge was the subject matter of the work to be programmed, I earned my undergraduate degree in accounting, and worked as an accountant until I went back to graduate school.
Why did you start writing about your work?
In academia, there is a saying that you must publish or perish. In the consulting world, it’s more like publish and prosper. Besides that, it fulfills my desire to educate others, so that the lessons I’ve learned outlive me and benefit others that would otherwise be beyond my reach.
What attracted you to writing for ContentLab IO?
Though I never expect to get rich from writing articles, I anticipate that the increased visibility may enable me to secure more and better work to keep me going until I quit working, which I hope is about the same time that I stop breathing.
What positive changes in your professional or personal life have you seen since you started writing about programming/IT work?
When I was consulting, people would occasionally comment about something of mine that they read, and some of that writing indirectly led to client engagements and speaking opportunities that, themselves, led to paying work.
What written work are you most proud of?
The Gray Report Design and Layout Conventions. It’s actually available on SlideShare.
What technical achievement are you most proud of?
Three things come to mind.
- In 1990, I devised a promotion pricing model for a self-storage company that has stood the test of almost 3 decades during which the market changed very significantly. It remained in use, virtually unchanged, until the application was retired last year.
- For the same client, I designed and implemented a vendor-agnostic application interface that supports two-way communication between hardware supplied by 3 vendors whose designs were very dissimilar.
- Over my career, I’ve designed and implemented numerous concepts to which I never gave names. Others came along years later, put forth the same ideas, and raked in millions for showing other people how to use them. Among them are the following.
- Stack traces
- Continuous software integration and delivery
- Mocking frameworks
- Unit testing frameworks
What interests you about client writing projects?
I get to explore more deeply the things that interest me, and from time to time, I get to play with new hardware.
What challenges have you encountered in technical writing that surprised you?
Though I won’t say that it came as a surprise, I was dismayed at the scarcity of information about the other libraries that I had to find and convert in order to complete a well-established, commonly used code library.
How did you overcome them?
What words of wisdom would you like to share with other prospective technical authors?
- Set aside ample time to review and rewrite.
- Your editor is your friend. Clearly explain and illustrate concepts that may be new to your audience.
- If doing so would exceed the desired length of the article, include references to well-written explanations, preferably from well-regarded authorities.
- Protect your intellectual property; you aren’t expected to give away your trade secrets.
What words of wisdom would you like to share with prospective clients about the content creation process?
- When the project requires a program to be written, be prepared for the fact that even an experienced programmer can underestimate the level of effort.
- When you send a writer a demonstrator for his use, be sure that you either have the master password, or that you provide clear instructions on how to reset the operating system.
Is there anything I didn’t ask you that you’d like to share with our audience?
There is a good reason that the fifth of the Ten Commandments is “honor thy father and thy mother.” That implies that you should respect your elders, and avail yourself of every opportunity to learn from them.
Is that metaphorical “elders” as in those that have gone before you, have more experience, or literal “elders?”
It’s really both. Yes, there are people who are your metaphorical elders because they simply know more about how to do something than you do. And, you should respect that knowledge and learn from them. But there also are people who know how to do more things because they are literally older than you. They may be faster at adopting a tool, because they know the history behind a tool and are not doomed to repeat its mistakes. There’s a bias in the software industry against age, and it really shouldn’t be there. Age can mean experience, and experience can make all the difference, especially with a new tool or approach.
For the Road
Improving as a writer and a programmer means leaning on and learning from others. It could be an editor, it could be the CodeProject or other developer-to-developer community, or it could be a practitioner author like David. That willingness to put bias aside and learn from developers regardless of “image” can be a competitive edge. And, having a workflow-first view to programming is a key takeaway to approaching programming tools to improve business applications. It has worked for David, and it can work for you.