“Turuan ang sinumang Pilipino na gustong matuto ng Programming o Computer Science.”

If there’s a tagline for my current project, Pangkaraniwang Developer, that would be it.

No need for a lengthy blog post, just head over to the About page and learn why I’m doing this.

Donations are always welcome. LOL

Last Sunday, while waiting for the final pitches, I (an unemployed slacker, LOL) got to sit at the same table as John Arce of WebGeek, Jason Torres of Proudcloud and ArtisteConnect, Rico Sta. Cruz of (among other things) JS2Coffee and Sparkup, and Eric Su of PicLyf.

The surreal thing about this was not just the fact that I got to be with these big names in the local tech industry, but the fact that, contrary to what the tech media would lead you to believe, there was no “rockstar” thing going on in that table.

As it stood, we were just a bunch of people who build software talking about building software.

We need more of this in the tech industry: people collaborating and talking about great ideas, and less pissing matches and startup fan fiction.

Go over there and watch them now.

Can you help me with this? I’m going to take a technical written exam for a job i’m applying. Here is the list of what are expected on the exam:
-Basic Programming
-OOP
-recursive programming and variables in programming
-? statement
-conditional statements
-loop statements
-flowcharting
-pseudocodes (strings,odd/even)
Can you guys give me tips and heads up on where to focus and what to expect on the exam? The exam will be next week and I want to be prepared for it. Thanks in advance.

PS: Hindi ko alam kung anong programming language ung eexam. (I don’t know what programming language will be used in the test)

Whenever I see these type of questions, the first thing I do is give a ಠ_ಠ to my monitor. The listed coverage above is so basic that every 2^nd year college student should have no problem with it.

It’s like a carpenter asking what tool to focus on when applying for a carpenter position: screwdrivers, hammers, saws, or measuring tape? Yes, it’s that basic.

Unhelpful snarkiness aside, what advice would I give to these fresh grads?

There only need to do two things:

1. Relearn the basics

If you’re not confident about the things listed above once you’ve graduated college, it may mean that you don’t have a good foundation with the fundamentals yet. So the best advice I could give for that problem would be to forget everything you know and start over using the following books:

• Learn to Program by Chris Pine
• Learn Python the Hard Way by Zed Shaw
• Think Python or Think Java by Allen Downey
• Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Sussman (optional, if you want to double your starting salary. LOL)

When reading these books, you may find out how outdated or incomplete your college courses were back when you were taught programming. This is normal, and is an important part of the (re)learning process.

While you are reading these books, you may do the second advice at the same time:

2. Practice. Practice. PRACTICE!!!!

Apart from lack of fundamentals, the other reason you might not be that confident in going into a technical interview is the lack of coding practice — you should’ve encountered all of the things above had you coded thousands of lines of code before graduating.

So practice! Go to Project Euler and try to solve the problems! Go to Top Coder and do the same with the High School competitions!

Find algorithms and try to implement them! Start with simple ones like the Sieve of Erasthosenes and Conway’s Game of Life, then move on to progressively harder ones like Quicksort and Dijkstra’s Algorithm.

Also, don’t be content with just writing code; make an effort to read code. Good programmers are like good novelists; they read a lot more code than they write so they know what looks right and what looks wrong.

In other words, if you can’t figure out how to code something, just search for sample code on the internet and study them.

—

Just to wrap things up, I’ll be commenting on the items in the “technical interview coverage” listed at the start of this post.

-Basic Programming
…
-…variables in programming
-conditional statements
-loop statements

If you’re not familiar with these after a CS/IT course in college, I really question the quality of your education.

-? statement

It’s the conditional operator, used for writing if-then-else statements in shorthand.

Technically speaking, you really don’t need to use this (and in turn, don’t really need to know this) but there are a lot of cases where the shorter form makes code much easier to read. (And there are a lot of cases where it makes code really hard to read, but that’s another story.)

-recursive programming …

This is recursion. There are two types of interviews that use recursion:

• The bullshit type that makes you use recursion for tasks that can be done with simple loops like factorial and fibonacci sequence. If you know what loops are (and you should) and what recursion is, this shouldn’t be hard for you.

  Why do I find it bullshit? Because any programmer worth his/her salt knows how bad tail recursion can be in certain languages.

  If a decent technical interviewer would ask me this question, I’d expect a follow up question on how to eliminate the tail call.

