Word has it that developers on the Mac team at one point were spending more than 90 hours a week on Mac development. In fact, Apple had T-shirts to commemorate the Team for their efforts:

Andy Hertzfeld describes the work culture at apple back in the days in First-Person:

In multiple cities of this planet, in every office I’ve worked at, every once in a while, I come across one or two Nine-to-Five-Folks who are awesome individuals; they not bad programmers at all and this post is not about criticizing them. This post is about asking the million dollar question:

“Are 8 Hours a Day Enough?”

In a slightly old survey Dan Malachowski from Salary.com suggests that employees aren’t even spending 8 hours a day at work. In his article where he publishes the results of a survey, He explains:

As per the survey surfing the Internet for personal reasons is the top time wasting activity. “Don’t have enough work to do” is the top Time-Wasting excuse. It was sheer co-incidence that I always believed that this is the same excuse people use for wasting precious hours of their life when they are on bench. Anyway, I digress. So basically, Dan doesn’t believe that employees work 8 hours a day. They are in-fact doing multiple other things which cannot be classified as work.

On a serious note, the survey just makes me wonder if it makes sense to measure hours wasted in office by employees? Given the fact that engineers working remotely from home, at times even during insane hours, is a part of the culture in almost all software development shops.

John Wesley has a slightly different take on this. In my personal opinion, John is completely correct in claiming that the 9 to 5 office worker will become a thing of the past for the information worker. He explains why 9 to 5 is not such a good working model:

If you clicked on the link, John suggests that we do away with the 9 to 5 work culture with Information Workers. Instead, John is all about introducing agility into work schedules:

The Mac team’s example, the survey on wasted time and John’s post might seem contradicting at first but give them some thought and they fall in line pretty well. In fact, add them up and they answer the million dollar question we set out to find an answer to. Take data and observations from all these three sources and some commonalities evolve:

1. We as humans, are not very good at working 8 hours at a stretch on PCs. 
2. We as humans, need a re-charge and motivation from time to time, in order to keep us hooked. 
3. We as humans, often multi-task between multiple things! (Multi-tasking is bad for human beings, but it has its own Pluses. It has a “feel good factor” which gives us a high. This is why alt-tabbing in windows feels so much better than working in Tubro-C IDE of Ms-Dos! :))

Know these basic limitations and the next time you take a break between work, don’t feel guilty about it. Having said that, wasting time can be a highly productive activity which can benefit you, your organization and even your clients!

Some ways of productively wasting time and getting recharged include reading about a new technology you are passionate about and seeing how that fits in your current project, talking about code with your colleges, conducting a training, discussing your work related problems with fellow developers, having quick meetings to show off what you are doing or what you are excited about, writing a quick article on something new you learned, answering some questions in a forum etc. (the list can be endless!) - Pick your ways to waste time, depending on which “productive time wasting techniques” re-charge you the most! 

Software Development is like walking on a Treadmill. Stop and you are bound to fall – flat on your face. Keep running and you keep getting fitter and stronger. The fitness and the strength you acquire by running continuously helps you in running faster and harder. It’s a cycle! While it’s important to spend 8 hours a day working, find out productive ways to waste time so that you can put in more and keep your talents razor sharp. Keep running and make it interesting so that you don’t burn out! Who knows, it might give you the motivation and excitement to put in more than 8 hours of work a day.

Patricia Fripp gives a tip on how you can fall in love with your job all over again:

Learn how to maintain personal and professional To-Do Lists for life. There is no better sense of achievement than striking off items from these lists!

Coming back to the million dollar question – Are 8 hours a day enough?

Eight hours a day might be good enough for a job but they may not be good enough for a profession. And they are absolutely no good for keeping a passion alive. If you can’t love what you do, maybe you need to stop right now.  Look harder for profession you can love. Seriously, if you are going to be an unknown-programmer who writes depressing programmer poetry - it’s best that you chase your dreams in a profession you love.

But chances are that if you are reading this, you already enjoy building software and you don't really need the advice on the above paragraph. Spend more time with what you enjoy doing and love it just like you love your lover! Go Ahead, hack your life so that you can spend more time with what you love doing without giving up on other personal commitments. 

To wrap things up, the next time you take a quick-break or engage in an activity for a while, which is technically a waste of time, don't feel guilty! And by the way, the next time you end up spending 16 hours a day with a computer, don't feel guilty either! :)

