How To Make Email Better

1.

Don't open an email unless you are prepared to deal with it right away. If you only open email when you have time to respond, archive, delete, or turn emails into tasks.

2.

Create a filter that searches for "unsubscribe" and put those emails in a separate folder. That way your newsletters and/or deal alerts don't get mixed with your work email.

How To Have A Successful Off-Site

Off-site meetings are a great way to break free from the tunnel vision that can develop in the workplace. They can inspire your team to think big and in creative, new directions. Off-sites can resonate for years.

Before

Set realistic goals. The senior person at the off-site should determine what the off-site is meant to accomplish then create an agenda that guides everyone toward that goal. To ensure that everyone can make an intelligent contribution you must make sure that everyone attending has the relevant data ahead of time.

During

Set ground rules. Consider setting specific times where phones and laptops are not allowed. Any topics that are raised that take away from the off-site goal should be written down - "parked" for later discussion. If questions are asked of your attendees then make them open-ended questions to encourage more participation.

After

End with a plan of action. One way of doing this is to assign a champion to each action item that comes out of the off-site. The champion doesn't have to do the work but they are responsible for getting the right people started on it.

Four Points For a Better Team

1. Promote The Team
• Teamwork is powerful. Reward it. Also, make the effort to stop selfish and egocentric behavior.
2. Get Visual
• Everyone understands a good image. Instead of a paragraph that starts with tl;dr make a graphic that captures the point.
3. Tell The Company Story
• A company story enables deeper understanding than a vision statement. This understanding will help your employees focus on the company mission.
4. Be Present
• Get out and mingle with your employees and coworkers. Your team is watching you so strike up conversations and inspire unity and foster some goodwill.

From Sensing An Opportunity To Implementing An Idea

That's when you know -- you can't sleep because you're thinking about this idea incessantly. -Mona Bijoor, Founder of Joor

The above quote was listed under the heading "On Sensing An Opportunity" in the November 2014 issue of Inc. magazine. I completely agree that always thinking about an idea is an indicator that you are sensing an opportunity. Great! You have sensed an opportunity now what should you do about it?

Write down your idea. It is time to stop just day-dreaming and get to work turning the idea into a reality. Writing down your idea will make it easier to improve, share, and implement. Before trying to improve, share, or implement your idea you need to start thinking about it with purpose.

What is needed to make the idea a reality? How much would it cost? Be sure to break down the costs. One grand sum may be useful for a bottom line but everyone who is serious about your idea will want the details. How will the idea either make money (business venture) or pay for itself (charitable effort)? What percentage of people really want this? Etc.

I can't list out all the questions because many will be specific to your idea. The point is that once you sense an opportunity it is time to stop thinking about how great the idea is and start thinking about how to get it implemented.

Managing Technical Debt

Technical debt is all the shortcuts that save money or speed up progress today at the risk of costing money or slowing down progress in the future. It is inevitable, and can even be a good thing¹ as long as it is managed properly, but this can be difficult. The difficultly comes from many causes, usually has hard-to-predict effects, and almost always involves a gamble about what will happen in the future. Managing technical debt is similar to risk management, and similar techniques can be applied. If technical debt is not managed then it will tend to build up over time until a crisis results. It can be the catalyst to system failure, or a multiplier of failures.

Technical debt can be viewed in multiple ways and can be caused by all levels of a company. It can be managed properly only with the understanding and assistance from all levels. It is extremely important to help nontechnical parties understand the costs that can arise from mismanaging that debt.

1. Releasing code early to get feedback sooner rather than later can save a company from investing heavily in something that is not desired. Fast feedback helps development stay on track with the customer's desires.

Computer Science Areas and Their Journals/Venues

A summary of Computer Science areas, abbreviations, and their corresponding journals and venues.

I started to link each of the journals/venues to each Computer Science area then found that I kept going to Microsoft Academic Search to look them up.

Artificial Intelligence (AI)

• AIJ, JAIR, JAR, AAAI, IJCAI

Bioinformatics (BIO)

• BMC Bioinf, Bioinformatics, JCB, RECOMB, TCBB

