Remove Hot Network Questions from StackOverflow

While I’m at work, I try to keep distractions at a minimum so I can concentrate on my work.

Like many .Net developers I tend to use StackOverflow a lot but one thing that gets the better of my curiosity is the Hot Network Questions tab on StackOverflow. I’ve clicked on non work related questions fare more time than I’d care to admit. To remedy this, on my workplace computer, I’ve made the HNQ tab go away.


Using the Grease Monkey Firefox add-on it’s possible to create JavaScript scripts, to modify the pages you surf.

I wrote a small script to make the entire thing go away on both StackOverFlow and SoftwareEngineering :

// ==UserScript==
// @name        HNQ Hider
// @description Hides the Stackexchange HNQ

// @include /^https?:\/\/(.*\.)?stackoverflow\.com/.*$/
// @include /^https?:\/\/(.*\.)?*$/

// @version     1
// @grant       none

// ==/UserScript==



Project on Github and code reviews


I recently (in the last few weeks) released a very small project on Github called SummonMonster. I might work on it more later, but for now it does pretty much what I wanted and I am working on something else bigger, so updating it is not a big priority.

This project is an Erlang. I like to play around with Ruby and Erlang at home but for the last few years, I spent most of my time at work with C#. Needless to say my Erlang and Ruby skills aren’t currently up to par with my C# skills.

That’s why I wanted to have the code reviewed. Code reviews are really great. Learning a new language and it’s conventions is always faster when you can have your work reviewed by a peer.

To do this I used a great site which is currently in beta on the stackexchange network. It’s currently called and I suggest you give it a whirl if you are in a similar situation.

Code reviews

Of course, code reviews are better done in person. Since I am on this subject, I will give a few guidelines I personally adhere to for code reviews.

First, code reviews are for everyone. No matter the experience or knowledge of both participants, reviews can always be beneficial. The reviewed person gets a chance to explain his ideas, might find mistakes himself in his code and gives information to the reviewer. Following a review, the reviewer is in a better position to maintain the code in question or answer questions on it when the original author is not available.

All of this suggests that reviews are beneficial even if a person is getting reviewed by someone who is more green. This is a great time for the a new member of the team to learn the standards and conventions used on a particular team or project.

Having everyone submit to code reviews also sends a positive message to new members of a team who might be reluctant to being reviewed. Older members can lead by example.

Secondly, it is always better to review the code at hand rather than the programmer and to question the implementation rather than the person who wrote the code.

Third, how the reviews should be conducted and how/if/when corrections are to be made should be decided in advance.

A policy I like is to have most propositions be optional, especially the ones who would result in a major refactoring. In these cases it might be more efficient to simply correct the reviewed person so that future developments will be free of a certain mistake.

Finally make sure to have a flexible code review policy. A lot of times, check-ins are trivial and do not necessitate a review. Imposing a mandatory review will result in time misspent and a negative view on the review process.