How to Freaking Enjoy Yourself

Wisdom from youtube today:

Signs of Enlightenment:

  • It is not possible to discern enlightenment in people unless we sit and listen to them. i.e.: Enlightenment is a dynamic filter. Focused movement and interaction lights up enlightened minds in a way that others can see by cutting directly to the truth.
  • It is important not to mistake memory for intelligence. Our society regularly confuses this concept. Intelligence is a process – a way of processing data, not a collection of facts.

About Adventure Movies: (long)

  • Adventure is a Good of First Intent. We don’t need plot elements to convince us of the necessity of adventure. One reason Jurassic Park was a great adventure movie was the people didn’t have to be convinced to be there. They wanted to be there, drawing us along for the ride.
  • In a true adventure, monsters are meant to be understood and respected, not defeated. Again, Jurassic Park met this requirement by not making it about defeating the dinosaurs, but rather about surviving while learning. The true enemies in that movie were the people/ideas trying to destroy the adventure.

Synthesized thoughts:

  • The main reason I enjoy coding is the constant sense of adventure. I often drop projects when most of the adventure has been mined out of them.
  • The main reason I enjoy acting is the movement into fear. The butterflies before a performance are energizing. Acting involves memorizing lines, but the point of acting is interpretation, not simply memorization. I was in a show recently and I noticed that every night I had something new to try, new to give. I love to recite monologues because I get to think about the character and what the words mean for them. Showing these interpretations to others is a risky endeavor!

People worry endlessly about developing creativity and productivity, as if these things aren’t already built into us from birth. We fret about fear and procrastination as if these were defects to eliminate and not signals from a perfectly functioning mind. The point of life is adventure and enlightenment. Children understand this on day one, only to have this sense gradually covered over by a wave of rules-training and domestication. As adults, the wise inner child remains with a few limited means of communicating, but these can be useful if we pay attention:

  • Procrastination is telling you that your priorities are out of order.
  • Fear of failure is telling you that expansion is at hand.

If you want to, you can use these signals to make brave choices and break out of the mold that has been layered over you.


How to Freaking Find Great Developers By Having Them Read Code

When hiring developers, there are many things we are looking for, but over the years I have found that raw coding ability is easily the most important quality to look for.   I can quickly train a person to have knowledge in some domain, but I’ve never seen raw coding ability come from anything other than personal commitment to extensive and deep practice.   Because of this, I have found that some methods work better than others to discover talent.

The Old Way

A typical coding interview starts out something like this:  “Write a function that reverses letter order of words in a string.”  Then for the next half hour or more, the candidate scratches out something on the white board (or a shared text document if they are lucky).    This approach is weak for a number of reasons:

  • The same questions get passed around and candidates often memorize answers.   Are you testing their skill or their ability to memorize answers?
  • The problems are often “trick” problems, requiring some kind of deep insight to come up with the O(log(n)) solution.   True insight almost never comes to even the smartest candidates in the timeframe of an interview.
  • It tilts the power balance in favor of the interviewer.  Who likes having to awkwardly produce code in front of a judge who will determine your professional prospects for the next several years?
  • Writing code on a white board or even a text document is unnatural and slow.  Nobody sketches code on a white board or notepad as part of their daily work.   What people really do is sketch code in an IDE with a heavy dose of Google on the side.

A Better Way

So instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works. This offers some powerful advantages:

  1. Reading probes the most fundamental skills.   Reading code is probably 95% of what a developer does as part of their job.  Whether a developer is writing new code, fixing bugs, or creating documentation, they are constantly reading.

    What abilities does a coder need to read code well?   There are two important ones: 1)  The ability to remember variables and stack locations and 2) The ability to generalize a piece of code once they understand it.   I can memorize interview coding questions, but I can’t prepare for being plopped into some random code (other than just writing and reading code all the time). It is essentially impossible to fake these skills.
  2. Reading code is way more efficient than writing.  A candidate can tell you a lot about their programming skill in the first five minutes of reading because reading is easily an order of magnitude faster than writing. In a reading interview, I can skip around half a dozen essential topics in the time it would take the same person to write code to reverse characters in a string.
  3. Reading puts candidates at ease compared to writing code.  As an interviewer, stress is your enemy because it raises adrenaline which lowers IQ by several points, causing you to miss good candidates.   Candidates prefer reading partly because they are relieved to not have to write code, but also because the interviewer can easily adjust the reading questions to accommodate for the candidate’s skill.   (This adjustment can include writing code if it seems like the candidate wants to.)

How I do this in practice

