At work; as a labs project; Kaushik Das; who is one of our seriously talented developers has been working on studying the SQL Server Schema --- just for the fun of it. To turn this learning into practical implementation instead of just theory; we decided; to build a web based administration console which users can use manage SQL server instances that they have access to using a web based administration console. This; is how eFORCE SQL DB Administrator was born.

Put simply; the first version of SQLDBAdmin by Kaushik; in it's scope and basic philosophy is pretty much like any other web based administration console for SQL server; one common example being - Microsoft Web Data Administrator.

We do realize that this problem has been solved multiple times before; and we also realize that as of today SQL DB Admin happens to be a 'me too' product; but what we believe makes SQL DB Admin worth giving a try are the following facts:

1. Looks and feels just like the SQL Server 2005 Database Management Studio - so there is very little learning-through-fiddling that needs to be done. 
2. It is free and open source; which means you can not just download it but actually modify the source code for your implementations if needed.
3. We will be working really hard to add new features to SQL DB Admin which might make it easy to do day-to-day administration tasks. Some examples include: scheduling a database backup, compressing a database, re-indexing a table. etc.

As of today you can grab a copy of the SQL DB Admin code base by visiting its codeplex site.

As a matter of fact; this is one of those projects that we just started for 'fun' and now that we have something that works; we are seriously looking at adding new features that give you; dear reader; reasons to download it and use it while comparing it with multiple other web based SQL server administrators that are out there.

If you; dear reader; have a task or a feature in mind that you or your database-administrators do regularly on SQL server administration front and you would like to perform the same tasks through a web based console; let us know about the feature and we will try out best to squeeze those features into the road map for SQL DB Administrator.

In the meantime; if you want to grab a copy of the latest code base and start using it in it's current beta stage; you can get a copy from the SQL DB Admin codeplex website.

We genuinely and sincerely hope that this product; makes your life; as a database administrator; developer or anyone who has to manage multiple remote databases behind the firewall; just a little more easier. We will continue to add new features to SQL DB administrator and then blog about those features when we add them into the product.

Wish us luck.

More open source goodness coming soon.

Stay tuned.

Throughout my career; if there is one thing I have seen a lot in the software development world; it is; programmers who cannot program pretending and advertising that they are the alpha geeks of the millennium.

When I was a young and budding programmer; brimming with dreams and confidence; I walked the world of software development assuming only three kinds of people existed in the world of software development:

1. Alpha-geeks who were kick-ass programmers making huge dents in the universe with their code.
2. Passionate programmers who knew how much they sucked and were on the life-long path of learning how to become kick-ass programmers.
3. Programmers who could not program but were busy pretending they were alpha-geeks.

Then; years later; while consulting for a client; who for the purposes of this post; we shall refer to as Multiplitaxion Inc; I met Jack; and I realized; that I was; dear reader; so very wrong; in my assumptions about people who exist in the software development world.

Jack was not a programmer.

In fact; he had done his major in philosophy.

When I first met Jack; the question that bothered me was simple: how the f@#k did Jack manage to join a software development firm?

In my first few weeks of working with him; I found my answer in the way Jack approached work; people and life. The guy was an interesting storyteller. He was almost a catalyst. To add to that; he was what I then started referring to as a --- 'contributor'.

During the first month of the project; Jack and spent a huge amount of time with me and the five person development team. He would read the requirements end to end and then talk about those requirements; so that we would not have to read them; he had valid questions on the flows we built; he engaged himself in usability testing; he tested the screens that we rolled out and pointed out valid bugs the official testing team was often not able to point out.

Our true surprise however; came when someone from the development team showed Jack how to write Ant scripts and we discovered that he was surprisingly good at it. Within a few days; we also had a build manager; taking up tasks which no developer wanted to take up.

Jack; dear reader;  was not writing a single line of code; but in a matter of three months; he had made himself very difficult to replace.

Steve Yegge brushes against the concept of a contributor in his post on a completely different topic; he explains:

Let's face it: there are a lot of professional programmers out there who realize they're not very good at it, and they still find ways to contribute.

If you're suddenly feeling out of your depth, and everyone appears to be running circles around you, what are your options? Well, you might discover you're good at project management, or people management, or UI design, or technical writing, or system administration, any number of other important things that "programmers" aren't necessarily any good at.

