I love writing on this blog. For me this blog is more of an opportunity to stand back, evaluate the experiences of my life and write about these, by adding a little bit of myself to this blog. The very fact that I post multiple times a week, turns this blog into something which allows me to exercise my writing skills and develop my writing mussels.

Having said that, this post has developed a very different audience than what I initially expected. Besides programmers, this blog is read by managers, business folks and even my mom. One of the thing that I try to pay special attention to, while writing, is the timelessness of each post.

I try to add content here which usually does not tend to become obsolete when the next version of visual studio comes out. Of course, there are one or two  exceptions, but then, most of it happens to be timeless. At-least I try to make it timeless to the best of my ability, even though when I read my older posts, I do realize how much I sucked.

Because this blog is read my more than one reader, it often means that I end up spending a lot of time adding graphics, hyper linking, formatting and proof reading all content that goes out here.

To be honest, I love doing all of that.

A huge part of my life includes working with other human beings and that is what this blog is all about.

But then, there is another part of my life. A different persona, so to say. One that deals with bytes. One that likes to fiddle with technology, explain design patterns using wild examples and whacky home made philosophies and the one that likes to tinker with the code-base of crux in my free time.

Unlike most software developers, I have been fairly open about my experiences with other developers or what I learn from these experiences but then unlike most developers who write blogs, my close encounters with code and technology often remain undocumented.

The idea is not new however. I have been thinking about this for a long time. The whole concept of learning like a teacher and teaching like a student is something that I have talked about before on this blog.

I think it is time when I can introduce a different part of my personality on a different blog all-together.

People, here is presenting, my code-persona.

Think of code persona as my personal little wall to scribble things on as I work. Just bought a new cam-coder, you might read a review that I slapped together rather quickly there. If I just learnt a neat way to solve a programming problem, you might read it on code persona. The posts on code persona might not be as well formatted or as minutely proof read as this blog, but that's the whole point. Like I said, its my personal little wall.

So What Happens To This Blog?

Nothing. It continues. Just as before.

I am not stopping to write on this blog.

This blog will continue to have posts added to it, just like before.

So if you like the kind of content that you read here, you will continue to find more of it. But if you are a hardcore programmer and you are more interested in curly brackets and semi-colons, code-persona is the blog you also want to subscribe to.

It's been quite some time since I did some serious hardcore technical blogging.

I feel like a little child again and that, I believe is a really good thing.

Feel free to hang out with us on code-persona.

More content will start getting added there soon.

Wish me good luck.

It's Learning Time.

If you have read this blog more than once; you probably know; that as an highly opinionated individual; I tend to express my strong-opinions-weakly-held; rather openly; loudly and boldly.

What you may not know however; dear reader; is that for most of the posts that I write; I try to give a quite bit of time; effort and attention to see to it that as I express my strong opinions openly I do not end up sounding like my self-proclaimed-authority or end up posing as an expert on the craft of building software.

I have very little respect for experts and have no intentions on posing as one. Besides; self-proclaimed-experts shouting at the top of their voice are a dime a dozen and no-one cares about what they have to say anyways.

How I think of myself; as far as the field of programming is concerned; is pretty much on the same lines of how Jeff Atwood describes himself as a programmer:

I'll be the first to tell you that I am not an exceptional programmer. A competent programmer, yes. Always. On a good day, perhaps even a decent programmer. But I don't kid myself, either. I'll never be one of the best. But I have an ace up my sleeve that most don't: what I lack in talent, I make up in intensity.

When you think of yourself as someone who is nowhere close to being an exceptional programmer; coming out saying that you are going to start writing a series of technical posts with a different style of technical writing is hard and might even sound like stupidity.

In spite of that; in one of my earlier posts; I explained my gripes with technical writing and announced that every one in a while; I am going to be trying to indulge myself in some interesting fun filled technical writing on this blog. Technical Writing about developing better code that programmers and even managers who were once passionate about programming can enjoy and learn from.

As I mulishly work on trying to develop a writing style that does not doze you off to sleep while reading a technical article; and continue my research for some of the topics and articles I plan on writing about; here is one question that keeps coming back from people I know personally: 'Why?'

'No seriously; Pops' - people I know or work with have told me recently - 'There are tons of technical books on programming out there; why do you want to write another one?' --- or at-least they have said something to that effect.

On the face of it; the obvious reason; dear reader is that I am not hugely happy with the type of technical books that are being written out there and I want to make my humble contribution to the world of software development. The actual; blunt honest and selfish reasons for attempting to write a technical book; dear reader; are however; very different. They are:

