Superhuman Developers, Decision Fatigue and Procrastination

Superhuman Developers

So the day has finally come: you've leveled up your development life! Whether it's getting a raise, getting your dream job, landing a side gig for more cash or becoming more recognized by your peers for your value - it's all gravy, right? Take a moment to breathe it in. Reaching a goal, regardless of size, does wonders for our very human need for feedback on our level of success. You worked hard and focused, and it paid off. That's no small feat, so be proud of taking another step (or five) up the ladder.

Fast forward to a day, a week, a month later. With success comes opportunities. Once you have established a foothold as an expert in your craft (or at least one particular subject matter) they will come knocking. Passion is contagious, and many people naturally want a piece of that. Something you possess. It can be wonderful affirmation of your value to be asked to do something with more obvious visibility, or higher responsibility. First you have one person asking you to teach in front of an audience, next another recommends you for leading a new project (or three) and yet another wants you to start blogging more. You are in demand, and everyone is holding out their hand expectantly. You are the savior, the leader, the visionary that will help make them or their project successful!

One problem: You are a finite resource.

You - your mind, your time, your health, your presence - all have a certain max levels of bandwidth. Unfortunately, we are mammals with physical limitations regardless of IQ or creativity. Although there are certainly other opinions on this scenario, science backs me up on this one. Some of you might be thinking the following: 

"Hate to disagree with you, Heather, but... I've got a superior system in place that allows me to simply accomplish more than the average programmer." 

However, usually when we think this, we are simply fooling ourselves. A human being really is a finite resource and we are just setting ourselves up for eventual burnout fast with that mindset. Not to mention the additional fallout of software quality loss and interpersonal relationship failings.