Here’s some practical points on how I actually do this in interviews:  

  • For each fresh interview cycle, I create a set of predict-the-output exercises that start really easy, then get harder.  My current set starts off with a basic function call, then multi-level function calls, then recursion, then side-effects.  These are generally “pretend” functions that are meant to give the candidate some quick success and give me some clues on how the rest of the interview will go.   For more advanced questions, I pull code from stuff I’ve written.   My current “hard” questions explore ability to make abstractions while reading and also following asynchronous operations.   (Some other things that make good reading are unlabeled routines that execute well-known algorithms such as sorts or tree traversals, and finding bugs from error output.)
  • Before I use my questions with candidates, I calibrate my questions against people I work with so I have a realistic expectation for how to gauge the skill of the candidates.  Calibrating the questions also helps me refine them and weed out confusing parts.
  • At the start of the interview, I explain:
    • I’m NOT testing knowledge of syntax.  Treat me like an AI-enabled google and I will just tell you what some function or operator does.
    • I don’t expect you to finish because nobody does. We will stop after 20 minutes.
    • I don’t expect you to get answers correct.  If the answer is wrong, I would love to see you go back and debug your thinking.  This is just as valuable to me as anything else.
  • The test goes like this: 
    • I show a commented line of code that will call some function and return an output. 
    • The candidate reads the code and predicts the output
    • I uncomment the line and run the program so they can see the answer.   
    • If the answer is different than their prediction, they go back and explain why. 
  • I give the candidate 20 minutes to get as far as they can.  This gives me extra time to ask follow-on questions.    In the interview report, I write how far they got and what strengths and weaknesses they showed.  

Obviously, these special coding skills are not the only thing to probe for in interviews.   Domain knowledge and cultural fit are important, however I find that reading does a great job weeding out candidates who do not fit where it counts the most.

Some of you might want to know how to develop your skills to do well in such an interview.   My answer is simple:  write lots and lots of code because there is no substitute for regular practice. How to get practice?  The easiest way is to crank up some non-trivial side projects that you care about.   A game, a web site, an app, … whatever.    Target 4-8 hours per week of getting into code you care about and make it something you like to use and are proud to show off.    (Also, it helps to host it somewhere and put the source on github so that future employers can see your activity and get a sense of how you work. ) 

Hope this helps

How to get people to freaking visit my web page?

What we are talking about here is “Search Engine Optimization” or SEO.   This is a big topic, but there are a few simple things anyone can do to get started. I will assume you have already set up a blog or web page somewhere.

When you search Google or Bing for something, how do they pick which web site goes to the top of the search? There are really only two things that get a link to the top:

  1. Money – you pay for the privilege to be at the top.
  2. Relevance – lots of other web sites link to yours.

Starting from these two foundational facts, we can arrive at a nice set of practical steps anyone can take to increase web traffic.

Ads – Mostly easy and not as expensive as you think

Internet advertising allows you to target your ads to narrow groups of people. It also allows you the option of paying more when you really want to be noticed. There are many ways to purchase ads online, however there are two major players everyone should know about: Google and Facebook. Both platforms track extensive information on their users in order to sell ads, and they make billions doing so.

Note: It is a common misconception that Google and Facebook sell information about you to advertisers, but this is not true. What they sell is the ability to put an ad on their network and say what kind of people should see it. This keeps your private information private while allowing advertisers to approach you. It’s a pretty neat system, actually, because it helps ensure that most of the ads you see online are relevant to what you might care about. For example, I’ve personally never seen an ad about going to monster truck rallies, but I see ads all the time about electronic gadgets and video games, things I do actually shop for. Targeted advertising is truly a powerful service for both businesses and individuals.

The main difference between Google and Facebook is how they are able to target ads:

Google: What? Google can target ads because of what they know about a user’s searching habits. Their ad system is built around buying specific words or phrases. So let’s say you have a web site for making custom Lego kits. You might want to buy ads for specific word combinations people are typing into google search such as “custom lego”, “lego kits”, “lego building”, etc. You could also try branching out by buying “star wars hobbies”, “batman stuff”, “bored with netflix”, etc.

Facebook: Who? Facebook knows much more about who you are as a person. They know how old you are, family status, job status, interests, hobbies, etc. When you buy ads on Facebook, you are buying into a demographic. Facebook’s ability to do this is unparalleled and most people don’t realize how powerful it is (expect to complain about it). Using the custom lego kits example, a useful demographic might be “single men, with tech jobs, aged 25-35”. Another relevant demographic might be their mothers who would buy custom kits as a gift for their children: “educated married women, ages 45-60”.

On either platform, you can set yourself up with a budget to limit your spending over a period of time. You can also specify the maximum amount you want to spend on any single ad. Spending less means that others who are spending more will get their ads in first, but there is usually enough to go around. If there is not too much competition in your subject, you can reach people for around 20 cents per person. The “gold mine” for any particular ad is to find a niche demographic or search term without a lot of crossover into other domains. This will give you cheap ads because there is little competition, and high click-through rates because the targeting is so precise.

To wrap up: buying ads is a good way to jump start a page. I’ve done it several times and it is pretty easy to generate traffic. The harder part is to know what kinds of ads work best for your money. This takes a lot of experimentation and all of the ad providers have tools to help, but there is still some art to it. There is also a art/skill to helping users stay on your web page and become “converted” by doing something such as reading more articles, buying something, or leaving a comment- that’s a more advanced topic I’m not going to cover here.

Links: The path to “free” advertising

