Creative Thinkers versus Critical Coders

Skip navigation

Creative Thinkers versus Critical Coders

Creative Thinkers versus Critical Coders by David Kuhn

Insurance: The New History

History, as we all know, is written by the victor. Winning means you get to tell your side of the story and have it live on through time as the facts as they accurately happened. How the simple passage of time elevates one person’s perspective to the absolute truth I’ll never know, but that’s how it is. In order to be history, you have to make history.

I’m going to venture into the world of insurance and tackle history with a more agile approach. In this new blog series, “Insurance: The New History” we’ll take a dive into the things happening in insurance and around insurance now, or things that I think will be a major player in the industry very soon. This is my perspective on the what, the why, and the how of history-making tech in insurance.

These articles should serve as an innovation jumpstarter or, better yet, get companies to think “let’s try something different” instead of “this is the way we’ve always done it; this is the way we’ll keep doing it.”

I’m hoping this helps people in insurance be the victor, the historian of record for their own stories.

Be the disruptors, not the disrupted.

Stop giving the blue ribbon to one-trick ponies

There is nothing more frustrating than when I hear people say, “Mr. X is our best engineer, he really knows everything about .NET!” Two important things to remember – knowledge isn’t wisdom and exclusive, intense expertise in one subject can be limiting. What if the company decided to change everything over to Java, Ruby, React, or even a low-code platform like Mendix?

What you really have in that employee is an SME, not “the best engineer.” In the case of Mr. X, you have a person who probably has a lot of experience in their favorite language. They will use this language for everything. While they do leverage their skills to deliver results, they often create more complexity than was needed for any particular project just to show off their development prowess.

They will evangelize how their ideas are spot on and everyone else is just way off. More than anything, they will tell you that any technology that goes against their “stack” is the reason the team can’t move as efficiently as they should. The rest of the team gets pushed to the back and Mr. X is typically seen as a “leader” and is modeled when looking for new talent.

Mr. X’s outlook is “there’s one right way, one good way, and it’s my way.” Now, the Mr. X’s of the world are often impressively proficient and have delivered on some big projects, but their narrow-minded and hyper-focused mentality is an innovation killer and hiring more people just like him is a fast track to massive IT failure.

Code as Craft

Code is beautiful! The ability for someone to make a machine bow to their will is something that will always amaze me. For a huge part of my career, I developed software. I mean that I literally would sit down and write lines and lines of code. I helped create frameworks that are used around the world to communicate data. I have my hands all over code that helps determine mission-critical operations for manufacturers and world governments. For me, there’s nothing better than putting hands on a keyboard and solving a coding problem.

When I moved into architecture, I wasn’t painting that coded canvas anymore, instead, I was the innovative muse. Seeing other coders take my ideas and turn them into lines after line of incredible code was so personally fulfilling.

I pursued writing code because it fascinated me. I pushed myself to learn more and expand my skill set because I liked the challenge. Coding was something I loved (still do) and it was something I made sure I was good at. I could very easily have turned into Mr. X and decided that there was one – and only one – right way to do things. But there was one truth I learned early in my career that vastly changed my outlook on how I work. And that one thing stuck with me forever. My personal satisfaction meant nothing to the company. Let me phrase that differently for those in the back, louder and prouder…the company doesn’t care how beautiful the code is.

What does the company care about? Getting it done. And getting it done well.

There is a reason that insurance companies moved away from writing assembly language a long time ago (or at least tried to). It was slow and prone to defects.

When I realized what the company truly cared about, it was a slap in the face. How could they NOT want me to write beautiful code? Why would I spend all of my time learning the intricacies of new parts of the languages coming out? How were they going to review my code and measure me when code reviews are done by talented people who have a deep understanding of the language of choice?

The answer to all of these questions is that, in the broad scheme of things, none of those matter to the company. They just don’t.

Code as craft is a great mentality for writing beautiful code, figuring out how to minimize the memory footprint on the hardware, creating reusable code that anyone can use anywhere, but does that stuff matter?

Hardware space is no longer an issue. Newer languages have the ability to stop memory problems from happening and clean up memory issues before they happen. And reuse is overrated. In the amazing movie “Field of Dreams”, they say “build it and they will come”. That’s just not how software works. What I learned is that if I create everything as a reusable component, the solution takes 10-100 times longer.

I had to change my mindset to learn that code shouldn’t be my craft, but a means to an end. A way to solve a problem. And solving that problem beautifully doesn’t really matter. People using the applications I built – and you are building – give no thought to how pristine it is or how many reusable components it contains. They just want it to work. Companies aren’t wowed by first-class coding. They are impressed when big, costly problems are solved quickly and completely.

Programmer, Coder, Developer, Engineer….oh my

Over the last 50 years, technology has changed drastically. So have the degrees, certifications, and diplomas needed to work in an IT department for an insurance company.

