Stories Told

Twenty-five years in the software salt mines

Tomorrow it will have been 25 years since I started my career in the software industry.

It might seem odd that I remember the day only until you know that I started work on Monday, July 3, 1989, making my second day a paid holiday. The office was nearly deserted on my first day. My boss regretted not having me start on July 5 so he could have had an extra-long weekend too.

I was 21 years old when I joined that little software company in Terre Haute. I’m 46 now. I have worked more than half my life in and around the software industry.

I taught myself how to write computer programs when I was 15. When I was 16, my math teacher saw some of my programs and praised my work. He encouraged me to pursue software development as a career. He began to tell me about this tough engineering school in Terre Haute.

I graduated from that tough engineering school hoping to find work as a programmer. Jobs were hard to come by that year, so when a software company wanted to hire me as a technical writer I was thrilled just to work. And then it turned out I had a real knack for explaining software to people. I did it for twelve years, including a brief stint in technology publishing and five years managing writers.

I then returned to my technical roots, testing software and managing software testers. I learned to write automated functional and performance tests – code that tests code – and it has taken me places in my career that I could never have imagined.

Office

My office at one of my career stops

I’ve worked for eight companies in 25 years. The longest I’ve stayed anywhere is five years. I left one company in which I was a poor fit after just 14 months. I’ve moved on voluntarily seven times, was laid off once, and was fired and un-fired once (which is quite a story; read it here). Changing jobs this often isn’t unusual in this industry and has given me rich experience I couldn’t have gained by staying with one company all this time.

I’ve worked on software that managed telephone networks, helped media buyers place advertising, helped manufacturers manage their business, run Medicare call centers, helped small banks make more money, enabled very large companies to more effectively market their products, and gave various medical verticals insight so they can improve their operations and their business.

Some of these companies were private and others were public; so far, I’ve liked private companies better. Some of them made lots of money, some of them had good and bad years, and one of them folded. Some of them were well run and others had cheats and liars at the helm. Some were very difficult places to work, but those were crucibles in which I learned the most. Others have brought successes beyond anything I could have hoped for a quarter century ago.

I did, however, hope for a good, long run in this industry, and I got it. But I’m also having a hard time envisioning another 25 years. It’s not just because I’d be 71 then. I really like to work, and – right now at least – I plan to do so for as long as I am able. But I’m starting to have trouble imagining what mountains I might yet climb in this career. Maybe that’s part of reaching middle age – indeed, many of my similarly aged colleagues, some with careers far beyond mine, have gone into other lines of work. I’m still having a lot of fun making software, though. I currently manage six software testers, one test-automation and performance-test developer, and one technical writer. I get to bring all of my experience to bear, and encourage my teams to reach and grow. I don’t want to stop just yet.


If this sounds familiar, it’s because it’s an update of a post from four years ago. Cross-posted to my other blog, Stories from the Software Salt Mines.

Advertisements
Standard
Essay, Personal

Technical problems can almost always be solved, but people problems are hard

I’ll never forget the revelation it was when I figured out how to write computer programs. You mean, I thought, I can make this machine do what I want it to?

It was a watershed moment in my life.

A portrait of the geek as a young man

I was shy, introverted. People often frightened me, at least a little. I struggled to interact with people I didn’t know well, and I had no idea how to influence others. And then here was this machine that I could order around. It had limits – it couldn’t make my breakfast for me. But within those limits, it was all about what my mind could imagine and then code. I wrote games that my dad and my brother played. I wrote programs that illustrated concepts of geometry, which I demonstrated to math classes in school. I wrote a payroll application for my aunt’s small business. I even wrote a very rudimentary operating system once – it was terrible, but I learned a lot.

So I went off to college to learn how to make software. When I got out, the job market was terrible, so I took the only software job I could find, writing user guides for a software company. Later in my career I moved into testing, and into management. I’ve delivered a lot of software since I started almost 24 years ago.

Here’s the crazy thing I’ve learned: The hardest thing about making software is not the technical stuff. The hardest thing is getting people aligned and pointing the same way!

I’ve often said that it’s a modern miracle when a software project succeeds. Any software development project that involves more than about two people will have coordination challenges, differences of opinion, and all the other normal issues of working together. My experience has been that the programmers and the testers can do whatever you need them to (short of, say, telepathic user interfaces). They will work hard at it, they may struggle to get it right, and there may be frustration and late nights getting it done. But those struggles can pale in comparison to how hard it is to get everyone to agree on what to build, how to build it, and what it means to be done. Here’s how code is better than people:

Code People
Once coded, code stays coded and reliably does the same thing over and over. You think you have people all organized and then they go off and do whatever they want anyway.
You will sometimes struggle and work hard to make your code do what it needs to, but you can almost always get the job done. Sometimes you simply can’t influence people. Drat their free will.
Change your code, it doesn’t mind. It knows no fear. People hate change! When change is thrust upon them, they often resist it or even run away, screaming.

By the way, the WordPress editor doesn’t offer a way to create tables, so I wrote some HTML code to generate one. Fear my mad, l33t sk1llz.

Unfortunately, even if you have the best coders in the world, if you can’t get them to work together their projects will fail. Fortunately, I understand geeks, for I am one. I know what makes us tick. I’ve learned how to influence us and get us all reasonably pointing the same way. And I’ve built on these skills to learn how to influence non-geeks such as upper management, salespeople, and customer service folks to get them all working together. It’s not easy, and it’s impossible to ever get it perfect, but I’ve had pretty good success over the years and it’s contributed strongly to any number of successful software releases. And it’s helped me come out of my nerdly introverted shell.

I can’t remember the time I last wrote any serious code. I don’t miss it. To my astonishment, I’m having much more fun and success on the people side now.