• The good type of interview that really requires recursion i.e. the ones that require stacks and backtracking. For example:
  

  Given a string of characters, find the longest palindrome within the string.

  These problems may be harder, but they’re very much doable if you practiced the way suggested above.

-flowcharting

As I’ve mentioned in last night’s tweet, flowcharts are cute but useless. Anything less than Data Flow Diagrams or UML Diagrams can be better written as pseudocode.

-pseudocodes (strings,odd/even)

Which brings us to this one. Pseudocode has nothing to do with “strings,odd/even”. My guess is that this just wants the applicant to be comfortable with writing pseudocode that deals with strings. (and numbers?)

-OOP

Now here’s the hard part. Even I didn’t have good OOP knowledge even after graduating from college.

Fortunately, the books listed above have decent chapters on OOP so just read up on the topic and practice.

And finally:

PS: Hindi ko alam kung anong programming language ung eexam. (I don’t know what programming language will be used in the test)

This means the test is language agnostic and you will be coding in pseudocode. Just use the language you’re most familiar with.

If the interviewer berates you for syntax errors on code written on a whiteboard or a piece of paper, you probably won’t want to work in such a company. Trust me.

–

In closing, most technical interviews are just there to weed out applicants who pose as developers but can’t really write a line of code. So if you really know how to code, you shouldn’t have a problem with them.

And if you do fail, just take it as a sign that you need to practice harder. Unlike in other fields, a few months of practice in programming will actually help you get better jobs.

Screenshot again with my depressing lotto app:

Overall, it’s ok, especially with the Explorer plugin. However, there are still a bunch of stuff I’d nitpick about:

• Split screen is limited to 2 screens. Which is weird limitation considering both vim and emacs can do an infinite number of them.
• EOL symbols are ugly and can’t be modified.
• No Haml support yet.

At first glance, this tweet in response to my previous post looks like a simple joke. But it’s actually true the more you think about it.

Understanding body language is important because software engineering is more about dealing with people than with software itself: almost all failed software projects are due to people problems (e.g. management and client problems) instead of technology problems.

Here are some cases where knowing body language can make a difference:

• A client asks for too many features under an impossible deadline – by gauging the client’s behavior, you can determine if she’s basically bluffing (to which you negotiate a compromise by reducing the scope) or if she’s really that stupid/sadistic (to which you drop the client for better ones).
• A developer puts in too many hours into overtime – depending on the dev’s behavior, a good manager would determine if that dev is simply temporarily getting brownie points for a promotion or upcoming long vacation. On the other hand, it may also mean that that dev is incompetent to the point that he needs more hours to fix his crappy code. At the worst case, it may also mean that that dev is already at stage 2 – 3 of going into burnout.

Another non-technical language you need to learn is Basic English.

Go ahead, laugh. But then recall the last time you’ve seen a “plz send me teh codez” post in a public forum or a job posting full of misspellings and grammatical errors (a big warning sign) and you’ll quickly realize how important it is to have a good grasp of the English language.

Lack of proper written English skills is a somewhat widespread problem in the current generation, with the prevalence of text-speak and the fact that a lot of young people don’t join international community websites/forums/mailing lists/chat rooms. This can be a problem when they enter the corporate world, where semi-formal English is the lingua franca: I’ve even heard of stories of project managers re-writing some of the team members mail before sending them to their foreign counterparts because of their poor English.

Note that your English doesn’t need to be at the level of essayists or other professional writers. In fact, simple, direct to the point (but at the same time, polite) messages is much more effective at communicating to clients or team members when compared to long-winded messages full of highfaluting words. Doubly so when dealing with clients whose primary language isn’t English.

To wrap things up, I just realized that I wrote about a similar topic a few years ago. You don’t need to click that link, as the tl;dr is just the same thing I’ve been saying all the time: developers need to learn more than just coding.

Anyway, the point of this post is to answer a question posed to me by a student in the Q&A portion of the talk:

Anong programming language ang dapat naming pag-aralan?
(What programming language should we learn?)

Here’s a question I wouldn’t want to hear answered by someone else (i.e. someone who’s also invited to talk to students). The question itself may seem simple, but unless you’ve seen how the industry works as a whole, you’ll probably give a wrong answer.

