Getting people to commit to an idea is hard.
Let's talk about the difference between a Pitch, a Presentation, and a Proposal.
I like working with grownups.
Here's an example:
When I was a wee little New Hire at my current employer, one of the things that came up a lot was the "15 minute rule." That is, if you're stuck on a problem, take a solid 15 minutes to bash your brain against it in whatever manner you see fit. However, if you still don't have an answer after 15 minutes, you must ask someone. I shorten this down to "You must try, and then you must ask." It's a simply-worded rule, which works something like this:
If you've hit the point of giving up, you have to push yourself for another 15 minutes. The pressure is now off. You know that in 15 minutes, you'll be able to take what you found and talk to another person about it and get their help. For right now, all you have to do is step back and look at the whole problem from the top. Maybe you'll find the solution that was sitting there all along. Maybe you'll convince yourself it's completely unsolvable. Whatever you end up doing, those next 15 minutes are where you look at the problem one more time.
During those 15 minutes, you must document everything you're doing so that you can tell someone else. So, what does "look at the problem one more time" mean? It means taking notes. Lots of them. I'm a big fan of using a paper notebook with an excruciatingly fine-point pen, because I don't need to move windows out of the way to keep writing in it, and I can fit a lot of words on a single page. Use what you like, but keep writing. Write down all the steps, all the assumptions, everything you tried, and anythingyou can do to reproduce the problem. More likely than not, you've now probably figured out at least one other way to solve the problem, just by getting it out of your head and onto paper.
After that, you must ask someone for help. Okay, you've decided you need help, and you've spent another 15 minutes looking at the problem again (and again (and again)),and you've documented your approach.
Stop trying to solve the problem, if only for a moment.
Call for help. Even if you think that you almost have it, stop. Even if you think that an incarnation of the wisdom of the masters is perched on your shoulder whispering the answer in your ear, stop. Write that email or walk over to the office/cube/etc. or cast the appropriate summoning spell, but make sure that someone else knows that you need help. Request assistance, state the problem, and show your work. You may not get help right away, but now you've employed at least one other brain in helping you, and now they have a great head-start, courtesy of you.
So, that's the 15 Minute Rule in 3 easy steps.
Here's why it's important:
Your paid hours are costing someone money. You can be in a Professional Services Organization, an internal IT organization, or an independent contractor, but it all works out to the same thing; someone is paying for your skills. While it may feel good to figure out the answer on your own, there's no medal for wasting 3 hours worth of money on a problem that doesn't merit that kind of time. In a sneaky way, this also helps you value your own time, if only by making you ask yourself "Is this problem worth this much of my time?"
Your colleagues will help you because they're playing by the same rules. This means they're used to asking and listening to informed questions, and they'll be expecting the same from their peers. Needless to say, use your common sense... find someone that isn't heads-down in a problem of their own; no one likes to have their flow interrupted. That being said, your colleagues will know that if you come over to ask for help, you'll already have taken time to look it over and documented your findings so they can help you figure out the problem faster or point you in the right direction. It's possible you'll end up Rubber Duck Debugging the problem, and the act of talking through the problem will help you solve it.
Last but certainly not least, You have to interact with your colleagues because they have the answers you need. Building and maintaining an enterprise software platform (to choose something of appropriately fiendish complexity) is not a solo sport. Your colleagues have different ways of understanding problems and different ways of using the knowledge they have. This goes for many definitions of colleague and many definitions of knowledge.
This eventually turns into a virtuous cycle. People value each others' time and their own, so they do their own homework before asking a question. In turn, people are more likely to answer questions because they know the person asking will give them the interesting part of the problem to solve.
Put another way: by explicitly taking enough time, everyone saves time.
Matt Ringel is Enterprise Architect in Akamai's Professional Services team
The following is a guest post from Enterprise Architect Matt Ringel, Senior Enterprise Architect Joseph Morrissey and Enterprise Architect Manuel Alvarez.
There are many factors that affect your site performance and one of the less discussed ones is the Rendering Engine. There are a lot of smart people developing browsers, why should you care about how your page renders? The reason is simple: the rendering engine is using rules to paint your site and if you do not follow them, it will penalize you by slowing you down.
The Rendering Engine is a component of the browser in charge of displaying the requested content. The most common rendering engines, Gecko (Mozilla), WebKit (Safari), old versions of Chrome, and newer versions of Opera) and Trident (IE), follow a similar flow:
Figure 1 Rendering engine flow
At a high level, as soon as the HTML has been retrieved it is sent in chunks to the Rendering Engine. The Rendering Engine will parse the HTML and create the DOM, every element of the HTML will have a corresponding entry in the DOM. Styling information from the CSS along with the visual attributes defined for the elements in the HTML are combined to create the render tree. The render tree is then parsed and the exact coordinates/location of each element in the window is calculated. The render tree is traversed and each element is then painted onto the screen.
The process is not as straightforward as it seems. The Rendering Engine follows defined rules to support the dynamic and evolving nature of websites; for example, an script adding stylesheets causes the page to re-flow as coordinates might need to be adjusted. Another example is that if a <SCRIPT> tag is encountered, parsing of the HTML may pause while the script executed. If the script is external, then parsing pauses until the script is pulled from the network.
Matt Ringel and Joseph Morrissey discussed these rules at the Boston Web Performance Meetup in August and they have summarized them here for you:
The One Rule of Rendering
Anything that introduces uncertainty into how the page should be rendered will block rendering until it's resolved.
Rule #1: Scripts Block Parsing
Rule #2: Style Sheets Block Rendering
Rule #3: Less Caching, More Problems.
During the Boston Web Performance Meetup event, our speakers took a look at the top five rendering issues affecting e-Commerce sites by using these rules. You can watch their findings or download the presentation here.
² CSS "print" styles or non-matching media selectors will not block because they're not immediately applicable