Saturday, December 29, 2012

Why You Should Try

Blog Post 16: Why you should try.

Well, my last post explained why one should always be ready to "prove that you tried" something before asking a question. In this post, I will suggest to you why you should WANT to try something.

People have a lazy tendency. This is not insulting, it is just true. It is in human nature. That is what we do for a living, make things easier for people. (Or more entertaining). We want things easy, even us programmers. I do, I know you do as well.

However, there is a tendency to ask for the actual code, or to not be happy with what information you have been given, because you do not know how to use it. Right? Not always, sometimes, it is because we do not want to take the time to discover how something works. "As long as it aint broke, don't fix it." But this is a mistake. It is creating a culture, where the actual software engineers don't know quite a bit of what they are working with.

Now, this is expected. After all, the people who invented the binary system, don't expect us to learn binary as well as they do. We have better ways to do it... More convenient ways. And that is spectacular! We can create greater things. But, it has come to a new point.

My father is also a software engineer, he does software for Harman, and automotive/audio company. He works specifically on Bluetooth. His division was in desperate need of more workers (Surprising for this age), so they interviewed lots of people. They never could find one that had what it takes. He mentioned to me how hard it is to find programmers that know enough to work there. I believe him.

Today, with graphical UI plotters, like Xcode's IB, and the eclipse plug-in for Android, we just don't need to learn as much. We don't seem to focus on the actual way in which things work, we just copy code. Not all the time, but for a lot.

Now for the real point of this post. When people ask questions, they sometimes want the actual code, and don't want the "hints" or pointers. When they should. If you take the time to learn to get something to work, you actually learn a lot more.

For the longest time, I did not use Stack Overflow. I searched and researched forever, trying to diagnose problems. By doing so, I learned not only about that problem, but other issues I could encounter, and how things work in general. It was greatly beneficial. 

As an example, let's take the first time I tried making a web browser for Mac. I ran into a pretty big problem, pretty fast. This was how my experience went.

Web View won't load. ---> How WebView's work + reasons WebView's won't load. + Others.

How WebView's work --> How they are created + How they are manipulated + delegates + etc.

Why WebView's won't load ---> Example of a problem that applies to the second thing on this list. Problem solved.

That is an extremely tamed down version of what I learned. It took me days to fix the problem, but I learned a lot about webViews. 

So, if someone gives you a suggestion on how to fix something, don't discard the answer and ask for the code, look it up. It's good for you. It's probably good for everyone. And if you are answering someone. Don't give the code as fast as you can, especially if they haven't even tried anything. Help push them, that is what this world needs. A little helpfulness. 

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.