The traditional answer I don’t want to hear is to give a suggested list of languages based on market demand.

Simply put, this is bullshit. This is the same sort of bullshit that pressures our youth to take nursing courses even though they’re just in it for the money, money that they probably won’t get due to the eventual over-supply of nurses.

So for the student’s question, I gave two answers:

Programming language and platform choice doesn’t matter, because for the most part it’s a business decision.

Yes, I’m talking about steaks and strippers. In a large company, you may be initially hired to work on a single language, but eventually there will be a time where the company will make a business decision to shift technologies, whether due to market pressure or due to a new client. If you focus too much on a language, you will not be prepared for the change and you may end up getting fired or demoted.

In smaller companies or in a freelance setting, language still doesn’t matter, though for another reason: the client will not care about the language as long as you deliver the product.

This leads to the other answer:

Focus on the fundamentals, not on the language/platform.

A common mistake among fresh grads is that they’re confident they know language A or platform B because they were able to make their school projects or theses while at the same time not having their fundamentals down pat. Not only does this make them inflexible in terms of learning new languages, it also makes their work brittle and sloppy.

In other words, a student who has 4 years of school “experience” in Java is nothing compared to a developer who just had learned Java a month ago but has solid fundamentals in OOP.

You might say “Screw learning, I’m just in this for the money!”. But the fact is, there’s this thing called the Python Paradox: developers who are passionate enough to learn more than their peers often end up in higher-earning and less-stressful jobs.

Bottom line: There is no “best” language that you need to learn in order to earn a lot of money. However, if you have good fundamentals, learning the language and platform that the market needs will be much easier for you.

A recent system upgrade gave me a spare SSD for my laptop. I decided to install Linux Mint on it given my good experience on the Ubuntu based OS.

Here are some tips/thoughts related to this install:

Gnome 3 = Full Retard mode

It’s been a while since Ubuntu introduced Unity as the default display manager and it still feels sucky. The mere fact that I can’t change the number of workspaces easily on Mint 12 Gnome was enough to make me format the drive and try again with Mint 11 (which is still Gnome 2).

So I suggest you give Mint 12 a try first for a couple of hours and see if the “simplified” desktop appeals to you. If you’re not satisfied, just go with Mint 11 or Mint 12 KDE.

Lenovo wifi bug also happens on Mint

Remember that post about wifi not working in Ubuntu on my Lenovo laptop?

The same thing happened on my Mint installs. And the same solution still applies.

Changing lockscreen and login background on Mint 11

Remember that post about changing your lock screen on Ubuntu?

While that solution works, there’s also a simpler solution:

$ sudo ln -sf /path/to/another-background.jpg /usr/share/backgrounds/linuxmint/default_background.jpg

Note that, unlike in the old post, this only changes the background and not the whole lock screen.

As for the login background, some people might say that the default background trick will work but unfortunately it doesn’t. The real solution is an old trick from Ubuntu, namely:

$ sudo cp /usr/share/applications/gnome-appearance-properties.desktop /usr/share/gdm/autostart/LoginWindow

Logout. The appearance window will appear on the login screen and will allow you to change the background. After making your changes and logging in, prevent the window from opening again at login by doing:

$ sudo unlink /usr/share/gdm/autostart/LoginWindow/gnome-appearance-properties.desktop

The trick here is that Gimp considers the current directory (i.e. where it is executed) as the default directory. Thus, to change the “default” directory setting in Windows, all you need to do is to open the launcher properties:

And change the “Start in” setting to the folder of your choice.

ffnpdf, a tool that converts FanFiction.net stories into PDF files.

(Great for putting your favorite Harry Potter slash fics on your mobile phone or tablet for portable use! LOL)

The code and documentation are found at the Github page. Theoretically, this gem can work anywhere Ruby, pandoc, and XeTeX can be installed (e.g. Windows, OS X, *nix) but I’ve only been able to make the whole thing work in Ubuntu/Mint.

Demo and how-tos are posted in this playlist:

I haven’t gotten around to make a license for this, but I assume that anyone into fanfiction knows that publishing and selling fanfics without consent from the rights owner is a big no-no. Thus, I don’t need remind them that this tool is just for personal use and not for commercial purposes.