The ByteBaker » Programming

Sunday Selection 2011-12-11

Shrutarshi Basu — Sun, 11 Dec 2011 14:00:00 +0000

Around the Internet

More shell, less egg It’s alway a joy to see two masters at the top of their craft engaged in a respectful, but determined duel. This is a short commentary on Donald Knuth and Doug McIlroy’s approaches to literate programming. Worth reading even if you’re not a big fan of literate programming.

Selective use of technology I firmly believe that science and technology is a good thing and that our world is better because of them. However I also understand that technology cannot do everything for us. In particular there are a lot of decisions it cannot make for us (yet). I also tend to get a lot of my best work when I am least partially disconnected and can hold at bay the full force of the Internet. All things in moderation.

Why sugar makes us sleepy (and protein wakes us up) As much as many of us would like to live as if we disembodied brains surviving on anything that barely resembled food, that is definitely not the case. Since we are stuck with our flesh-and-blood physical bodies for the foreseeable future, it is a good idea to figure out how it all works and make the most of it.

From the Bookshelf

Do the Work While I’m not entrely a fan of Steven Pressfield’s use of vaguely “spiritual” ideas and terms, this book is still worth reading for everyone. It’s especially useful if you have that big project you’ve been thinking about but never got around to actually starting. At $1.99 for the Kindle edition, it’s a steal.

Video

What we actually know about software development Despite the importance of software development, most developers are acutely unaware of the scientific studies in the area and rely mostly on anecdote. Luckily there is an increasing amount of research in software development (not to be confused with computer science) and it’s worth knowing what we actually know about the field and what is myth.

Getting to Work

Shrutarshi Basu — Thu, 08 Dec 2011 14:00:00 +0000

There is a danger to doing what you love as part of your day job. For a few weeks I’ve been working on a programming project. The project should have been very interesting and motivating. It involved combining programming languages (which I love and have been learning about for years) and networks (which I don’t know that well, but have a growing interest in). This should have been an ideal project – a project with just the right combination of personal skill and challenge. It was a project with definite goals, with people who supported me and wanted me to succeed and were willing to give me regular feedback. And yet it was so hard to actually get myself to do the work.

The Motivation Problem

I think the problem is that for most of my life programming was something I did on the side. In school, programming and computers were never the main course of study. In fact, more than once my parents had to tear me away from the computer. In college I decided to be an Electrical Engineer because I wanted to know how the machine worked from the lowest level up. Though that was an interesting and very fulfilling learning experience I realized at the end of four years that I would rather use computers to do something interesting rather than improve the machine itself. Though I did do a good bit of programming in college, most of my classes did not involve programming as the focus.

But now I’m in graduate school and programming is supposed to be part of the job description. Yes, I know that large areas of computer science are essentially mathematics and you can get away with writing very little code, but that’s not where my interests lie. For me, programming is no longer just something I do for the fun of it. It’s something I do because my grades depend on it and because I’m getting paid for it. It has become work and that has been fairly disastrous to my ability to get things done.

As knowledge about our psychology improves one of the interesting facts that has come up is that intrinsic motivation is a much stronger force than any form of external motivation. In a specific sense that means I need to have an internal reason for doing my work. In a more general sense I need to have an autotelic personality: to “have a purpose in and not apart from itself”. The good news is that I’m in a line of work that favors autotelics. The bad news is that it seems to be all too easy to lose the sense of self-motivation, to feel like that the only reason I’m working is because I’m expected to and I’ll get something definite out of it.

However one more piece of good news is that starting is often the hardest part, especially for something you think you should want to do, but can’t muster the motivation for it. I’ve noticed that once I’ve started and am making progress it’s easy to keep going. The trick is to both start and end in the right way.

Start and Stop

Whenever I start out reading and thinking too much about my problem I sabotage myself. I tell myself the problem is too hard, there’s too much other stuff I need to know first, surely someone else has already solved the problem and I can just use their code. Down that path lies madness (and not getting anything done). Though I’m all for thinking before pumping out code, for starters I like to just jump in and get going.