You'll start filling those niches (because there's always more work to do), and as soon as you find something you're good at, you'll probably migrate towards doing it full-time.

If you read between the lines; Steve's post might actually suggest that finding other ways to contribute when you discover that you are not a programmer; is not the best of things. You can actually hear a slight tone of sarcasm between the lines if you were to read them carefully. A few years ago; I would probably have agreed; but my experience with Jack; and a couple of other contributors I worked with after Jack; changed my opinion of this topic all together.

Yes; we don't need millions of non-programming contributors; but till date; I hold the opinion; that if you are a young and budding programmer; struggling with programming; not loving it; but you still feel passionately about being connected to the world of software development; you are much better off trying to morph into a contributor who contributes a host of things towards making the project a success and is a 'fun' guy to have on the project.

We do need a select few genuinely passionate 'contributors' around; much like we need good passionate programmers and at times; if you are genuinely passionate; we might not even care if you can write any code in the first place.

So stop trying to pretend you are the best programmer around; stop trying to climb in pecking order of your organization and desperately get promoted to the position of a manager; stop being a whiner; or a 501 programmer.

Find your niche and start making genuine contributions.

I wish you good luck.

Multiplitaxion Inc; a consultancy services organization I worked at years ago was an organization where Managers sat in ivory towers and gave strange; unclear instructions to engineers. Then when you started working; they would score a foul by emailing you about a completely disconnected topic; turning you from a programmer to a multi-tasking joker.

A classic example of unclear instructions happened at a project where we were building device drivers for a multi-functional device. This is when two young engineers fresh out of college were asked to --- 'map device codes to device names' halfway down the project.

What followed; as I watched in horror; was a long tale of errors and confusion; as these two young engineers; too scared to ask and get an intimidating response back from their managers; fumbled through the project document repository in an attempt to find the document that contained master device codes; device names and their mapping. Turns out; the repository had no such document.

After a couple of days of fumbling when the engineers asked for the device codes they were sent an email containing all the device codes that could exist in the system; leaving them to ask for all the device names and the mapping information between the two.

The entire cycle took three days of emailing back and forth after which they finally had everything they needed. It took more than five emails back and forth. One email had device codes; the other hand device names and three others had 'business logic' on how they could map device names to device codes.

My exposure to prickdom however; came when I needed additional specifications of the device and asked for the information I needed. Turns out; the manager was being bogged down with meetings and was too busy to respond to my email. What I got in response of the email I sent was an attachment. It was excel file containing device codes; names; the device specifications and the mapping between the three pieces of information.

As I scrolled through the email trail that had been forwarded to me; I learnt that the file had been sent by the client a couple of months ago.

A Gazillion questions filled my head as I glanced through the file:

1. Why did the manager not upload the file on the project repository and let everyone know?
2. Why did he not send the file to the two young and budding engineers when giving them their assignment?
3. Why did he actually take the pain to extract information out of the file; paste it in an email and send out only partial information over to the engineers; even when they explicitly asked for the information?

While this may sound like an extreme example of prickdom; I have seen managers around the world holding on to information and being highly reluctant to share it out; almost as if their job depends on what they know and what no-one else in the project team knows. Others spam the team with random information that the team does not need in the first place.

Joel Spolsky provides sound advice to young and budding managers when talking about the topic to human task switching. He explains:

On the individual level -- have you ever noticed that you can assign one job to one person, and they'll do a great job, but if you assign two jobs to that person, they won't really get anything done? They'll either do one job well and neglect the other, or they'll do both jobs so slowly you feel like slugs have more zip. That's because programming tasks take so long to task switch. I feel like when I have two programming projects on my plate at once, the task switch time is something like 6 hours. In an 8-hour day, that means multitasking reduces my productivity to 2 hours per day. Pretty dismal.

As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they're going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, think about whether you can handle it yourself before you delegate it to a programmer who is deeply submersed in a project.

At the end of the day it is not just about multitasking. If you call yourself a manager; a leader or whatever-it-is-that-you-call-yourself; it is your responsibility to see to it; that your fellow programmers have precise; compact and concise information to act on the tasks that you expect them to work on.

Do not start parallel threads of work; don't make them starve or look for information when it is readily available with you; and don't bombard them with more information than what is necessary.