Remember WebCrawler? Alta Vista? Those were the big search engines before Google showed up and blew them all away with a powerful search algorithm that was fast and accurate. The way Google accomplished this was to look carefully at which sites that got linked to the most. The links were evidence that other people trusted the web site as a source of useful information. The actual algorithm is not quite that simple, but it still boils down to having a site that is relevant to what people are searching for.

If you don’t want to spend money on ads, then you can still generate traffic by triggering the things that the Google algorithm is looking for. Here are some ways to do that:

  • The most important thing is to put lots of excellent, desirable content on your web page.  There has to be a reason for people to go there.  Some ideas:
    • Write your own stories and articles
    • Report news that interests you
    • Review products, movies, other web sites, etc.
    • Post the status of projects you are working on
  • Participate on the internet to generate interest for your web site.  E.g.: If you make a web site about lego building, then find social media web sites where people talk about building with legos and use those platforms to write about your web site and send links.
  • Create a unique brand name that is easy to remember and unique for searches.  I made a program a while ago for little kids and I looked for a name that would for sure rise to the top because it was unique. I ended up calling it “PixelWhimsy”  My web page is still the #1 hit for that term.    To test the uniqueness of a name, just do a Google search for it.   E.g.: check out the hit counts for these different terms:
    • “Lego”            743,000,000 hits
    • “LegoBuilder” 186,000,000 hits
    • “SpaceLegos”        341,000 hits
    • “legonaut”                11,600 hits
    • “LegosInSpace”             342 hits
    • “Uberlegonator”               0 hits

By no means is this a comprehensive list for generating web traffic. I’ve left off some powerful options such as getting published or getting an influencer to mention your site. However, what I have listed here can at least get some eyeballs onto your page. The only other piece of advice I have is to make sure there is a way for users to contact you. Actual contact from a user is a rare and insightful and thus valuable.

Hope this helps and good luck!

PS: If you want to dig deeper, here is a site that has a good comprehensive introduction on SEO:

A Freaking AdMob ad in a Monogame project

I’m close to publishing my first Xamarin Monogame app and now I’m putting in ads to monetize it. I knew this would be tricky, but after hours of sifting through bad examples and misleading forum posts, I was pulling my hair out. “Why is this soooo hard?” Finally, I found a sample that actually worked. It was too complicated of course, so I simplified it and I am presenting the results here for you. What you see below is the bare minimum code to get ads working in a Monogame project.  Enjoy!

Step 1: put in required activities and permissions.  My android manifest looks like this:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="" package="AdMobInMonogame.AdMobInMonogame" android:versionCode="1" android:versionName="1.0">
  <uses-sdk />
  <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
  <uses-permission android:name="android.permission.INTERNET" />
  <application android:label="AdMobInMonogame" android:icon="@drawable/Icon">
    <meta-data android:name="" android:value="@integer/google_play_services_version" />
    <activity android:name="" android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize" />

The android activity look like this:

using Android.App;
using Android.Gms.Ads;
using Android.OS;
using Android.Views;
using Android.Widget;

namespace AdMobInMonogame
    [Activity(Label = "AdMobInMonogame" , MainLauncher = true)]
    public class Activity1 : Microsoft.Xna.Framework.AndroidGameActivity
        protected override void OnCreate(Bundle bundle)
            var game = new MyGame();
            var gameView = (View)game.Services.GetService(typeof(View));

            // A container to show the add at the bottom of the page
            var adContainer = new LinearLayout(this);
            adContainer.Orientation = Orientation.Horizontal;
            adContainer.SetGravity(GravityFlags.CenterHorizontal | GravityFlags.Bottom);
            adContainer.SetBackgroundColor(Android.Graphics.Color.Transparent); // Need on some devices, not sure why

            // A layout to hold the ad container and game view
            var mainLayout = new FrameLayout(this);

            // The actual ad
            var bannerAd = new AdView(this)
                AdUnitId = "ca-app-pub-3940256099942544/6300978111", // Get this id from admob "Monetize" tab
                AdSize = AdSize.Banner,

            bannerAd.LoadAd(new AdRequest.Builder()
                .AddTestDevice("DEADBEEF9A2078B6AC72133BB7E6E177") // Prevents generating real impressions while testing

            // Give the game methods to show/hide the ad.
            game.ShowAd = () => adContainer.AddView(bannerAd);
            game.HideAd = () => adContainer.RemoveView(bannerAd);


And finally, the game class is set up to do a simple demonstration that turns the add on or off every 3 seconds:

using System;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;

namespace AdMobInMonogame
    public class MyGame : Game
        GraphicsDeviceManager _graphics;
        double _secondsPassed = 0;
        bool _adIsVisible = false;

        // Methods back into the Android activity to control ads
        public Action ShowAd { get; set; }
        public Action HideAd { get; set; }

        public MyGame()
            _graphics = new GraphicsDeviceManager(this);

        protected override void Draw(GameTime gameTime)
            // Some simple code to turn the add on and off every three seconds
            _secondsPassed += gameTime.ElapsedGameTime.TotalSeconds;
            if(_secondsPassed > 3)
                _secondsPassed = 0;
                if (_adIsVisible) HideAd();
                else ShowAd();
                _adIsVisible = !_adIsVisible;