Book Review: Deep Work

/

Soon after I was about to finish So Good They Can't Ignore You, I stumbled upon a post by Ryan Holiday (another author I frequently follow), and it mentioned another book by Cal Newport - Deep Work. I thought a second and realized, "I think I have a book by that name." I go up to my library and, sure enough, there it is on my shelf. So when I finsihed the current book I was reading I picked this one up. I expected to receive similar benefits as I did in his previous book that I just finished and, sure enough, I got some good insights and advice from it as well.

 
 

The first part of the book goes into how deep work is valuable, yet it's increasingly rare in our work environments. In fact, the author goes into two core abilities you must have to thrive in our work environments. You must have the abilities to do the following:

  • quickly master hard things
  • produce at an elite level in terms of both speed and quality

These two abilities, though, depend on your ability to perform deep work. The author pretty much sums it up in this statement:

If you don't produce you won't thrive - no matter how skilled or talented you are.

This makes sense, of course, but what we may currently produce may not be the best value that we can give.

Deliberate practice needs deep work

You may recall my current strategy for doing deliberate practice for my programming career. However, doing deliberate practice in itself is a practice in deep work because core components of deliberate practice are

  • Having tight focus on a specific skill you’re trying to improve or an idea you’re trying to master
  • Receiving feedback so you can correct your approach to keep your attention exactly where it’s most productive

The first core component of deliberate practice is getting deep work done on the skill or idea you're working on to master. The second component is essential so you can receive feedback to better tailor your next deep work session so you can continue to improve.

In order to produce great work that is valuable working for extended periods with no distractions at all is the key. This is essentially what deep work is, and it is essential to getting the deliberate practice you need to master a skill.

Enemies of deep work

Earlier in this post I mentioned, as the author does several times in the book, that deep work is very valuable, yet it is very rare in current work enviornments. If it's so valuable why isn't it happening more?

The author gives several reasons why, but one of the biggest enemies of deep work is the need to always be connected or to always be reachable, whether through email or through a chat application. I always knew that email was a big distraction from my readings of The Four Hour Workweek. You'll save so much time by scheduling when to check email and only do it, at most, twice a day. Another connection it drew in my mind was, in the Tim Ferriss Podcast episode with David Heinemeier Hansson, DHH (as he's often refered as) goes into how they get so much work done. Once you listen its very simple how...they're able to get deep work done often. The whole company seems to love being able to get deep work done. From a post about working four day work week they mention how they reduce or completely remove the common distractions one can have during a typical work day. Meetings, email, and chat can be very distracting and will remove your concentration causing you to not get much deep work done.

As I say this, me and my company do a good bit of email and we have even adopted Slack as our main way of communication. This doesn't mean that we have to change our ways as a company or anything. This simply means that we have to be more mindful of how we are personally using these tools.

It's ok if we don't immediately respond to an email or chat message. Nothing work related is going to be life or death. The author even mentions a small study done with a group of management consultants at a very big company who were asked to disconnect for a day. Naturally, the consultants were nervous that the clients wouldn't like that, but it turned out that the clients didn't care. People will usually respect your right to become inaccessible as long as those periods are advertised in advance, and are able to get in touch with outside those periods.

How can this help your programming career?

The author cites a great book for developers on honing your craft, The Pragmatic Programmer:

We who cut mere stones must always be envisioning cathedrals.

As developers we are constantly trying to hone our craft of programming. There's always something new to learn in our field, whether we want to stay up-to-date or to go in a different area. Deep Work has good advice to do deliberate practice and ways to change your work day so you can get as much deep work done as possible.

Even in your day-to-day work what you produce can be greatly expanded if the rules of using deep work are applied. Outside of your daily work, incorporating these deep work rules can also be of great use. Going through training material or working on that side project will yield better and quicker results if they are done as deep work.

There were some great insights from this book that I plan to incorporate in my own working life. Even turning off email and checking it on a schedule, I believe, can yield great results. I recommend this book if you feel like you can do more during the day but not quite sure of how it can all be done. It can be done and this book shows you a few ways to get there.

Why I'm Reading Research Papers

/

In my recent post on doing deliberate practice to become a better developer I mentioned that I was going to spend some time to read and understand some research papers. This may seem a like an odd thing to do in order to become better at my craft, but I figured a little experimentation couldn't hurt. At the worst, I'll have a few research papers read and understood. Perhaps I'll even meet one of the co-authors and have something to engage in discussion with. However, I believe I may get a bit more out of it than just that.

Understand Latest Research

Seeing what the latest research trends are, I feel, can be quite beneficial in a practical sense. For instance, there's a paper that suggests that simple testing can prevent most critical failures in software. From reading the paper and Adrian Colyer's post about it one can get a lot of insight about preventing most crashes in software. One having that insight, you can put it to good use in all of the software that you currently are developing.