If you are not comfortable leading from the front; the least you can do as a manager; dear reader; is get down from your ivory tower; develop a strong bonding with your team; show some empathy; stick around as a helper as they slog; and when they need information make the information available to them; without making them beg for it; or bogging them down with too much data or information that they do not need.

If you can just do that; you have probably taken your first step towards fearless project management without a lot of insecurity.

I wish you good luck on your way ahead.

Remember; if they are confused and lost as they develop; it probably is your fault.

Wikipedia defines Lorem ipsum in a website design proposal as - generally incomprehensible placeholder text allows viewers to focus on the visual elements, rather than the content.

Lipsum - the online Lorem Ipsum generator is bullish about the Lorem Ipsum history and future:

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.

It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.

It was popularized in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

To be honest; Lipsum has a genuine reason to be bullish about Lorem Ipsum.

Graphic designers around the world have loved Lorem Ipsum for more then one generation.

Even today; I see countless graphic designers designing their site-layout using Lorem Ipsum; sending the designs out for review and then replacing them with real content as the project moves ahead.

Most graphic designers love Lorem Ipsum because it keeps them from having to work with those nasty business guys who are way too lazy to think about or give them genuine content upfront. Lorem Ipsum also shields the designers from those pesky programmers who make them fix their nasty HTMLs every time the designers try to work hand-in-hand with them.

The business folks love it because it allows them to walk up to a creative designer and say - 'I want a marketing website' - without having to worry about giving them any content or specifics before they start designing the website.

The programmers love it; because they can now develop their system without having to worry about synchronizing their development with the pretty-looking-screens.

Throw in a few stock photos; make pretty boxes; fill them up with Lorem Ipsum; and you are good to go. Life; for a designer; was never so beautiful before Lorem Ipsum showed up.

Put simply; at the end of the day; programmers love building ugly systems; graphic designers love building pretty boxes and business users love telling both programmers and graphic designers what they should do without feeling the need to take any real responsibility of the content or the message upfront. Lorem ipsum is a universal glue that makes this entire ecosystem function and makes all this possible. No wonder; we all love Lorem Ipsum.

Jason Fried at 37Signals however; has the courage to walk a different path and say no to Lorem Ipsum. He advices developers and designers to consider Lorem Ipsum their enemy; not their friend. He explains:

Lorem ipsum dolor has long been known as the designer’s best friend. We think it should be your enemy. Using lorem ipsum dolor reduces text-based content to a visual design element (a “shape” of text) instead of valuable information someone is going to have to enter and/or read.

We recommend that when you build out interfaces you use real and relevant words not “lorem ipsum” representative text. If your site or application requires data input, enter real and relevant words and type the text, don’t just paste it in from another source. If it’s a name, type a real name. If it’s a city, type a real city. If it’s a password, and it’s repeated twice, type it twice.

The goal here is to get as close to the real customer experience as possible. Don’t abstract yourself from the real experience. Every layer removed pushes you further and further away from the actual customer experience.

Ben Hunt in his book; Save the Pixel; explains the same thing from the perspective of a veteran experienced web designer. He explains:

Design the content, not the box it comes in.

Use your pixels on things that communicate meaning. It used to be very common for web designers to make just templates – attractive or jazzy  containers which would have “content” added at a later time.

This is a fundamentally wrong approach, because it doesn't fulfill the designer's mission - facilitating communication. If you find yourself decorating the package, rather than crafting real, meaningful content, stop & ask: “Are these pixels best used here?”

You want the visitor to focus on the navigation & content as that's where the signposts are that point to the goals.

When you are designing the layout of a website; it is easy for you to get consumed by just the layout and not even think about the content or what the design is trying to communicate in the first place. Ben describes this concept rather articulately in his book - Save The Pixel. In his book he explains:

Design isn't Art. It's not about creating beautiful or thought-provoking things for the sake of it. Design is a discipline – creating communication with a purpose.

So the next time you head out to a Lorem Ipsum generator; try spending some more time on your content or your system and try to figure out the message that your application or website is trying to convey using your design. If you don't have a strong message your pretty boxes will not mean a thing.

Now; go think of a concrete message and decent amount of content or the system before you even open Photoshop.

This dear reader; is your chance to designing something meaningful.

