failing like never before


Once More With Feeling

I have a tendency of starting things and never finishing them and an inability to let go of the past. It is a dangerous pairing. Overtime, my mental to-do list has grown precariously large and every new project I take up is an eternal entry in an infinity long list that feeds my worries and doubts. At some point this has to stop, either I learn to take on less or I learn to let go. For now, I'm going to try to start finishing out old projects.

I started this blog by writing a custom ruby on rails web application for a high school economics project (I wanted to grow it as a blogging platform and sell ads). I transitioned my content to Typo (github link) after a year or so, and then not long after that to WordPress, which it currently still runs on. Towards the end of college, after experimenting with, what was then, a brand new programming language called Go, I thought that it would be a great learning experience to write a blog platform in Go. Not to mention, I wanted to get off of WordPress. WordPress is a perfectly functional application, but it is a sawmill when all I really need is a pocket knife. I find emacs to be preferable to a browser based WYSIWYG editor and I don't want complex, flashy templates laden with javascript. What I want is simplicity and something that just works. Its been more than ten years since I first thought of rewriting this site. Yet every time I started work, I would get caught up in other things and loose interest.

So I've started writing a sort-of flat file blog application, tailored to my requirements and I hope that this time I'll actually finish this time. I'm giving myself until April, when I have to renew my hosting fees. I want to finally put this task to rest, finally get off of WordPress, finally transition off of this ruby on rails hosting service, finally lighten my mental load.


Why I Hate Remote Working