Diving in and hacking away helps produce the feeling that I’m making progress. Whatever I do at this phase is pretty basic: code cleanup, documentation, minor refactoring, maybe fixing a small bug. The point isn’t to get productive immediately, it’s to load the working context of the program into my brain, to get minor victories that help get past the resistance to start. Once I’m past the initial hump I can pause and think deeply about the core of the problem. Since I’ve already loaded up the problem in my head that also becomes easier.

I’ve learned the hard way that stopping probably is just as important. The key is momentum. During each coding session I build up a certain amount of momentum as I build up a mental model of the problem and the solution. Unfortunately I have to re-acquire that momentum every time I start again. I want to pick the proper stopping points so that the re-acquisition is quick and smooth.

I make sure that I always leave code in a relatively clean state: everything has been committed, there is some amount of documentation and most importantly I’ve identified what I need to do next. That way the next time I sit down with the code I can look up the README or the TODO file and pick off the next thing on the list. If the last commit was broken the next thing is usually something to fix. If the last commit was good I can add a new feature. I use a version control system that makes it easy to roll back changes and commits so I don’t hesitate to put in a “checkpoint” commit, even if it’s broken. The less time and effort I have to spend in deciding what to do next the better a chance I have at actually getting something worthwhile done.

This isn’t about computers

…or computer science or programming. This is about getting work done, work that I love. But sometimes love isn’t enough to get me out of the browser and into the text editor. Habit is often stronger (and less demanding) than will power. The good thing about habits is that they can be both formed and broken. I’m starting to learn that the key isn’t to beat yourself up for being a slacker, but rather engineering your life so that getting stuff done is on the path of least resistance.

And now it’s time to get back to my project.

Sunday Selection 2012-12-04

Shrutarshi Basu — Sun, 04 Dec 2011 14:00:00 +0000

Around the Internet

How I went from writing 2000 words a day to 10,000 words a day Writing is no easy business and writing a lot on a regular basis is even harder still. It’s good to know that there you don’t need some special gift to become super-productive, you just need to carve out the time and work to the patterns that let you get the most out of the day.

Eleven equations Computer Science geeks should know There’s not much consensus when it comes to how much mathematics computer scientists and programmers need to know. Personally I would say that if you are a computer scientist you need a fairly strong mathematics background (something I’m still working on, I’ll admit). Even if you’re just a programmer I think having some mathematical familiarity will make you a better thinker and give you a better bag of tricks to call upon.

Clay Johnson’s Information Diet Though I love social networks, both the technology powering them and the interesting interactions they produce, too much of anything is a bad thing. I’ve been considering going on an information diet (or perhaps more correctly an information consumption diet) so that I could more of that time into creating instead of consuming.

Videos

How Github uses Github to build Github I firmly believe that good tools and workflows can make your job easier and your production better. I also think Zach Holman is really cool. While this focuses on Github it’s easily applicable to any group of developers (or creators in general) working together to produce awesome stuff.

Sunday Selection 2011-11-27

Shrutarshi Basu — Sun, 27 Nov 2011 18:00:48 +0000

Today’s a bit of a health and fitness special to compensate for all the Thanksgiving excesses. But first, some programming.

Programming

All I Need to Be a Better Programmer I Learned in Kindergarten Sometimes the basics can be boiled down to just a few sentences. Sometimes I think I knew more when I was five than I do now. Of course, that’s a lie, but it’s worth thinking about.

Code Fearlessly I think version control is amazing. I’ve been using Git for a few years now (Subversion before then) and I keep all my writing as well as my code in repositories, backed up to Amazon and a VPS. The great thing about version control is how it lets you make mistakes and try out wild ideas without worrying about how you’ll get back to a working state if you break something.

Health and Fitness

