I just hit my 5-year anniversary this week, and I've been reflecting on the past. Here's a collection of tip & tricks and lessons learned in the trenches creating Software for 5 years here at QL.
Disclaimer: I am not necessarily fully compliant with all these rules, I've just noticed them along the way.
Disclaimer 2: YMMV, these have worked well for me, but we're all different.
Disclaimer 3: We already have some really good ISM's and Tech Philosophies, this is just an addition on those.
Although a Team Member (TM) may have screwed up, there's never a good reason to call out a specific TM for screwing up in a public setting. No one like being called out for mistakes. On the other hand, when a TM does something great, shout it from the rooftops.
Praise in public criticize in private. -Vince Lombardi
Ultimately organizations are just collections of people. You can learn a lot by talking to people and listening to people. Especially in a fully remote COVID world, it's important to take time to talk to other TM's. Additionally, keep an ear to the ground to listen out for things that are relevant to your Team. Also, when people talk, listen for the hidden messages. For example, "Hey, you've done this before, right?" might be a way of asking, "Hey, can you help me out with this?". (P.S. Personally, I happen to not be a very good listener, but I'm working on it :))
When people talk, listen completely. Most people never listen. -Ernest Hemingway.
It's always important to understand why before you start writing code. Especially when talking with "The Business" or any stakeholders in a project. Quick example:
The Business (TB): Hey can you create a button that will close the ABC Task? And then create a way to export Task data to Excel?
Me: Why?
TB: Because we want to track if TM's do X, and the way we do that is by opening an ABC Task, and then closing it. And then we pull it out into Excel and filter by Y.
Me: So then why not just have a Database table that stores information about X, and then has a UI that shows the data filtered by Y?
TB: Sure, that'll work too
Achievement Unlocked: Less Excel, More Databases
Why's make you wise. -Me
As explained in the previous section, there's no way you can ever think about How you will do something, until you clearly define the What and the Why. For example, Hey, we're going to use Elixir and Kubernetes as the solution. Wait, what was the problem again? Meaning a deep understanding of the problem will lead to choosing the right solution.
Cake is the answer. What was the question?
Sometimes you can be so deep into the weeds on a process, that you lose sight of where the process stops making any sense. Like Michael Scott following the GPS into the lake, sometimes you just have to grab the override controls. I see this often with work prioritization where the process says X is more important, but deep down, everyone knows that Y is more important. So yeah, let's do Y. Additionally, if you can fix something in 30 seconds, but the process says to create a story, and get it assigned, etc. Don't forget why we're here. To make TM's and Clients lives easier.
Ryan thinks that technology is the answer. Well, guess what? I just drove my car into a lake. -Michael Scott
If you see someone struggling, and / or asking for help in a public chat, help them. Obviously if you don't have time for that, you don't. But many of us have the time and can help, so do it. It's that simple. Side effects of helping people may include:
- Those same people (possibly on other teams) being more interested in helping you in the future.
- Your teammates having greater respect for you and looking to you for guidance.
- Becoming a kinder person.
- A marketing effect where other folks know who you are thereby raising your "Street-Cred" score.
Cast your bread upon the waters, for after many days you will find it again. -Ecclesiastes 11:1
This is something that is true in general but becomes much more pronounced at a large organization. Previously I worked at a much smaller company where we all had the same quirky brand of humor. When moving to an organization with thousands of people I realized that I needed to be much more specific in my communication. Additionally, there are many TM's with strong opinions out there, and I realized that I couldn't just assume that everyone thought like me. A key part of this is that you can't assume that you have alignment just because you've said your piece. There may be some TM's that deeply disagree but will not speak up (even after you ask "Hey, does anyone disagree?"). TLDR: Always good to keep in mind that we're all different and communicate different.
Different strokes for different folks
There will often be frustrating situations that will arise. A change in requirements, a late-night Tech Incident, a mistake by another team, etc. Instead of feeding the tension and anger, try diffusing it with humor. At the end of the day, everyone will be calmer and happier as a result.
Laughter is the best medicine. -Henri de Mondeville
If you speak up, and give constructive feedback, good things will happen. Most people are not malicious. They just may be doing something dumb, because it's the only way they know. Teach them a new, better way to do things. Most people will ultimately be appreciative of good, targeted feedback. If they're not, well then that's their loss. You'll be surprised how far good feedback can go. When people give you feedback, listen to it. Swish it around in your head, tell your ego to pipe down for a second and think if they may be on to something. They probably are.
Feedback is a gift.
"I spoke with Team X", "Team X is aligned", etc. these are not necessarily true statements. What you really mean, is that I spoke with Jim, Greg is aligned, etc. When collaborating across the Enterprise, working with a specific TM will typically get you farther than working with a faceless "Team". If you need to work with a "Team" get a point-person / dedicated buddy, who will be a real live person you can collaborate with.
Individuals and interactions over processes and tools. -Agile Manifesto
One of the dirty secrets of the Tech industry, is that no one really knows exactly how everything works. Collectively, we understand how various bits and pieces work, but individually, many of us have a surface-level understanding of many parts of the technology stack. When something breaks, and the "Owner" is on the line, they often don't have enough understanding and / or context to understand why something isn't working. Because we're also not great at saying "I don't know", we've come up with alternative ways to address the fact that stuff just happens. For example, Network blip, Network hiccup, etc. are ways of saying that the network is having issues, but we honestly have no idea why. This is where the famous IT rule of turn it on and off comes from, sometimes it helps, and we don't really know why. This will often come up during Tech Incidents, essentially things break, and we don't know why. I think it's fair to (gently) call out the BS and ensure that we get to a "real" root cause, not a BS one.
Hello. IT. Have you tried turning it off and on again? -The IT Crowd
Additionally, there are 2 different angles during Tech incidents. Imagine we found an injured person in the woods and rushed them to the hospital. The first thing we need to do, is stabilize their health, not start a complicated surgery. What this means in technology, is get the service back up and running at all costs (possibly by restarting, rolling back), before getting into root cause, pushing new code to fix things, etc.
Michael: What comes before anything? What have we always said is the most important thing?
George Michael: Breakfast.
Michael: Family.
George Michael:Family, right. I thought you meant of the things you eat.
--Arrested Development
Many moons ago, when the world was young, there were mythical creatures known as ".Net Developers", "jQuery experts", "SQL Developer", etc. Today, in the full stack era, all that has changed. The complexity and cognitive load on Engineers keeps rising. First Operations got added to Dev, followed closely by Security. They came Database responsibilities, followed by Business knowledge. This has led to a world where no one really fully understands anything. Everyone has a half-baked understanding of different topics. Some Engineers have the mental capacity to juggle all these different topics with ease, and some don't. When Engineers start getting overwhelmed, they key solution is automation and tools. Meaning farm out complexity as much as possible. AWS and "The Cloud" are the obvious ones, but there are a TON of tools in our collective toolbelt. Learn how to use the tools to save your sanity. If tools don't exist, convince the Enterprise to buy them or just create them.
Devs are from Venus, Ops are from Mars. -Steven Haines
The most powerful tool we have as Devs is Automation. -Scott Hanselman
This one can get you in trouble (so don't say I didn't warn you) but yeah in most cases if you have a clear vision of what your team needs to get done, you can often just do things to achieve that goal, and deal with the consequences (or lack thereof) later. For example, every Production change needs a Change Request, but our Prod system is totally down right now, and I know how to fix it by clicking a button. You should probably click the button and fix it first and worry about the paperwork later. Use this one with caution though.
It's easier to ask forgiveness than it is to get permission. -Grace Hopper
Throughout your career you will see new and shiny solutions that promise to solve old problems. They rarely do so without introducing serious problems of their own. Ultimately any technology solution can solve any technology problem. It's all about using the right tool for the job and balancing the trade-offs. When you jump into a new technology, there's typically a honeymoon period where everything seems great, followed by a "What have we done?" period that leads to regret. It's important to fully understand the tradeoffs of switching to a new technology and be sure that they are worth it. Being the first one to jump into the pool is the riskiest. Beware the unknowns.
As we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say, we know there are some things we do not know. - Donald Rumsfeld
Technology moves fasts. So fast in fact, that universities are often years behind the industry. It's one of the only industries where doing something for a long time can be held against you. If you stop learning, you'll wake up one day and realize that you're a dinosaur. The only solution is to learn every day. Don't ever stop learning. It's that simple.
Once a new technology rolls over you, if you're not part of the steamroller, you're part of the road. -Stewart Brand
At the end of the day, the only thing that really matters is working software. Are the users happy? Do they have software that meets their needs? Well then, you've succeeded. Improving technology never ends. Google still has thousands of engineers working on Search. It never ends. It can get frustrating knowing that you never reach the end of the road. Success in technology should really be measured in terms of happy users. Do you have happy users? Well then, you've succeeded. The best way to tell if your users are happy? Talk to them.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. -Rick Cook
This is a lesson that I learned the hard way. The hard part of Enterprise Software is not the software, it's the Enterprise. More people mean more opinions, which means more confusion, which leads to messier complicated software. If you locked an engineer in a room for a year and said build X, it would be beautiful. But alas, we have to communicate. Communication leads to alignment. Alignment is the act of getting everyone on board with a common vision and plan. Allegedly, this is what leaders do. You should try it too.
High-performing teams use synergy and alignment to pursue organizational goals. -Some Thought Leader Guy
Thoughts? Leave some feedback in the comments below.