Ever felt the “need” to go grab all those files you are seeing linked to the current page? Deep-copy type downloading of a website to your box for offline viewing isn’t new. Wget did quite a good job at it back in the days. In fact, even today it does a pretty good job. You give it a URL, you specify the recursion level of “N” and then it goes and fetches all the URL’s which are connected to the specified URL and are “N” levels deep.

Recently however, I was faced with a slightly complicated problem. What I really wanted to do, was to download a set of 500+ word documents from our work intranet (which runs on SharePoint 2003). The word documents were a part of a SharePoint Document Repository that has a gazillion other Word documents. I was faced with the default SharePoint Document Repository View that has Filter options. After I had set the appropriate filters and was able to see some 500 odd documents that I wanted to download on screen, the million dollar question surfaced in my little mind:

“Ok, now I can see the documents I want. How do I click on all these 500 document links and get them to download at-once, in a single shot, without having to go through the download / save / open dialog box for each and every one of those documents?”

I’m pretty much an Internet Explorer guy because I think it starts up faster than Firefox (and for the Firefox lovers, that’s just a personal feeling so no hate mail please :)) – but there are exactly the scenarios where the power of community plug-ins in Firefox leaves Internet Explorer cold.

FlashGot is a cool little Firefox plug-in that can do some serious damage when it comes to downloading multiple files!

Let’s try and juggle around with some hypothetical situations to see where you would need this tool:

1. You’re looking at a SharePoint document repository and you want all 100 documents you see on screen downloaded to your box, right now!
2. You’re looking at a SharePoint document repository, you’ve filtered your view and you want all those documents that you see on your screen downloaded to your box, right now!
3. You are looking at any screen with X number of downloads and you want all those X downloads on your box, right now! (Ok, I think you get the idea :))

The bottom line is that if you often stare at your browser window, look at a web-page and tell yourself – “wow, this page has so many useful links - I wish I could download all of them in a single click” this tool is the Holy Grail you’ve been looking for!

Besides letting you get all those links, FlashGot lets you filter based on File-Types. So if you are in a page which has hyperlinks to 100 documents, 100 MP3s, 50 GIFs, 20 other HTML pages and 12 Text files and you just want to download just the 100 documents in a single click the FlashGot “More Options…” menu comes to the rescue. The "General" Tab in this is the same dialog also lets you pick your favorite download manager.

You just pick the type of files you want to download, click [Tools / FlashGot / FlashGot All…] menu, and pick a folder. That’s it. FlashGot Rips the URLs and adds them to your favorite download manager. Which means, you can now let the Download manager slog away at saving each download as you give yourself a well deserved nap. :)

Initially, when I was told we needed a set of 500+ word files from a SharePoint List, My first reaction was that I would have to use the SharePoint web-services and throw out some custom code to do this. But then, why write code when you can get the same results much faster using a tool? :)

I downloaded some 500+ word attachments from a SharePoint 2003 filtered view using FlashGot and I’m a FlashGot Fan already! Give it a shot, it’s free.

There were a couple of folks who asked me what happened after the one-man-army post? Why did I stop writing? I didn’t. In fact, I’m back! And I feel light and awesome!

The Past couple of weeks were exciting, depressing, motivating and sofa king (to be read loud and very fast, repeatedly) educational that I felt like a baby who was taking his first baby-steps at learning how to walk.

Past couple of weeks was my first time at a lot of different things or for that matter, the first time where I did a lot of things, “differently” (depending on how I see it). A lot of things happened and that changed both my personal and professional life – faster than I could cope up.

So what were these few weeks all about?

1. These weeks have been about watching near and dear ones sort out their problems and knowing completely, that there is nothing I can say or do to help them other than praying for them and standing by them - “if” they need me. 
2. These weeks has been about realizing that at times I can do a people much more help by moving away rather than by being there during the most vulnerable and embarrassing moments of their life.
3. These weeks have been about getting to know a few new people and a lot of people I already knew, newly.
4. These weeks included having a long conversation which lasted for hours in the middle of a busy road and making a promise to myself that I would try to change parts of myself completely, after that conversation. 
5. These weeks have been about seeking help from family and friends by waking them up in the middle on the night, night after night, and then keeping them awake all night in discussions. 
6. These weeks have been about having my friends and family stand by me in all decisions and letting me know that what mattered most to them was my happiness. Everything else was secondary.
7. These weeks have been about getting some very sound, timely and spontaneous advice, which came straight from the heart of friends and family. Advice that has always given me the hope and courage to make the crazy decisions I often make in life.
8. On professional side, these weeks have been about having discussions with mentors and realizing that I can completely trust them to represent me, exactly as I would represent myself, without having any fear of being misquoted, misinterpreted or misunderstood.
9. These weeks have been about dumping the excess baggage and developing stronger roots! These weeks have been about making difficult decisions about what is important to me and what is not and then letting the things that don’t mean much to me, go. It has then been about watching those things come back, all of a sudden. 
10. These weeks have been about trying to become a better human-being on the professional side and trying to become a better person on the personal side.

