Brute Neighbors

One of my more cherished and private possessions is a book - American Prose. It was printed in 1892, and is filled with short stories by American authors. Every so often, usually in late fall or early winter I'll pick a story at random to read. Today was "Brute Neighbors" by Henry Thoreau.

I think it wonderful that a book over a hundred and twenty-two years old is perfectly functional and enjoyable to read. Though I do dread the day when the book becomes damaged from use and age; I think that I'll continue to read from it each year. It has more value to me as a book then a collector's item.

Not Even In The Same Ballpark

Not so long ago, a new Product Manager told me that she also is a programmer... a software engineer. She implied that if she wanted she could be part of the development team. She had just started and I had no reason not to believe her and accepted it as an interesting side note and went on. As time has gone by it has become increasingly apparent that this individual was never a software engineer in the way that my peers are. The comparison is almost offensive in the stark difference and extreme lack of understanding of what a software engineer does.

To anyone reading this:
Please do not say that you are part of someone else's group unless you truly know about that person's group. I've brewed beer and cider a handful of times. I've even had the lucky experience of brewing some stuff that is better than some store bought stuff. But I would never call myself a brewer in the presence of someone like Sam Calagione or Jamil Zainasheff. I've never brewed commercially and have no concept of the constraints involved, and I don't have near the same range of experiences. Notice the difference in tone the following two statements have:

• I'm a brewer like you.
• I've brewed at home.

If they both seem innocuous then here are some example responses, respectively:

• Oh yeah, what bars are serving your beer?
• Since I have never brewed commercially, I do not grok the need for high efficiency sparging, dealing with distribution laws, etc.
• That's cool. What is your favorite style.
• I love Bock beer. And Belgium style. And Kolsch. And Scotch ale. And, oh man, Southern Tier's Creme Brulee stout is just epic. But I mostly make cider because I'm decent at it.

Of course, those responses could go any number of ways but the point is that you can share that you have some shared experience without implying your of the same level. Especially, when you have no idea. Heck, you might be better but you just met so you have no idea.

In short, just be genuine. If you were hired to do a job, focus on that. Don't worry about trying to "fit in" with people in other roles.

How To Make Meetings Better

1.

Improve collaboration in meetings by removing the chairs from the conference room. Researchers at the Olin Business School at Washington University in St. Louis used body sensors on two groups of participants and found that team members who stood were more engaged, less territorial about their ideas, and generated more creative results.

http://news.wustl.edu/news/Pages/27031.aspx

2.

Start your longer meetings by giving everyone a chance to share what they need to do or to say to be fully attentive. One person might have a specific question. If they have more than one then they should have asked their set of questions beforehand. Another person might need to leave at a specific time. Yet another person might just want to vent about being in meetings all day. If the same person makes this complaint often then they might not be ready to be included in these meetings.

3.

Make more meetings more engaging by making them voluntary. I find it pretty satisfying if one of my meetings finishes and no one leaves. The meeting has developed a life of it's own.

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.