What you can, and can’t plan for
Lately, I have been finishing up classes for the semester, and doing a lot of studying, and a lot of finishing up projects. I have learned a few very interesting things both about myself, and about finishing up projects. First off, I have learned that sometimes glossing over the simple things can hurt you in the long run. I have been noticing lately that I tend to get the integrated idea of things. For example, if you were to give me a bolt and a nut, I would completely understand that they are to go together, and because of that, they can hold something together. However, if you were to ask me what the purpose of either one of the individual pieces was for, I would tell you that they are to be used with their pair to complete a goal. This type of thinking has been hurting me lately. So, I have been slowing myself down when I learn something, and asking myself, what is the purpose of all of these things individually, before asking the question about what the process of them are together.
The other thing that I have been learning lately, especially with projects, is that every issue can be in one of three different categories. They can either be something you can plan for, something you should have planned for, or something that you couldn’t have planned for. I have had a lot of these issues come up lately. First off, I have gotten ahead of some issues, but asking myself, and then the client, what happens in case A, or is this situation ever possible. Those types of questions have been helping focus how one of the projects I have been working on have been going. I have been able to figure out the scope of this project earlier, so I don’t end up doing extraneous things that aren’t needed.
The other type of situation, those you should have planned for is something that I have been noticing with a project that I am working on that is nearing completion. There are a few things that have come up in meetings, where we both looked at each other, and were confused about how something was working, and it ended up being an earlier miscommunication and if I would have at that time, asked about specific edge cases like I am now doing with the newer project I am working on, these problems would not have come up. This was a failure on my part that I have learned from that has helped me a lot.
Lastly, there are those cases that you can’t plan for. These are the situations that are never fun to see. The other day, I was out at a clients, installing the completed version of a project for them, and an issue with the password for their local database had been recently changed, so the program wasn’t able to connect to it as desired. This wasn’t a hard thing to fix, but it was an example of one of those issues that was thought should be fine, as the database was used, and it was shown working to us, where something as obscure as the password being changed so the connection wasn’t getting made wasn’t something we had thought of, and the fact that it was a local database meant that the password that was used previously to connect would just get changed. This is an example of my least favourite issues, the one that shows up while you are trying to show your product, but at the same time, these are the issues that I don’t mind dealing with. I like thinking on my feet, and figuring things out while the pressure is on, is something I would like to say I am great at, and I feel it really makes me use those critical thinking skills that sometimes like to try and hide away.
Anyway, That is what I have been doing in the last month or so. Over the next few weeks I will be heading down to Argentina and Uraguy, so expect an update after I get back, but probably not one before I leave.