The Creative Brain on Exercise I know, I know. Exercise doesn’t come naturally to most of us spending our days in front of our screens. But given how much of our work is creative in nature, it makes sense to take care of our engines of creation. I think the time spent in exercise will more than pay itself back over the years (in saved medical bills and lost work time if nothing else).

How Getting Buff Can Make You a Better Rubyist. In case you’re wondering about whether any of this exercise and diet stuff actually works or not, here’s some evidence straight from the source. This is worth watching even if you’re not a programmer, but just someone who has a normally sedentary work life.

Tim Ferriss on the 4-Hour Body at the NEXT conference I know that so-called “extreme” advice such as provided by Tim in his book always earns a skeptical look, but I find his idea of minimum effective dose quite interesting. If you’re looking for the most efficient ways to change your body for the better, this is a must-watch.

Eat to Live If you’d rather have advice from a medical doctor who’s also changed the lives of dozens (if not hundreds) of people, this book is your best bet. I tend to think of it as more of a primer on nutrition and health in general rather than just a diet or fitness book. It might take you some time to get through it (though it’s a small book) but again, the investment is definitely worth it.

Deliberate Practice for Programmers

Shrutarshi Basu — Mon, 21 Nov 2011 16:00:00 +0000

The main reason one should go to graduate school is to do research. To earn a PhD you must have advanced the state of your field. In fact, your PhD defense is all about convincing the guardians of the frontier that the frontier has been moved. That being said, I have a personal goal of improving myself as well. I’m surrounded my brilliant professors and peers and it would be downright stupid if I didn’t take this chance to learn from experts in their fields.

While I want to improve as a computer science researcher I also want to improve as a developer. For me, the fact that we must take our beautiful algorithms, logics and abstractions and express them in terms understandable to a dumb machine is not something to be despised. In fact, I consider it a pleasant challenge and a source of infinite creative joy. I would like my job a lot less if it didn’t involve a significant amount of programming. That being said, how exactly do we level up as a developer? In fact, what does leveling up even mean for a developer?

For the last few months (years?) I’ve been a growing fan of the idea of deliberate practice – the idea that the best way to improve is to take well-defined measurable steps towards getting better where at each step you get feedback as to what you did wrong and how you can do it better the next time. Deliberate practice has been applied by athletes and writers, can we apply it to programmers? In particular, can we come up with something more detailed than “Read code. Write code. Repeat”? Luckily for all of us, Jason Rudolph took some steps on that path a few months ago.

Remember that deliberate practice requires that we have a list of well-defined, actionable goals on our path to excellence. We must know clearly what the goals are and also be able to unambiguously tell if we’ve achieved them or not. Jason came up with a list of simple yes/no goals that will exercise your programming muscles. What I love about Jason’s list is that it combines a lot of what it means to be a good developer. There are goals for learning tools of the trade (different languages, environments and frameworks), goals for learning core concepts (different paradigms and parts of the software stack) and social goals (open source and community involvement). There are a lot of things on the list, but then again, computer technology is a vast field.

Jason’s list is also necessarily incomplete. I’d argue that it’s practically impossible for one man to know all about the computer technology field today. But the good thing is that we have the technology and the community to take one man’s starting point and extend it for our own purposes. Jason’s list is available as a gist on Github and has already been forked many times by people who are using it as their own deliberate practice guidelines. I have my own fork where I’ve fleshed out sections on uncommon programming languages and more theoretical learning goals.

It might be a bit naive to think that just going through a list of programming challenges will make you level up. However, I think the list is a good head fake. The point isn’t really to go and do everything on the list. The point is everything that comes as a side-effect of completing the list. You’ll definitely put in a few thousand hours and churn out thousands of lines of code in a variety of different languages and environments. You’ll expand your mind by learning about programming styles and tools that you would have missed out on otherwise. As you encounter problems you’ll have to ask around on forums, mailing lists and IRC for help. This is important because deliberate practice is useless if you’re practicing the wrong things. In the absence of programming coaches, the global communities of programmers are your best bet to find mentors and guides. If you release your code to the world you’ll gain some street cred, get valuable feedback and maybe even provide something of lasting value to fellow developers. If you follow through on the social and community goals you’ll gain non-programming, but useful skills and meet a lot more people who can point in new and interesting directions. You’ll discover interesting new problems and come up with applications and solutions you might never have thought about otherwise. Maybe, just maybe, you’ll learn enough to level up as a programmer.