Don't build pretty boxes with Lorem ipsum. Let your design be a part of your communication; what you want to say and what it is that you stand for.

I wish you good luck.

Sam at CodeOder.com asks a rather interesting question; asking which is much like opening a can of worms.

Sam's question seems like a simple question raised by an inquisitive mind; but scratch the surface of the question and you will realize it is not just a controversial question; but a question that can end up defining your character and life-style as a software developer. Sam questions:

We hear vague descriptions about project size tossed about all the time: Ruby on Rails is better for small projects. Java is for large projects. Skip the framework for small projects, but I recommend using one for large projects. What factors go into determining the "size" of a project?

Reflect on the question dear reader; and chances are that you might realize the problem in attempting to answer the question. You probably know this already. If you do not; ask anyone who has spent even a couple of years programming and estimating projects and he will tell you that:

1. Simply counting LOC or number of lines tells you nothing about the project size. It is a ridiculous metric.
2. Complexity is not indicative of largeness but just bad design.
3. Large team size is not an indication of a large project but just an indication of bad management.

And so; if we as programmers; are going to take every metric out there and thrash it against the wall; how are we to then; dear reader; measure which project is large and needs special attention and which project is small and can be built easily?

As a young and budding engineer at Multiplitaxion Inc; years ago; I was a part of countless meetings where my ideas were turned down with stereotype remarks like - yes-we-know-it-worked-for-your-project-but-our-project-is-really-large.

Attending countless number of those meetings taught me that the difference between a large project and a small project can be described using this rather funny code snippet on the sun java forum:

'Large Project' usually does not mean or do a thing other than give you a warm and fuzzy feeling of being involved in something complex deep down inside; and that dear reader; is not such a good thing.

No; seriously; if there is one thing years of programming; software development; and software management has taught me; it is that if you are working on a 'large' project you are doing something wrong.

Now; stop drooling over how large your project is; how huge a team you have; and how many lines of code you have to write. Go ahead; break your next so-called-large project down into smaller components and start hiring kickass developers  who can design each component like there were neatly cut pieces of diamonds.

I wish you good luck.

At Multiplitaxion Inc; a bunch of programmers (me included) started what we called a 'knowledge sharing sessions' which would happen every fortnight. The idea was to exchange thoughts; talk about what we had learnt; and get inspired.

As months passed; the number of people joining these knowledge sharing sessions increased and so did the frequency of these discussions. We moved from once every fortnight to twice a week. With an ever growing audience; discussions moved from hardcore technical topics where people would program on stage; to discussions on design; abstract philosophical topics connected to project management and sometimes these talks even touched the social aspect of things.

Before we knew it; we had turned a technical session planned with a specific purpose into a general purpose discussion forum where people got together and --- well; talked; about --- anything.The little fortnightly meet of ours; dear reader; had turned from a meaningful specific into a wondering generality; and it was happening two days a week.

Now as someone who is a big time fan of TED videos and inspirational books; I completely understand the importance of inspiration. Having said that; most good inspirational book nudge you to read them and then go out there and work. TED talks range for just 18 minutes where people talk about what they have 'done' or 'built' and the entire event ends in about three days; after which you get down to real work of trying to make dents in the universe.

That is exactly what makes TED so beautiful.

We; on the other hand; were doing inspiration two days a week; and that dear reader; was a real problem. We were talking more; and doing less. Jeff Atwood describes this phenomenon rather articulately in his post about doer-or-talker. He explains:

It's an easy conceptual trip from building bridges to building software. In software, some developers take up residence on planet architecture, an otherworldly place where software is eternally planned and discussed but never actually constructed. Having endless discussions about software in a conference room or mailing list feels like useful work-- but is it? Until you've produced a working artifact for the rest of the world to experience, have you really done anything?

There is something to be said about getting ready for and then assembling for a serious meeting in a conference room. Its really easy to fool yourself into believing 'this-is-necessary' or 'this-is-important' when in reality it is nowhere in the same vicinity as 'necessary' or 'important'.

Every time you find yourself spending more time getting inspired or discussing stuff than you spend actually doing stuff and shipping things; may I suggest; dear reader; that you take a pause and indulge yourself in some serious work.

Charles Miller uses the example of open source project to illustrate the same point. He explains:

