Why Your Philosophy to Programming Sucks
I recently got mad. Like, genuinely mad. If you know me, you know that’s a rarity. I got mad because I was arguing with another programmer about a project we were working on, and I found out that they had a seriously corrupted philosophy on programming. My current main focus is a cyberattack activity and intrusion detection system with a web application interface, called “CyberTrace.” I proposed this as a final project idea for my full stack development class, although I easily see this project extending beyond the scope of the class and having a life of its own. This is a group project, and that’s partially been great and partially not-so-great.
One of our group members had proposed using ArcGIS in our project. I was open to the idea of it, but I was unfamiliar with ArcGIS and didn’t know how it would fit in, so I asked. Another one of our group members backed up the idea of using ArcGIS, saying that it would be to “filter and have more features.”
At this point, I was confused. Filter? Have more features? What features? I asked them that: “what features?” At this point, I wasn’t mad. I was genuinely curious as to what ArcGIS could do for our project. If it could help us implement some kind of important core functionality, features that would enhance our project, then sure! – let’s use ArcGIS. They avoided the question for a little bit until I asked again: “what features?”
This was the part where I started losing my patience a little bit. They said, “To blow him away,” referring to impressing the professor. I was frustrated again. I didn’t ask what these “features” would make the professor think; I asked what features. I repeated my question yet another time.
And here’s when I realized that this particular programmer had a seriously corrupted, misdirected, confused philosophy to computer programming, to software development, to the very fundamental basis of problem-solving: confronted with the question again, they said, “Extra features.”
This was when I lost my patience and became genuinely mad. I did not ask how many features, I asked what features. The problem with some “programmers” is that they, at a fundamental basis, don’t know what they’re doing. I’m not referring to not understanding a language. I’m not referring to not understanding data structures or algorithms. I’m not referring to not understanding memory management. I mean that at a fundamental, foundational level, they neither understand nor know what they are doing.
Your philosophy to programming sucks because it’s completely backwards. The sane approach to problem solving is to find a problem and then make a solution. What you have here is a philosophy that makes a solution first and then finds a problem. It’s backwards. If you approach software development like this, you’re fumbling blind until you succeed in making a product that nobody wants, because you didn’t design the software with a problem in mind to start, so nobody really has the problem your solution ended up solving since it was an afterthought.
Think about the user first. Before anything else, think about the user. Say: “My user is whom? Myself? Researchers? Consumers? People who have some specific problem X with some kind of task Y?”
Then, ask yourself what problem the user has that you can solve. Say: “My user has what problem? Some hardware in need of drivers? They do some repetitive task X that could be made faster? They need to monitor data about Y?”
After you’ve asked yourself those questions, then, and only then, can you begin to make a solution. That is the sane approach to problem solving. Don’t make a solution first and then look for a problem afterwards. When you do that, you solve problems nobody has, introduce bloat into your project, and find yourself fumbled and confused.
Happy hacking.