Communications and Networking (COMM)

• TON, TCOM, Mobicom, Sigcomm, Infocom

Compilers and Programming Languages (C+PL)

• OOPSLA, POPL, PLDI, TOPLAS, CGO

Computer Architecture (ARCH)

• ISCA, MICRO, DAC, ASPLOS, TCAD, SC

Computer Graphics (GRAPH)

• TOG, CGA, TVCG, SIGGRAPH

Database (DB)

• TODS, VLDB, Sigmod

Distributed Computing (DC)

• TPDS, JPDC, ICDCS, ICPP

Human-Computer Interaction (HCI)

• TOCHI, IJMMs, UMUAI, CHI, CSCW

Image Processing and Computer Vision (IPCV)

• IJCV, TIP, CVPR, ICIP

Machine Learning (ML)

• JMLR, ML, NECO, NIPS, ICML

Management Information Systems (MIS)

• ISR, MANSCI, JMIS, EJIS, MISQ

Multimedia (MM)

• MMS, TMM, IEEEMM, MM, ICMCS

Operational Research and Optimization (OR)

• Math Prog, SIOPT, C&OR, Disc Appl Math

Security (SEC)

• TISSEC, JCS, IEEESP, SP, USS, CSS

Software Engineering (SE)

• TOSEM, ICSE, TACAS, ESE

Theory (TH)

• JACM, SICOMP, STOC, FOCS, SODA

Web Development Best Practices

The following are techniques for maximizing website performance on mobile devices. Personally, since more and more mobile devices are being used to browse content, I think all Web development should be done against the constraints of mobile. Please don't make a "full website" and a "mobile website". Those setups never look good or function well. Furthermore, redirecting a mobile request to a mobile site is expensive and slow. If you are dead set on the "full website" and "mobile website" configuration then make mobile the default and redirect to the full site if the request is not from a mobile device.

A mobile site needs to compensate when bandwidth or service becomes spotty. In other words, the site needs to be responsive even when the network is not. The same can be said for regular websites. Especially if you are trying to break into areas with questionable Internet service, e.g. Bolivar, Missouri, or questionable firewalls, e.g. China.

Eliminate HTTP Requests and Round Trips

• Use CSS sprites to represent images embedded as inline data:URLs.
• Use HTML5 application cache (app cache) to force the browser to cache all the unchanging content.
• Insert dynamic content in the document via XHR (XMLHttpRequest).
• Most effective if you can design the prefix of your page to fit into a single packet, 1492 bytes, render a basic framework for the page before any script is executed. To give the user immediate feedback that the page is loading, load the framework of the page as a fade effect by providing an opacity transitions from 0.0001 to 1.0 just after the framework is loaded. If you cannot get the basic framework of your page to fit into the first packet, then you can instead load a spinner or a logo, again as an opacity transition from 0.0001 to 1.0. The spinner or logo should be conditionally loaded after checking whether the app cache is already populated.
• <script>
    if (window.applicationCache.status == 0) { // Reveal the spinner
  } else {
    // Page was loaded from app cache. Bring out the kitchen sink.
  }
  </script>

• Make changes to minimize DNS lookups and redirects.

Use Compression

• nuff said.

Manage JavaScript Parse Time

• Move the vast majority of script to the bottom of the page.
• Allow the browser to load your JavaScript without recognizing it as script and defer parsing and initial evaluation until needed.
• To do this, set the type of the script to an unrecognized type and change it to text/JavaScript later. For example,
  <script type="deferred" id="module1">
    // deferred code here
  </script>
  When you are ready to use the script, reference the script tag by the id and change the type. The browser will parse and evaluate the script at that time.

Avoid Layout and Style Calculation

• Avoid reading properties that rely on the position of elements on the page to be returned. Any such property could cause the browser to recalculate styles on demand and return the value to your script.

Monitor Request Size

• Reduce the number of cookies you are using.
• Ideally, all requests should be smaller than a TCP packet.

Preload Components

