Baguhan Biyernes: Mga Kailangan Para Tanggapin Sa Trabaho

Madalas humingi ng mga “tips” ang mga estudyante kung paano sila makakapasok sa mga kumpanya. Ang problema, palaging mali-mali ang mga nakukuha nilang na abiso mula sa “nakakatanda”. Dahil dito, naisip kong ilista kung ano sa tingin ko ang talangang kailangan ng mga magtatapos ng kolehiyo para makakuha ng trabaho:

1. Tunay na kakayahan sa pag-program – Napag-usapan ko na ito noong nakaraang linggo. Maraming mga nakakatapos ng kolehiyo pero hindi marunong mag-program ng solusyon sa mga simpleng problema.

Bago ka mag-apply sa trabaho, siguraduhin mo munang mayroon kang kahit isang programming language na kaya mong gamitin sa isang high-pressure situation gaya ng interview. Mahirap na na mataranta sa gitna ng interview dahil lang kulang ka sa practice.

2. Passion for learning – Sa lahat ng mga bagay na makikita mo sa mga magagaling na programmer, ito lang talaga ang magagamit mo sa isang interview.

Hinahanap ng mga IT company ang mga taong gutom sa kaalaman kasi, una, sa bilis ng paglabas ng bagong teknolohiya, walang lugar sa IT ang mga taong tamad mag-aral (kung tutuusin meron: sa mga bulok na kumpanya). At ikalawa, magastos ang training: malaki ang matitipid ng kumpanya sa mga taong marunong mag-aral sa sariling sikap.

3. Marunong makaintindi at makitungo sa tao – Baka akalain ninyo na puro mga nerd lang na walang ginawa kungdi mag-program ang kailangan ng mga IT company. Pero kung ganoong klase kang tao, sa totoo lang, mahihirapan ka sa mundo ng IT.

Ang software development ay hindi tungkol sa programs o sa computers, ang software development ay tungkol sa tao.

Ang trabaho mo sa IT ay gumawa ng solusyon sa mga problema ng mga tao, mga problema na hindi nila lubos na naiintindihan pero kailangan mong alamin sa iba’t ibang paraan. At para gawin mo yung mga program at system na iyon, kailangan mong magtrabaho kasama ang iba’t ibang klaseng tao.

Kung hindi ka marunong makisama, hindi ka marunong makipag-areglo, hindi ka tatagal sa IT.

Kawawang mga nerd.

4. Kuneksyon – Mas madaling makakuha ng trabaho pag mayroon kang mga kakilala sa industriya.

Buti na lang sa panahon ngayon, napakaraming pagkakataon ang mga estudyante na makakuha ng mga kuneksyon sa industriya dahil sa mga tech-events. Nandyan ang DevCon na bumibisita sa mga kolehiyo para magbigay ng talk tungkol sa IT. Kung sinusubaybayan mo ang mga kumpanya tulad ng Google, IBM, at Microsoft, malalaman mo kung mayroon silang mga event na malapit sa inyo. Mayroon ring site tulad ng WebGeek na naglilista ng iba’t ibang events.

Pumunta ka sa mga event na ito para matuto at makakilala ng mga tao na makakatulong sa iyong makakuha ng trabaho. Wag lang sana maging rason mo yung isang nakasulat sa ibaba.

5. Portfolio – Hindi talaga kailangan, pero malaki ang maitutulong ng pagkakaroon ng isang portfolio sa simpleng dahilan na ang gumagawa lang ng mga portfolio ay yung mga matatapang na kayang ipakita sa mundo ang gawa nila. Karaniwan kasi itinatago ng mga tao ang code nila para “di manakaw” – pero sino naman ang magnanakaw ng pangit na code?

Gaya ng mga tech-events, sa panahon ngayon, maraming paraan para gumawa ng portfolio. Maraming mga libre at murang web hosting sites para sa Web Developer. Hindi ganoon kamahal maglagay ng app sa mga Apple App Store, Google Play, at kung anumang marketplace para sa mga Mobile Developer. At lahat ng developer pwede gumawa ng GitHub account at mag-upload ng kung anumang code na gusto nilang ipakita sa mundo.

Ngayon na nasabi na natin ang mga kailangan para matanggap sa trabaho, mararapat lang na banggitin na rin natin ang mga hindi ninyo kailangan:

1. Certificate – Iilan lang certificates ang talagang magagamit mo sa paghahanap trabaho. Walang disenteng kumpanya ang kumukuha ng tao base lamang sa certificate – kailangan nilang patunayan ng harapan kung ano ang kakayahan nila. Kaya nakapagtataka kung bakit hanap-hanap ng mga estudyante ang mga walang kwentang piraso ng mga papel na ito.

