Skip to content

Mistakes

What I Don’t See When I’m Envious

I’m getting to the age where peers have accomplished a lot. I’m not talking about people who were exceptional out of the gate and did great things in their 20s and 30s. I’m talking about people that felt like genuine peers, but now have done things like:

  • made a boatload of money
  • built a business such that they have all kinds of freedom
  • are well known in their fields

These folks have things that I want. And I feel like I’m just as talented. I could be where they are and have what they have.

In my mind I often think “why does <X> have that and I don’t”. This envy is not constructive, but that doesn’t stop it from popping up from time to time. I think I’m getting old enough that status and legacy are starting to matter in a way they didn’t a decade ago.

Here are strategies I use to combat envy:

  • Remind myself that I don’t actually know everything they have. I can see certain aspects of their life, but even for close friends I don’t know everything, just what they choose to share. The friend who is a professor who works with interesting projects and gets the summers off might have to deal with horrible politics or a low salary. I just don’t know. That means I don’t know enough to know if I’d actually want to trade places. I am idealizing what they have and not understanding the downsides.
  • Even if I would want to trade places, I don’t know what they went through. When I see a friend with the thriving business who has flexibility and can work when he wants, I don’t see everything. I don’t see how he had to be tethered to it for years, or the risks he had to take, or the multiple years of 60+ hour workweeks and the stress that wrought on his body, family and friends. I try to imagine the late nights and the worries in the same way I imagine the benefits.
  • Remind myself that I have agency and can work toward what they have. Even though I’m mid-career, if I wanted to adjust things to move towards what someone I see has, I can do so. As mentioned above, I need to be willing to make sacrifices, but I am lucky enough to have the space to consider it. With sufficient focus and effort, I can do most anything, I just can’t do everything.
  • Even if I want to trade places with a friend, know what would make me happy, and would have been willing to make the sacrifices to be where they are, I am still discounting my current situation. It’s very easy to think “oh, <Y> would make me happy” but if I can’t look at where I am and be grateful, I might be kidding myself. And when I do take a hard look at where I am, I do feel more gratitude and satisfaction. One of my hacks when I’m feeling down is to just list 2-3 things that I like about my life.
  • Related to feeling grateful for what I have, I also try to remember that just as I am looking at people and saying “why can’t I have what they have”, other folks might be looking at me and saying the same. In fact, I might have said the same 20 years ago if I was looking at someone where I am now. It’s easy to discount what you have and focus on what you don’t, but thinking about these folks makes me more grateful for what I do have.

I’d be surprised if I’m alone in feeling this way. Do you feel envious? If so, how do you deal with it?

Lifehack Mistakes Thanks Useful Tools | moore |

Book Review: The Cuckoo’s Egg

I recently finished “The Cuckoo’s Egg”, by Clifford Stoll. It was a fascinating non-fiction book exploring the foundations of computer security in a personable format.

The setting is the mid 1980s. The author discovers something weird on his academic computer system. There’s an unexplained charge of 75 cents. He digs deeper, discovers that someone who’s left the university is logging in.

After further investigation, he discovers that the user who is logging in is an intruder. After discussing the situation with his boss, he gets three weeks to find out who they are. He figures that’s plenty of time.

The investigation ends up taking a year.

It also extends far beyond his academic systems, both in scope and effort. Stoll talks to numerous government agencies and private organizations, letting them know they’ve been attacked and getting their assistance tracing the hacker. He sleeps under his desk. He rigs up a pager so that he can know which accounts the hacker is using. Stoll sets up printers so that every word the hacker types is recorded, unbeknownst to him.

It’s quite the tale. As someone who has worked with software for years, I really appreciated the historical nature of it. When I became aware of the internet, in my youth, some of the groups and communities he mentions were still around; I remember reading and posting to usenet. But many of the systems were before my time. I’ve never touched a computer running VMS, for instance.

But, for all the history, the people problems were the same: users not changing passwords, system managers not locking their software down, bureaucrats happy to take information but not willing to share. Let’s just say, mistakes were made.