I wish I could write more about the turn of events rather than just talk in riddles. But then, that would mean writing a very long post involving mundane details of my personal life. :) Rather than writing down and then remembering each and every incident, I would rather remember these few weeks by what they taught me and how they changed me.

I have a habit of versioning myself. After my last version (0.2.0) - this weekend has made me feel like a new me! I feel like the version 0.3.0 of myself was developed and taken to production in the past few  weeks. These past few weeks, as difficult as they were, will be very special to me because they taught me so much on both personal and professional sides that I feel like a baby again.

<Aside> For everyone who can make any sense what-so-ever out of this post, for everyone who talked to me these past couple of week (be it for my personal problems or be it for my minor problems on the professional side), I thank you from deep corners of my heart. Thank you! Thank you for being there. Thank you for discussing. Thank you for teaching me things I will cherish for the rest of my life. Thank you for making me a better person. Thank you for helping me become “Me 0.3.0” :)  </Aside>

These past few weeks have been about realizing that no matter how much I grow, I would always find myself on the road of life long learning where there'll always be something fundamentally new to learn. I will cherish every single lesson learnt in these past few weeks for life. Dear Reader, meet - "Me 0.3.0"! Hopefully, many more versions to come in future as I walk down this road of life long learning. :)

So, you are a kickass programmer? You can write coherent code, tweak it to the last line for performance and spend hours refactoring it? Perfect! Btw, can you write well formed HTML? Or maybe a decently formatted Word Document with amazing content? Oh and yes, are you also good at a Drawing / Design tool?

Every few months I scan through countless resumes without a spell check or grammar check. With very little or no formatting in the resume, the applicant is making a statement: I’m a coder; I’m not supposed to know or care about Microsoft Word!

In a consultant’s life this statement doesn’t sell. Of course, you can’t play all the roles all the time but learning multiple aspects of software development helps you respect and appreciate “the bigger picture”. In special situations it allows you to be a one-man-army!

My Fifteen+ certifications are often discussed in casual conversations with clients, friends and colleagues. At times people wonder why I did certifications ranging from MCSE to OCP when I always was a Programmer at heart. I think Scott Ambler’s idea on Generalizing Specialist answers the question for me:

He describes the whole idea of being a generalizing specialist:

But what are these "other areas" that Scott talks about? The areas vary from individual to individual. If you are a developer who are starting out on his / her career or are a specialized .NET programmer who is submerging himself / herself in code or just one specialization, may I suggest that you also start -

1. Learning Microsoft Word – Learning how to write formatted, presentable and good looking document with awesome content in an Art which takes time to master. Like all things it is practice that will make you perfect. Don’t shun documentation. Start learning the art!
2. Learning a little bit of IT – Folks fumble when asked to configure IIS. Developers who are clueless about how to install active directory on a Windows 2003 box are not difficult to find. If you try really hard you might also find a developer who doesn’t know how to backup his data, format his machine, install Vista and then recover his data back. Learning the art of configuration will make you a better developer who is cognizant of the whole picture, including security. Rolling your sleeves, getting under your desk and tightening your own network cable instead of calling IT helpdesk will go a long way in making you confident in client offices! Setting up your own SVN and Continuous Integration Server will help directly in projects. I spent a few months of my career when I would switch as an IT administrator when Administrators were on leave or not available. Skills I picked up then and during my MCSE days help me every-day.
3. Learn a Drawing / Design tool – I’m a Photoshop guy! The design of this blog isn’t perfect, but it’s self made. I don’t do the UI myself at work – we have specialized folks who do that – but then not giving the design folks a chance to complain about your messing up their formatting or well formed XHTML when you add your server side code to that ASPX file is a good feeling to have. :) Besides, being able to build your uncle’s website’s vision, your cousins marriage invitation card or the new wall of your room in Photoshop, is always fun!
4. Learn Database – Table A has 3 rows 3 columns, Table B has 2 rows 3 columns – how many rows and columns does “select * from A, B” returns? I see countless folks fumble at basics like Cartesian Products or Normalization, look at me blankly when told to write fundamental SQL queries. Tweaking your databases will go a long way in making you write applications which run with blazing fast speed!
5. Learn to write, speak and communicate – basically, learn how to be a thick skinned shameless developer. At the end of the day, every developer does some level of Business Analysis!
6. Learn the language of your end users – If you are making an accounting application, start by reading the three golden rules of accounts. If possible go write a few journal entries! Following the specs a business analyst wrote works, but knowing the domain helps connect to the end users and clients much better.

