Complex Logic

As Florida reports its highest number of deaths in a day, I've been called back to the workplace. While this doesn't seem to make sense, it's what I expected. My company stays in line with the government's recommendation and is not in favor of working from home, so I knew as soon as the stay-at-home orders were relaxed, they would call me back. I've really enjoyed my time working from home, and I wish I could continue working from home. My daily quality of life has been much better, and I've really made the best of my time. I think the biggest thing companies worry about when their employees work from home is they can't monitor them as closely. While this isn't actually true, I don't think it's actually necessary either. For some people, they may need close monitoring, and might easily be distracted from home. Those same people probably aren't that reliable inside the office, either. I've been as productive or more productive since I started working from home, and it certainly hasn't heeded my progress. If anything, I'm able to focus at a higher level and I'm more relaxed while doing so. It's definitely opened my eyes up to what I want from future positions, and with this added experience I now have from working from home, I think this will definitely be a priority when I start to look for my next job. I've always wanted to work from home, but I didn't know if I would actually like it. It turns out that I loved it.

It wasn't news that I didn't expect, though, so I'm definitely not taken off guard. The show must go on, regardless. I'm still waiting on my cohort to get the React Native project fully set up for both of us to work on it, and he didn't really gain on it today at all. Instead of being able to work on it, he had to switch gears and work on hooking up the payments application to get it ready to ship. I'm glad this is finally getting done, though. I've been waiting for the backend to be complete for this project for almost 2 weeks now, and it's become farcical. Finally, today, we got word that the database was ready to go, and my cohort set to work on hooking up the frontend to the database. I don't pretend to know much about the process of what he does at this point, but I would really like to learn more about it. All I know is the backend is in ASP.net and the code he writes is in ASP.net. He has some kind of package or something that helps him to compile the JSON data that comes from the frontend into C# and then has some kind of set up to get that data to the SQL database. With this process, emails are automatically generated and sent off to managers and the customer, as well as the sales representative. I believe ASP.net handles the emails automatically, but that's about the extent of my knowledge. I would really like to know how all of this works a little better so I could own the process. Right now, I finish my part of the project and then have to wait on the others on the team to get it shipped, which can take an inordinate amount of time. I'm not saying I could do it faster, but I think if I knew how, I would be determined to get it shipped.

While my cohort is getting the React Native project ready, I've been working on the next version of the payments application, and after about 3 full days working on the code, I think I finally got it to an acceptable place. It was difficult, probably the most difficult code I've ever written, but I can tell you, if I had tried to write this even a month ago, I wouldn't have stood a chance. This feature is basically 9 forms within one. There are 9 boxes, and if any of them are selected, inputs are dropped down below them, coinciding with the box selected. Getting all of this to work together boggled my brain; I think I wrote a total of about 4000 lines of code, and out of that 4000 lines, I only kept about 1000, if that. I wrote the whole thing out really dynamically at first, only to find I had made a fatal error in the way I structured the state management. I brought everything back into one gigantic component and busted the state into 9 individual useStates. I got it to work, but the code was horrendous. At this point, I realized this was the perfect opportunity to write a reducer. I basically needed to manage the toggle of each of the boxes, and with that much local state, only a reducer would make it manageable. So, I wrote a decent reducer that was very light on functionality, and again, I got it to work. I also broke it back out into reusable components and brought the line count down considerably while maintaining readability. Then I realized I could condense the code even more by passing some other bits of state to the reducer. This made the reducer a little more complex, but that's ok. The code became much more readable and I was pretty satisfied with the result. I'm going to show it my CTO tomorrow, so we'll see if it was even worth it.

Until tomorrow!