The best way to start an open source project is with code. Working code. Hack away at home on weekends, maybe get a couple of friends to help you out, and don't go public until you have something to show people that does something interesting, and that other people can use to build more interesting stuff on top of.

You need this for a bunch of different reasons: it establishes the original contributor's bona fides in the open-source meritocracy, it shortcuts all sorts of damaging debates about coding styles and architecture that can stop a project before it starts, and so on.

Most importantly, though: working code attracts people who want to code. Design documents attract people who want to talk about coding. I've seen what happens on projects that start with no code and a commitment to produce a design. Some of the procession of UML diagrams were really well put together, but that's about the extent of it.

Yes; inspiration is a critical part of moving forward and so is design but if you surround yourself with people who want to 'talk' inspiration and design all the time; without doing any real work on it; you are going to have highly scalable systems that don't exist and highly rewarding careers which produce no real meaning.

Word of advice; stop talking and ship.

If you are a programmer; slog away at a truly remarkable system; if you are an author; go ship a book; if you are a blogger; blog consistently; if you run a podcast; package and deliver it consistently.

Yes inspiration is important; but remember; it is a medicine and an overdose of inspiration can have some serious side effects.

Take the right amount of inspiration; know when you have had enough; and when you realize you have enough of it; stop; get your ass out there and slog at shipping something.

I wish you good luck.

If you are a programmer or even remotely associated with the world of software development; you have probably seen an entire team; built and function on lies. No; I am not talking about the occasional long nosed marketing weasel who lies to a customer about how much functionality your product has; and how quickly you can get stuff built.

What I am talking about; dear reader; is an entire ecosystem that stems out of the lie of one marketing weasel. Somewhere; during the life time of your project; usually even before the project starts; someone lays a foundation or a contract built on a lie; and then it snowballs from there. Before you know it; you have an entire ecosystem built to survive and thrive in an environment of lies. Jan-Erik explains this much more articulately than me. He explains:

Back when I was doing project work in the traditional waterfall way, I noticed liars all around. Developers lied about the status of their work (more or less deliberately) to the project manager, the customer lied to the project manager about how much functionality they really needed in order to use the product. The salesmen lied to the customer about how quickly the team would deliver.

It was lies all around and we where so used to it that we started to make daily routines to cope with the effect of lies . For this reason, all estimates would for example be padded with a fixed percentage and in all contracts you would find legal statements that would punish the parties if they was caught lying.

It was a cruel environment to work in. We even lied about the process we used, what we said we would do in a sales meeting was often quite different from what we actually did when we started to feel the pressure of delivering.

If you have lived the world of professional software development you can probably connect to Erick's post. Of all the things that Agile does; one of the most important things it does; is that it brings things out in the open. But even Agile; in all it's glory cannot keep the liars out of your project and your professional life if the very foundations of your project are built on lies. Jan discusses this while talking about the benefits and limitations of agile. He explains:

So, where have all the lairs gone? The lying people are still there, even in Agile teams. But it is simply too hard for them to lie and they gain too little from doing it.

Whenever it becomes easier to lie than to be honest and the immediate gains of lying is high enough, they will be back.

If you miss the times of deception and lies, please feel free to put more formalities and team separation into your process. And make sure to have lots of fixed price projects. The liars will be back before you know it.

Let's try to stay honest for a while, it feels much better than the alternative, don't you agree?

Visualize for example; the vice-president of marketing in a meeting room when a simple statement - we-can-get-this-done-in-a-month - can land him with a fixed price project worth a couple of hundred thousand dollars and you might understand how easy it is to find yourself engaging in a tiny little lie that you feel can be turned into reality by putting a just-a-little-bit-of-pressure on your team.

That's when the grand saga of lies begin which pretty much runs downhill; till the time developers give into the pressure and start looping around in the infinite loop of failure.

Look around your office hard enough; and you might actually come across a manager or two who actually want you to lie and tell them the every-thing-is-on-schedule even when it is not.

Look around your office hard enough; and you might also find developers who cannot break the bad news or give up.

Whenever it becomes easier to lie than to be honest and the immediate gains of lying are high enough; people will lie and those very lies will create broken windows that result in projects; careers and organizations coming to a slow painful end.

