Whenever I read that you should embrace failure, I think that many people won’t get the point.
The human mind loves routine. Routine is a series of steps you’ve done before, in a way that’s always the same. When you know something works in a certain way, it’s a safe feeling that you know what’s coming. It’s the opposite of danger, and the fear that’s connected to danger.
When you read somewhere that you should embrace failure, they really mean that you should change. Change always has a positive effect, and if it hasn’t (you failed!) you can usually change again and learn something in the process, advancing you overall.
What keeps you from change is when you never break your routine.
Every person is convinced that his perception of reality is true. As most of man’s beliefs are only subjectively true, man’s greatest flaw is if he bases his decisions upon the assumption that his outlook on the world is true. An even greater flaw is if he realizes his own inaptitude and is unable to decide anything thereafter. Lack of decision equals stasis. So in order to not fall into stagnation, a strive for finding and connecting the little pieces of information that are canonical and that hold a high probability of objective truth is necessary. This is called science and has to replace religion.
The type “id” is always a pointer, so no asterisk there
Strange effects happen when you “#inport” .h files with cyclical references. I didn’t find a better solution than having id instead of the Type I wanted to use in one of my classes
There are no null pointer exceptions. This means you’ll all the time miss the initialization of some object or some reference and won’t recognize it. Since recognizing this, I love null pointers exceptions. But this is language design in Objective C. So if you definitely need to be sure, throw an exception if you want to be sure and / or add some unit tests.
When the application crashes, you won’t get meaningful answers from the console often times. To get some more information you’ll need to set a breakpoint in the last thrown exception statement. You can find out more here.
When you want to use a simple integer like 5 and get the warning / error “makes Pointer from integer without a cast”, you need to use [NSNumber numberFromInt:5]
Always correct header file first, implemetation file second and always correct from top to bottom, as the compiler does this too. When the compiler sees an error in the header file for example, it might make up 50 more errors somewhere below. This is literally top-down debugging.
There are great resources for iOS development out there, for example the full open source Canabalt game or framework-like libraries that could make some things easier, if you see it before you’ve implemented all such things yourself.
To usual people, it’s often hard to understand why nerds and especially developers often are pretty critical about the way you Google, the texteditor you write in, the way you find that funny link you want to show off or how you do the various tasks at hand on your computer. You want something done and just do it the way you know it and a minute later, your problem is solved, your Google search has found a page that you now browse for the information you need; your Word file contains the screenshot you just took or whatever. Meanwhile, the computer nerds besides you rolls on the flood, apparently died of old age or many from the agony of watching you do what you just did.
Why is it that way? Developers work on their computer the entire day.You’re trying to use the tools they use all the day, and they always know a better and faster or more effective way to solve your problem.They’ve solved that problem 1000 times more than you, and for them saving 30 seconds if a big time benefit.
And using those better waysis like wearing a watch when you never did so before. It feels strange first, often you don’t realize it could help you, but then, you find enough situations where the quick glance on the watch is really much more convenient than getting out your phone buiried in your pocket, klicking a button and waiting the screen to apprear, only to have to lock the screen after that and putting the phone in its safe position.
If you’re programming, you most likely know that problem. You try to solve a problem, and deal with some sort of library, framework or concept you haven’t used before. Inevitably, you fail to get it working right of the spot and get frustrated. This is where people in my field are every day, as we’re using new technologies, frameworks and concepts all the time.
There of course isn’t a precise way to solve such problems. But the only sure way to approach this is to make sure you grasp the underlying concepts. If you’re building a web application with some client side jQuery goodies loading stuff from your struts2-server, the first step isn’t to learn about Struts2 or jQuery. Make first sure you understand:
how a HTTP-Request works
what GET and POST means
that HTTP is stateless and what that means to your application
what JavaScript is and where & how it is interpreted
what AJAX is besides a nice word you heard often
how a server works
what request and response are
what a servlet is
…
Connect all the information
After you have understood the basics, you can go on and understand the higher level stuff. This is what most of us learns while attending a university, but you never have understood everything and you’ll never stop hitting new fancy acronyms and technologies if you’re into programming. But for every acronym you see and that you don’t understand, try to make sure you at least read the Wikipedia page before you try to do some fancy coding by copypasting things you found via Google – because if you don’t understand what you’re using just now, you implemented a black box that might or might not work and that you didn’t learn anything about.
When you approach new concepts, frameworks and technology in that way, you can build up a solid foundation of knowledge that get even more solid every time you learn another new technology that bases on stuff you already know, assuring to yourself that what you learned before is correct. Fast and dirty is slower in the long run. And as such, you shouldn’t be concerned that something takes some time to understand – because when you don’t really understand it, then you won’t be able to fix the issues that will occur anyways. And it’s a long way from zeroes and ones to AJAX.
by h.koppdelaney