As a parting note, let’s all keep in mind that this will not be easy. It will take time and effort. I’m in graduate school so I might be able to make it part of my day job to do some of these things. But a lot of it will have to happen on my own time and energy, when I could be exploring Ithaca’s gorges or watching infinite Star Trek episodes on Netflix. This is even more true for people who have legitimate day jobs and families. We all need to come up with our own reasons for why we want to invest all this time and effort in deliberate practice. But one thing I keep telling myself is that the time will pass anyway and my energy will be spent somehow. I would rather spend it on writing my own operating system than on Star Trek reruns (no matter how much I love Star Trek).

Salvaging Dead Time and Procrastiworking

Shrutarshi Basu — Fri, 04 Nov 2011 14:00:00 +0000

The last few weeks have been another continuous episode of “too much to do, too little time”. Graduate school is a very interesting environment from a work and productivity standpoint. On the one hand I don’t really have a fixed schedule (outside of a few hours of class a week) and can work whenever I want. I also live close to campus so commuting isn’t a issue. However distractions abound. I’m not meeting with professors on as regular a basis as I was, but there are still lots of talks, colloquia and seminars that I find really interesting and want to go see. It’s very easy to have the day be perforated by lots of little things and never get anything done. However, there’s one trick that I’ve learned that in the past week or so that can mitigate this fragmentation and helps me get things done: salvaging dead time.

Salvaging Dead Time

I currently have a class that runs from 10:10am to 11:25am. Then I go to a lunchtime talk at noon. Taking out the 5 minutes or so to get back to my office that leaves about half an hour that would normally be wasted on Hacker News or Twitter. As a graduate student I need to have pretty long blocks of time to sit, think and get work done. Thirty minutes generally isn’t a lot of time to get brain-work done and hence this would be “dead time” – time that is just lost.

However half an hour is more than enough time to knock off errands. Today I filed two helpdesk tickets, processed email down to inbox zero, paid my power bill and wrote out my rent check. Not only did I get actual work done (and a little high from crossing them off my checklist) it means I don’t have to take out time for them later. I don’t have to devote separate time chunks to errands later and I can allocate that time to actual research work. I think that counts as an all-round win.

Procrastiworking

While knocking off errands works great to salvage small blocks of dead time (up to about half-an-hour) sometimes there are sometimes larger blocks of 1-2 hours that also needs salvaging. This generally happens around dinner – I don’t have a fixed dinner time. Hence there’s often this awkward state where I won’t be having dinner till a little later, but don’t have anything planned before. Normally that time would evaporate into nothingness, but I’ve been trying out a different technique to salvage it.

While an hour isn’t enough time to do real research work, it definitely is enough to do some programming exercises or go through a few more pages of Real World Haskell. Earlier this week I decided to finally sit down and learn Haskell seriously. I’m familiar enough with Haskell at the moment that I can get up and running in a few minutes. Doing exercises is challenging enough that it takes brain work and requires thinking and learning. However at the same I don’t feel bad about leaving in the middle for dinner (I can generally finish the program I’m working on before leaving). This is classic procrastiworking: I’m slacking off on what I really should be doing (research) but instead of digesting Twitter I’m doing something beneficial.

There’s also a small matter of me being lazy and using dead time as an excuse for slacking off. Even though I know I could use an hour for programming exercises I’m tempted to slack off anyway. I’ve been trying to use procrastiworking for that too. I start off doing something that is really not work: like updating all my git repos or cleaning up my Emacs config. But once that’s over, since I’m already at the computer in a terminal, dealing with scripts and code I just quietly move myself over to a Haskell file and start hacking. It helps if I leave an unfinished function that I can then fill in (or a TODO note).

