Definitions matter. They seem pedantic, but they do matter.
What is a square? Fours equal sides, four right angles... right?
Well this is a square too isn't it? obviously not. We can see that this image isn't a square, but what if we couldn't. What if we were dealing with some object that wasn't so easy to understand, and we just never realised we were wrong.
Anyone who has done any olympiad mathematics has probably had this exact same experience: You're sitting an exam, you solve the geometry problem but uh oh, you walk out the exam and you realised that you fake solved. What you had actually done was assume the answer was true, did a bunch of working, and gotten back to the answer.
Maybe in your quest to prove that three points were collinear, you chased an angle that relied on the fact the three points were collinear. Maybe you reverse reconstructed a point that could have been defined in one of three ways, and you used a property you hadn't proven yet.
This is surprisingly common. So for the sake of your sanity, please just write down your definitions and once you have these, then go solve the problem.
Defining things is just good problem solving technique anyway. Once you write down something like
let be the number of ways to partition elements into non empty subsets.
You free yourself to do higher order reasoning. You could write something like . I have no idea how you would even say this in an english sentence, but that's okay. We no longer live in medieval times where all mathematical equations had to be written in prose.
Definitions guide you to solutions. Sometimes defining something one way over another way allows you to do an induction that you otherwise wouldn't be able to do. In geometry problems often times conditions can be interpreted in multiple ways, and different constructions can be more or less helpful in actually solving the problem.
Usually the best definitions are the ones that give you a lot of useful information or help transform the problem at hand into a more approachable one.
Definitions don't solve problems by themselves, but definitions serve as great starting points.
Picking a good definition is very important. Definitions are also very cheap, it doesn't take very much effort to define something. Think about how many definitions must have been written in the whole history of mathematics, and how many of those would fit the name "group", yet despite this we have a single thing that we call a group. What this tells us is that definitions are not equal, some definitions are more useful than others.
Don't be afraid of the sunk cost fallacy, it's okay to explore different definitions and constructions until you find the right one, because good definitions are worth it.
Ideas like continuity have precise definitions, but the power of these terms arises from the fact that on top of their technicality, they allow one to reason more abstractly.
To use a theorem, we can just use the fact that the function is continuous, instead of having to reason through the epsilon delta definition every time. We have the power to both prove continuity precisely and also use continuity abstractly.
This is an idea not restricted to mathematics, but also in programming.
When I first started working on a parser for my A-level pseudo-code compiler I had no idea how to implement a parser for the language until I saw how a "Parser" was defined in Haskell. All a parser of type T really was just an element of type
Parser T = String -> Either (T, String) Error
This is a function that takes a string and returns some stuff of type which it obtained hopefully from parsing some of the string and then the rest of the string which has not been parsed yet, or an error if it failed. That's it, that is all you needed to write a parser. What makes defining a parser so important is that now it allows you to actually reason about parsers in general. Once you have this definition you can create function that takes a parser and returns a parser, what this means is that you can use combinators that combine and alter parsers.
For example, you can create a parser that parses a string and then applies a function to result of the parser. This is called a "map" combinator. You can also create a parser that takes two parsers and returns a parser that applies both parsers on a string one after the other. This is called a "bind" combinator. You can also create a parser that takes two parsers and tries to use the first parser, then if it fails it tries the second parser. This is called an "or" combinator. In fact this is how I implemented my own pseudo-code parser.
Defining things might seem a little pedantic, but definitions aren't just formalities. They're tools for thinking and they are important.