Sunday, December 21, 2014

Not so functional yet

Functional programming still seems an elusive concept to me -- something that I am trying to pick up but can't yet apply anywhere. The big boost came from the SICP lectures by Sussman and Abelson which I started watching from sometime in the middle of the year. Now, as the year is about to end, I have watched only till lecture 4A. And I cannot think of any way to apply what I have learned. A few days ago I was watching a talk called the 'The Feel of Scala' and I felt Scala was nothing but Java with a powerful front-end which does a lot of rewrites. Nevertheless it was clear that the features provided were for functional programming. Yesterday I downloaded Scala and tried to get the basic control structures and syntax. But again, I hit a wall when I started thinking -- where do I use these features? I know Scala is giving me immutable lists but so what about that? Maybe I'll have answers after I finish the SICP lecture series.

Monday, December 1, 2014

The first task

I could have written this entry in my general blog as well, since unlike regular technical blog posts this one doesn't involve any code. But I am choosing to put it here because I feel it is an important topic which all technical teams need to understand.
Let me get down straight to the point I want to make - how the developer you hired will perform depends a lot on what is the first major task you give him/her. Don't give your dirtiest task which others in the team are 'too important to do'. I have seen this happen to different people 4 times in my 9 year career. Yes, it once happened to me as well, long ago.

So what I am talking about is the following sequence of events:
1. New candidate is joins a technical developer position after tremendous technical interviews
2. A few days after joining, the 'technical' manager asks the candidate to do one of the following as a prime activity for some time:
a. analyse everyone's regression failures every day and/or delegate them to the right engineers
b. manage some infrastructural role for keeping the codebase in sync with components it depends on

I have observed this so far in Indian technical teams only. I don't know if this is a fall-out of our society's caste system where some 'dirty' work is left to be done by a certain group of people only -- that is something for sociologists to comment on! But in effect it is equally devastating to the new candidate's morale and growth.
I guess some 'technical' managers dream of this as the ultimate way to get started with understanding a new product and team. They could not be more wrong. The best way to get someone started is to give him/her good problems to solve. I understand the best work has to be reserved for more experienced candidates, but nothing can justify giving some non-development tasks to a developer at the beginning. I also appreciate the need for developers to be able to do all such stuff, but that should come in time after a developer has started contributing smoothly to a codebase. Only after you have started managing own your work well can you afford to do some housekeeping for others.

Saturday, June 21, 2014

Insecure coding talk by Olve Maudal

I was introduced to Olve Maudal by a friend who used work in a company called Tandberg (which finally got acquired by Cisco). This guy is a real expert, one who can explain things nicely as well. I just finished watching his talk at this year's NDC. It is titled 'Insecure coding in C and C++'. I think it is a must watch for all C programmers. The concept of 'Return-Oriented Programming' just blew me away.

Insecure coding in C and C++ from NDC Conferences on Vimeo.

Tuesday, June 17, 2014

MIT's take on web development

Yesterday I was reading the introduction to a book written in 2006 by some MIT professors titled 'Software Engineering for Internet Applications'. I was thrilled at the level of ideas they proposed, many of which are a reality now. For example, here is an excerpt:

"...Speaking of mobile browsers, their small screens raise the issues of multi-modal user interfaces and personalization. With the General Packet Radio Service or "GPRS", rolled out across the world in late 2001, it became possible for a mobile user to simultaneously speak and listen in a voice connection while using text screens delivered via a Web connection. As an engineer, you'll have to decide when it makes sense to talk to the user, listen to the user, print out a screen of options to the user, and ask the user to highlight and click to choose from that screen of options. For example, when booking an airline flight it is much more convenient to speak the departure and arrival cities than to choose from a menu of thousands of airports worldwide. But if there are ten options for making the connection you don't want to wait for the computer to read out those ten and you don't want to have to hold all the facts about those ten options in your mind. It would be more convenient for the travel service to send you a Web page with the ten options printed and scrollable...."

What is being proposed has already been partly achieved in the 'responsive' web design trend going on for the last two years!

The best  part I liked was about how web applications could fulfill the unmet goals of humanity:

"...What are the enduring unmet human goals? To connect with other people and to learn. Email and "reference library" were the two universally appealing applications of the Internet, according to a December 1999 survey conducted by Norman Nie and Lutz Erbring and reported in "Internet and Society", a January 2000 report of theStanford Institute for the Quantitative Study of Society. Entertainment and business-to-consumer e-commerce were far down the list...."

Saturday, June 7, 2014

A tool to solve any problem

Last year I developed an itch for learning functional programming (so much so that I signed up on a functional programming contest!), and that led me to Brian Harvey's course in UCB (search for CS61A on youtube). I enjoyed that immensely and watched more than 10 lectures from the series. A few days ago when I mentioned this to my friend Sayamindu, he suggested I watch the SICP lectures by Sussman and Abelson. And so I started watching them as well, and I now like these even better. Compared to Brian Harvey's course this one is faster and much more intense. Of course I might have felt that this was too abstract if I hadn't watched the previous one.
So far it feels any big or complicated problem can be solved programmatically using lisp. Since I have been working only on big and complicated software systems for most of my career, I am really looking forward to use it fruitfully.

Thursday, May 1, 2014

Inspiration to write your own language

This line set me thinking of various possibilities today:

"...So, you want to write your own language? All I can say is: Certainty of death. Small chance of success. What are you waiting for?..."

Read the full article by Walter Bright, the creator of D, on DrDobbs site.

Tuesday, March 18, 2014

A hidden insecurity of phones