1. I want to write a book on the craft of building stuff; programming and coding better primarily because that is what I am interested in learning.
2. I am a loud learner --- what that means is that I like to make a lot of noise when I learn something new.
3. I have seen that I learn the most when share what I am learning with others and teach them what I just picked up.

Put simply; I learn best; when I learn like a teacher.

It's Teaching Time.

For the first couple of years of my career I happen to teach students who were taking their Bachelors in Information Technology. There were quite a few things I learnt and picked up during those days; ranging from giving presentations all the way to basic concepts used in software development and IT.

Most of it was quite valuable.

The first few months however; were not very present.

Here I was; fresh out of high school; picked after of multiple rounds of interviews; as I wondered what my first assignment was going to be.

It was to teach programming and IT lessons to a bunch of students doing their Bachelors in computer science.

Soon I found myself walking into classrooms with my huge ego when every once in a while; a student would just get on the white-board correct me or just prove me out right wrong; as I watched my ego float and sink to the ground.

After it happened a few times; though; I started turning shameless and started learning from my students.

That is when; dear reader; things got interesting and my growth chart; in terms of what I was learning; started shooting up.  That; dear reader; is also when I was able to keep a class full of students fully involved and connected with the topic. That is when we started having something that was close to 'fun'.

If there was one thing that part of my life taught me it was that the only way to teach something to anyone is by brining yourself on the same level ground as your students and walking the same learning path with them.

Put simply; I  realized that I teach best; when I teach like a student.

You Are Invited.

If you find the whole idea of learning like a teacher and teaching like a student confusing; all I can say is; like the rest of the software development world today it is supposed-to-be-confusing; in a very good way.  Michel Lopp describes this confusion much more articulately than me when nudging managers to write code in his book Managing Humans. He explains:

The simple fact is that well-defined roles in software development are fading.

User interface guys are doing what can only be called development in JavaScript and CSS. Developers are learning more about interaction design.

Everybody is talking to everybody else and they’re learning from each other’s mistakes, stealing each other’s code, and there is no reason that a manager shouldn’t be participating in this massive global cross-pollination information cluster-f@ck.

Michael's invitation of joining the massive global cross-pollination information cluster-f@ck is not just limited to nudging young and budding managers  to write code. Take the same idea further and it extends rather well to how the world in general and web in particular is shaping up.

While my early teaching days were painful and merciless on my ego; as I struggled to turn from a teacher into a student; the web today makes it possible for every single one of us to do that much more easily; and this dear reader; is precisely what I intend to do with these series of posts.

With my first book slowly starting to reach an end I will indulge in free-flying and writing about anything that is on my mind; but then every every once in a while; you might end up seeing articles here on how to build stuff better.

You might connect to some of these articles and find them useful if you are a developer; or a manager who was once passionate about development and still wants to remain technical; even if you do not code actively. The other possibility is that you might hate them; find that I am overly simplifying things and adding too much spice to serious technical topics. There might even be times where you might discover that I am talking about things I have no clue about.

As you read these articles; which might show up on this blog every other week or so; please do remember that this is me; teaching as I learn and learning as I teach.

Long story short; I am going to indulge in the act of doing some bathroom singing in a live concert again and you; dear reader; are invited to listen in.

This might be a yet another golden opportunity to come watch me make a fool of myself.

Wish me luck.

By the way; if you find me talking about something that is blatantly wrong; feel free to walk up to the white board; or use the comment field; shatter my ego and tell me how wrong I am. Enlighten me. I will thank you for it. Honest.

Programmer Tip: Differentiating Between Toys And Wisdom.

Have you seen a young and budding programmer flex his engineering mussels?

No; seriously.

If you get a chance to overhear two young and budding engineers bump into each other at a cafeteria or a grocery; chances are that all you will hear is a conversation which revolves around the famous which-technologies-are-you-working-on-now-a-days-question.

Observe.

There is a huge possibility that the discussion will continue forever as both these engineers try to impress each other with the cutting-edge technology they are working on in their latest project. 

You Don't work on Windows Communication Foundation yet?

Seriously?

Don't tell either one of these engineers.

If you do they might look at you like you belong to another planet.

Every now and then I personally witness the minds of more than one young and budding programmer explode when they hear that I am not working on any project that uses Microsoft Windows Workflow Foundation.

As developers we like to drool over the latest technology that Microsoft, Google or 37Signal throws our way. We crave to put it on our resumes and we get a huge technical-ego-boost out of using it in our real-life projects.