• When the odds are good that you know what a user will request next then it is time to preload.
• This can be seen in Google's Calendar website. The next day's events are loaded as the user clicks through each day, giving the effect that all of the data is already loaded.

Optimize Images

• It is worth the time and effort to experiment with finding a good balance of image compression vs image quality.

Common Recommendations with Questionable Consequences

Make JavaScript and CSS External?

• Inlining all your JavaScript and CSS into each webpage will deliver the best results in terms of speed. For maintenance reasons, you could use XHRs to fetch the JavaScript or CSS and the HTML5 database to store the resource for later reuse.

Make AJAX Cacheable?

• Skip trusting the browser to cache AJAX responses. You're better off to build a full-blown write-through cache layer or a XHR caching layer on top of the HTML5 database.

Properties of Deliberate Practice

Some of the following is a couple pages from Talent is Overrated. It is a good book, if you care about improving your performance and agree that hard work is the way to do it then you should buy it. Most of the following is a personal note for myself to refer back to when defining and refining my own 'properties of deliberate practice'.

The properties of deliberate practice have been studied as key components of self-regulation. Effective self-regulation is something you do before, during, and after the work activity itself.

Before the work.

Self-regulation begins with setting goals. These are not big, life-directing goals, but instead are more immediate goals for what you're going to be doing today. In the research, the poorest performers don't set goals at all; they just slog through their work. Mediocre performers set goals that are general and are often focused on simply achieving a good outcome - win the order; close out my positions at a profit; get the new project proposal done. The best performers set goals that are not about the outcome but about the process of reaching the outcome. For example, instead of just winning the order, their goal might be to focus especially hard on discerning the customer's unstated needs.

You can see how this is strongly analogous to the first step of deliberate practice. It isn't precisely the same; you are not designing a practice activity, but rather doing whatever the requirements of work may demand of you that day. But within that activity, the best performers are focused on how they can get better at some specific element of the work, just as a pianist may focus on improving a particular passage.

With a goal set, the next prework step is planning how to reach the goal. Again, the best performers make the most specific, technique-oriented plans. They're thinking of exactly, not vaguely, how to get to where they're going. So if their goal is discerning the customer's unstated needs, their plan for achieving it on that day may be to listen for certain words the customer might use, or to ask specific questions to bring out the customer's crucial issues.

An important part of prework self-regulation centers on attitudes and beliefs. You may be thinking that figuring out specific goals and plans for what you'll be doing every day sounds hard. It is, and doing it consistently requires high motivation. Where does it come from? The best performers go into their work with a powerful belief in what researchers call their self-efficacy - their ability to perform. They also believe strongly that all their work will pay off for them.

During the work.

The most important self-regulatory skill that top performers use during their work is self-observation. For example, ordinary endurance runners in a race tend to think about anything other than what they're doing; it's painful, and they want to take their minds off it. Elite runners, by contrast, focus intensely on themselves; among other things, they count their breaths and simultaneously count their strides in order to maintain certain ratios.

Most of us don't do work with a significant physical element, but the same principle applies in purely mental work. The best performers observe themselves closely. They are in effect able to step outside themselves, monitor what is happening in their own minds, and ask how it's going. Researchers call this metacognition - knowledge about your own knowledge, thinking about your own thinking. Top performers do this much more systematically than others do; it's an established part of their routine.

Metacognition is important because situations change as they play out. Apart from its role in finding opportunities for practice, it plays a valuable part in helping top performers adapt to changing conditions. When a customer raises a completely unexpected problem in a deal negotiation, an excellent businessperson can pause mentally and observe his or her own mental processes as if from outside: Have I fully understood what's really behind this objection? Am I angry? Am I being hijacked by my emotions? Do I need a different strategy here? What should it be?

In addition, metacognition helps top performers find practice opportunities in evolving situations. Such people can observe their own thinking and ask: What abilities are being taxed in this situation? Can I try out another skill here? Could I be pushing myself a little further? How is it working? Through their ability to observe themselves, they can simultaneously do what they're doing and practice what they're doing.

After the work.

