Wisdom from youtube today:

Signs of Enlightenment: https://www.youtube.com/watch?v=VQrhl7KJ0m4

• 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: https://www.youtube.com/watch?v=2MtMdAmoZK4 (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.

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

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="http://schemas.android.com/apk/res/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="com.google.android.gms.version" android:value="@integer/google_play_services_version" />
    <activity android:name="com.google.android.gms.ads.AdActivity" android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize" />
  </application>
</manifest>

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)
        {
            base.OnCreate(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);
            mainLayout.AddView(gameView);
            mainLayout.AddView(adContainer);
            SetContentView(mainLayout);

            // 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
                .Build());

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

            game.Run();
        }
    }
}

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;
            }

            GraphicsDevice.Clear(Color.CornflowerBlue);
            base.Draw(gameTime);
        }
    }
}