If you have not read my previous and first blog post, I highly recommend you do in order to get a sense of the topics and ideas I will throw out.
Now that we are all settled, let's get into the title. You're probably pondering upon the title and asking yourself, "Now Ben, when are these strange titles going to stop?". You also probably have your mouse hovering over the back arrow, which is perfectly reasonable and understandable, but wait! If you click that button, you could miss out on some lessons that might be worth while depending on the situation you are in. If you're caught between a rock and a hard place, be sure to read until the end.
This blog should be a place for the clutter-minded programmers to come and ease their troubled minds. A place where students can come to rest their eyes and fingers. A place where homework is done, and the code passes tests and performs flawlessly.
Now without further ado, let's continue into the topic.
First off, several of my programming mates, several being one, dislikes numerous quirks I exercise while performing my tasks and jobs. This section is here to reinforce my ways. To prove a method for my madness! (Get the title now?)
Number one: 'Ben Numbers'
Reader: "Uhh, what are 'Ben' numbers?". Great question! Ben numbers are real numbers that appear as irrational floats in code. These values are not returned, but declared. Many people, such as this certain one, dislike these numbers. Why do I appreciate their cause? Ben numbers have the capability of providing more accurate positions and rates.
Now that we have that out of our way, let's move on to the next topic: Skipping tests.
Many of you not part of a group that runs tests on code prior to its deployment, which is alright. My point here is short and concise. Tests can lead to the build-up of time, and depending on what you run and how many (I run 5 and they can take around two minutes) you run, it might be quicker to "Ship it" and avoid the tests. Nowadays I am comfortable enough with my skills to set the title for this blog as my title, but also skip tests. If you run the tests every time, you're essentially taking small chunks of time just to get an error, or an annoying statement that says, 'Congrats! Subtract two useless minutes from your day!". Now, when you write big programs or are relatively new to a certain language, running tests are not a bad idea. However minor changes are not necessary in my opinion! Not only do they waste time at some points, crashing right away, and performing a part of it, could be very instrumental in cracking the error.
I hope these two concepts make enough sense that you see where I am coming from, but you do not need to agree.
Congratulations! You made it to the end and heard and reviews the method to my madness! Now for my words of wisdom from the day.
I understand that there are large obstacles in everyone's life, and you can get bummed out all the time. And I mean, all the time! But you must remember: if you claim to have hit rock bottom and you've sunken so low, what are the odds of your day improving to your day getting worse? Hmm? When you sit down on your couch after a hard day and think "Why did I do that?" or "Why did I say that?", I want you to think about what you can do to repair yourself, or get rid of the bug in your code! Make it up to them, rebuild, reconstruct, and most importantly, do not get distracted from the future. The future is everything while the past means and does nothing, except act as a footnote simply pointing to what we could improve or fix. So the key points?:
- It can only get better.
- Rebuild and regenerate!
- You cannot change the past, but you can influence the future.
As I wrap this up, I hope I leave you with a sense of satisfaction and relief, while providing a method to my madness. So, as a friend who understands the struggle, and the cure, have a great day, and an even brighter future!
No comments:
Post a Comment