Early on in my software engineering course at Bloc, I made the mistake of saying to my mentor that I couldn’t figure out “the answer” to a problem in one of my assignments. The conversation halted while he pointed something out to me: when you consider the many different ways a software developer can accomplish a task, and then consider that said developer can name objects and methods whatever they want, there is quite literally an infinite number of ways to solve any given problem related to software.

I had not intended to imply that there was only one right way to solve whatever problem I was stuck on at the time, but the message stuck anyway. Software problems have infinite solutions, and infinite possibilities. Some may be better than others, sure, but even that is something that’s difficult to objectively compare in many cases.

I was reminded of this during my most recent assignment for my Blocipedia project (which I will be posting here in the near future). I was struggling to make it so that the creator of a wiki on Blocipedia could add collaborators to the project, so that only the creator, the collaborators, and administrators could view and edit those wikis. I kept wanting to accomplish the task by taking the email the creator entered and using it to track down whichever user ID it was associated with, but I couldn’t for the life of me figure out how to do it.

The funny thing is that the solution I came to instead really isn’t much more complex. Rather than finding a user ID, I took the emails the creator had entered and stored them in a group of emails called collaborators. If whichever user was logged in had an email address equivalent to one of those emails, they would be allowed to view and edit the wiki.

For most people, this would probably be a fine solution. And in this instance, I’m going with it myself because I spent like two days straight trying to solve this problem. But I think it’s important to remember as the resident INTJ Bloc student that there are times when I need to push myself to be better and times when I need to recognize that if a solution works, I should use it instead of trying to go back and do it the way I first thought of doing it just because it popped into my head first. As my mentor has pointed out, it’s often more important to ship code than to belabor every tiny detail.

I have always been my harshest critic, so this is a difficult thing to bear in mind, especially when I’m so new to programming. Just like with writing, however, coding is not black-and-white. There’s typically no “right” way to code something any more than there’s a “right” way to write this sentence. There are certainly several wrong ways to do both, but there’s no definitive approach.

The important thing, therefore, is not to make every line of code perfect, since it can’t be. The important thing is to constantly improve, which is exactly what I plan to do.