IT PINOY is now 
watch out for the big changes! 🙂

IT PINOY! in Facebook!

we’re officially joining the facebook community!

here, all you readers can log into and post in the discussion boards your thoughts and share your videos and notes as well…

even if some claims that facebook is just a mimicry of twitter and friendfeed, i don’t really care, i still find facebook as a kewl social network app! in fact it offers us IT PINOYs a chance to share our knowledge (eventually) and create apps for them – i’ve already started looking into their API for a “racket” i have in mind 😉

i have added a button on my upper right hand sidebar for you to click and follow me @ facebook!


10 commandments of egoless programming

The Ten Commandmentsi was looking through some old stuff when i got a chance to see this, which i used when i once conducted a session on programming, thought this be kewl to be posted here.

the ten commandments of egoless programming was originally established in Jerry Weinberg’s book The Psychology of Computer Programming:

  1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.

  2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.

  3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.

  4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

  5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.

  6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

  7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect — so if you want respect in an egoless environment, cultivate knowledge.

  8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.

  9. Don’t be “the guy in the room.” Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.

  10. Critique code instead of people — be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

ruby on rails

IT PINOY‘s you might have heard of ruby on rails, if not then this is the perfect time to learn the newest and the kewlest development tool right now!

there are 2 components here – ruby programming language and the rails framework.

often called as ruby on rails (RoR), this is an open source web application framework and is intended to be used with an agile development methodology. most of the framework components such as spring mvc and orm are already abstracted to the developers! it’s new, it’s hip! much less code! much less to worry about! i myself have been converted!

see this and know why…

learn more from RADLAD in

a java poem

let’s build on our last blog – the OOP song, this time let’s read doug hoff’s java poem….

Static – a Java poem

public class Static {
static Class Public;
public Static Class;
System out;

static {} static Public string;

public class Public {
System out;

public void main ( String print []) {
System.out.print (string);}

static public void main (String print [] ) {
System.out.print (Public);}

the OOP song

“Object-Oriented Programming got a song?” I bet you asked. oh yeah!

all i can say is that finally someone had the balls to express how all IT PINOY‘s felt while learning how to program and how to digest OOP!

see Design Minstrel‘s spin-off of britney spears’ oops i did it again (wtf!!! oh yeah, this will be fun!)

now… tell me if you can beat that! hahaha

IT PINOY’s cut back!

this is quite a delicate topic and rumors are all ready circling the IT industry.

it was said that a blog and an email started it all. that there is a quite noticeable number of employees from accenture being sacked as part of the cost-cutting initiative by the company.

news also reached us that other companies are now doing the same.

if this indeed is true, then it will be a sad long day for IT PINOY‘s.

we here hope and pray that we all be able to get over this hump and survive this volatile economic crisis. good luck to us all. have faith in yourselves IT PINOY‘s cause if you’re good, good things too will come your way… so let’s just have faith!

anatomy of a programmer

the influx of computers and of the information technology (IT) has changed the way we live our lives.

gone are the days when people hang out of their homes and converse with their neighbors or children spending the good summer outside.

nowadays, instead of going out, people opt to stay tuned into television or surf the web through their computers.

so how much did this change affect men? see this funny april’s anatomy of a unix programmer
sad to say, there’s a hint of truth in this caricature 😦

code clean-up!

cory foy put this topic bluntly, “as developers, system admins, and a variety of other roles in IT, we have to deal with code on a daily basis. sometimes it’s just one-off scripts we never have to see again. sometimes we stare at something that, for the life of us, we can’t understand how it came out of a human mind (or, as the book puts it, has a high WTF/minute count). but there is a time when you find code that is a joy to use, to read and to understand. clean code sets out to help developers write that third kind of code through a series of essay-type chapters on a variety of topics. but does it really help?”

i always believe that a clean code is a good code. having had experience as an IT consultant, we come and go to different projects. a critical part in our job is to transition our codes to someone else.
most of the problems however arise when facing messy codes (plus no docos!). in effect, the learning curve takes longer, business cost is higher, and productivity is lower.

so what causes a bad code? from experience, i would list these factors:
time pressure. with limited and immovable due dates, most programmers tend to be lenient in cleaning up their codes just to be able to deliver on time.
training deficiency. not being able to learn best practices,
no coding standards. no standards set from the very start of the development!

i consider chris coyler of smashing magazines 12 Principles For Keeping Your Code Clean as a good read and a best practice.

IT PINOY’s i encourage you to learn and above all enjoy a clean code!