If you are a programmer; a manager; or a young and budding entrepreneur starting your own organization; might I present to you; dear reader; three simple ground rules that you can stick to and avoid the painful software-development-ecosystems built on lies. The rules are really very simple:

1. Do not work with clients who want you to meet unrealistic hard dead-lines on fixed time fixed price projects.
2. Do not hire managers who have a habit of estimating tasks in man-hours.
3. Do not hire developers who cannot say no and are always ninety percent done.

Yes; all of the above is easier said than done; but I have personally seen organizations that stick to these rules; and reap the benefits by building remarkable software and building meaning.

Remember; every lie in your professional life; is a broken window with the full potential of snowballing into something nasty. Go ahead; say 'no' to your manager; give your estimations in days or weeks instead of hours; fail remarkably and turn down a client who just has to get the product built with every single feature discussed; before the road show which is three weeks from today.

I wish you good luck.

During my stay at Multiplitaxion Inc; I am asked to oversee a project that folks in the management team think is not shipping as effectively as it should. I am given access to the project repository and the mailing list. By the time I close my outlook on the very first day; I see project members communicate using very different medium of communications than the ones I am used to. Somewhere; a connection seems to be missing and they don't seem to be 'talking'.

Emails --- rule how project communication happens; how tasks are assigned; how task completion announcements are made.

On the very first day in the project; I quite literally; get spammed with over a hundred emails.

Emails providing details about mundane; irrelevant facts like:

1. A programmer just checked in a couple of code file.
2. A tester is taking the local development database down for five minutes.
3. A tester is taking SVN update.
4. The local database is back up again.
5. Bug IDs of bugs that have been assigned to a particular developer.
6. Bug IDs of bugs that have been fixed and assigned to a particular tester.

People in this project; had a tendency to paste SVN logs into emails and send those out for every check-in that they did. For every piece of work that you did; for every minor assignment you completed; it was expected that you to write an email; and send it out. When you send the email you were expected to  copy the entire team.

Now; to be honest; there was nothing wrong with me getting over a hundred emails. I would have been happy deleting the emails and moving on with my life; but then a hundred plus emails in my inbox meant that:

1. People on the project were wasting a lot of time writing these emails.
2. People on the project were wasting a lot of time reading these emails and dealing with random redundant noise.
3. People on the project were doing some level of CYA.

It was generally believed that if a programmer sent out a cryptic email with a SVN log of a check-in; he basically passed the responsibility of testing the code over to a tester; who was supposed to grab that email; get an update; understand what changed by looking at the log; and test the newly built functionality.

Shivers of chill ran down my spine as I saw the hundred plus emails get downloaded into my mailbox; emails with cryptic signals that you had to monitor like a hawk to see what was getting done or for that matter; what was not getting done. Terror struck with the number of emails I was getting just from this project team; I decided to investigate and find out what started the whole CYA exercise of emailing the entire team every time you did anything.

Turns out; the team had once been told to send out regular email updates on every SVN commit they did. Being the introverts and un-social creatures we as programmers are; every single programmer in the team; even the best of the builders; started following the rule; and in some little perverted corners of their geeky-brains started somewhat enjoying the rule.

When I was asked in a management meeting what it would take to get the team to become fully productive; my response was simple; direct and straight forward. The team was already productive. All you had to do to get things done was cut off their email accounts from them and you would have a golden team that not just flocked well; but communicated and connected with each other.

That dear reader; was of-course easier said than done. After days of trying to convince people to walk up to person in the next cubical and talk; if there was one thing that I learnt it was this: if you want your programmers to succeed; keep them as far away from meetings and emails. Get them white-boards; get them markers and more than anything else get them to talk to each.

So the next time you find yourself writing an email to your colleague; stop. Think. Can you use better forms of communication than a random haphazardly written email? If you must use email; can you limit your audience to people who really need to act on your emails rather than randomly emailing the entire team? Take some time and indulge in some serious soul searching before you press that send button.

After all; you might be spamming your whole team; and you might not even know it.

What is worse; is that you might be spending hours of your day pretending to yourself that you are indulging in an act that is professional when all you are doing is indulging in a CYA excursive; wasting your time and the time of those who work with you.

Facing a problem fixing that code you are working on?

Don't send an email yet; go talk to the person sitting in the cubical next to you; ask for help and try to strike a meaningful one on one conversation.

I wish you good luck.