I was reading this post by Michelle Bu and it really resonated with me.
When I was starting do go into programming from doing freelancing on design, my morale is probably at the lowest. It’s been the most discouraging year perhaps. Everybody would go how simple it really is, just do this and this. Some would give suggestion of some super big framework that totally addresses your problem and more.
But. No one, no one, showed me how to do it. No one has any intention to. Perhaps it’s too simple, perhaps it will take too long of their time.
The dirty secret
There’s a vast difference between being able to imagine how to code something and actually making use of the tool to code it. Great programmers can imagine the intricacies of the task and have a good plan how to attack it. Helpful programmers can lead you to completion.
Most programmers underestimated the task at hand and trivialize the task. Why? Because they want to get the feeling of having conquered the problem in their minds without actually doing it. You get the same elated feeling when you do that. Not knowing what you cannot do will make you less disappointed with yourself. Programmers trivialize things to make themselves feel better.
Some programmers want to use your asking for help as a platform to show off how well-read they are too. They tell of a library you never heard of and claim how easy it is to get things done there but not how to achieve that for your task at hand.
Explain your rejection
In many ways, if you are a programmer and you do that, what you are doing is rejecting to help someone. If so, say it directly. I sometimes have to say this is a laborious task and I don’t have the time to guide you through. If there’s a tutorial that I can easily find, I send it to the person to get started too. I think people appreciate the truth. Either help them all the way or lead them to get help from some other source. Be encouraging. I won some friends this way.
As we put more and more into programs, debugging becomes time consuming. This quote is particularly true:
As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.
This is just not sensible to me. This is, perhaps, a result of an overly-conservative interpretation of religious doctrines.
Execution of web programmer in Iran may be imminent
A computer programmer from Canada faces imminent execution in Iran for the actions of another person, which he had no control over, a human rights group says.
Saeed Malekpour wrote a program to upload photos to the Internet, an accomplishment that could cost him his life, Amnesty International reported Friday. Authorities in the Islamic Republic claimed his program was used by someone else to upload pornography and charged him with “insulting and desecrating Islam.”
I have done a few projects using CakePHP the past couple of years. CakePHP has grown to become one of the more popular PHP web frameworks, think of CakePHP as Rails-inspired PHP framework.
If you’re interested in CakePHP, you may like to check out CakePHP Application Development by Packt Publishing. This book covers lots of beginner topics such as installation and configuration. It is a good book to get started on CakePHP, it has a step-by-step guide that can be useful for starters. The book targets CakePHP 1.2 however, the book is written before CakePHP 1.2 is released so it does not have updated screenshots in it.
Generally the book’s concept is correct. The explanations are written as if someone is talking to you. If you do not like that style of learning, best you avoid this title. CakePHP Application Development covers a creation of a sample app — Quickwall — at the end of the book. Unlike typical tutorials that teaches you how to create a blog with XX framework, this goes into more depth on how best to use the inbuilt features of CakePHP.
My major grip on this book is its numerous errors in code, and a couple of quite unforgiving ones too. The books could have been better edited. Some of the codes did not appear to run and you have to look around to check for syntax errors. It isn’t often, still it’s a bad impression. The codes in the book are badly indented too. This makes the codes hard to read. It’s a good book to learn, but can be better.
Joe Armstrong, the principal inventor of Erlang, is quoted as saying:
“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”