See Cutting Edge Technologies

I'm sure most of y'all have seen this graph on emerging technologies.

CC BY 2.5, https://en.wikipedia.org/w/index.php?curid=11484459

Keeping up with new research articles allows me to be a part of the early adopters. Whereas now, I'm most likely split between the Early Majority and the Late Majority. Getting in early to new technologies will give multiple advantages, such as being among the first to submit pull requests if they have their code on GitHub, or generating the first set of blog posts on the subjet.

For example, Elm, a functional web language that outputs to JavaScript, was first introduced as a research paper. While I would say it is still in the late stages of the Early Adopter phase, if I was able to get on it earlier soon after this paper came out I could be considered one of the go-to people for this technology and even could help contribute to future releases of it.

Try to Understand More Math

A lot of computer science, and especially most of the research done in the field that I've seen, has a good bit of math behind it. While I took some math in my own studies of computer science, a lot of that was lost due to just not using it or keeping up with it.

While it's not necessary in day-to-day programming, it can be a bit helpful. Learning the math can help develop that extra bit of logic that will help in my daily programming, whether business logic or debugging.

With these benefits in mind, I plan on reading a paper a quarter this year and see how that goes. I'll definitely report back any benefits, or lack of any, that I believe I receive during that process.

My Deliberate Practice Plan to Become a Better Programmer

/

In the previous post, I reviewed the book So Good They Can't Ignore You. I wanted to take the ideas and advice from there and to create my own plan for deliberate practice as a software developer. Here's what I came up with...

Continuous learning

Being a software developer means to always be learning. Whether it's a new framework, new programming language, or a whole new programming paradigm learning something new is integral.

There are several ways to do this and I will try to incorporate all of them, though more will take more presidence and attentnion than others.

  • Use sites like Pluralsight and Udemy for on-demand tutorials and training.
    • Watch at least one course each one or two weeks, depending on the length of the course.
  • Watch at least one software presentation on YouTube or similar site.
    • Watch one at least each week. This should generate some "Top 10" posts for everyone to enjoy or, if it's really good enough, a post about a specific presentation.
  • Read at least one technical book each quarter.
  • Read and try to understand at least one journal paper on programming each quarter.

Practicing

Of course, one of the biggest and best things to do as a developer is to actually program something...anything to help put into practice what I've learned. The above methods are great for learning new things, but they have to be put to use, as well, otherwise I won't be able to retain what I've learned.

  • Have at least one personal project going at a time.
  • Blog about things learned and always have a demo project for it, if possible.
  • Get certified, if available.

Being uncomfortable

Doing deliberate practice often means being uncomfortable during the practice. This is an easy way to know if the practice is good or not. Here a couple of ways I can step outside of my comfort zone.

  • Speak at a local user group at least once each quarter.
  • Try to speak at a conference at least once this year.
  • Do more screencasts instead of regular text posts for the blog.

Keeping track

Now, none of the above doesn't mean all that much if I don't keep track and accoutable for each of these. Saying I'm going to do it doesn't mean I am going to do it.

  • Once again, blogging about each of the above items as much as possible
  • Use a time tracker such as Plan to keep a digital record and for some nice reports.

Since it's very close to the 2017 year, this is a great time to get started with this.

Do you have something you've done work very well for you but wasn't mentioned? What are your plans for having deliberate practice?

Book Review: So Good They Can't Ignore You

/

I've always known books can have a profound impact on your life. So Good They Can't Ignore You just may be one of those books for you. I believe it will be for me. Though, it's not one of those books where you gain so much after just reading it. This book gives you a bit of a guide on how you can be so good at your career, that you can make it become the dream job you often hear about people going after.

 
 

Sections of the Book

Ignore the passion

In the first section of the book, the author goes into why you should ignore your passion for your career; why just following your passion isn't good enough for the job we all dream about.

Build career capital

The second section details about being so good that they can't ignore you - or building what the author calls career capital. Career capital is rare and valuable skills within your line of work and getting good at them.

The author quotes a reader from his blog that very accurately details a key aspect of when you're building career capital:

Willing to grind out long hours with little recongition

This section heavily reminded me of the episode of The Tim Ferriss show with Derek Sivers where Derek goes into, early in your career, say "yes" to everything. But when you get "so good they can't ignore you", you're free to say "no" to whatever comes up that you think doesn't allow you to gain any more career capital or that doesn't interest you.

The best thing to gain from this section is the aspect of deliberate practice. Merely doing the practice of skills you enjoy will result in a plateau of skills. Doing practice and projects that result in being uncomfortable is a way to break away from the plateau and to continue building skills.

Gaining control