At some level all of us experience the valiant feeling of capability far beyond our actual abilities. We inherently want to solve the problems quickly, correctly, and stand on top of our desks with a cape on and shout "You are welcome, good people!" (Okay, maybe that's just me and my circle of programmers). It's a natural to desire to take on the world's problems - simply because you are capable of doing each of the ones presented to you. Instead of being realistic about your time/abilities/mental health, you take on X times more work then you secretly know you should. But you are SuperDev! You are flattered and excited by the additional responsibility, and a go-getter after all. You can do this. Just need to buckle down, right? 

Decision Fatigue

It's Day 1 of taking on 3 major projects at the same time. What do you do first? Everything is equally important. Your list of things that HAVE to be accomplished immediately might look like the following sample of mine:

CAREER MANAGEMENT

1. Enhance your personal brand with more blog posts weekly

2. Redo/update your website (that hasn't been touched since 2011) immediately

3. Stay ahead of the pack by learning (insert latest Javascript framework here) ASAP

WORK PROJECTS

1. Research a new technology for an upcoming requirement review by Monday

2. Create a proof of concept piece of software for a demo in a few days

3. Manage bug fallout from a recent push to production (urgent)

SIDE PROJECTS

1. Create a statement of work for a new client by Friday

2. Prepare slide deck/code samples for upcoming conference due in a week

3. Come up with better optimization integrating 3rd party software that is running very slow

This is the bane of my existence right now. Decision fatigue is looking at all the things that are possible to do, but have trouble selecting which one to do first, or at all. Choice fatigue plagues us when presented with too many great options of soda at a fountain, or food on a menu. One study in choice fatigue research is that "forcing a consumer to make a series of decisions will tire them out (even though they won’t be conscious of that fatigue). As the decision-making continues, they will be increasingly reluctant to decide at all." [Excerpt from Neuroscience marketing]

For my first attempt, I end up doing things in tandem - giving a little of my time to each and switch back and forth so it FEELS like I'm attending to them all. It works for a bit, until I look at the actual progress for individual tasks vs the the timeline. Everything is crawling along, because I cannot devote time to finishing anything completely. Context switching is difficult to do.

When everything is high priority, nothing is. When you hold all tasks in equal importance, something's gotta be first or you'll never win.

When I am procrastinating because of indecision, I ask myself the same question Tim Ferriss poses in this brief interview: 

Which one of these, if done, will make the rest irrelevant or easier?

After careful consideration, I decide finally that a blog post can come first. It should take a relatively short amount of time. Additionally, this will provide me with fodder for my upcoming speaking gig and satisfy some of the research requests I had been tasked with. 

Procrastination

Second attempt at productivity is now underway. It's been a while since I've blogged. It makes me uneasy to put an idea out there that can be easily trolled online. I felt I had to be "inspired" to blog, and inspiration comes and goes when it pleases in my mind. There is no schedule that it adheres to, or so I thought. So I wait for the enlightenment to come. And wait.... and wait. I start a draft of the faint glimmer of a topic and then toss it almost immediately. O, inspiration, where art thou? Thus procrastination is born.

"At it’s core problem, our brains are making an assumption on the task at hand. Say it’s a project that you’re starting, you may think it’s going to take days or weeks to get done, and as a result never start it. Or, how about thinking that it’s too difficult and that you don’t have the skills. In fact, the human brain is chronologically wired to procrastinate." [Excerpt from Cody McLain's article - highly recommended reading]

I'm incredibly guilty of procrastinating out of fear. If I don't start, I don't have to stare possible failure in the face.

So how do we overcome this? In most cases, the task is not as daunting as it seems if we break it down into the smallest chunk possible. Time management and productivity tactics can assist here (such as the Pomodoro Technique) but none of that matters if you cannot build in an incentive to even begin. Whether it's a blog post, a technical book or a piece of code for the day, the task can be a little overwhelming at times. 

Neil Strauss offers an interesting take on writer's block - he doesn't believe it actually exists. Rather, he suggests your standards are just too high and you are creating performance anxiety for yourself. [Excerpt from interview on Tim Ferriss' Podcast]. I know what you're all thinking...

"LOWER my standards?! This is computer science we are talking about here! No one wants to read something written poorly."

Hear him out first. This was my gut reaction as well. The psychology behind this is making it as easy as possible to succeed with minimal effort on your part, one step at a time. For instance, in this article, Neil outlines doing three mini drafts as follows:

The first draft is for yourself

The second draft is for the reader

The third draft is for the haters

I've found creating mini homework assignments work well for this. It's a lot easier to commit to just doing the first draft for me that no one will ever see. It just gets my ideas down in written form, messy is it might be, and allow me to marinate in it a bit. Then I re-sculpt it for the junior developer, peers, or whatever audience you are catering to. Finally, I look for the holes in my logic or position, and remove anything incorrect that could trigger the evil trolls who only exist to complain about my work in some way (a la Stack Overflow).

After three drafts, we are done - accomplished in short bursts of focused time. I now have a blog post I feel good enough about to run past a mentor. I choose wisely, only looking to someone who both has my best interests at heart, but unafraid to tell me the truth. If I get any constructive feedback, I think on it and decide whether or not to incorporate. Finally, I publish my work.

Checking off even one item in your list is progress. Don't focus on what you didn't get done today - focus on what you accomplished. Your brain will release small amounts of dopamine, motivating you to continue onto the next big thing. [For more, see The Psychology of Checklists]

Managing the demand

Lastly, remember you can trim the fat off of your over-sized list of high priority projects. Politely decline projects that won't have a larger return on the required invested time than others. Suggest a smaller role (such as advising or consulting others to carry out the task) or a deferral to another time. That doesn't make you hard to work with, it makes you the master of your life. The true SuperDev is one that chooses wisely to focus on the most important tasks well, instead of the mediocre many.

So, you're a finite resource. What can you do to manage that?

1. Pick a task to focus on
2. Just start it, even if you don't know where you are going yet
3. Take motivation by focusing on what you've accomplished
4. Choose your commitments wisely


Go forth and #SaveTheCode!


Special thanks to David Neal for the SuperDev illustration

3 Important Programming Tips (that every student should embrace)

1. Immerse yourself in the coding universe

Commit to spending time in and around others that do the kind of tech stack you are learning, and do it right away. For example, the quickest way to learn a foreign language is to live in that country and expose oneself to people that speak the language. There are nuances and cultural pieces of information to be gleaned from this approach and cannot be reflected by formal instruction alone. Go to user groups, participate in things you know absolutely nothing about but are curious and driven enough to figure out. One thing we all have in common is our passion for tech, so connect with those that can share insight. This requires a commitment outside of your school or job hours, but is well worth the effort over time.

2. Ask why before you ask how

If you have come across a particularly confusing piece of code to learn, ask for clarification as to WHY you would use this in the first place. Code without context is not helpful to anyone, not every course is written perfectly, and some are better coders than teachers. Understanding the why will help you know when to apply this technique in the future, and allow you to speak intelligently to other programmers about your opinions on the approach. It is he best way to file it away for later in your mind. An added bonus to this question is that it can send you down an alternate path, if you find the answer unsatisfactory or unclear. Often I have discovered some of the coolest plugins, libraries and frameworks this way. Don't be a lemming - think for yourself. Don't just accept that you have to bang away at some code - know WHY you would do it first. If you don't get a good answer from your teacher or the self-paced course you are going through, put on your detective hat and make some discoveries of your own.

3. Never, ever quit

Mastery of a subject varies in length from person to person. What may seem hard for one is easy for the other. What took 2 years for you to learn one can take 6 months for another subject. Programming is not something you are born doing - you learn to do it. So never, ever quit persuing your passion. You will make more mistakes than you ever thought possible before you can stablize to some true successes. There is no time limit on finding your groove as a coder. Regardless of whether or not other people think you can do it - you can. Those eureka moments are worth every moment of the struggle it takes to get there. So when you are trying your hardest and still not getting that program to compile - take a moment, refocus, walk away - and then return to it. Shift your perspective and approach until you find the right way. What makes a great programmer is an subjective question - but one thing is for sure, they are never made overnight. Be hungry for the solution and resolute to finding it. Many of us have no idea what we are doing when we start on something new. Don't worry, you aren't alone. What will make you stand apart though is your drive and tenacity to figure it out.

It's time to declare war on "Hello, World"

Whoa there. Harsh title? 

Perhaps. War is such a strong word. However, through experience, I have reached the conclusion that this teaching approach cannot be tolerated anymore, and forceful removal is necessary. Stumbling blocks being what they are in this industry, I feel it's time to talk about this, and without any beating around the bush. Let's start with an analogy:

Danny wants to be a board game player. He looks up how to play a board game on the internet. He selects checkers as it's a simple game to learn for someone new. After playing the game a time or two, he feels confident enough to sign up for a beginner board game competition. He is assigned to play chess - which is also a board game, so he figures he can apply what learned from checkers and figure it out as he goes along. His first turn, he moves a piece and feels good about that. The next move that ensues from his opponent leaves him scratching his head. He doesn't understand it exactly, so he decides to shake it off and move another pawn. That's how he learned to do it with checkers, so it can't be that different. It's just a board game. The game progresses with each move from his opponent removing his pieces, one by one, and he can't seem to confiscate any of their pieces in return. Even though he was moving his pieces forward, he didn't understand that each TYPE of piece represents different levels of capabilities. Before he knew it, he was outwitted and checkmated. All he knew was how to move a piece forward one space, like in checkers. But this was not checkers - this was chess. While both games, on a board, with some movement - how you get to the end of a real game is vastly different.

Danny failed to learn the strategy and approach to the game. 

This is what new developers, or experienced developers switching to an unfamiliar tech stack, experience often. As teachers, we believe in breaking things down to it's most basic and simple level. When presenting a quick reference of help, like on Stack Overflow or in the comments section of a blog, this approach is welcome. But when you prepare a tutorial, article, video course or speaking session, you have a greater responsibility to show a more complete application.

Wait a minute. Hello World was not designed to teach people design patterns and architecture. It's just to communicate a small example of what a particular thing does. Why is there a problem with this?

Teaching how to do something that is REAL WORLD in how you would be expected to execute it shouldn't be a concept that we leave behind for the sake of brevity. Documentation examples are notorious for this. One of the fundamentals of clean code is to handle naming in a human readable fashion, as robust as is necessary. Most would agree that getTimezoneAbbreviation() is clearer than the shortened version getTAbbr().

I don't have time to arrange the holy grail of teaching courses. I'm just going to put all my code in one file so I don't have to worry about a bigger structure. As long as it runs and proves the point of the functionality I'm showing, I call it good.

Sure, you could do that. In fact many of the authors of instructional code do this. It doesn't make it good for the student to learn. Why set up the learner for failure? It doesn't really take that much longer to JUST DO IT RIGHT in the first place. At the very least you show proper placement in a real environment, and what kinds of hurdles will have to be overcome in relation to the rest of the application. In addition you also educate, indirectly, how good architecture can work. Reinforcing the fundamental best practices of thoughtful development is the responsibility of all of us. Why take time out to do it any other way? Common sense programming doesn't exist until we make it commonplace.

The reign of Hello, World has had it's time, but a new approach should be considered that can assist the learning curve and make more sense. That is a tutorial style I know I'd be more likely to dive into. Therefore, I issue everyone the challenge to craft more of your examples this way whenever possible. Perhaps we can refer to it as:

Hello, Real World.

Because context matters.

Compatibility: Xamarin Forms 2.0 and UI for Xamarin by Telerik

The new year brings new changes to the Xamarin framework, and most notably the Xamarin Forms abstraction library. With the release of Xamarin 4 and Xamarin Forms 2.0, we have inclusion of Material Design for Android, a new API for ListViews, enhancements for Windows Phones, lot of extras and of course much needed bug fixes. It's a solid release, and looks to make the use of XF even more efficient. The upgrade looks perfect for what is in demand right now.

Sounds good, but I still dislike messing with the visual design. Are there any other options?

Enter UI for Xamarin by our friends at Telerik. Although the Android and iOS libraries were presented previously, support for Xamarin Forms was released in late 2015 with a basic set of controls. More are being added quarterly. They bring the familiarity and ease of their Rad controls to a Xamarin mobile app (if you have had any experience implementing them on .Net applications, they are second to none in quality). You can find out more about the plugin here.

Fantastic! I'm sold. Plugin trial downloaded, Xamarin project started, I'm only gonna focus on Android for now. Adding the plugin references and... wait, why won't my project build?

At this time, UI for Xamarin is compatible with the previous version of Xamarin Forms. Since 2.0 is so new that it just came out, Telerik has not had a chance to test their plugin against it and make it compatible. Do not be dismayed, fellow developer. It is still possible to try out the suite of controls with a few extra steps (which ultimately should be fixed in the next release).

Things you need to know:

• When you download Xamarin 4, you get Xamarin Forms 2.0
• If you use the Visual Studio plugin for Xamarin, the project templates have old references to XF, so a package update via NuGet would be necessary anyway
• Telerik's UI for Xamarin compatibility is only for Xamarin Forms version 1.5.1.6471 [reference]
• You will need the most recent Android SDK (API 23) installed

How to run UI for Xamarin in Xamarin 4

For this example, I choose to set up the app for the Telerik Xamarin Forms ListView control.

1. Create a blank Xamarin Forms Portable app in Visual Studio

2. Uninstall the existing version of Xamarin Forms that is shipped with the visual studio project template. Note the version.

3. Install the Xamarin.Forms NuGet package (must be version 1.5.1.6471 - done through the Package Manager Console in Visual Studio) to the PCL and platform-specific projects. See NuGet command.

4. Add references to the UI for Xamarin Forms controls from Telerik to the PCL and platform-specific projects as you need them. Read the API documentation for specifics about using the ListView control, for example.

5. Pay close attention to what additional NuGet packages are required for the Android project to get up and running using Xamarin.Forms. There is an excellent blog post on installing the necessary references for the Telerik ListView for Xamarin Forms here.

6. Build the project to make sure you are ready to proceed with building your app. If you still find issues building, make sure to clean and build. It may also be necessary to open the bin folder of your Android or iOS project and delete anything that was previously in the Debug folder before building again (thanks to the Xamarin Forums for that suggestion). I only ran into that once at the beginning of this process. After that, no problems with running the Android app.

Eureka! We got a welcome screen. Is this something that could happen again, or just for this version?

Always Be Prepared

Handling compatibilities between software can be a bit of a bear, to be sure. With the ever-changing landscape of mobile apps, we want the growth and enhancements to occur. Seldom does it come with easy integration into existing technologies. But take heart! It won't be long before subsequent min versions should be able to clean that up for us. In the meantime look at it as an opportunity to examine how the fabric of a Xamarin Forms application is woven together with third party plugins. Knowledge that will certainly serve you well in the future.

The SPROC Stress Buster: SQL Table Types

Most recently I worked on a .Net project that required a layer of database obfuscation by working with stored procedures and not the data tables directly.

...Say what now? Why not just Entity Framework for my data access layer like normal?

There are several reasons you might find yourself in this position. Perhaps the DBA does not want to allow you to write records at the table level for added security or you might be batch processing a lot of rows at once... or perhaps the database is in such a state that accessing views might be more preferable. For this project, that requirement meant eliminating Entity Framework as an ORM option for the application - as it requires direct access to the schema in order to reflect the data objects properly.

Translation: Now I must think about database work a little more. 

Kind of a pain in the easy world of plug and play EF. There are always trade offs when determining which architecture piece is the priority: ease of development or additional security approaches. In this case, I needed to put my DBA hat on. The solution involved utilizing a Micro ORM that would execute a stored procedure a layer above the individual tables in the aforementioned SQL database. For this approach a micro ORM was selected: Dapper - the lightweight, quick and nifty framework that allowed you to handle CRUD in a variety of ways with anonymous objects (important if your ORM will have no true knowledge of the database schema).

Re-thinking Repositories

I had several rows that needed to be inserted in bulk. In other words - I didn't want to insert the rows one by one. The performance would be nasty. I had an average of 50 rows to insert all at once that a stored procedure would need to handle. So how do I hand those off to the SPROC within my data access layer in code?

This is starting to sound complicated. Can I give a stored procedure a collection of objects?

Why yes, yes you can. With a table-valued parameter, utilizing user-defined table types.

Great!...What does that mean and how is it done?

It means you decide what the object properties are at the SQL level in the User-Defined Table Types folder in the database (see screen shot below) and that is the data type the stored procedure will expect to receive as a parameter - the entire data table. You just model it after the object you are sending.

What does a database-level data type have to do with Entity Framework's capabilities?

At the time of this project (early 2015), EF did not support user-defined table types. It does not import them from the database and convert to a virtual object that you can access in code and then hand off to an ExecuteStoreProcedure() operation. So, I would loop through my objects and painfully, individually insert them one by one... but this post isn't about the ORM choice (which are ever evolving and add features all the time) - it's about understanding and harnessing type tables to handle your bulk lists of objects and insert them in ONE TRANSACTION.

Why do I care about inserting rows in one transaction? What's the big deal?

Depending on the amount of data, bandwidth. Give it all to the SQL database and let it do the lifting - that's what it's made for, handling large amounts of data. It's important to realize what is going on when you call an Insert() in an ORM. When it comes to scaling up larger data sets, sometimes you need to get your hands in deeper to get more control over the end result.

A Little More Effort for a Lot More Efficiency

This approach is a bit more hands-on but I'd argue that until I did a project like this I never really thought much about how to make data insertion more efficient. Now this is something I can really utilize for shuttling a list of objects to a stored procedure. Table-defined parameters are a great option.


Editor's note: See this post for an excellent how-to with a NuGet package that you can now add onto EF that will handle part of this for you.

Handling the Heap: Xamarin Forms Memory issues on Android

Memory management is, by Xamarin's own admission, an advanced topic in their framework. In order to make the right design pattern decisions with the exciting Xamarin Forms library, you have to first understand what is going on in translation between C# and the native platform you are deploying to. In this article we will tackle the Android build using the Portable Class Library in a XF (Xamarin Forms) solution.

Your Garbage, My Garbage

Java is the language responsible for the native performance on your Android device. It's namespace handles garbage collection differently than the language we are using to build this XF application, which is C#. More than just the .Net approach to garbage collection is Xamarin's custom garbage collector as well. That's three to keep track of. Note that the C# namespace does not contain knowledge of the actual size of your native object - only a small pointer to it, which is exponentially smaller in size (maybe only a 2k object). When it gets collected in .Net/Xamarin Forms will be different than when the native platform disposes of it's objects. It's important to understand this, so you can tackle handling when objects are disposed of in the correct project - PCL or Device-Specific.

Custom Renderer Usings

A great rule of thumb is to wrap Java objects in a using statement when implementing anything on the Android project. For example, a code snippet inside of a Task method class will go from this:

var bitmap = await BitmapFactory.DecodeByteArrayAsync(imageData, 0, imageData.Length, options);

return bitmap;

To this:

using (var bitmap = await BitmapFactory.DecodeByteArrayAsync(imageData, 0, imageData.Length, options))
            {
                return bitmap;
            }

Using statements call Dispose() once the code inside of it has completed, queuing the object for the platform's garbage collector to free it from memory. It won't happen immediately, but it will promote it for priority collection, and should happen faster.

Welcome!

So much is happening. Stay tuned.