Seagull Management

Last year, I read Surrender, a book by U2 lead singer, Bono. Bill Gates listed this as one of the top books to read at one point, so I picked it up and dove in. I have enjoyed U2s music since I was in high school, and was interested to hear what made Bill Gates recommend his book. The book is partially a journey of U2, but mostly a look at how Bono’s view of the world and life has changed over time.

Bono grew beyond music in his life to become an activist and try to shape the world into a better place. Whether you agree with his efforts or focus or not, it’s admirable that he has tried to be more than a rich and famous singer. He’s had to build more skills around how to communicate with others, convince them to take a course of action, and educate himself about the world. In trying to build these skills, he’s founded or worked in organizations around his time with U2.

As a part of that, he had a great quote about leaders who are busy elsewhere but try to be involved in different parts of the business. He called this seagull management, and it was something he tried to avoid doing as he only comes into the office periodically.

Seagull management is where you fly into the office, shit over what everyone is doing, and fly off again. I wonder how many people in management do this but think that they are motivating, helping, or improving their workers’ efforts. Trying to bring their view, experience, knowledge, etc. to others, but invariably doing so in a way that doesn’t resonate with workers. Perhaps it’s not even helpful if management hasn’t taken the time to understand why people are working in a certain way.

I also see this with technical leads or senior engineers who come into a situation, often with strong opinions. They might express how they would have coded or architected something completely differently. Perhaps even informing existing staff that they are doing something wrong. Whether good intentioned or not, seagull management doesn’t help improve any situation.

We make bad decisions, we may build something without considering all the information, or perhaps the situation changes. We all find ourselves in situations where the technology doesn’t seem to be well matched to the environment. We might wish things were different. However, no matter how we arrive at our present situation, we are there. Extracting ourselves from any legacy environment takes time and has to be a journey that is undertaken with support from both technical staff and management.

Most of us want to build great systems that work well for our clients and are admired by others. We rarely find ourselves in a place where we have the time and resources to do that. We can refactor, evolve, and grow our systems to be better, but it does take time. We need a goal, direction, support, and understanding that change is a journey, not something that a manager can fix on their rare visits to our environment.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Posted in Editorial | Tagged , | 2 Comments

A New Word: Apolytus

apolytus– n. the moment you realize you are changing as a person, finally outgrowing your old problems like a reptile shedding its skin, already able to twist back around and chuckle at this weirdly antiquated caricature of yourself that will soon come off completely.

I don’t know if I am changing that much, though hopefully I’m still maturing a bit. More, I think about my daughter, who graduates college this year. She’s changed so much in the five years since she left home for college, outgrowing the problems and concerns she had as an 18-year old.

I think I went through that myself, leaving home at 17 for college, coming back 4 years later a completely different person, viewing the world completely differently.

From the Dictionary of Obscure Sorrows

Posted in Blog | Tagged , | Comments Off on A New Word: Apolytus

Using Git Prune–#SQLNewBlogger

As I’ve been working with SQL Saturday and managing changes to events, I’ve accumulated a lot of branches. Even though I’m a solo developer, I decided to use branches, as I expect others to share this load in the future. This post looks at how to start cleaning those up.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers. You can see all posts on Git as well.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

Finding Old Branches

When I ran the git branch command, I saw this. There are a lot of old branches in there.

2024-04-11 10_44_53-cmd

I decided that I should reduce this number. After all, even removing stale branches means I have a lot of events in flight.

We use GitHub, and when I go on the site, I see lots of branches, some of which date back to last year. Those events are done, so I decided to delete some branches. In the image below, there are three branches. To the right, there are delete icons on the bottom two as I’ve already pressed the one to delete the remote branch on the top one.

2024-04-11 10_51_00-Branches · sqlsaturday_sqlsatwebsite — Mozilla Firefox

Now, how do I delete the local branch? Let’s start by removing it.

Git Prune

There is a command to remove references to remote branches that are deleted: git prune. I deleted a few older branches, and then ran git prune for remotes, with the –dry-run option. This tells me what would happen. As you can see, a number of branch references would be deleted.

2024-04-11 10_51_57-cmd

Nothing in here I’m worried about or that is active. I’ve deleted these on GitHub, so I’ll re-run the command without dry run. This removes the references.

Unfortunately, the local branches still exist. We don’t remove these, as it’s possible I have work on a local branch not sent to the remote, so doing this automatically, even if I do it, is dangerous.

I’ll do another post on removing the local branches.

Automating the Removal of Remote references

I might want to remove local references for branches that get deleted on the remote. This is useful if you delete branches on merge. I don’t in this case, as I’m often using the same branch for multiple changes for an event, rather than a new branch for every one.

One way to do this is to change the config with this:

git config remote.origin.prune true

This will then run the prune on each fetch or full. This helps keep things cleaner, though local branches still exist. However, if I commit to a local branch and push, I’ll get an error that I need to configure the upstream. That helps with me being aware of what’s active or not.

SQL New Blogger

Using version control is a core skill for anyone in technology. Even database people. You could write posts on how you use or learn about git (or something else) and showcase your skills.

This post took me about 15 minutes to write, even with screen shots.

Posted in Blog | Tagged , , , | 2 Comments

Missing the Office

Recently I traveled to visit a customer who has an in-the-office culture. They have multiple large buildings outside a major US city and almost all their employees (7000+) live nearby and are expected to be in the office the whole week. More senior people can opt for 4 10-hour shifts rather than 5 8-hour shifts, but with few exceptions, they have people in the office.

I hadn’t seen that in a long time. Almost every customer is mostly remote or some level of hybrid (usually 2-3 days a week in the office). What’s more, they have an open culture, with rows of desks for teams and spaces between the rows for managers and directors. No cubes!

Everyone below a senior VP/C-level is at a desk. There are conference rooms and smaller quiet pods, but mostly everyone works in wide open spaces. From developers to sales to finance to human resources. It’s both chaotic and loud, but also refreshing. I also loved seeing so many people wearing company logos on t-shirts, jackets, hats, and more.

The environment reminds me of my time at JD Edwards. We had cubicles, but mostly open ones with half walls to the side and one full wall at the back where two cubes met. However, it was a very strong culture of comradery and closeness that I hadn’t seen at any large company before or since: until now. Teams might be close in some places I’ve worked, but the entire company at JD Edwards felt like a family of people who were working together. We didn’t always get along and argued, but we were all united. It was a great feeling.

I miss that. Redgate is a great company, and I enjoy my co-workers, but I miss going to an office and seeing everyone inside it. Most people come to the office once or twice a week, but I miss my visits when most everyone was there every day. I’ve worked remotely for over twenty years, but I do still miss the office some days. Certainly my visits to the various Redgate offices, while good, have me wishing I saw more people there every day. I’m heading there tomorrow, and I hope I see lots of people.

I don’t know that mandating everyone in the office is a better choice, but I do know there are good things about gathering groups of people together. Strong leadership, empathy, a clear vision, and a balanced workload are important for any organization, but especially important if you want everyone in the office these days. This customer did a great job with it, and I think they would still have a strong culture with remote work, but their choice works, and I’m a little jealous.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Posted in Editorial | Tagged | 3 Comments