In Conclusion

Salvaging dead time and procrastiworking isn’t a catch-all solution for time management but I’ve found that it works great for the small blocks of time that I would have been wasting otherwise. Of course, you can’t fill in the blanks unless you have things to fill them with. Personally I use OmniFocus to keep a list of errands that I can go through in sequence. I also have a “project” for the longer blocks – working on Haskell – that easily decomposes into blocks of just a few minutes in length that can be taken up and put down without too much buildup. Finally I hope that in this case practive makes perfect and I get better at making use of dead time the more I consciously do it.

Is programming a creative pursuit?

Shrutarshi Basu — Sat, 15 Oct 2011 13:21:00 +0000

It’s becoming clear that we, as a society, are placing a larger and larger emphasis on innovation and creativity while at the same time bemoaning the lack thereof. There are some activities that we instantly recognize as creative pursuits: painting, music, writing, theatre. And also more modern ones: graphics, web design, info graphics and industrial design, font design and lettering. But when it comes to modern acitivities and professions one of the elephants in the room is programming. The question that’s been on my mind: is programming a creative pursuit?

Programming is problem-solving. It’s about coming up with ways to do things that couldn’t be done before (or at least doing them better). But that’s just the beginning. Once you figure out a way to solve the problem you then create something – a program – that embodies your solution. The program is what goes ahead and solves the problem, hopefully correctly and repeatedly. A program that only works once isn’t very useful. If you’re not creating anything, then you’re not a programmer.

That being said, I think there are some significant differences with typical creative work that needs to be made clear. For one thing, there’s lot less waiting around for inspiration to hit. There isn’t anything really analogous to writer’s block – once you have a problem to chew on you can get going. That’s not to say that you can’t get stuck or that it’s smooth sailing. Far from it, your typical programmer is pretty experienced in applying head to desk. When you don’t have a definite problem to solve it’s a different matter. Luckily there’s lots of interesting software that needs building and problems that need solving. To get out of the rut you just need to do a little Googling (or keep a little stash of side projects to hack on).

Perhaps one criticism of programming as a creative endeavor is that the products aren’t instantly identifiable as creative works. Perhaps if you spent a lot of time crafting GUIs you can make some comparison to the visual arts. If you’re writing server software or building programming languages the end results are far more abstract and invisible. But I’d make the argument that a programmer produces a work of art in the same way that a novelist or a poet does. Understanding that art requires the use of some more mental faculties — understanding symbols, structures, mathematics, semantics and their inter-relation. The process is perhaps harder than looking at a painting. But the payoff to the observer is no less than listening to, and appreciating a piece of music.

All that being said, one of the coolest things about programming is that you can use your programs to produce obvious art work, or write programs that will create art for you. As I’ve been exploring programming and computer science I’ve been thinking of programming as a medium for expression in the same way that music or art is a medium for expression. But more on that later.

Programming has some of the other hallmarks of other creative pursuits. You need lots of practice to get any good. When it’s time to actually create you need to isolate and separate yourself from the rest of the world or you just keep getting distracted. I think there’s an image of programming being dry and interesting only if you’re already into it while the classic creative arts are supposedly fun and energizing. I would argue that’s an unfortunate by-product of our social evolution. If you consider a creative person (or want to become one) I would say give programming a try. There are lots of ways to get started. Though the learning curve is certainly steep (and probably steeper than it needs to be) it’s probably not that much harder than learning to draw or play the violin.

UPDATE: Thanks to Jason Yosinski for pointing me to Hackers and Painters – a far more detailed essay on similar considerations by a far wiser person. Learn from the masters.

Sunday Selection 2011-09-25

Shrutarshi Basu — Sun, 25 Sep 2011 13:00:23 +0000

Unfortunately work-related activities having been taking up a lot of my time and energy over the past couple of weeks. On the good side I’m gradually making progress towards figuring out this grad school thing. While work on a funny and insightful blog post to blow you all away I leave with you a brief tour of the Intertubes.

