Software – Dorai Thodla

Good Read: Advice to CS Students

I loved this advice from James M Turner.

When I talk about passion, I mean love. I’ve been in love with computers since I was 14 years old, and I’d be playing with them even if I didn’t get paid for it. If software engineering is merely a means to an end, you’re not going to be happy in the long term working in this field, because much of it is God-awful boring unless you have a passion for it.

People in their 20s tend to jump into small, fledgeling companies, and that’s one of the best things you can do. A junior developer at Fidelity or Akamai is going to work on one thing for long periods of time, while at a start-up you’ll get a chance to jump all over the place, learning many different aspects of the field.

Truly pioneering development can change the world. Flickr did it, by giving the world a single photo album to share. Linux did it, by creating a solid, flexible, performant operating system that you could throw into a $9.99 product, because you didn’t need to license it. Try to find at least one opportunity in your career to move the ball a little, rather than just doing what’s already been done. It doesn’t have to be a touchdown; even a few yards can make a difference.

I have worked closely with over 50 software developers over 25 years. I would rate about 5-7 of them world class. One true outstanding quality that made them different from others – love of software.

LinkLog: Why Functional Programming Matters?

Functional programmers argue that there are great material benefits – that
a functional programmer is an order of magnitude more productive than his
conventional counterpart, because functional programs are an order of magnitude
shorter. Yet why should this be?

LinkLog: Why Functional Programming Matters?

A couple of days ago, I went into the wrong networking event by mistake. This is one of those, where exchanging cards seems to be the main activity. The only saving grace was that I bumped into a programmer. We got to chatting and I asked him about his favorite programming languages. Pat came the reply “Haskell”. Before I could dig deeper, we were called into a formal (rather boring) meeting. So I went and Googled “Why functional programming” and here is one the neat papers I came across. It is kind of old but, will give you a sense of why you should consider giving it a try.

Functional programmers argue that there are great material benefits – that
a functional programmer is an order of magnitude more productive than his
conventional counterpart, because functional programs are an order of magnitude
shorter. Yet why should this be?

You can Read the full paper.

Multiplying the Multipliers

Reading Amund Tveit’s Blog reminded me of Doug’s ABC model of capability improvement.

Amund talks about the importance of software and a few ideas on how to multiply the multipliers.

the only point I want to make is that software is extremely important :). And since software has a multiplicative effect that few other technologies can beat (e.g. 1 persons code can effect a large amount of users in a positive way), making software engineers more productive can have a massive impact on society

Teaching has a multiplier effect. So improving teaching is a one to many activity with huge impact since each teacher comes across many students and have deep influence. Good teachers are great at inspiring people. My love for Math came from my early teachers.

Bloggers are the new teachers. Highly Effective bloggers are thinkers, dreamers and passionate about sharing their ideas. They have a deep multiplier effect too.

LinkLog: What Kind of Software Would People Actually Pay For?

A great blog post and a discussion thread on reddit. Some snippets (read the blog for a very insightful discussion):

Software that re-defines a category (Google and Amazon come to mind)

Software that saves businesses (and individuals) money (figuring out the benefits to your customer)

Software that helps business earn more money (making it compelling)

Piggyback off where people are already spending tons of money (choosing your marketplace)

Become easier to choose and you become harder to leave (by building and managing excellence)

shrink a market or disrupt your competitors

Get bold initial customers who will take the risk and are willing to share their experiences.

You don’t have to be the guru of an industry; you can often make a huge difference by bringing a computational perspective to the domain (think how you can apply technology to solve real problems)

Find out what they have to do but hate doing and find a way to simplify or automate it.

This is the kind of blog post that I would book mark and read several times, think about it, find more similar ones. It will also be a nice exercise to keep this list some where and grow it based on actual experiences of successful products. Peter Christensen’s articulates so well some of the things I kind of know but never really reflected a lot about.

I think blogs are the best knowledge sharing network you can think of especially If you are lucky to discover ones like Peter’s.

Teaching

I had a chance to address a group of software developers recently. I had about ten minutes to describe one of our recent research labs – the broad goals and a road map. It was fun. More fun was the question, I was asked, in the end.

What would you have done if there are no computers or internet?

I really struggled for an answer. I started my career by working in a team that built a mini-computer. My role itself was pretty small – a diagnostics engineer,testing hardware by writing software. That was more than 35 years ago, just when mini-computers were getting popular.

I guess I would have become a school teacher. I love teaching and I always thought it was one of noblest professions in the world.

LinkLog: Startups

This is a problem that faces everysuccesful startup – how do you go from small. Whether it is growing an organization or growing a product, how do you make sure that you do not become “soggy” as you grow?

The Elephant and the Ant: Why Companies Need Processes as they grow triggered by Seth Godin’s Soggy.A similar abstraction, on a very different subject- software. How a beautiful software system becomes Frankenstein paints a vivid picture of what happens when you grow from small to big.

The success is in handling this change in size well.

Resources: Technology Podcasts and Videos