Besides doing things like learning a new language each year, the first step to becoming a generalizing specialist is to look around you. Take a long hard look at all the other work that goes on around you besides the code that you write. You don’t have to be an expert in all that work, but every now and then, try to pick up a thing or two from all of it.

Can you do the IIS Setup and UI and Database Design and HTML and ASPX for your uncle’s website? Can you talk to him and build for him what he wants? How does your uncle’s website look after you’re done? Decent enough? Usable? Feature-Rich? Secured Enough? :) Start on your road to becoming a one-man-army who is a generalizing specialist today! I wish you luck!

When one of my early projects where I had programmed by co-incidence ended I was really happy to move on to other things in life. Then suddenly, I was told to support the same project for a few more months and then a few more and then a few more.

On one hand maintaining my own code that sucked, made my life miserable. On the other hand however, it taught me how to take ownership of my code early on in my development life.

It taught me to set things right, by ruthless refactoring slowly with time, rather than just giving up or running away. Much like a painter who draws something that he thinks is really beautiful and then sells it at a price, I’ve felt a tinge of sadness in transitioning code over to the client in every other project after the one where I programmed by co-incidence.

Every now and then in my development career I’ve been involved with projects in and outside work where the primary project was migrating from one technology to another.

Migration projects at times are exciting. In migration projects it is implied that you will be spending a lot of time reading code (a skill every developer should cultivate) that folks from all over the world, who you may or may not have ever met or talked to have written. All you end up knowing is that months ago the clients hired a team of consultants. They wrote some code, transitioned it and have now moved on.

Migration projects have also exposed me to my share of Code Smell and snippets that would qualify for Daily WTF (now called worse than Failure).

Every now and then during my development career I’ve also met (and interviewed) a lot consultants. Of all the consultants that I’ve met, I’ve observed a particular kind very closely. Let’s call a consultant of this type – Fred.

Fred has the following peculiar characteristics:

1. Fred usually works in short term billable projects.
2. Fred gets very uncomfortable when he is asked to work in a project that will last for more than 5 months. 
3. Make Fred work in a long term Product that lasts for more than a couple of years that he would have to support and Fred becomes very nervous. 
4. Fred has a tendency to introduce Code Smell and writing snippets that qualify for “Daily WTF” every once-in-a-while.

Long story short, this type works under a philosophy that can be described in a line: Code, Hand over the code, Run and Don’t Look back!

As you dive deeper into Fred’s mentality you realize that there’s a little bit of Fred in all of us. Writing good code is all about getting rid of Fred! So what’s fundamentally wrong with Fred?

Fred is not really a bad programmer. Like all other good programmers Fred is struggling with the same issues we all struggle with: changing requirements, dead-lines, pressure from customer etc. What Fred lacks however is – ownership.

Fred Codes, Fred Codes More. Fred Hands over the code to the Client. Fred turns around and then Fred Runs as fast as he can, to another project. He doesn’t look back and he knows that he got away – Scot-Free! Year after year Fred continues to add “successfully transitioned” projects to his resume but doesn’t learn the art of Refactoring, the art of throwing away code and the art of elasticizing the iron triangle of software development . Big Design Up-front methodologies with no iterations help Fred tremendously in his Run-Away attitude.

An acquaintance in a 300 person process oriented CMM software consultancy house defends Fred - “but he successfully completed a project, right?”- Yeah. (I think I will not answer that question).

Actually, he doesn’t need to defend Fred because this discussion is not about criticizing Fred. Like I said, there’s a little bit of Fred in all of us. Do you have a little bit of Fred in you too?

The first step to getting rid of Fred is to cultivate a sense of code-ownership. Throw out a framework or a tool and commit to support it for at-least a few years. This could be a simple Accounting tool you write for your finance department or an open source project you start with a very small user base. The size of the project or lines of code aren’t important. Start by writing something that you are proud to support and maintain – for a very long time.