readmore2

Life got lots easier for me
when I embraced my inner geek.

Standard
Stories Told

Even a mediocre plan will work if everybody follows it

I have been astonished in my life by how few problems are truly unsolvable. I have also noticed that, most of the time, when a problem ends up not being solved it is for one of two reasons: people deny the problem, or they won’t work together on the solution.

I make software for a living. We have a saying in software development: There are two things you don’t want to know how are made – sausage and software.

There are any number of ways to make software. All of them involve programming, of course; it’s the core activity. But there are other jobs to perform, and the bigger the software being developed, the more people you need to perform them. It becomes necessary to organize the people and form work processes. The ways to do that range from loose and chaotic to structured but flexible to ponderous and formal. They all have their strengths and weaknesses; they all can work. I’ve made software in all of these situations.

Scenes from US 50One of my past employers sequestered its programmers in a room to hack code together as fast as they could. When they were done, a couple people would play with the product for a week or two in hopes of finding some bugs, which the programmers might or might not fix. Then we shipped it to five customers, who upon installing it invariably found that it failed spectacularly. When we fixed all the problems they found, we chose five more customers. We repeated this process until the software stopped failing, and then announced to the rest of our customers that it was ready.

At the other end of the scale, another past employer had such a heavy software development process that following it felt like slipping into a straitjacket. There were reams of documentation to write and keep with layers of approval at each step. I worked on a team that tested the software to make sure it did what it was designed to do. We had to take a screen shot of every test step, print it, and put it in a folder. At the end of a project, we had boxes and boxes and boxes of printouts, hundreds of pounds worth, that we would send to an offsite storage facility. This was in case our only customer, which happened to be the U.S. government, wanted to audit us.

Both companies are still in business.

Brick segment of old US 40/NRA third past employer carefully hired smart people and trusted them to know what to do. Because they hired well, this worked for a long time. But as the company grew, this approach became more and more difficult to manage. Product quality became a problem. A big part of the software was an accounting package, and in one fateful release the general ledger simply would not balance. This affected every customer, and to make a long story short, it took the company almost a year to fix it. Several customers quit us.

Too often it takes great pain to drive important change. This pain made us face that we needed more structure to deliver successfully. So we hired a consultant to guide us toward a better software development process. He showed us a way with just enough checks and balances that we could have greater confidence in our work without being too bogged down. We also hired a consultant to help the management team (of which I was a part) work more collaboratively. She taught us how to lead the company through this transition.

It worked. In the very first product release under the new process, quality problems fell off dramatically and we delivered on time for the first time anybody could remember.

The more important hire was the second consultant. The new methodology was good, but it wasn’t magic, and it might not have worked for us if we had not done a good job helping the team through the changes. You see, a few people didn’t understand why the old way couldn’t still work and still others thought our new process wasn’t going far enough. Our task was to overcome the resistance and get everybody singing from the same sheet of music, and it was the hardest thing we did. But we pulled it off.

It’s a rare organization that faces its failings and works to change. It’s a rarer organization still that drives change collaboratively.

The company with the ponderous process
fired me.
 I’m so glad. Read that story.

Standard
Stories Told

Twenty-one years in the software salt mines

A personal anniversary passed quietly last Saturday. It was the 21st year since I started my career.

It may seem odd that I remember the day only until you know that I started work on July 3, making my second day a paid holiday. The office was nearly deserted on my first day. My boss regretted not having me start on July 5 so he could have had an extra-long weekend too.

And given that we seem to love divisible-by-ten and divisible-by-25 anniversaries, it may seem odd that I’m honoring this 21st anniversary. But I was 21 years old when I joined that little software company in Terre Haute.

I have now worked half my life in and around the software industry.

I taught myself how to write computer programs when I was 15. When I was 16, my math teacher saw some of my programs and praised my work. He encouraged me to pursue software development as a career. He began to tell me about this tough engineering school in Terre Haute.

My desk at one of my career stops

I graduated from that tough engineering school with a desire to find work as a programmer. Jobs were hard to come by that year, so when the only software company in town wanted to hire me as a technical writer I was thrilled just to work. And then it turned out I had a real knack for explaining software to people. I did it for twelve years, including a brief stint in technology publishing and five years managing writers.

I then returned to my technical roots, testing software and managing software testers. I learned to write automated functional and performance tests – code that tests code – and it has taken me places in my career that I could never have imagined.

I’ve worked for seven companies in 21 years. The longest I’ve stayed anywhere is five years; I left one company after just 14 months. I’ve moved on voluntarily six times, was laid off once, and was fired and rehired once (which is quite a story; I’ll tell it one day). Changing jobs this often isn’t unusual in this industry and has given me rich experience I couldn’t have gained by staying with one company all this time.

I’ve worked on software that managed telephone networks, helped media buyers place advertising, helped manufacturers manage their business, run Medicare call centers, helped small banks make more money, and enabled very large companies to more effectively market their products.

Some of these companies were private and others were public; so far, I’ve liked private companies better. Some of them made lots of money, some of them had good and bad years, and one of them folded. Some of them were well run and others had cheats and liars at the helm. Some were very difficult places to work, but those were crucibles in which I learned the most. Others have brought successes beyond anything I could have hoped for 21 years ago.

I did, however, hope for a good, long run in this industry, and I got it. But I’m also having a hard time envisioning another 21 years. Maybe that’s part of reaching middle age – indeed, many of my similarly aged colleagues, some with careers far beyond mine, have gone into other lines of work. I’m still having a lot of fun making software, though. I currently manage four software testers, two test automation developers, and five technical writers. I get to bring all of my experience to bear, and encourage my teams to reach and grow. I don’t want to stop just yet.

Standard