(Because titles with broad, sweeping statements (that may not actually totally reflect the author's opinion) are wonderful at garnering attention... So maybe read all the way through before deciding to lambaste me?)

I work in the Silicon Valley and my team works with people scattered across America, Singapore, Israel, and India. A terrific feat, that without technologies like desktop sharing, VoIP, and IM would be virtually impossible. Many tech companies support and even encourage remote workers these days. And why shouldn't they? It allows the company to hire the best engineers around the world without having to worry about providing a physical space for the engineers to work out of.

But communicating with people that are 12 hours ahead of you is hard. At 9 PM in California, it's 9:30 AM in India. So by the time that 9 PM meeting is done, it's 10 PM (or 1 AM(!) on the east coast), just enough time to talk "off-line" to individual people, wrap up loose ends, and go to sleep. You'll try to share the pain, alternating who has to take the late night meeting, so that everyone only loses one night a week. But things don't always work out according to plan. People are busy or sick, so meetings get moved, and then the management bureaucracy rears it's head and suddenly you're spending two or three nights a week in meetings.

Do you need some help from your co-workers that are abroad? Well I hope you enjoy working till 2 AM to accommodate their schedule. Do make sure to load up on coffee before tomorrow's 9 AM meeting.

And you'll especially love dragging yourself to work for your early morning meeting only to find it's been rescheduled (Hey, it was your fault. Maybe you should have checked your e-mails before you drove to work).

Social life? What's that? Maybe you'll make the mistake of going out with friends and accidentally miss your 8 PM meeting, much to the displeasure of your manager(s).

So now that I've raised your ire and piqued your interest, I can afford to be a little more reasonable. I do in fact work quite a lot, but it is not a 24/7 lifeless schedule. I have no trouble working with people in the midwest or the east coast; the time difference is not so substantial to be a burden. I've on occasion worked from home, or some other remote location and found it to be fairly easy and enjoyable.

This is not my attempt to publicly flame my company or deride my co-workers or managers. I actually like my company and enjoy the people I work with, but like all relationships it often needs work. The idea of remote workers working closely together as a team is relatively new to this world and difficult to pull off. They are plenty of success stories (just look at the open source community), but also many stories more like mine. I do not believe we created this globally distributed team without fully considering it's implication or the strain it would place on the engineers, and now that we're knee deep into it, happiness and normalcy is a long slog away.

TLDR: Long distance relationships are hard work. Make sure you've considered the challenges and set guidelines before you jump feet first into it.


Exceptions: A Tale of Love and Hate

I am very much a "C" style programmer, so exceptions are not something I use, or see on an everyday basis. Despite this, I've always had a love/hate relationship with exceptions, with my emotions depending on the situation I'm in.

In the past few years, I've used OCaml and Python on occasion to do some quick prototyping (and even some not-too-quick prototyping), and I found the languages' support for exceptions to be quite useful. Being able to call library functions without having to continuously check their return values, and instead be able to rely on the called functions to throw an exception when something bad happens, allows me to write much more quickly. Compare this, for example, to OpenCL in C (because C doesn't have exceptions), which I've been exploring recently. Even the most basic of OpenCL programs, to multiply two vectors, requires 50+ lines of boilerplate code, half of which is "if" statements checking to make sure a cl function didn't return -1. When I was writing my first OpenCL program, I was muttering in annoyance with how much boilerplate cruft I had to spew out and dreaming of exceptions. What I wanted, was for the cl functions to throw an exception on error, which would then allow me to have a single generic catch-all exception handler to dump some error messages and gracefully die.

But we shouldn't forget that exceptions have a place outside of simple prototyping also. Some level of terseness is always appreciated, especially when it allows the programmer to focus on the real task at hand, instead of writing an error check for every function call.

The real magic of exception handlers is that they allow the program to unwind the call stack all in one go, without actually having to jump to each and every return address on the stack as it goes. This is quite powerful, allowing the program to immediately handle the exception when it occurs, and removing the need for the programmer to organize her code to pass the error back up the call stack to where it can be processed.

But as Uncle Ben reminded us, with great power comes great responsibility. The power of exception handlers also gives programmers the ability to screw things up in remarkable ways. Because the exception basically forces a jump to the closest exception handler, all the code in between the exception and the handler won't get executed. This may include important bits like free() and close(), or even just simple things like finishing up printing parts of an output message. While the exception handler is *supposed* to handle all those bits, it's not uncommon for them to be forgotten. A common reason for this, is placing the exception handler very far away from where the exception might be thrown.

Which leads me nicely into my next story. I was working on a bug in some Python code last week, where an exception was thrown somewhere within several thousand lines of code and then handled way at the top of the program. The error message printed was "Exception occurred in <wubwubwub> server," making it quite possibly one of the most useless error messages of all time. I spent a good five minutes raging silently at the programming gods before trying to identify a root cause. It's important to remember that the point of exception handlers is to improve our lives not just in the short term, but also for the long term when code needs to be fixed and maintained.

There are of course many other reasons to love or hate exceptions. But these are the ones that strike a particular chord with me because of my limited experiences. I don't believe exceptions are totally bad, it is merely a powerful tool that is far too often misused, much like "goto" (let's not get ourselves muddled in that argument though...). My personal belief is that the power and terseness of exceptions is sufficient enough that it shouldn't be completely eschewed, but simply used sparingly and with great care. The problem with that idea of course, is that software development sits in the real world, not some lovey-dovey happy-place, where there is always plenty of time to work on projects, everyone is properly trained, all code is properly reviewed, and vampires sparkle in the sun.


College Career Fairs for Engineers

We all know the career fair drill, you push your way through a mass of humanity to stand in line for a company that you hope will offer you a job. After five or ten minutes of waiting, you finally get to yell at an engineer over the din of hundreds for a few minutes, barely enough time to introduce yourself, get asked a few questions, and maybe even ask a few questions yourself. Hardly enough time to make a lasting impression. I attended a few college career fairs earlier this year while recruiting for my company, and throughout the process I realized that a vast number of students were completely misusing their oppertunities at the fairs.

Now, college career fairs present a fantastic opportunity for students. Whereas applying to a job online simply places your name into a bucket with dozens, if not hundreds, or even thousands of faceless applicants, a career fair allows students to cut through the HR and automated resume screener bullsh*t and immediately talk directly with a real life engineer, thereby allowing the student to show off their skills and express their interests. The importance of this opportunity cannot be overstated.

When I was a student, I had a few companies start scheduling me for interviews on the spot when I impressed their engineers at the fair. Now this isn't my company's style, but for a few people, I've scribbled on the back of their resumes phrases such as, "AWESOME, HIRE HIM NOW," and "AMAZING!!." I can assure you those resumes went to the top of the list.


On… Many Things

I've had quite a bit of time to dwell on things during my unscheduled sabbatical from my dearest web server, so this is going to be a doozy of a post.

On Graduating From College

I never really yearned for high school to end, but after three years of college, I began to grow restless of school. By the middle of my fourth year, every fiber of my being was screaming to be released from learning. I was tired of spending hours in the library studying things that seemed hopeless to understand, tired of 8 AM lectures on circuits, tired of long sleepless nights writing code, tired of worrying about grades, and just tired of being tired. It was a bittersweet relationship that I had with school; I loved UCLA and I knew that I would miss it after I left, but I was desperate for a break from learning.

I made my way through high school with a nagging voice at the back of my mind telling me that I needed to succeed in order to get into a good college. Upon entering college, that voice fell silent and I grew complacent. But I was soon spurred forward, partially by a true desire to learn and to a lesser degree, a niggling realization that a sub-par performance in school wasn't going to get me an even passable job after graduation. The fact is, I've spent most of my life working towards the moment when I would graduate from college, a goal that I always thought was far off in the distant future and therefore never considered the consequences of. So after I moved out of my apartment in LA, a new thought wormed its way into my mind, asking, "now what?" And its a question that I have yet to properly resolve to my own personal satisfaction.

Others brought up in similar scenarios as mine undoubtedly have the same thought running around in their heads. From this point in life, there ceases to be as many milestones set out for us, if any at all. The goal now (as I try to tell myself) is to live fully and pursue that which inflames our passions, refusing to accept the limitations ahead.


Cheating on Slow-Start

I just saw this, Ben Strong's observation of how some websites are playing with TCP slow-start's initial window size to get better page load times. Its good to see that some people are pushing to get the protocol changed to allow for bigger initial window sizes. An initial window size of 3 is a little small given the amount of bandwidth now avaliable and the stronger reliability that you see in the tubes these days.


Classess, and Stuff

Its been a distressingly long time since I last blogged, but thats OK because I'm the only one that cares. My numerous lamentations now aired out, we move onto the good stuff (or bad stuff, depending on your point of view...)

So this last quarter, I found my digital design course consuming an inordinate amount of time, and with each passing week the amount of time I spent in lab per day increased at a logarithmic rate (logarthmic, because there are only so many hours a person can spend in lab before there simply ceases to be hours in the day). The premise of the class was quite simple: spend the first few weeks going through cookie-cutter labs whilst learning the ins-and-outs of the tools and VHDL, and then spend the rest of the quarter builidng your own personal project on a FPGA. My group of three proposed to create a system where a user could drive an iRobot Create by mimicking driving motions in front of a camera, an idea perhaps less ambitious then other groups in the class but nonetheless quite daunting. Unlike Microsoft's super-amazing-funtastic-galactic-awesome Kinect, our system made no use of fancy infrared projectors. Instead, we simply required the user to wear blue gloves or grip a stick tipped in blue, and place their foot over a piece of green cloth. Take a look at our demo:

You'll notice also, that on the disply we drew solid bounding boxes over the blue and green objects in the frame.

This was done almost entirely on the FPGA and was written in VHDL, with only  communication over serial port handled by the PPC405 CPU. So yeah, it took a really long time.


Project Backlogs

I'm a little disappointed in myself for having so many little half-baked projects floating around. But I do however have a particular project thats been mostly finished (and then forgotten) for a while now; its a python audio converter program that tries to maintain similar file size and quality to the original file, when performing a conversion. It should be hitting the tubes in a few weeks when I finally have some time away from marching band, and administrative tasks that I really don't want to bother with.

Also still currently in the works, is my  Google App Engine project. But we'll just have to wait and see how that one turns out...

Filed under: Programming No Comments