The talent you have that works on creating and modifying software can be called many things: programmer, coder, developer, ninja, etc. What those individuals can accomplish within their skillsets is astonishing. The problem is that the majority of them lack the ability to solve actual problems. They are presented with a request, they code a solution that meets the demands of that request. The reason Software Engineering was created, in my opinion, is to apply the problem-solving rigor that an engineer brings to the software world. Engineering is a complex science, but just like every doctor learns all of the basics and then specializes, all engineers learn proper engineering processes.

Put the titles aside, our world is more complex than ever. There are hundreds of systems and applications that run an insurance company. There isn’t one way to solve a problem, software engineering and computer science are one-part science and three-parts art. Someone who is driven and defined only by the quality of code they can produce is very, very good at one thing. They can solve problems, but they only solve them one way. You need employees that can step back, examine the problem, and solve it with the best tools available to them. You need people who can think and execute creatively.

You need farmers.

Farmers are the best problem solvers

One of my many hobbies is farming. I have a small sheep farm and harvest quite a bit of hay. I use the hay for my sheep, but it’s also a way of making more money on the side. Farmers typically don’t make much money, unless you are a very large farm. With limited funds, they have to get creative.

People might think that farmers are not very intelligent because the majority never went to college and a lot barely graduated from high school. But what I can tell you is that farming is hard and requires either a massive, almost limitless operating budget, or a level of ingenuity and problem solving that I haven’t seen anywhere else in my travels.

The newest piece of equipment I have is my tractor, and it is only 32 years young. When they say that they don’t make things like they used to, they are correct. In farming, it is normal to see equipment that is 70-80 years old still running strong. There is one major problem with this, the availability of parts.

There is an old saying, “make hay while the sun shines,” often shortened to “make hay.” Meaning that you need to make good use of an opportunity while it lasts. While the internet has made it easier to source parts for older equipment, you still have to wait for those parts to get to you and with farming, you have to work when you can. Rain causes all kinds of chaos with farming and harvesting, and Mother Nature doesn’t really give a damn about the availability of reliable ground shipping to rural areas. If something breaks on that tractor while I’m bringing in the hay, I need to figure out a way to make it work immediately.

In farming, just like in IT, a storm is always brewing. Farmers have to think – and act – quickly to avoid disaster, knowing that whatever fix they come up with doesn’t need to last forever, it just needs to hold until that new part comes in. Farmers don’t think “what the most perfect and ideal way to fix this broken axel, what is a way to fix this axel that will astound my peers?” They think “what the quickest, best option I have available to me right now?”

The insurance industry is no different than a farmer’s life. As an industry, we need to make hay. There are a lot of startups challenging the insurance world and even scarier, large companies trying to get into the market. I hear constant excuses for why insurance companies can’t move quickly. I think it’s because they are still “waiting for parts,” The dynamic that I still don’t understand is that farmers, by schooling background, are way less qualified to fix critical components on machinery that could kill someone…but in insurance, we require computer science and software engineering degrees at a premium and the majority focus on code as craft instead of solving the problem.

Addressing the lack of talent

I talked about the company caring about getting things done and not at the expense of quality, but what I didn’t explain is how they measure that today. When we look at performance metrics of our software development teams, we use lines of code (LOC), the number of defects, documentation, code reviews completed, and the hidden one, personality. Developers who value code as craft are often put on a pedestal, they have beautiful code that others envy, they also are the more vocal detractor to anything new.

Insurance is seen as a lagging industry. When I moved from the US Department of Defense to insurance, all of my old co-workers thought I was nuts. I even heard things like “that industry doesn’t do anything” and “be prepared to be bored and work on a mainframe.” Anyone in the insurance industry knows that this is completely false. But perception is reality. If new talent sees the industry as stuffy and not forward-thinking, you won’t get creative minds to show up. Insurance companies are often not in the major hot spots for IT careers and if they are, they are usually not able to compete with tech giants like Google, Amazon, and Uber when it comes to attracting new IT talent.

Wow, this sounds really depressing. What you’re probably thinking now is that you should just give up and take whoever shows up. While that’s one option, I wouldn’t recommend it. You must change hiring practices. Instead of hiring extremely talented people who know the ins and outs of the technology, hire people that like to solve problems in their spare time and can learn quickly. Take people from the business and utilize higher-level languages or technology like Low-code to let them focus on fixing the business problems faster. HR needs to understand what you really need to look for. The legal team needs to ensure that what you are looking for doesn’t create visa issues for immigrants. Everyone needs to be on board for celebrating the individuals and teams that just get sh*t done and don’t look for credit.

Don’t turn away those top engineers though. For true innovation and differentiation, you will more than likely need their abilities. Just make sure they know what your company values. Not code as craft, but code as a tool. A crucial tool, but one of many. The true goal is for all the creative minds available to use those tools to solve problems faster than everyone else.

Your best hires will be the ones who solve problems like a farmer. They’ll do what it takes – whatever it takes – to make sure nothing gets in the way of making hay while the sun shines.

Author Info

David Kuhn