Society

It’s not gender warfare, it’s math Being a computer science graduate student I’m regularly confronted by the fact that there are not enough women in our field (and that doesn’t seem to be changing any time soon). Here’s a look at why and that needs to change and some work in the right direction.

The Fraying of a Nation’s Decency Sometimes we just need a reminder that we’re all human after all.

Web Technology

10 best @font-face fonts I think embeddable web fonts are one of the best things to have happened to the web in recent years. Think of this article as a good “getting started” guide if you’re trying to figure out what fonts to use for your own projects.

How to make a simple HTML5 Canvas game The canvas element is an even bigger improvement than web fonts. Like the name suggests, it gives you a general purpose drawing element on a web page. Combine that with fast JavaScript engines and you have a pretty decent game engine on your hands.

Video

QuakeCon 2011 John Carmack keynote If you’re interested in gaming engines or high-performance, down-and-dirty programming then you should take the hour and half to listen to John Carmack — the brains behind the Doom and Quake game engines.

deck.js lite: modern HTML presentations

Shrutarshi Basu — Tue, 13 Sep 2011 02:35:00 +0000

Taking a page out of Don Stewart’s book I’m planning to release a project to the Internet every week or two. Most, if not all, of them will be open source and hosted on Github. I’ll be posting blurbs about them on this blog filed under a new category – Projects. Feel free to follow along or fork away.

Deck.js is a very cool project that provides a set of CSS and JavaScript templates that let you create clean, elegant slideshows using HTML. I’m becoming increasingly attracted to HTML as a general purpose documentation format so seeing like deck.js makes me really happy.

I’m currently using deck.js to put together a presentation for a class I’m taking, but while at it I thought I’d do some reorganization of the deck.js codebase to make things a little easier. The files that you need to include to use deck.js are currently spread out between a number of different folders meaning that as a user it might take you a while to figure out where everything is and what you need to include. So in the spirit of open source I decided to fork the repo on Github and create a ‘lite’ version.

This version (also available on Github under the same license) packs all the files into a single folder, shortens some names and paths and removes some things (tests and SCSS files) that users might not care about. I’ve also updated the introductory presentation to point to the new files so you can use that as a template for making your own slides. I’ve been talking to deck.js’ creator, Caleb Troughton and I plan to keep the ‘lite’ version in sync with the main repo so that you’re always using the latest and greatest.

If there’s anything else you’d like to see in a lite version (or just in deck.js in general) please let me know. I think the best days of the web are just ahead and having web-native slideshows is definitely a step in the right direction.

PS. In case you’re wondering: no, The ByteBaker is not going to become just an announcement board for my projects. However, graduate school is taking up a lot of my time and energy right now. Also I think it’s important that I keep to releasing one project a week. The best I way I can think of keeping to that is by documenting my progress online. Normal programming will resume soon.

Bluebot: a simple HTML template

Shrutarshi Basu — Tue, 06 Sep 2011 13:00:00 +0000

Over the weekend I took a few hours to set up a simple webpage on the Cornell CS department servers. While doing that I realized that I didn’t have a template in store for the occasions where I needed to throw together a page without fiddling for hours. I cobbled together a simple design for my page based on my personal website.

The result is Bluebot: a simple template designed for creating HTML5 webpages. It provides a set of CSS styles and web fonts along with some example HTML for writing clean, decent-looking webpages. It’s designed to be used for standalone pages, i.e. single webpages that are complete in and of themselves. That’s not to say it couldn’t be used or adapted for full websites.

Though the template is mostly black and white, there is a little bit of blue used for the borders and blockquotes, hence the blue. It also makes use of the Droid family of fonts provided via Google Web Fonts, hence the bot.

You can see what Bluebot looks like on the Bluebot project page. You can clone the Git repo or download a tarball from the Github page. I plan on continuing to add styling for the remaining HTML5 elements gradually. Feel free to fork, edit and send me a pull request.