LinkLog: Programmer Competency Matrix

On a winter day in Boston, I sat through a two hour lecture on B-Trees. There was snow outside and we all sat spell bound as Greg Basset, our instructor taught us how Digital’s RMS-11K (the record management system) worked. The concept of incremental loading, fill factors, splitting data and index buckets and compression of duplicate keys, is still fresh in my memory. I gave that talk several times later in my life when I was teaching the subject. In each repetition, I learned a little bit more, answering questions. A few years later, I had the chance to use many of the ideas when we built C-Trieve and Objectrieve, two record management systems on top of which we built an SQL relational database. That more than a couple of decades ago.

Looking at the Programmers Competency Matrix brought back lots of those memories. I think I am going to make a custom version of this matrix, make a poster and put it up on the wall of my class. A lot of these topics are not needed for the application programming today. But for a few of those intensely curious students, this is a kind of road map.

Meta:

Reddit is a great source of interesting posts, especially for programmers. I should thank the kind soul who posted this link.

Technology Trends Talk at TiE Chennai

I gave a talk on Technology Trends and Gleaning Opportunities at TiE Chennai today. It was gratifying to hang out with the participants and swap stories. I just uploaded a copy of the presentation (in PDF format). Here is the link -  technology-trends-jun2008

I also uploaded a copy on slide-share. Here is the link to the presentation.

I would love to hear from you. I am going to keep updating this presentation and incorporate suggestions. I am also planning to spend some time expand my list as well as tools for tracking trends.

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.

Invitation to Python Developers from Guido

Thanks to @reddit here is the invitiation (dated May 1, 200

I'm inviting the Python developer community to try out the tool on the
web for code reviews. I've added a few code reviews already, but I'm
hoping that more developers will upload at least one patch for review
and invite a reviewer to try it out.

To try it out, go here:

    http://codereview.appspot.com

Golden Rule of Documenting Software Design

In the Next Programming Skill You Should Learn, Scott Hackett talks about the ability to communicate well, especially in writing. I totally agree. The post is certainly worth a read.

An unexpected bonus in this post is Scott’s tips on the golden rule of documenting software design.

The golden rule of documenting software design

Try to document whatever you are working on. It doesn’t have to be the worlds most perfect UML and you don’t need an expensive tool to do it. In fact, Wordpad and Paint are sufficient, and don’t tell me you don’t have those. Write in a way that best expresses your intent and your thought process in coming to the design decisions you did. I have a golden rule of documenting software design:

Describe your design to others as you would have others describe their design to you.

When you spend the time to do this, you’ll find that many benefits will follow. You’ll get feedback from others that may have tried to solve a similar problem and have insight you may not have thought of. You’ll leave a clear trail to follow for those that work on the code after you. Most importantly, you’ll shed light on your work, which everyone who depends on your work will appreciate. Even if no one else reads what you write, you’ll still have worked through problems in your head that can only lead to better design in the long run. There is no downside to documenting your designs.

One of the experiments I am conducting with a set of interns is to make them write a LearnLog and ProjectLog - just a few bullets or short sentences. We do this in a wiki so that every one in the project has access to it.  It is also one of the easiest and most effective ways to communicate asynchronously with the team.

In the Project Log, they are supposed to write the following:

• Design decisions
• Decision to use libraries/tools and why
• Problem areas and stumbling blocks and how they solved it
• A list of links to the resources they used

It is still an uphill battle but we are getting better gradually.

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.

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.

1. Train clear logical thinking.
2. Understand modern software concepts and environments.
3. Learn to effectively implement customer needs.

Contextual Ads

I just read a piece on the discovery of a new element called Administrium. The geek in me, urged me to click on the link and read the text. Go ahead and read it here.

A major research institution recently announced the discovery of the heaviest element yet known to science, tentatively named administratium.

The funny part of this episode is not just the story but the ads below. Scroll all the way to the bottom and see how well we do in contextual ads -probably triggered by the title “element”.

LinkLog: Programming

From the food pyramid: for the journeyman programmer

It is a great way to structure:

• Teaching Software Development
• Training new employees (the environmental training is equally important)
• A way to understand how developers do in various activities
• For each project move from bottom to top and repeat

Other activities, like reading and writing about programming can help developers break the monotony of just doing work by combining it with a bit of learning.

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