Practice activities are worthless without useful feedback about the results. Similarly, the practice opportunities that we find in work won't do any good if we don't evaluate them afterward. These must be self-evaluations; because the practice activities took place in our own minds, only we can know fully what we were attempting or judge how it turned out.

Excellent performers judge themselves differently from the way other people do. They're more specific, just as they are when they set goals and strategies. Average performers are content to tell themselves that they did great or poorly or okay. The best performers judge themselves against a standard that's relevant for what they're trying to achieve. Sometimes they compare their performance with their own personal best; sometimes they compare with the performance of competitors they're facing or expect to face; sometimes the compare with the best known performance by anyone in the field. Any of those can make sense; the key, as in all deliberate practices, is to choose a comparison that stretches you just beyond your current limits. Research confirms what common sense tells us, that too high a standard is discouraging and not very instructive, while too low a standard produces no advancement.

If you were pushing yourself appropriately and have evaluated yourself rigorously, then you will have identified errors that you made. A critical part of self-evaluation is deciding what caused the errors. Average performers believe their errors were caused by factors outside their control: My opponent got lucky; the task was too hard; I just don't have any natural ability for this. Top performers, by contrast, believe they are responsible for their errors. Note that this is not just a difference of personality or attitude. Recall that the best performers have set highly specific, technique-based goals and strategies for themselves; they have thought through exactly how they intend to achieve what they want. So when something doesn't work, they can relate the failure to specific elements of their performance that may have misfired. Research on champion golfers, for example, has uncovered precisely this pattern. They're much less likely than average golfers to blame their problems on the weather, the course, or chance factors. Instead they focus relentlessly on their own performance.

The final element of the postwork phase is affected by all the others and affects them in turn. You've been through some kind of work experience - a meeting with your team, a trading session, a quarterly budget review, a customer visit. You had thought about what you wanted to achieve and to improve, ant it went however it went. Now: How do you respond? Odds are strong that the experience wasn't perfect, that parts of it were unpleasant. In those cases, excellent performers respond by adapting the way they act; average performers respond by avoiding those situations in the future. That stands to reason. Average performers go into a situation with no clear idea of how they intend to act or how their actions would contribute to reaching their gols. So when things don't turn out perfectly, they attribute the problems to vague forces outside their control. As a result, they are clueless about how to adapt and perform better next time. Little wonder that they'd rather just avoid going through anything like it again, which of course means they have zero chance of getting any better.

Since excellent performers go through a sharply different process from the beginning, they can make good guesses about how to adapt. That is, their ideas for how to perform better next time are likely to work. So it's hardly surprising that they are more likely than average performers to repeat the experience rather than avoid it. And when they do repeat it, we can now understand why they go into it with some of the prework traits and attitudes we observed: They approach the job with more specific goals and strategies, since their previous experience was essentially a test of specific goals and strategies; and they're more likely to believe in their own efficacy because their detailed analysis of their own performance is more effective than the vague, unfocused analysis of average performers. Thus their well-founded belief in their own effectiveness helps give them the crucial motivation to press on, powering a self-reinforcing cycle.

Notes

Yellow: key points
Green: summary statement
Blue: summary story - it explains why deliberate practice matters

Abstraction

We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called "abstraction"; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.

Edsger W. Dijkstra

Agile non-negotibles

Agile non-negotiables are those software engineering practices that you'd be crazy to go without.

Unit Testing: Knowing your code works
Refactoring: Paying down your Technical Debt
Test-Driven Development: Knowing what your Goal is before Coding
Pair Programming: Tightly binding review and development together
Continuous Integration: Making it Production Ready

I'm a little crazy. I don't always use all of the above practices. I try to but my desire to be a hero and get things done quickly overcomes my sensible side. I think most people do this too. There are always outside influences that can seduce a developer into over promising.

The argument for ignoring those outside influences and always practicing the above agile non-negotibles is that you will have:
- better quality code,
- more consistent deliveries, and
- less bugs.

Stop worrying about taking three days to develop something that might have took two days had you left out unit testing or refactoring. That is only a short term savings. Consider how long it will take to fix a missed bug or add a new feature next year.

Using the above practices is an investment in the future of your software.