I am always on the lookout for good podcasts to listen to. Here is an opportunity to listen to thought leaders in the tech industry.

Here are a few of my favorites:

Interviews with Innovators by Jon Udel from ITConversations Network. ITConversations also hosts some interesting podcasts on Social Innovation and other interesting topics.

Talking with Talis is one of my more recent discoveries. In their own words, it is:

conversations with thought-leaders at the interface between Web 2.0, Libraries, and the Semantic Web…

Inside Silicon Valley from PodTech News is another one of my favorites. I became aware of PodTech when Robert Scoble moved there from Microsoft.

ScobleShow is another one of my favorite ones. Since Scoble is no longer at PodTech, I wonder whether this series will continue.

Channel 10 is a great source that covers products and innovations at Microsoft. I have watched some really grate videos and podcasts there.

Google Engineering Edu and other Google tech talk videos is one of the best sources of technology information. Google often invites thought leaders, developers, language designers to their campus. They make these videos available free.

A talk a day is my motto. A technology or Science podcast or an audiobook is a great companion when I take my walks or sweat it out on my treadmill.

LinkLog: Software

This blog is such a wonderful source of information. Here are just a few of the posts:

How a beautiful idea becomes a Frankenstein system is a must read for every software developer. Here is a small fragment of a much more comprehensive diagram in this post.

I always thought that we built tools to take boring repetitive parts of the work and automate it. How Tools Frame Programmer’s Mindset makes you reflect a lot more about the tools. What qualities should effective programmer tools have? The author identifies three:

Usability – enhance flow of programmer’s ideas or at least don’t impede and interrupt this flow.

Representation – enable easy for understanding and modification representation of the structure, ideas and domain concepts in the code.

Agile development friendly

From Beginners to master programmers – First Language and More is a problem that faces every training organization. When I started working on Learning Point, this was one of my constant worries. I have seen several threads of discussions on the choice of first language for programming.

This blog post is a good starting point. Hopefully I will have more to contribute after my current experiment with 5 interns for the next six months.

Train clear logical thinking.

Understand modern software concepts and environments.

Learn to effectively implement customer needs.

When You Solve Your Own Problem…

When you solve your own problem, you create a tool that you’re passionate about. And passion is key. Passion means you’ll truly use it and care about it. And that’s the best way to get others to feel passionate about it too.

This and other great ideas in a book called Getting Real. It is a book about smaller, faster, better ways to build web applications. Some great ideas about building software. Here is a list of my favorite ones.
Build Less
Less Features means you can get the product out earlier into the hands of the customers. You get to hear what they really like and what they would like. This can be invaluable.

Fund Yourself
You can focus on doing something good instead of spending time looking for money. Meebo did this and so did lot of others. In fact, this is the norm in many of the Web 2.0 startups.

It Shouldn’t be a Chore
I love this one. If the app does not get you excited, it is not worth building. It should be fun to build. You need to enjoy every bit of the process. And if you built it for your own use, make sure that the experience of using it is fun, as well.

Seek and Celebrate Small Victories
Build incrementally. With each increment, make it more useful.

Check out the following advice.

Hire Less and Hire Later
You Can’t Fake Enthusiasm
The Blank Slate
Context Over Consistency

Open Doors
Ride the Blog Wave
Promote Through Education

Feel The Pain

Treating Code as an Essay

This was a chapter from the book Beautiful Code. I am doing some random sampling of various chapters. Some notes from this chapter on Treating Code As An Essay by Yukihiro Matsumoto, designer of Ruby programming language.

These are quotes from the chapter. I formatted them a bit.

Lightweight Languages are not lightweight in the sense of ease of implementation, but they are called lightweight because of their intention to lighten the workload of the programmer.

Brevity is one element that helps make code beautiful. As Paul Graham says, “Succinctness is power.” In the vocabulary of programming, brevity is a virtue.

Brevity can also mean the elimination of redundancy. Redundancy is defined as the duplication of information.

In order to eliminate redundancy, we follow the DRY principle: Don’t Repeat Yourself. The concept of DRY is the antithesis of copy-and-paste coding.

Simplicity is the next element of beautiful code. We often feel beauty in simple code.

When simpler tools are used to solve a complex problem, complexity is merely shifted to the programmer.

Balance is the final element of beautiful code. So far I have talked about brevity, conservatism, simplicity, and flexibility. No element by itself will ensure a beautiful program.

This chapter is a great read, as are many others I am sampling right now.

Update: 14th Apr 08

Just found that there is a 3-part series of videos. Here is part-1.

One of the highlights at the recent SD West 2008 conference was the panel discussion on “Beautiful Code” that I had the honor of moderating.

Based on the book of the same name, the Beautiful Code the panel was made up of six of the 33 contributors to the book — Michael Feathers, Jim Kent, Christopher Seiwald, Elliotte Harold, Ron Mak, and Alberto Savoia. As I previously said, my job was to make sure the panel had plenty of bottled water.

To give you a flavor of the panel discussion, here’s a video excerpt of the event. We’ll have more clips in the near future.