Why I Code Solving problems that matter

I grew up in a pretty modest environment (think poverty line) but we somehow managed to be on the forefront of having computers in the home. I don’t believe my parents ever purchased any of the machines, but we were frequently the recipients of hand-me-downs as others upgraded their hardware.

We got our first computer when I was in elementary school when my uncle gave us an old Commodore 64. That machine was pretty awesome, and I loved loading up the 5.25” floppy to play Wheel of Fortune.

Then something happened that would change the course of my life, and my future career: my older brother came home from school.

I believe at this time that my brother was in the 8th grade and was in a class learning to program in BASIC. As any good older brother would do, he decided that if he had to learn BASIC, then he would force me to learn it as well. And so our lessons began. He would come home from school and teach me what he had learned, and we’d slowly build out programs together. This was all going on in the late 80’s when Al Gore was still working out the kinks in the interwebs, so we didn’t have Google as a reference.

While I still spent time with Pat and Vanna, I began to spend an increasing percentage of my computer time writing my own programs. I don’t think they got any more complicated than “Guess a number between 1 - 100” but the experience was thrilling.

Some years passed, and having learned the basics of BASIC my brother introduced me to me next programming challenge: graphing calculators. The language syntax was very similar to the BASIC I had hacked on the old Commodore. I began programming our TI-81 some time in middle school, and by the time I got to high school I would write simple programs to do all of the heavy lifting for me during my math exams. I felt a bit guilty about this, so I showed my teacher a sample program I wrote that would use the matrix methods we were learning to determine the values of 3 variable equations. She wasn’t quite sure what to think of me, I suppose, but decided that if I wrote the program then I was free to use it on my tests.

So naturally I wrote a series of programs to solve any problem that might possibly be tested. Need to run the quadratic equation? No problem, just input the coefficients A, B, and C. I’d have the program also spit out the discriminant just in case that was needed later on in the problem set…

Later that same year, my math teacher approached me and asked if I would be willing to represent the school at some regional programming competition. The competition would be in Pascal and they had a book I could take home to learn the language by year’s end. I was flattered and agreed.

I really meant to teach myself Pascal, I swear I did. I think I even installed the compiler on our computer. I know that I opened the book at least twice.

I used to spend hours on Friday nights (while at the high school football games) programming a text-based version of Blackjack onto my calculator. For no other reason than I liked Blackjack and I wanted to see if I could do it. But I found it almost impossible to crack open a book and teach myself Pascal for that competition.

There are a couple of takeaways from these simple experiences of my youth that have continued throughout my life and into my career. First, I’m a geek. A nerd even. I programmed my graphing calculator during our high school football games. While in my band uniform. Waiting to perform our half-time marching show. Obviously I was quite the lady’s man. Second, when a problem captivates me I will get lost in it until I get it solved. Third, when I’m asked to solve your problems, it is incredibly hard to care.

I could have learned Pascal, I just didn’t care. I could make a website for you, but odds are that your idea either sucks or doesn’t interest me.

That last line might kill my contracting career, but here’s a very simple truth: writing code to solve your problems will never be as fulfilling as writing code to solve my problems.

As I’ve moved into management, I have tried to remember this truth. I work best when I care about the problems being solved, so I assume others do as well. Some businesses try to solve this issue by offering equity, but this approach has been mostly ineffective. In all honesty, it is highly unlikely that it will make business sense for you to give me, much less a team of developers, enough equity that we feel like partners in the business. Being offered 0.0001% of the company is great and all, but I’m going to write that off as having an expected return of zero.

If you can’t offer me enough equity that it binds me to the company, what can you do? Addressing that question is at the heart of my management style. My approach in management is pretty simple: hire solid talent and then help them take ownership of problems. I’ve been most successful in getting developers mentally engaged in the process by including them in the business decision process. That is, rather than just give them a PSD and say “make this work” I try to get them involved in meetings where we talk about business goals. If we’re trying to decide if we should release Product X, it makes a lot of sense to pull in part of the development team and solicit feedback from them. And not just on the “how long will it take to build” type of questions. As a technical manager I have a pretty good idea of how long most things will take to build any way. But getting their input on if Product X fits into the overall view of what we’re trying to do as a company; getting their input on the opportunity costs of pursuing Product X; honestly soliciting their input on the business implications of the technical work that will be assigned to them – this sort of engagement does wonders for helping talented people feel part of the company and committed to its success.

By engaging developers in business problems, by having them give input into business decisions, the hierarchy of the business flattens and individuals take a larger mental/emotional stake in the business itself. As that happens, as talented individuals take ownership of business problems, they write higher quality code that’s better directed at solving those problems. You can partner with a talented team of developers without parting with equity: you just have to make your problems matter.