Rarely do we realize that all we are doing is tinkering around; consuming API's; tweaking configuration or should we just say --- playing around with new programming toys that are made available to us; year after year.

Now go grab the same two programmers you were overhearing at the grocery and ask them what Inversion of control is; what dependency injection is; or what liskov substitution principal is and watch them stare at you like you just dropped a stinking rat on the table.

Chances are that most of them will fail at even the fundamentals of object orientation.

Look hard; and chances are that you might even find programmers who cannot program working on some seriously cutting edge technologies out there.

If you are one lucky son-of-a-gun who landed in an organization that works on the latest technologies out there; and you have been busy slamming your fingers on the keyboard; writing code on some of the latest technologies out there and living in a technical-paradise; it is time to take a pause and reflect. 

When was the last time you studied closures as a language feature instead of just focusing on lambda expressions as a cool new C# feature?

When was the last time you picked a book on object orientation or the craft of writing better code and decided to browse through it?

When was the last time you kept some time aside for investigating how big your functions should be; what you should call them; or how you can get better at the craft of working with best invention in history computer science?

While it is OK to go grab the latest-beta-version of windows on your box; play around with ubuntu; and have fun exploring Windows Presentation Foundation; are you; dear reader; also giving in serious and conscious effort at understanding programming languages or reflecting on object orientation?

Are you  browsing through the code-base of open source projects out there and seeing how they lay out code; how they design their applications or approaches they take to solve generic problems.

As far as the world of software development is concerned; if playing with toys is important; developing wisdom and deeper insights about the craft of writing good code is equally important.

Do you actively track; realize and differentiate your playing-with-toy time from your wisdom-development time?

How much time do you spend on a weekly basis to get better at the craft of writing better code or developing deeper insights?

What are the tools you use to develop the craft; pick up deeper insights and grow wiser every day; dear reader?

Discuss.

My Gripes With Technical Writing.

My previous blog was all about technical writing. As a young and budding developer; some of the posts out there were aimed at talking about the latest cutting edge technology; flexing my engineering mussel and getting more traffic out of Google.

As I wrote the posts however; I realized that; unless you are talking about the products you are yourself involved in; technical writing is harder than any other forms of writing.

Unless you genuinely believe in the craft of story-telling; the life-cycle of writing a technical post pretty much goes like this: You take a topic; you dissect it; you understand everything there is too understand about it and then you try to pass that understanding over to your readers. It was almost like taking a traditional approach to teaching.

After a while; I realized that there was one word that describes this entire process: Boring.

Don't get me wrong; dear reader. The mere act of writing code or reading it isn't boring. It gets you in the flow and does amazing things to your life. Having said that; the very process of writing about code; or reading about it; is in fact very boring; and there are multiple reasons; dear reader; why this is the case.

I'm going to make a humble attempt at touching some of these reasons and try to figure out why most technical articles or books out there are unable to keep my attention span end-to-end.

Ready?

Let's get started with my gripes on technical writing.

Technical Writing is Based On Facts.

Let's face it; the way most technical writers of today write; Dependency Injection is basically --- dependency injection. That's where most technical writers of today start and stop. Take the Wikipedia definition of dependency injection; for instance. Here is how it goes:

Dependency injection (DI) in computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to more clearly describe the mechanism.

The very first sentence is a turn off. By the time you near the end of the article; you can hear yourself snoring out loud.

It isn't Wikipedia's fault though.

What Wikipedia is doing; dear reader; is capturing facts and presenting them to you. This is what most other technical writers writing technical books seem to be doing. Most of them; seem to base their books or their writing around facts; and the inherent problem with this approach; dear reader; is that facts; are boring.

Lack Of Spice And Information Surrounding The Content.

Pick a few basic books on neuroscience and they will tell you a great deal about how our brain stores and interacts with information. Neuroscientists; around the world; up-till the recent times believed that information in the human brain is stored in a central location and that lesser the information the easier it is to commit and recall.

Recent opinions however; seem to suggest that information in the human brain is basically stored all over the place; and the human brain uses the 'context' to get you a faster recall. Long story short; dear reader; spice and some amount of irrelevant information; connected with the fact is just as important as the fact itself.

I first understood the importance of this brain-rule during my French-classes.

To illustrate my point; dear reader - I am going to teach you some French.

Ready?

The French word for 'who' is 'qui' - I want you to commit this to your memory - get on with your life and do a recall a couple of months later.

Now; if you are like most of us; chances are that a couple of months later; as you move on with your life you are going to forget this piece of information all-together.