I also enjoyed the author’s interspersal of lived experiences. We don’t simply follow one computer nerd tracking another. We also learn about milkshakes, parties in San Francisco, curry nights and his first experience with the microwave. While some phrases and analogies are repeated (“should we thank someone who goes to a little town and robs people to illustrate they should lock their doors” pops up at least twice), in general the book is pretty readable. Stoll’s personal stories and musings help that readability immensely.

All in all, a great book if you are interested in the history of computing or modern security practices. If you’re interested in learning more, you can check out a paper he wrote based on the same experience for ACM.

Books Mistakes Programming | moore |

What I wish I had known when I was starting out as a developer

As I get older, I wish I could reach back and give myself advice. Some of it is life advice (take that leap, kiss that girl, take that trip) but a lot of it is career advice.

There’s so much about being a software developer that you learn along the way. This includes technical knowledge like how to tune a database query and how to use a text editor. It also includes non technical knowledge, what some people term “soft skills”. I tend to think they are actually pretty hard, to be honest. Things like:

  • How to help your manager help you
  • Why writing code isn’t always the best solution
  • Mistakes and how to handle them
  • How to view other parts of the business

These skills took me a long time to learn (and I am still learning them to this day) but have had a material impact on my happiness as a developer.

I am so passionate about this topic that I’ve written over 150 blog posts. Where are these? They’re over at another site I’ve been updating for a few years.

And then I went and wrote a book. I learned a bunch of lessons during that process, including the fact that it’s an intense effort. I wrote it with three audiences in mind:

  • The new developer, with less than five years of experience. This book will help them level up.
  • The person considering software development. This book will give them a glimpse of what being a software developer is like.
  • The mentor. This book will serve as a discussion guide for many interesting aspects of development with a mentee.

The book arrives in August. I hope you’ll check it out.

Full details, including ordering information, over at the Letters To A New Developer website.

Lifehack Mistakes Programming | moore |

Not delivering end user value

When you’ve worked in software for as long as I have, you have made mistakes. I’m going to catalog some here intermittently so I can analyze them and hopefully avoid them in the future. I may change identifying details or use vague descriptions.

When you interact with a client, especially if they are knowledgeable about their domain, it can be hard to come in and seize the reins. You want to be respectful of what they know and what you don’t. But at the same time, they hired you for what you know, and sometimes you have to stop hurrying forward and take a look around, especially if the project is not running smoothly. This is a story about a time when I didn’t seize the reins, and the problems that followed.

I was working on a long running project for a client. It was a bear of a project, with a ton of domain knowledge and some complicated partially done software. The team working for the client churned, including employees and consultants. When I was brought on, I didn’t have a full picture of the problem space and it felt like we didn’t have time to gather it. No one had this global view. Meetings with the client would often go down rabbit holes and into the weeds. The project was a rewrite and the system we were targeting to replace kept evolving. This original software system powered the business and yet didn’t operate with normal software development practices like version control. When looking at the code, it was unclear what code was being used and what was not.

But most importantly, other than diagrams and meetings, we didn’t deliver anything of value regularly to the client. We would spin in circles trying to understand previous work and take a long time to make small changes. We did write a testable new system and follow other SDLC best practices including version control, CI/CD and deployment environments.

This project finally started to turn around when we shifted from trying to replace the entire running system to replacing the smallest part that could possibly work end to end. This gave the team a clear vision, and showed the client a path to business value. We accomplished more in a couple weeks with this perspective than we had in the previous couple of months. This also let us commit to a real project plan and timeline. Unfortunately, the client wasn’t happy about the projected and past expense, and shut down the project weeks after the development team was starting to show traction.

Lesson: I wish we would have had taken the “smallest bit that would possibly work” approach from the very beginning. I wish I’d had the insight to call a halt and not continue down a path that was clearly not working a few weeks after observing it, not a few months.

Mistakes | moore |