It would take a lot of incentive for established tech workers to uproot and move to…Washington D.C. I just cannot get exited about this news. It’s not official, mind you.
The following is a list of company domains that send out opt-out SPAM / UCE. These companies have no problem sending you daily SPAM, sometimes more than once a day, and then require you to fill out a form to opt-out. I’ve also had instances where a year will go by and new salesman from the same company I’ve opted out start emailing me again, so I’ve stopped opting out and gone to domain blocking. It’s GREAT!
Feel free to import this list into Outlook and make them invisible. I’ve spent months curating this list.
I found, given recent political developments, that I get tempted to access news sites, social media sites, and other non-work related websites at work more and more often lately. I wondered what I could do to force myself to be more disciplined.
One day as I was rigging my hosts file to point to a particular webserver to do some testing, it occurred to me. I should make it harder for me to access these sites by modifying the hosts file for this purpose!
What is a hosts file? If you’re a computer newbie this might be a revelation to you. The hosts file is a legacy system that has plenty of useful applications in today’s networked world. I won’t go into them here, but for the purposes of this post, we want to edit the contents of the file. On most computers, you will need elevated access (Administrator on Windows, root on MacOS) to save changes to this file.
The location of this file on Windows is in the \Windows\system32\drivers\etc folder. It’s named “hosts” without a file extension. This follows the UNIX convention, although years ago it was “hosts.txt”.
Normally this file is almost empty but usually has the “loopback” address there as a lonely entry:
You can leave that there. On a new line, you can start making entries to start blocking access to websites. Here’s a few of mine:
Make sure to save the file and close all open browser tabs and the browser itself. Now when you access twitter in an impulsive moment, you’ll get a nice 404 message.
Note that this technique is also useful for blocking out ads without triggering the “You’re using an adblocker” warning from the website itself. I recommend adding this in, too:
Bye-bye Google ads!
I’ve done this to my work computers several months ago and I’ve found myself to be tremendously more productive. Now, if I want my internet fix I pull my phone out while getting coffee. Hope it helps you too.
If you are unfamiliar with the subculture of Dungeons and Dragons, allow me to enlighten you with one of the rituals of the game. Role playing games are part narrative where the “Dungeon Master” who is the emcee of the game plays referee as well as storyteller. Another part of the game besides narrative is rules based where inflection points such as combat between your brave virtual heroes and monsters is decided by chance with the roll of the dice. When you first start a battle “round” you have to roll initiative. Usually this is a standard six sided die that is thrown both by the Dungeon Master (on behalf of a monster) and the player character. Whoever gets the highest value gets to attack first. This is important because if you are against a tough opponent, dealing a mighty, mortal blow first will likely benefit you due to your foe reeling from your righteous onslaught.
Hold this concept in your mind as we now turn to a team setting in the office.
If you are a manager, then likely you have a team of people who are at various stages of development in their career. What typically happens with junior developers is a cycle of work where you the manager fill the employee’s work queue based on prioritization driven from business needs or internal business owner lobbying. The junior developers will pick a task up, work it, and when they are finished come back to the queue and ask for the next task (or even better just grab the next task off the queue and start).
What do you suppose happens when something comes up, such as a pet project from an executive that appears, usually in the context of a “drive by”? Nine times out of ten the developer will immediately stop and ask the manager, “Which one do you want me to do?” What ensues is a painful back-and-forth that might go like this:
“How much more work will the existing project in flight take to finish?”
“How long will the pet project take to knock out?”
Seasoned developers should know better than to engage in this banter. They should proactively negotiate a deal with their manager. If the new task takes a few hours to knock out, then it should be done so that the team scores a quick win with management and then the developer can context switch back to the original task. Nobody is asking you to multitask, we want you to preemptively multitask. This is computer-speak for pausing on the original task, devoting a time-slice to a new task, and then switching back.
Now that’s one version of initiative that seems to be in scarce supply. A second type I want to discuss is one that separates employees from “goto guys”. A “goto guy” is someone you go to when you want something done. Goto guys anticipate needs and already can tell you three ways to implement it. Goto guys think holistically and recognize an opportunity in the code / the business / the business funnel / etc and they speak up. They come to your desk and tell you about an idea they have they want to work on. EVEN BETTER – they have already done a prototype instead of working on their Facebook likes and they want to show it to you like an eager child showing a parent their finger painting from art class.
What is the environment that would be conducive to this behavior? What can we do as managers to encourage and reward employees that bring this attitude to work with them? I don’t know but I wish I could figure it out. Sometimes it seems people get worn down by the corporate grind and lose that edge that motivates and pushes us. If I see this second kind of initiative I will laud the employee and remember it come bonus or review time.
I read this today and it resonated.
“There is no way to happiness — happiness is the way.” — Thich Nhat Hanh
Read more on ArsTechnica: Ataribox
If you ever visited my home, you would know I have a trove of 1980s Atari computers and game console parts stacked on a wall. Besides the nostalgia of that time in my life where my brother, cousins, and friends spent hours around the TV playing games (and programming!) I honestly hope that Atari has a second life.
The unit purportedly is priced below $300. Still no release date, but as the article I’ve linked to states, at least this isn’t a 3D rendering of a prototype.
Here’s a typical scenario that you might recognize. Your boss sends you an email about an issue in the production environment. You research the issue and immediately find that there is a fast way to fix it, but it is kinda/sorta like a hack and you’d eventually have to refactor it in the future if you wanted to extend the functionality of the feature. You study the problem some more, and realize there is an opportunity here to add more functionality for the users of your product while fixing the issue your boss sent you – the problem with this approach is that it will take at least a week longer than your quick fix. You may have already intuited that there is a third option, which is between the first two I mentioned – industrialize the quick fix but it will take longer to get into production by several days.
Many times in my experiences I’ve found out, ex post facto, that a junior developer will opt for the quick fix band aid. This is one way how fragility and technical debt get injected into the codebase. Similarly, you will find that some seasoned developers will choose the option with the longest implementation time to market because they are driven to create the best possible solution they can – and let everyone know that it has to be done perfectly if it’s worth doing at all.
What developers fail to recognize here is that management has to weigh in the balance multiple competing agendas. A few that come to mind are: customer experience, breakage, and prioritization. The customer experience is something everyone in the company should be interested in. For this particular issue your boss told you about, you should without being asked, try to find out the volume of the issue, and the run-rate. In other words, when did the issue happen, and how many times a day / how many users a day does it affect? Once you quantify the issue, a severity can be gleaned from the results. If the volume is high and impacts revenue then that’s what breakage means. (I tried to find a good definition of breakage but Google kept pushing hair product results at me???) Breakage can be thought of as opportunity cost but that’s not technically correct. You’re not giving the user an alternative you’re removing a an opportunity because the feature is broken. Lastly, if there are high priority features that must wait while you repair existing features that might jeopardize the timeline and release date of the pending launch.
Using empirical metrics calculated by debug logs or sales figures will quickly help you ascertain what the priority of a quick fix is. If the breakage is small or (if you’re lucky) zero, then you can wait until a scheduled release and opt for an industrialized fix or potentially the “Boy Scout fix” which is the second option outlined above. If you respond to your boss quickly with data that supports your recommendation you will have hopefully scored big with her because she will notice you have anticipated business questions and delivered a menu of choices that have accompanying data to lend credence to your conclusions.