Now; do this - turn the literal fact - "who in English equals qui in French" - into a tiny little sentence with some useless information and some context.

Put simply; just try and remember the English sentence - 'who has the key'.

Now; given that the pronunciation of key and qui are exactly the same; months later; when I ask you the French translation of 'who' - chances are; that you will not just remember the French translation; but you might actually have a faster recall.

Ok; back to technical books on programming. The problem with most technical books today; is that they lack this additional spice and information that is supposed to make it easier for people to remember the facts that the book is presenting.

When it comes to technical writing and reading about code; less is not more. In fact; neuroscientists around the world will tell you that when it comes to storing information about a fact; the more random connected information you have about the fact; the higher your chances of remembering that fact are.

Now; look around. Take a look at all the technical books you have. Also take a look at all the technical blogs that you can find online. How many of them give you this additional information connected with the facts they present? How many of them provide you with additional; hugely interesting information that helps you commit and recall the stuff; faster?

Thought so.

This Thing Is Supposed Be Fun.

I've known some amazing fun loving authors and have had the pleasure with observing them or even remotely working with them. These are seriously fun loving guys who can take a concept and drill it into your head by the time you are done with your lunch with them.

However; when they indulge in the act of technical writing; you somehow seem to get a sense that you are reading a completely different individual all together. Pick their books and you will realize that the sense of humor is gone; the jokes are gone; the funny analogies are gone.

What remains is a me-too book or a me-too programming blog on C# or Ruby On Rails that other C# or Ruby On Rails programmers go to.

Over years; our technical writers and authors around the world seem to have nurtured the thought that a technical book ought to be something 'serious' and 'professional' and therefore it is completely inappropriate to go out and experiment when you are writing a technical book or a technical blog-post. That dear reader; makes most technical books and blogs out there nothing more than material that you reference when you are stuck with a problem.

When was the last time you picked up a book on Design Patterns and had 'fun' reading it?

When was the last time you giggled while reading a book on C# programming?

When was the last time you had a deep realization that triggered a chain of thoughts while reading the explanation behind a code-snippet?

Technical Writing Lacks Persona.

Every book; be it a novel; or book about software development; reflects the author's personality. Most technical books out there however; don't.

We have seen the use of F-word; in books and blogs that are connected to software development.

We have seen management books use words like Asshole.

We have seen books on organizations and entrepreneurship which move and inspire.

The idea is not just to grab the attention of readers with purple-cow words; but to leave a little bit of your daily-persona into the book when you are writing it.

While it is true that no-one cares about you or your product; it is also true that there is a little bit of you in everything that you do and that little-bit-of-you makes everything you do different. Most technical writers however; seem to miss out on putting in a little bit of their personality into their technical writing.

We are Taking It Way Too Seriously.

There are over two hundred blogs that I subscribe too. The ones I love the most are blogs where authors take chances; post something that is wrong; learn from their comments and then go out there and change with time.

While the whole idea that authorship does not mean authority seems like a well known fact in blogs that do not talk about code; the ones that do; still seem to be a little hesitant at being opinionated; passing on their own thoughts and insights about the code they are explaining and making blatant mistakes while they do that.

As a matter of fact; most authors seem to take the easy-safe-boring way out; which is to eliminate this information all together.

As authors and programmers are we taking what we write or read; way too seriously?

Are we missing out on all the fun connected with making mistakes and learning from these mistakes?

After all; there is something to be said about learning with a mind of a child.

As I slowly start nearing the end of my first book and as I find more time to fly-free; every 'once-in-a-while'; I plan on working on an article or two that touches code; programming techniques and even design approaches; to see if I can add a little bit of myself to my technical writing.

The idea; dear reader; is to introduce you to my very own personal code persona that has it's very own approach to dissecting and trying to understand code; programming techniques; and information pertaining to improving your programming skills that is freely available out there.

Maybe; I'll make a fool of myself; maybe the articles will not be 'technical enough' for a few hardcore programmers out there. Maybe they may not fetch me all the Google traffic that my older blog used to fetch me; but I am going to go ahead and give it an honest shot anyways.

If you are a programmer at heart; you should too.

Go add a little bit of spice; fun and yourself to every seriously technical post that you are about to publish on your blog.

I dare you.

Small aside: If there is a book or technical blog out there that you know of; which goes deep into programming; code and design in a way that is fun; if you know a book or a technical blog that has an interesting persona of its own; I would love to read it. If its a blog I would love to subscribe to it. Go ahead; drop me a comment; or send me an email.