This talk was a pretty alarming one. There are at least two OS's inside every smartphone, and the communication with your service provider is done via a proprietary RTOS which shares the same RAM as your Android/IOS/etc. Corrupting the RTOS is apparently pretty easy.
I watched it yesterday:

Tuesday, March 4, 2014

Future of democracy by Smari McCarthy

I watched this talk today. It really blew my mind. I suggest it strongly for those of us who are working towards bringing democracy in our respective countries. The speaker is, among other things, a founding member of the Iceland Pirate Party.

Monday, February 24, 2014

Local sharing

I was looking for a way to copy some of my music recordings with my teacher from my office laptop to my mac and realised I really don't know any easy way to do that. Its not that I don't know of any way to do this -- I have copied lots of stuff by connecting two machines with a LAN cable years ago before internet was so widespread. But I don't know a real sleek and easy way like sharing over dropbox or gmail which we use all the time. I think we have too many apps based on the internet today. We forget that now we all have a LAN at home -- a wifi router which all our powers all our internet-elabled devices. Shouldn't we have more apps which lets us chat and share over LAN?

By the way I found this excellent lifehacker post which I eventually followed. However I'd still be happy to see something sleeker and easier.

Sunday, February 23, 2014

How software is not 'engineering'

I have read similar thoughts before, and have myself thought similarly many times. Today I came across this write-up by Prof Terence Parr, author of ANTLR and I hope people will pay more attention to the point he puts because of his credentials. I have mostly worked in teams maintaining successful software products and invariably I have seen a huge effort towards preparing sacred 'specifications' which mostly lead to delayed and badly-written code which creates more problems than it solves. I don't know when I will see a shift towards having better-written code as the first priority.

Thursday, February 20, 2014

Working remotely works?

Saw this talk today:



It is certainly very hopeful that a company is successfully running with managers and engineers working remotely. The point that Mike makes about work being identified more with a person's presence in a physical location rather than a task is very very valuable. We have moved on from factories and live in the age of the knowledge industry. Today's companies should certainly stop paying attention to location or physical presence.
However I have personally felt that physical presence leads to better brainstorming, more learning, and more socialisation -- all of which increase the efficiency and quality of work. I think what might be good for a company is to allow employees to work 100% remotely for 2 months of a year. This might be helpful for people wanting to travel -- specially those with kids in school. It might also help travel and adventure enthusiasts.
In a nutshell, the more companies judge employees by actual tasks accomplished, the more they'll be able to allow remote work. Which means the chances of Indian companies doing such things is very less -- going by the sheer percentage of incompetent-and-yet-highly-successful people I have seen in my career!

Tuesday, January 14, 2014

Learnings from 2013

Here are a number of things related to programming I did in 2013:
  • Started creating a new wordpress theme for selfawarenessforchange.com -- my friend Frederic Labarthe's site. The work never progressed beyond a prototype of the home page. The only takeaway is that I used Twitter bootstrap for the first time and that was a very easy experience.
  • Did some freelancing with some friends in a php-based project. Added some tiny features but could not do everything the client wanted, and not on time either. I dissociated myself from the project pretty soon.
  • Tried some data visualisation hacking at a Hacks n' Hackers session.
  • Started some coursera courses and one udacity course -- none even halfway done.
  • Watched around 12 lectures by Brian Harvey of UCB which were part of the CS61A lectures of 2008. This was a fantastic experience and opened up my thinking process. The lectures are all available on youtube and I look forward to completing them.
  • Started an open-source project with some other folks, an attempt to reincarnate fossevents.in . This is in limbo right now since I don't know enough of Flask and the people who know are busy.
  • Resurrected the code of a product I wrote 9 years ago when I was in college. I could build the source code after some effort but it is not in a working state on Ubuntu (I wrote it on RedHat of that era). I need to update the code related to Xlib keyboard event handling.
  • Participated in a hackathon where an ambitious news mining and visualisation project was hatched over a day-and-a-half. I think this is the most promising project I've taken part in, mostly due to the technical prowess of others in the group.
Now that I wrote it down, it does seem a lot of work for doing on the side after giving time to work, personal life and repeated hopeless attempts at becoming a violinist! Nevertheless I see the year as a year of failed attempts and I want to pen down my key learnings:
  • I thought that since I had once coded a site alone in php, I could work in anything written in php! So I boldly tried to write wordpress themes and make progress on a huge legacy php codebase. Even if a language is 'easy' it doesn't mean it is easy to work with. Knowing a language and the underlying platform well is what makes work easy -- otherwise even Javascript can be difficult.
  • I was much inspired by the quotation 'Talk is cheap, show me the code'. Hence whenever I heard of a project, I started browsing its codebase on github! I think it is self-explanatory to mention that now I first read the documentation and then think about looking into the code of any project
  • Coming back from office and jumping into doing something else -- this is a sure way to burnout. Unless your mind and body are relaxed and ready to do some work you cannot do anything creative.
  • Trying to do multiple things apart from office work is futile. Only one thing can be done at most apart from office work -- this is what experience taught me.
  • Office work is what you get paid for and what you spend most of your energies in. Do not expect to do your side-activities at the same pace as your office work. It is not possible. Just keep on taking baby steps and that will be more than enough.
  • Unless you know the semantics of a language and its debugger -- don't start coding anything. Interpreted languages give an illusion of being easy since they don't complain so fast -- but that is a dangerous trap for getting lost in silly problems.
  • Try to read good articles and hear good talks. Articles in journals like Communications of the ACM or Dr Dobbs are really good and written by solid engineers or good experts. Blog posts popping up here and there may look attractive but there may not be much to learn from them.