If you have posted articles / code out to the world, take time to support your code and content. Answer questions you get related to these. Don't abandon your content and code! Support it. If possible, Get involved in a longer project or product with support contracts.

In other words, learn to stand by your code, writing and words when they are released to the world. Learn to own and support them! Jumping from organization to another or jumping from one project to another, every few months, doesn’t take Fred anywhere in the long run.

Scott W. Ambler compares software development to the iron triangle as follows:

He states the problem rather elegantly:

For a Software Project / Product to be successful, we as development teams and above all, as responsible individuals, need to learn how to elasticize the triangle. Scott suggests over four ways to introduce elasticity in his article. He suggests that you can actually alter any side of the triangle, depending on your project / situation.

Andy Hunt and Venkat Subramaniam in their book – Practices of an Agile Developer suggest time-boxing as an answer:

The book offers a very real example (which I can relate to from past projects that I've worked on):

I’ve seen developers around the world (I refer to them as Fred :)) give-in to the temptation and try to make the triangle elastic by lowering quality. We (a mentor and I) also even went ahead and termed this - the Junior Developer Syndrome.

Having said that, Time-boxing really works wonders in introducing elasticity into the triangle and at the same time maintain sanity! Especially if you are shipping projects / products with a strong leadership and a mature team that will not compromise on quality.

As developers, we all suffer through the I-can-do-it syndrome. It’s easy to get into trap by having a conversation with a marketing person / client, which goes somewhat like –

“Can we build this?” – Developer: Sure.

“Can we build this in 3 months?” - Developer: Ummm….

“Thanks! Our current team is enough to build it, right?” – Developer: I think so... I...

“Great! Thank you so much! Let’s start building it then!”

The next time you estimate or say “yes” continuously in a conversation like the one above ask yourself – have you respected the iron triangle? Have you left enough room for elasticity? If you haven’t, chances are that the fourth dimension - quality - will suffer. Time-boxing, prioritizing features and dropping the ones that don’t really add value is the safest, smartest way to introduce elasticity into the triangle. When in doubt prioritize up-front!

My fascination for fish tanks at one point in my life is well known to all who know me. When I owned the fish tank I spent hours reading the big fat fish encyclopedia and other fish-tank-management (my term :)) books. My objective: To create a self sustaining tank that I would never have to clean or maintain.

“Why can’t this darn thing turn into an eco-system of itself?” - I often wondered. I read about how the eco-system in a real river works and figured that a Fish tank had everything it needs to turn into a self-sustaining eco-system by itself after I had read something in those lines. The fishes could eat the plants, the plants could use what the fishes leave behind, as manure – you know – the whole tiny replica of a real life fresh water eco-system.

I was actually starting to think about simulating the whole running water thing the way it happens in real rivers... I was obsessed; not with actually maintaining the tank but in making sure that I would never have to maintain it! :)

Memories came back to life years later today as an engineer during an interview mentioned this as one of his long term goals:

“I want to manage my own team”.

After some discussion and playing with words (I do this with people I'm friendly with) he was a little confused about what he wanted. Here’s what he was basically saying:

1. I want a team. My team! And I want to manage them.
2. I don’t believe in hierarchies! It'll be an open friendly team... It’ll be my team with no hierarchies.

Here’s what I was hearing:

1. Let’s have just 1 level of hierarchy. I’ll be the one who manages everyone else and everyone else can be my junior. 
2. I hate hierarchies. :)

I was just kidding! Seriously, this guy is awesome and I was just pulling his leg. He knows it! 

But for now, I think I’ll stop playing with words and get back to fish-tanks and software... and my obsession with both of them, which is what I'm comfortable talking about.

At age 12 what I was trying to do with my fish-tank, was this - I was trying to develop an eco-system that I would not have to manage. I soon realized that this was very difficult to achieve with a fish-tank. Doing the same thing with product / software development team is relatively easier. Here’s why:

1. Fishes by their very design aren’t as intelligent as software developers.
2. Fishes suck at communication. They don’t even speak the same language we do.
3. Fishes can’t ask for help when they are failing (or when the tank beings to suck), fishes can’t shout, yell... ok, I think you get the idea. :)

Coming back to the point, jokes apart, I don’t feel that a software team that needs to be managed can survive in the long run. A team that automatically forms a self sustaining, self managing unit, much like that eco-system in the fish-tank, has much higher chance of success.

