We’re (hopefully) taught some important things as children:
[Spoilers ahead, for Avengers: Infinity War and Avengers: Endgame]
A pet peeve of mine (Josh) is messy garages. I was ranting about this to Laine the other day, and an epiphany hit me.
Souls are like garages. Keep yours cleaned the f&$# out.
We are not naturally highly organized people. This is not a rant/post proposing that you itemize, alphabetize, and categorize every one of your possessions, towards living a better life. This is not that kind of post.
However, your garage is made for a specific purpose. We both live in Michigan. It gets cold here. If you have to park your car on the street, or in your driveway, your car gets covered in frost that has to be scraped off with one of the most annoying tools ever created. It also gets covered in snow when it inevitably snows, and regardless of snow or frost, it’s cold in the mornings.
Your driveway is also the safest place for your friends and buddies to park when they come visit you – but if you have to park in the driveway, they have to park in the street.
If you park in a garage, if you use the garage for its intended purpose, you avoid all of this pain.
Garages are for parking. They shouldn’t be filled with cruft and detritus that you don’t need, you haven’t used in years, and you have no real plans to even think about.
We talked in a previous post about neat stuff that was coming up in OpenShift. We wanted to follow up now that more information is available and 4.1 is GA and quickly break down some of the neatest stuff.
OpenShift 4 is the major version that will bring Kubernetes to being the standard platform: it provides features that let the majority of enterprises build and run the majority of their applications on an open, agile, future-ready platform.
What is it: Networking upgrade for OpenShift Applications
Status: Tech Preview as of 4.1
How does it work: Injects a container sidecar to monitor (mostly to say who’s calling who, and how much), secure, and manage traffic.
Key Features:
Big Talking Point: OpenShift Service Mesh makes managing all of the services you’re building visual and clear
Business Use Case: Enterprises looking to get visibility into their microservices, AppDynamics and Dynatrace customers.
What is it: Containerized Application Development Environment. Tagline is “cloud-native development.”
Key Features:
Business Use Case: Enterprises with poor developer IDES will appreciate CodeReady.
Competitors: IntelliJ and VSCode
What is it: FaaS/Serverless is an even easier, and more restricted architecture than containers or PaaS.
Serverless is an alternative to containers. Applications that would be a good fit in a simple container are an easy fit for serverless.
What is it: Kubernetes-based serverless “Application Easy Button” – just write code, forget about packaging. We talked about it in more detail here.
Key Features:
Competitors: AWS Lambda, Azure Serverless, Google Cloud Functions. K-Native provides this functionality without vendor lock-in from a single cloud provider.
What is it: intelligent automation that can manage an application by defining proper state and automate complicated application operations that using best practices.
Key Features:
Business Use Case: managing stateful applications like Kafka and databases, however new use cases show up all the time, such as managing the kubernetes cluster itself (Machine Operators)
Big Talking Point: Operators make managing complex applications in Kubernetes much easier, turning industry-standard practices into automation.
What is it: Kubernetes-native virtualization. Run VMs on Kubernetes. Basically, this is VMWare for K8s.
How does it work: leverage open source virtualization technology inside a container to run VMs.
Features:
Business Use Case: ditch proprietary VM platforms and run you containers and VMs on one standard, open platform
Cluster Admin is so much easier:
Theres’s a lot more coming with OpenShift that we’d like to get hands-on time with:
OpenShift is still the platform we know and love.
It was recently announced that more than 1000 enterprises across all industries are running OpenShift.
“I am the good shepherd. The good shepherd lays down his life for the sheep.” John 10:11
The Bible talks about sacrifice a lot. Sacrificing for each other, sacrificing to serve God. The Gospel, the most important story arc in the Bible, is in part about Jesus’ ultimate sacrifice – his death, yes, but more his complete and utter separation from God when he needed God the most. Unfortunately, over the past 2000 years, the definition of sacrifice has been broken to the point where it’s used to do more harm than good.
There’s a relatively simple list of things that most people want. We want to feel important to our world. We want to be good, kind people – people who aren’t the bad guy, people who deserve good.
We want the freedom to choose what makes us happy, and to find things that make us feel fulfilled. We want to be able to choose the things that fill our souls to the brim.
But the people around us don’t always want those things for us. They want us to work in their best interests, and they sometimes get hurt when we instead do what we want or need. When they get hurt, they try to control us into changing. They try to make us feel bad (or good) until we do change, until we do things that don’t make us happy or things that will hurt us – and if that doesn’t work, they decide that we must be an enemy and they begin to treat us accordingly.
I (Josh) didn’t like reality. Reality kept showing me that people may not always react favorably to the things I want or need – and I was scared of what might happen if I continued to fight for my right to those things. Ultimately, I was scared that they might leave if I continued to take care of myself.
I didn’t value my own soul enough to believe that it was worth taking care of, except…I kind of did. So in response, as a way to feel justified in fighting for my soul, I created alternate versions of people. I made people into monsters – monsters who manipulated me for their own selfish purposes. I saw them as willing to destroy me in order to get what they wanted. And since they were evil, I didn’t have to do what they said – I had the right to take care of myself, and I also had the right to control them into being not evil.
Some of these people were not trying to manipulate me. I would see people as evil who were just trying to help me face my fears – deeply hidden, pressed down, and blocked away – and I would see people as evil who would shove me at God when I didn’t want to do that.
But…some of the people I turned into monsters were trying to manipulate me. These people weren’t evil though, they were just…afraid. They were afraid of the same thing I was, actually, that if they couldn’t control me or our relationship, I would leave. In their fear, they were trying to destroy me, but sort of as a…byproduct. They tried to destroy me to make me safe for them to love.
What I struggled with was the simple fact that I’m supposed to do what protects my soul, what nourishes and cares for it, and what keeps it whole so that it can serve God to the best of its ability. I don’t actually need to see evil motives in other people in order to do so.
I don’t need to see evil motives in other people in order to protect my soul.
I realized that I believed in at least three realities:
If life was intended to be the utopia, then I had seriously messed something up at some point, despite always trying as hard I could to do and be what God wanted from me. If life was the horror, I thought I could (and should) seize control from God and set my own destiny – but it turns out that seizing control from God never works. I tried, and tried, and tried with all my soul and strength to take control and make the horror world less awful. It was a terrible process, but I realized, eventually, that it was impossible. Also, thankfully, that it wasn’t even reality.
That left only actual reality – and if actual reality was all that was available for me to work with, I was really scared that my life would never be what I wanted it to be.
We realized that other people do this too – we saw it happening, we had it happen to us as the objects, and we were confused and hurt when people saw us as demons or monsters out to destroy them. But…then we realized that these people were just really scared. They wanted to control us into doing the things that would make them feel less scared – which we weren’t willing to do. The inability to control us made them more scared, which led to more attempts at control, and…
Scared people do crazy things.
It gave us a lot of new empathy actually. We realized that most of the people who ever did a bad thing to another person…they probably just created a false reality. Every mugger was just keeping himself fed and giving himself the life he deserved – it was only fair, only what he deserved from the people and world around him. Every despot was just preserving freedom or safety for his people – whatever meager amount could be eked out from this cold, dark world. “Because even meager safety in my kingdom is better than the horror of living under their regime.”
At this point, we’re pretty sure that even truly evil people create their own moral justification via false realities. Hitler believed in what he was doing so hard that he convinced thousands of people that he was right – his opinions were awful, and fueled by fear. But he was convincing. He was sure.
Scared people do crazy things.
What’s always the answer?
Faith. Trust.
I had to learn all over again how to trust. I had to trust that God loves me – and while he disciplines, he does not punish. I have already been forgiven, so…there isn’t anything to punish.
I had to be willing to see the people I loved, which I had been avoiding in case I was about to see them walk away from me. Once I saw them, I knew that they were not trying to destroy me – or if they were, I didn’t have to let them.
Once I could trust God, and remember that he loves me and wasn’t trying to punish me, it was clear(er) that the utopia probably didn’t exist. And once I could see the people I loved again, and I trusted that they were not trying to destroy me, it was clear(er) that the horror probably didn’t exist either. That left learning how to exist in actual reality, which…is an entirely other blog post.
I really love Halsey. Josh introduced me to her via a roundabout way that included Bishop Briggs and Amazon Music’s stations – and she grew on me slowly, because typically pop music about someone’s bad romantic choices is not my jam. But the more I listen to what she has to say, the more affected I am.
There’s a song called Sorry that I thought I understood. What I heard spoke to some of the broken ways I’ve approached relationships – and then I listened and…I realized it spoke to some of the deeper broken ways I’ve approached relationships.
So I’m sorry, to my unknown lover, sorry that I can’t believe
anybody ever really, starts to fall in love with me.
This was the first part I heard. My default when I’m scared in a relationship is to retreat – shields up, and hide. In the past, that included looking for reasons that I should retreat – clues that I was about to be hurt, “proof” that the other person didn’t really want me around. And the clues and the proof that I found were always easier to accept if I believed that whatever I found was my fault.
This…well, it some kinda’ worked. It certainly kept me from being hurt – by anyone other than myself. It also made me blind to people truly caring about me, because all I ever saw were the “early warning signs” that the relationship was going to end.
Don’t realize how mean I can be
’cause I can sometimes treat the people that I love like jewelry.
I can change my mind each day.
I didn’t mean to try you on, but I still know your birthday and your mother’s favorite song.
And then I heard these words. And I noticed that she was lying to herself, because if she remembers their birthday and their mother’s favorite song, there’s no way that she actually changed her mind about them. But…again. Blame. “I was mean, I discarded you. It’s my fault you left. I accept that.”
Someone will love you, but someone isn’t me.
…Yep.
the way you laid your eyes on me in ways that no one ever could.
And so it seems I broke your heart, my ignorance has struck again.
I failed to see it from the start, and tore you open ’til the end.
I thought the summary of this song was, “There’s no way you love me, no way you’d really want to. Someone else will love you better than I can, so I’m glad that you left and I’m sorry for the pain I caused you by trying to have a relationship with you.” I thought she was basically choosing, that she was saying “nope, I don’t believe people love me, so I choose good bye.”
This made sense to me. It fit what I thought I was doing when I ran away.
And then I actually heard this verse. And…I realized that the summary is more like, “I…didn’t know that you loved me. I couldn’t see it. And what I could see, I didn’t believe. Because I didn’t believe, I kept you away, and that hurt you. So…you left. So…I will let you go, and I will choose to believe that someone will love you better than I can.”
…and then I realized what I was really doing when I ran away – I realized that I ran because I couldn’t see. This summary explained how it felt to find myself running away when I didn’t mean to – and it explained what I was afraid would happen every time I found myself running.
When Josh told me that I should explain what I learned about this song, I sort of painfully asked him why on Earth I would ever do that. We’re pretty open about our souls here, but…this is deep damage. And it isn’t fully healed damage, and…actually I hate that I do it.
I also just…don’t have any stellar advice on how to not do it. I started to learn how to not do it on accident, because of a relationship that was more important to me than the sense of self-protection that came from running away. Since then, I’ve fought through multiple layers of this thing. At every layer, it comes down to deciding which is more important – the relationship or feeling (falsely) safe. I keep choosing the relationship.
The only way I know of to do that, to choose the relationship in the face of a lot of fear and the instinct to run and hide, is via trust – trust the other person and trust God. With trust, I can believe that the people I’m in relationships with love me and will stick around through all of the pain and confusion and…eventual wonder and joy of “figuring it out.” With trust, I can know that if they don’t stick around, God will take care of me – so the risk of them leaving is not enough of a reason to close myself off from people or run away.
But…this isn’t new information or helpful clarification or a good how-to. The answer to most soul damage seems to be trust. And I did not want to talk about it.
And then Josh, in a tricky bit of wisdom, asked me why understanding the song mattered so much to me. And…it mattered because it put words to my broken. It described it, accurately. The existence of words that described my broken told me that I’m not alone in it – and that I’m not alone in being blind to people caring about me. I’ve ruined relationships by retreating when I get scared, and that weighs on me. It scares me that I might do the same thing with the relationships that are so important to me now.
The existence of words that described my broken told me that I’m not alone in it.
I said that my new understanding of the song explained what I’m afraid could happen when I run away. When I run, it feels like no one follows me. And…really, it isn’t up to them to follow, it’s up to me not to run – which I do manage to figure out. Eventually. But…I worry that before I can figure it out, I will run too far. And, having run too far, it will take too long to find my way back, or I won’t be able to find my way back – and that if I manage to get back, by the time I get there, no one will be left waiting for me.
So…ultimately, I think I’m explaining this because hearing the words and knowing I wasn’t alone helped me get past another layer of this broken thing I do. It helped me identify it the next time I did it, and because I understood what I was doing, I knew that trust was the answer – even in the midst of sheer panic.
Sometimes seeing our broken, having the words to accurately describe it, is one of the most important ways to heal. And the words in this song helped me see this jagged stabby place in my soul clearly enough to be aware of when I was inclined to run. And it helped me remind myself to trust instead of run – and it helped make it easier for me to stay.
Developers are a huge part of organizational success. Way back in 2013, Stephen O’Grady said that developers are “kingmakers” – so this idea is not new.
As a society, we’re increasingly connected – to each other, and to the businesses we choose. Those connections, and those businesses, run on software. We’ve moved to hitting a website or using an app to do business instead of picking up the phone – and even if we call a company, the person we’re talking to is definitely using software on our behalf.
We said that we’re more connected to the businesses we choose – and we do have significantly more choice about which businesses we use. The business’s software is part of how we make that choice – if it’s engaging and easy to understand and use, then working with the business as a customer is easier. If working with a company is easier, we’re more likely to go back. If, on the other hand, the website or app doesn’t work, or it’s confusing, we’re more likely to use one of the many alternatives that the internet allows for. Basically…
Customer service is characterized, facilitated, and proven by a company’s software.
Software driving a business’s success is also not a new idea – in fact, it’s the core concept behind the ideas of digital transformation and digital disruption. If we accept that it’s true, the next thing to consider is how to make software successful.
Software’s success is determined by how well it’s designed, built, and maintained. Great software can’t be built by mediocre developers using mediocre architecture, running on and designed for mediocre platforms. So…that means that businesses really need to know, “how do we enable our people to create amazing and engaging software?”
Software drives a business’s success – and software’s success is driven by how well it’s designed, built, and maintained.
What do developers need to be successful? Well…they need several things, but first they need to understand the rules of the software they’re building: what is it intended to do? How does it communicate with other software? What APIs, services are available? Where is data permanently stored? What languages can I write it in?
These questions are all architecture. The answers should be clear and consistent, and they should allow for flexibility in implementation. They should also allow for development speed and developer familiarity – usually by using modern, standard technology with lots of community support.
Open source technology is usually the best for enabling happy developers. The communities around open source development are strong, and they’re full of skilled, passionate people who love the technology they’re contributing to – and they contribute to technology that they would love to use. Spring (Java framework), NodeJS (JavaScript run time environment), Ruby (general purpose, object-oriented programming language, like C++ and Java), MongoDB (document database), and Kafka (pub/sub messaging) are all examples of great open source architecture ingredients that developers actually like to use.
Developers need to know what tools are at their disposal to develop, test, and run their software. They also need those tools to be kept up to date – via updates, or via new tools that accomplish what they need better, faster, or less painfully.
They need an IDE they understand – and enjoy using (we like IntelliJ, but nerd tools are something like holy flame wars, so…you do you. Laine quite happily made entire web pages in Notepad++ as a teenager, soooo…). Think about your office, or the primary tool you use to do your job – that’s an IDE for a developer. It needs to be comfortable.
They need code repositories (Git-based, Bitbucket is great), and security scanning (Sonarqube, and a dependency scanner), and test automation, ideally built in as early in the process of development as possible. They need fast build tools so they aren’t forced to stop everything and wait in order to even see if a change works (Maven, or Gradle), and automation where and how it makes sense, for builds, or deployment, or…whatever (Jenkins, or Ansible).
They need a good platform on which to run their software, ideally one that gives them the ability to self-serve…well, servers, so they don’t have to wait a week or a month or even a day to move forward once their code is ready (OpenShift).
Confusing release processes, slow purchase processes, unclear approval processes for free tools – these are all processes that choke innovation, and worse, choke a developer’s ability to even execute. To enable developers, a business actually wants them to have some freedom to stretch out – to use their skills, and to discover new skills.
Independent of IT processes, there are also HR processes – like rules that dictate many hours must be worked, or rules that don’t “count” any work done from anywhere other than on site. IT is an art, not a formula – IT brains are constantly designing and adapting and connecting information – and then refining those designs, adaptations, and connections. Expecting, and behaving as though, X developers = Y lines of code, and Y lines of code = Z business priorities delivered causes pain and actually slows developers down.
IT is an art, not a formula.
So…there are bad processes that, if stopped or lessened or sometimes just explained will enable developers. There are also good processes – giving them a comfortable means to communicate with each other (Slack! <3), or encouraging easy ways to learn and grow and try things without repercussions.
Application developers need support – people backing them up and fighting for them, and supporting the tools they need to do their jobs in the least painful way possible. They need Architects setting architecture standards, and making sure that people talk to each other and agree about how all of the software into, out of, and within a company will interact. They need Platform Architects (sometimes called Enterprise Architects or Infrastructure Architects) setting up their platforms and making sure their apps run, and giving them access to get clear, fast feedback about their applications from those platforms.
They need people who will cut through any cultural red tape to get them the information and tools and good processes that they need. They need HR managers who support their career and their personal and professional growth. They need technical leadership who teach and advocate – new architecture patterns, how to actually use new tools, what works and definitely does NOT work between teams and in other companies. They need people explaining how to use the tools provided and giving them permission to adapt the “how” in such a way that the tool is not onerous.
They also need each other – people who are native speakers of their language, who are trying to accomplish roughly the same things in the same ways with the same barriers.
Developers drive organizational success, but they need teams around them – supporting them, and fighting for the processes and tools that will help them be successful.
A healthy ecosystem is vitally important to developer success.
So…it isn’t actually just developers who drive organizational success – it’s teams. Teams centered around development, and enabling that development, but…definitely teams.
Successful businesses have successful software. Successful software is made by enabled developers. However, the truth of the matter is that because we are all so connected, no one exists in a vacuum. Developers need architects, and infrastructure people, and leadership (HR and technical, along with vision setters and vision communicators), and cutters of red tape, and purchasers of tools, and each other to truly be successful.
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. (Wikipedia)
At the end of 2017, we were both OpenShift Architects at our last employer. We were working on integrating the new-to-us platform with the existing processes of the organization – especially the build, deployment, and release processes. Most of the applications on OpenShift would be Java applications, and all Java builds were done with Jenkins. There was a release management tool that was written in-house serving as a middle layer to control deployments and releases.
We (the organization) were also in the middle of transitioning from enterprise Jenkins + templates to open source Jenkins + pipelines. There were only a handful of people in the very large IT division who even knew how to write a pipeline – and we took on writing the pipelines (and shared libraries) that would prove out a default implementation of building and releasing to OpenShift. We knew this would be a huge challenge – if done properly, the entire company could run their OpenShift deploys on this pipeline, and it could be improved and grown as more people contributed to it via the internal open source culture that we were building.
We ended up doing this via pair programming – because we work really well together, mostly. However, because we’re both technology nerds and also people/culture nerds, and because pair programming has some push-back from more traditional organizations, we wrote down the benefits we saw.
The team Laine was assigned to was the team that oversaw Jenkins administration and the build process, along with the in-house release management tool – but she’d only been on that team for about 4 months. She knew more about Jenkins than Josh, but….not by much.
Josh was the one who spearheaded bringing OpenShift into the company, and so he knew a lot of the theory of automating OpenShift deploys and had a rough idea of what the process as a whole should look like.
…basically, neither of us really knew how to do what we set out to do, and actually we didn’t intend to do something that fell into the realm of pair programming. We just already relied on each other for many things, including understanding and processing information, and we both deeply loved OpenShift and saw its potential for the company we also loved. We were determined to do as much as we possibly could to help it be successful.
Mostly our plan was to just…try stuff. We followed the definition of pair programming above some of the time – we took turns writing while the other focused more on review, catching problems, and planning the next steps. This was awesome, because we caught problems early just by keeping an eye on each other’s work – like, “uhh, you spelled ‘deploy’ D-E-P-L-Y, that’s not gonna’ work…”
Taking turns doing the actual coding also allowed us to churn through research while still doing development. We’re both top-down thinkers, which means that we understood the steps that needed to happen without knowing quite how we would implement each step. With one of us researching while the other was coding, as soon as one coding task was complete, we could more or less start right away on the next. Given the amount of research we had to do, this was huge in speeding us up. It also allowed us to switch up what we were each doing, and not get bogged down in either research or implementation.
In addition to taking turns coding vs overseeing, we also did a lot of what might be called parallel programming – we worked closely on different aspects of the same problem at the same time. This was also highly effective, but it required us to be very much on the same page about what we were doing. We did this mostly off-hours, via Slack communication, so…it wasn’t always a given that we actually were on the same page.
Despite the communication hijinks, or maybe because of them (it was really funny…), this was probably the most efficient of all of the coding work we did. If we got stuck or didn’t know how to solve a problem, the other could easily figure out how to help because we were already in the code. We also bounced questions and implementation ideas off of each other (efficiently, because we didn’t need to explain the entire project!), so…something like pair solution design.
And again, up there in overall efficiency, was some pair debugging. We could put our heads together to talk through what was broken (aside from typos…), figure out why it was broken, and land more quickly at the right solution to fix it. (See also: Rubber Duck Debugging)
(Quotes in this section are from Strengthening the Case for Pair Programming.)
Two heads are better than one. Often, the part of development that takes the longest or is the most complicated isn’t writing the code – it’s figuring out what to do, and then figuring out what you did to break it and how to fix it.
Having a person there who understands the project as well as you do can speed up…well, literally all of that.
…virtually all the surveyed professional programmers stated that they were more confident in their solutions when they pair programmed.
Pair programming provides better quality, hands down. We talked about this some already – a pair programmer can catch bugs before compiling or unit tests can, and they can catch bugs all the way from a typo to an architecture or design problem. Pair programming also requires by its very nature discussing all decisions – both design and implementation, at least at a high level.
…basically, you end up with an application where there’s been a design and code review for literally every aspect of the application.
We both had some laptop issues in all of this – Laine had some battery issues, and Josh had his laptop start a virus scan (slowing his computer to the point of being unusable) while he was trying to code. We got on Slack and helped the one who still had a working laptop, rather than that time just…being wasted.
…more than 90% stated that they enjoyed collaborative programming more than solo programming.
Laughing at mistakes, getting encouragement (or trolling) when we did dumb stuff, nerd emoji celebration when something went well – all of these were better because we were working together.
It was just…fun. There was joy in all of it, in both the successes and the failures. And there was joy in the shared purpose of setting something that we loved up for success.
There are a few things we learned that were vital to pair programming going well for us. We think that the following pieces are the most important to a successful pairing:
Without trust, you lose some of the benefit of pointing out mistakes and instead spend the time you’d gain making sure that feelings aren’t hurt. Based on our experience, we actually think that this one is the most important key to success.
You’ll want to find someone with approximately the same temperament and, uh…bossy-ness. We went with Bossy-ness Level: Maximum, but you do you. We both push for what we think is the right solution, and we kind of enjoy arguing with each other to figure out whose solution really is right. If either of us had paired with someone who was uncomfortable with conflict, chances are it…wouldn’t have gone well.
Pair programming probably isn’t going to work very well with a brand new associate paired up with someone who’s been in the industry for 10 years. That’s a lot of context to explain, so while this set up is amazing for training purposes, it isn’t the most effective for software delivery.
Look for someone who knows something you don’t about what you’re trying to accomplish. Laine knew Jenkins and is a Google savant, and Josh knew the OpenShift theory and reads constantly – when automating releases to OpenShift, it was a good combination.
Pair programming provides a ton of value. It speeds up development, catches bugs sooner, and aids dramatically in design and implementation. It’s also fun, which is important and sometimes forgotten about in the just deliver more world of IT.
We loved working together on this, which led to much joy in learning the deep knowledge necessary to build a pipeline the whole company could use. And, even better, it worked – teams that joined OpenShift used and improved upon what we did, and those teams implemented continuous delivery on OpenShift. We’re both very sure that we never have been that successful if we hadn’t paired up on it.
Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads.
– Source: Google, who “owns” the project
…a reasonable follow-up question is okay, but what does “serverless” mean?
Fear is really hard to deal with. Fight or flight is an inherent human truth – we think that if we’re afraid, we must act. But…most of the time, action in the context of fear doesn’t make a ton of sense. It’s very logical in the comparatively rare times that our lives are actually in danger – but in the times we are simply (ha) afraid that we will lose an important relationship, action spurred by fear usually just does a whole lot of damage.