Masasabi nga natin na kabaliktaran sila ng portfolio: ang portfolio ay bunga ng buwan o taon ng pag-aaral at pag-eensayo, habang ang karaniwang certificate na linalagay ng mga estudyante sa kanilang resume ay galing lang sa pag-upo ng ilang oras sa isang seminar.

2. Diploma mula sa sikat na paaralan – Bilang isang nagtapos galing sa UP, sasabihin ko sa inyo ng diretso:

Maraming nagtatapos sa UP, Ateneo, at La Salle na di marunong mag-program.

Dalawa ang implikasyon nito. Una, kung nakapagtapos ka sa mga paaralang ito, hindi ka dapat maging kampante hanggang talagang napatunayan mo na marunong kang mag-program.

At ikalawa, kung galing ka sa isang di-kilalang paaralan, huwag mong isipin na di ka makakakuha ng trabaho sa IT na may malaking sahod (at hindi call-center). Basta alam mo ang kailangan mong gawin, di malayong malagpasan mo yung mga walang kwentang programmer sa mga “bigating” paaralan.

Baguhan Biyernes: Hadlang sa Pag-aaral

Huwag mong hayaan ang pag-aaral sa eskwelahan na maging hadlang sa pag-aaral.
– madalas iugnay kay Mark Twain

Madaling sisihin ang mga paaralan sa mga pagkukulang ng mga bagong graduate. Pero ang artikulong ito ay hindi ko ginawa para mambatikos ng mga guro at eskwelahan (sa ibang araw na iyon), kungdi para batikusin ang mga asal ng mga estudyante tungo sa pag-aaral.

Sa rami-raming mga maling akala na laganap sa lipunan natin, may isang maling akala na nakakasira sa pag-aaral ng isang estudyante – ang akala na sapat na ang makatapos sa kolehiyo para masabi na marunong ka na sa IT o sa Software Development.

Di mo naman talaga masisisi ang mga estudyante kung bakit ganito ang asal nila; mula pagkabata, tinatanim na ng mga matatanda sa kanilang isipan na diploma lang kailangan nila para maka-trabaho – magandang payo para sa mga trabaho ng “industrial era”, pero hindi bagay sa “information era” kung saan hindi nagtatapos ang pag-aaral sa paaralan.

Ang resulta? Mga “CS graduate” na hindi bihasa sa fundamentals ng Computer Science. Mga “IT graduate” na hindi marunong mag-program.

Hindi ka na magtataka kung bakit kahit ang dami ng mga nagtatapos sa kursong IT at mataas ang demand para sa mga developers, ang baba ng employment rate ng mga bagong tapos (<10%). -- At hindi lang sa kolehiyo/eskwelahan ko nakikita itong problema na ito. Kahit sa mga taong gustong mag-"self study", buhay parin itong maling akala na ito:

  • “Natapos ko na TryRuby at TryGit, marunong na akong mag-Ruby at mag-Git!”
  • “Natapos ko nang i-copy paste yung mga code sa libro na ito, marunong na akong mag Ruby on Rails!”

Biglang pag pinagawa mo sila ng isang simpleng programming task, matatameme na lang sila.

Ang payo ko sa mga nag-aaral ng IT, huwag kayong makuntento sa pagbabasa at sa pangongokopya. Dapat i-practice at i-explore ninyo yung mga konsepto na nadadaanan ninyo. At kung pwede, subukan ninyo ring ituro ang mga natutunan ninyo.

Baguhan Biyernes: Mga Idiom at Pattern

Madalas itanong ng mga may balak matuto ng programming kung ano ang kailangan nila para maging handa sila sa gagawin nila. Sa totoo lang, maraming magagandang sagot sa tanong na iyan:

Kailangan mayroon kang ‘passion for learning’.

Kailangan hindi ka natatakot magtanong o humingi ng tulong sa mas may nakakaalam.

Kailangan sanayin mo ang iyong ‘analytical skills’.

Para sa akin, mayroong isang magandang sagot na hindi ko gaanong naririnig kahit sa mga bihasa sa programming:

Kailangan matuto kang pumansin at makaalala ng mga pattern at idiom.

Kapag tinuturo ang programming sa mga baguhan, kadalasan ito ang paraan na ginagamit ng mga guro:

  1. Ituro kung paano gawin isang bagay
  2. Magbigay ng problema na kayang malutas gamit yung itinuro sa (1).

Ang problema dito ay tinatrato ng guro na pareho ang Math (kung saan nararapat ang paraang ito) at programming. Hindi sapat ang malaman kung ano ang mga bahagi ng mga program — kailangan mo ring malaman kung anu-ano ang mga posibilidad kung paano mo ibubuo ang mga program gamit ang mga natutunan mong bahagi ng program.

At ang mga kumbinasyon na iyon ay matatawag nating “pattern“.

Kunwari tuturuan mo ng iteration ang isang estudyante. Siyempre ibibigay mo sa kanyang pang-practice ay tung paggawa ng tatsulok na asterisk gaya nito:

*
**
***

Magtapatan tayo: sino sa inyo talagang nakakuha kung paano gawin ito ng walang tulong?

Mukhang simple siya — kasi simple nga siya basta alam mo yung pattern kung saan pwede mong gamitin yung counter sa nested loop:

for i <- 1 to 3:
    for j <- 1 to i:
        print "*"
    print "\n"

Dito natin makikita na hindi nga sapat ang pag-turo ng "basic concepts" lang sa programming. Kung tutuusin parang dinadaya nating mga guro ang mga estudyante pag hindi natin pinapakita at pinapaliwanag itong mga pattern na ito bago natin binibigay yung mga ganitong klaseng exercises o tests.

At sino naman yung mga nakakakuha ng tamang sagot?
Tama, yung mga may karanasan na sa programming i.e. yung mga estudyante na may kaalaman na tungkol sa mga pattern na ito.

Magbigay pa tayo ng isang halimbawa. Paano mo isusulat itong expression na ito?

kung ang pangalan niya ay Juan o Maria, gawin mo...

Pag tinuro mo lang ang konsepto ng boolean logic operators, malamang ang gagawin ng estudyante mo ay:

if name == Juan or Maria ...

Pero itanong mo sa kahit na sinong marunong mag-program, ang tamang code diyan ay:

if name == Juan or name == Maria ...

Isa nanamang pattern.

--

Kaugnay sa pattern ang mga idiom; pwede nating ituring na pattern lahat ng idiom.

Ang mga idiom ay mga pattern na madalas mong makita sa mga program na hindi ganoon ka-obvious para sa mga baguhan. Yung name == Juan or name == Maria natin sa taas ay isang halibawa ng idiom.

Kung tutuusin, pwede nating tawagin na idiom ang "=" operator sa mga programming language na gumagamit nito bilang assignment operator.

a = 100
b = 2
a = b

Para sa mga taong walang alam sa programming, walang saysay ang tatlong linyang iyan. Tinuro sa atin sa algebra na hindi pwede ang ganyan.

Subalit para sa mga developer, dahil iba ang ibig sabihin ng "=" sa ilang programming language, mayroon itong saysay at mayroon itong ginagawa.

Baka isipin ninyo "ang hina naman ng baguhan kung nalalabuan siya sa 'idiom' na iyan". Pero sige nga, subukan ninyo ngang intindihin itong Haskell code na ito:

a = do x <- [3..4]
       [1..2]
       return (x, 42)

Kung hindi kayo pamilyar sa Haskell, tiyak na malilito kayo sa ginagawa ng code na ito. Mukhang dapat madaling maintindihan yung do-notation o kahit man lang yung return, pero pag pinag-aralan ninyo kung ano ang ibig sabhihin ng mga idiom na yan, magugulat na lang kayo na malayo sila sa inaasahan ninyo.

Sa example na ito rin makikita na minsan binibigyan tayo programming languages ng mga paraan para isulat ang mga idiom. Halimbawa:

count++;  /* increment by 1 in C-based languages */
if 10 < x < 100:  # one way to range check in Python 

--

Hindi lang sa programming language nakikita at nagagamit ang mga pattern at idiom. Sa lahat ng level ng software development, mayroong mga patterns na sinusundan para mapadali ang

Halimbawa sa game development, lahat ng computer games gumagamit ng game loop:

while( user doesn't exit )
  check for user input
  run AI
  move enemies
  resolve collisions
  draw graphics
  play sounds
end while

Iba pang halimbawa ng patterns ay ang Model 2 at MVC ng web development, at Design Patterns ng Object Oriented Programming.

Sa madaling salita, mas mahalaga ang pag-aaral wastong paggamit ng patterns at idioms ng mga languages at platforms kaysa pag-aaral ng languages mismo.

Baguhan Biyernes: Bakit ang daming terminology na binabato sa iyo pag nag-aaral ka ng programming?

(Susubukan kong gumawa ng isang “weekly column” tungkol sa pag-aaral ng programming at software development. Bukod sa extra advertising para sa Pangkaraniwang Developer, mahahasa ko rin ang aking pagsusulat sa Tagalog.)

May isang magandang thread ngayong linggo sa r/learnprogramming kung saan nagrereklamo ang isang nag-aaral ng programming hinggil sa rami ng terminology na nakikita niya sa isang tutorial. To paraphrase/translate:

Isa akong baguhan na sinusubukang matuto ng jQuery, pero noong ini-introduce ako sa kanya ng kakilala ko, maraming lumabas na mga terminology na hindi ko alam sa 5 minutong usapan na iyon:

  • bind
  • delegation
  • node
  • handler
  • listener
  • event
  • bubbling

Ganito ba talaga kahirap matuto ng programming?!?

Pag binasa ninyo yung thread, madaling mahalata yung problema nung nagtatanong: hindi pang-baguhan ang jQuery, pero gusto parin niya itong matutunan kahit hindi pa siya bihasa sa JavaScript.

Gaya nga ng sabi ng ibang commenter, parang pumasok siya sa isang Calculus class kahit hindi pa siya dumaan sa Algebra at Trigonometry, at ngayon umaangal siya na hindi pinapaliwanag ng propesor ang sine at logarithm. Kaya nga may mga terminology tayo — hindi lang para hindi tayo magsayang ng oras sa pagpapaliwanag kung ano iyon, sa paggamit ng terminology, ipinapalagay na ng kung sinumang gumamit noon na maiintindihan na ng nakikinig/nagbabasa kung ano ang gusto niyang ipahiwatig kahit hindi siya simple.

Halimbawa, maraming pwedeng ibig-sabihin ang “node” kahit sa computer science, pero pag lumabas siya sa usapan tungkol sa jQuery, dapat naiintidihan ng lahat ng nasa usapan kung aling “node” iyon.

Sang-ayon ako sa huling payo ng mga commenter: dapat unti-untiin niya ang pag-aaral ng programming. Sa web development, medyo marami kang dapat matutunan bago ka mag-jQuery: HTML, CSS, at intermediate JavaScript. Hindi magandang sumabak sa isang tool o framework na ginawa para sa mga experienced developers kung ikaw mismo ay hindi experienced developer.

Pero kung tutuusin may punto rin naman siya. Hindi mo maiiwasan na dumiretso sa mga intermediate topics ang mga baguhan kaya mabuti kung mayroon kang mga paraan para mas mapadali yung buhay nila.

Kaya nga sa simula palang ginawa ko yung PD na may mga “Previous Lesson” links para malaman ng mga student kung ano yung mga kailangan nilang malaman bago nila pag-aralan yung current lesson. Balang araw, magkakaroon rin ng glossary of terms bawat lesson para hindi mahirapan ang mga student sa paghanap ng kanilang kahulugan. (Pero saka na iyon, tinatamad pa ako ;P)

Just Shut Up And Do It!

As with all prudent website owners, I regularly check my analytics for my sites to see trends and the occasional weird referrer (e.g. just tonight my Wooga post was linked by some Korean guy on Facebook).

In addition to Google Analytics, I also use Piwik so that I could see the IP addresses of visitors without having to go and open the nginx logs. Unfortunately, Piwik’s somewhat unreliable with the IP lookup:

Piwik

When that happens, I turn to any one of the many Whois and IP lookup sites and see where these visitors come from.

One thing I noticed about this approach is that I sometimes search IP addresses which are similar to past searches. If I had a way to list down my previous searches, I might be able to reduce the amount of these repeat lookups.

Now the obvious first choice would be to build a Rails application with Geokit and call it a day. But that wouldn’t be fun, wouldn’t it?

So instead of doing that, I decided to take this opportunity to finally learn Backbone.js.

A couple of hours later…

Trac(k)er

Introducing Trac(k)er, a quick and dirty IP tracer/tracker built with Backbone.js, Backbone.localStorage, Zurb Foundation, Flag Sprites, geoPlugin, and Google Maps.

You might be wondering what’s the connection between introducing a simple web application and the title above. The answer’s related to a previous post where I ranted about people who wait until they get a certain tool before trying to learn something.

This time around, I’ll be taking aim at a superset to that set of people: people who talk about wanting to do something but never get around to do it.

When I want to learn a new technology, I do the following:

  1. I read up on the technology, maybe watch a few presentations about it, all just to see what it’s about.
  2. I find a current problem that I have that can be solved by that technology.
  3. I try solving that problem with that technology.

My 3-4 hour romp through building a mashup with Backbone and GeoIP is a perfect example of this approach. I’m nowhere near the level of even a competent Backbone developer, but at least I have a passing knowledge of the basics behind the technology.

Pretty much everything I learned on my own was like this. I learned how to setup and manage a LAMP stack to let me try out various PHP apps like WordPress and MediaWiki. I learned Rails to help out in building my friends’ inventory management system web app. I learned nginx because Apache was eating too much memory when I had a memory-intensive web app. The list goes on…

On the other hand, when they want to learn a technology, they go:

  1. They hear about the technology and get hyped.
  2. They talk about how they’re going to learn that technology.
  3. They realize it’s a lot harder than they expected and they start making excuses.
  4. They make a big excuse so that they can abandon the technology and move on to the next shiny thing.
  5. Lather, rinse, repeat.

So my suggestion to people who want to learn something new but don’t want to become like the latter:

Just shut up and do it!

And my suggestion to those who have “legitimate” excuses for not being able to push through with what they planned to do:

Just shut up the next time!