The fourth section details that having control in your job will help make it a dream job and loving the work that you do. However, there are two dangers in pursuing more control in your career.

  1. Don't have enough career capital to back up the extra control
  2. Have enough career capital, but employeers will fight back against you having more control.

Derek Sivers comes in and gives advice that the book takes about knowing which of the two dangers you fall into so you can act accordingly:

Do what people are willing to pay you for

Having a mission

Having a mission for your career helps create work that you love. To help find a mission, use the area just beyond the cutting edge of your career field, or the adjacent possible.

Once found, use small steps to get critical feedback in order to imporove quickly, or little bets.

Book Conclusion

An even more interesting part of the book is the conclusion. The conclusion details how the author used each of the sections from the book in his own life as a computer science professor. A very practical example of how these ideas can be used in your own life.

Is this book a must read? If you want to get so good they can't ignore you, then I recommend it. I personally plan on making a plan myself to build up more career capital for myself.

Getting Up and Running with FsLab for Data Science

/

FSAdvent time is back this year! I'm going to use this post to start a new work in progress series on using F# for Dara science. This series will mainly consist of using FsLab to manipulate and visualize data.

Setting Up Your Environment

The easiest way to get setup in the IDE of you choosing is to just download the basic template of FsLab. This just references FsLab with Paket and gives a small script example. That's perfect for all that we need to do.

We're going to go through the script that it provides (with a bit of changes) in this post. Don't worry though, we'll go through a good bit of different aspects of the script in future posts. We're just getting up and running here as sometimes that can be the biggest hurdle to get started in something new.

Generating Data

FsLab comes with the FSharp.Data package which includes a few very useful type providers which help provide a safe and easy way to get data from external sources.

World Bank Type Provider

As previously mentioned, FSharp.Data comes with a few very useful type providers. One that we'll use here to help give us some real world data is the World Bank type provider. You could spend all day looking at what data it provides. For this post, though, we'll look at the US and EU percent added to their GDP from industry.

Setting Up Script

Before we can access the World Bank type provider, though, we need to set up our script to access it. If you used the basic template it will already have FsLab setup with Paket so you would just need to run paket.exe install or build the project.

Now we can reference FsLab so first thing to do is to load the script to access everything we need from it:

#load "packages/FsLab/FsLab.fsx"

Now that we have the FsLab script loaded we can access all sorts of libraries from it by using the 'open' keyword in F#.

open Deedle
open FSharp.Data
open XPlot.GoogleCharts
open XPlot.GoogleCharts.Deedle

We have a few external libraries we're using throughout our script:

  • Using Deedle to explore our data.
  • The FSharp.Data library for our World Bank type provider.
  • GoogleCharts and GoogleCharts.Deedle to visualize our data.

Getting Our Data

Next we instantiate the World Bank type provider and from there we get a reference to the Indicators object for the US and for the EU.

let wb = WorldBankData.GetDataContext()

let us = wb.Countries.``United States``.Indicators
let eu = wb.Countries.``European Union``.Indicators

From there we get the industry percent value added to the country's GDP and create a data series.

let usSeries = series us.``Industry, value added (% of GDP)``
let euSeries = series eu.``Industry, value added (% of GDP)``

Now here is where some work on the data happens.

abs (usSeries - euSeries)
|> Series.sort
|> Series.rev
|> Series.take 5

From here we get the absolute value of the difference of the two series, sort it, get the reverse of it, then take only the first five items. Looks like a bit, but we'll go into details of certain statistics for data science in future posts.

Charting Our Data

Now that we have the data we want, let's chart it. The charting library in FsLabs will allow us to customize the chart as we see fit for visualizing. For this there is an Options type that we can create. We'll just give a title and tell the legend to appear at the bottom.

let options = Options ( title = "% of GDP value added", legend = Legend(position="bottom") )

Now we just need to tell the charting library to chart our data.

[ usSeries.[2000 .. 2010]; euSeries.[2000 .. 2010] ]
|> Chart.Line
|> Chart.WithOptions options
|> Chart.WithLabels ["US"; "EU"]

We give it our data as an F# list, tell it to create a line chart, give it our options, and then tell what our labels are for our legend.

Executing

Just run it all in F# Interactive. :)

New Wintellect Blog Posts

/

For this Thanksgiving, I thought sharing a lot of my recent Wintellect blog posts. If I may say, there's a lot of good stuff for you to go through while digesting a Thanksgiving meal. Hope you all enjoy!

Spectron

I've been doing a bit of Spectron lately for a client and have been posting some insights I've gained from it.

Xamarin

I've been into Xamarin for quite a while now and have quite a few links that go through different aspects of it, mainly with F#. This includes my very first screencast and using FAKE with your Xamarin projects.