At work, I've seen multiple teams of three to ten really awesome developers do just that and complete projects successfully without ever feeling the need of being "managed' by someone. I feel privileged to have worked with some of those teams. During the project, we would move in as a team, where everyone had his set of specialization and knew what each one of us would do.  We were all think-skinned developers who would shout if we had a problem.

This brings me back to the more important question - "Can you even Manage smart people?" - In a smart, self sustaining, self managing team, a manager is just like a servant of the rest of the team! When needed, he moves in, cleans up the mess and move out. It just involves ensuring that everyone has everything they need to function so they are on one single track. Doesn't sound very glamorous when I put it that way, does it? 

Mature methodologies like Scrum don't even refer to them as managers. Mature organizations like Yahoo have a better name for them - they call them the single wringable neck. :) -  Ken Schwaber remarks:

The Product Owner job is incredibly difficult. Almost all people fulfilling the Product Owner role are surprised by how much work it is. Historically, Product Owners were questioned by the development organizations about their requirements...They are responsible for elucidating these requirements as needed, decomposing these requirements on an ongoing basis, changing them to optimize return on investment, and even meeting with development teams frequently to tell them what is needed and to review what they have done. The Product Owner has gone from someone who could blame development if a project failed to someone who is responsible for the success or failure of the project. At Yahoo, this person is called the “single wringable neck.”

Managing a team is not as glamorous as a lot of young engineers make it sound; The trick (much like managing a fish-tank) is developing a team that doesn't have to be managed! And by the way, while we're at it - may I also suggest we change the term "My Team" to "The Project Team"? :) And yes, if you are a young developer who really wants to manage the life cycle of a product; I definitely wish you luck and success in due course of time.

Every now and then I meet young, talented and enterprising developers and interns who are hesitant to post code snippets, out of their work environment into the open world. There are some who will not write Code-Project articles for the fear of getting negative feedbacks.

Others won’t speak at knowledge sharing sessions or trainings, even if it’s just within their own organization, until they are fully prepared with an elaborate PPT and have spent hours learning a topic and know it like they know their mother-tongue. Some even worry too much about what their audience thought about a particular training they conducted last month.

Here’s a piece of advice to every young intern and engineer starting out on their careers:

Learn how to get naked!

You should have nothing to hide! Nothing. If you are succeeding in your project, say it. If you are failing, say it in a louder voice! If you are an expert in a topic, say it. If you don’t know a thing about a topic, say it, in a louder voice!

And once you’re naked, develop a thicker skin!

Don’t let the critisms get you down. Instead, use them to become a better developer (and a better person).

Being a think-skinned shameless developer who has nothing to hide is a life-style. After you have lived it, you begin to wonder how the developers, who don’t follow it, live without it :)

Are you a thick-skinned developer? Are you ready to become one? Try the life-style! You might love it! Here are a few steps that can help get you started:

1. Realize how much your code sucks - and then learn to say it with a sense of humor - shamelessly. After all, we all make shitty software… with Bugs! 
2. Ask for more time and make your code better - Pick one of your modules that sucks the most and ask for some extra time to re-factor it. If it’s not ready to ship and you need to work harder, learn to say so without feeling particularly ashamed about it! 
3. Besides writing code learn to talk about code - Try walking into a training that you are about to conduct with just a topic you think you know really well or feel passionately about. No elaborate PPTs, No Preparations! If possible, do this every few weeks. 
4. Throw out a few articles at code-project or start a blog - Blogs and articles open up forms of dialogs where it’s really easy to be shameless and ask questions or say “I don’t know” while answering them. The critism that comes in as comments through your blogs, articles or just ad-hoc email from your readers is usually very constructive. Personally I have and will (hopefully) continue to, learn a lot from Ad-hoc emails and feedback I receive from this blog and my articles.  
5. Read Code – Read code that’s better than code that you would generally write – Quite a few good open source projects are usually a great place to start. If you can’t commit to an open source project submit bug-fixes and patches for the ones you use in your every-day life! 
6. Copy Shamelessly – I’ve copied patterns of coding from every good programmer I ever worked with. In my professional life at work, the most recent example of shameless copy was a different way of writing Configuration Handlers that I picked up from a very capable Developer in my current project.

The above points don't form a definitive guide to becoming a shameless thick-skinned developer but if you’ve never made fun of your own code in a meeting or in a public blog post – they might help you get started on the road of thick-skinned-shamelessness where you might be able to learn much more by being a little more shameless and thick-skinned! I wish you a Safe and a Happy Journey on this road of shameless and thick-skinned development.