Book Review: Python Tricks

If you've been around Python for a while, then you're probably familiar with Dan Bader. He likes to help people up their Python game and share his knoweledge of the language. Because of that, he released his own book, Python Tricks.

 
 

The book has seven sections of Python goodness:

  • Clean Python Patterns
  • Effective Functions
  • Classes
  • Data Structures
  • Loops
  • Dictionaries
  • Productivity

Let's look at an example in each of the above items so you can have an idea of what is in the book. These examples are ones that I have learned from when reading the book. Code examples in this post are my own.

Clean Python - Assertions

The very first tip in this book goes over using assertions in Python. Assertions, if you aren't familiar, is a way to well, assert if a condition is true. More specifically, a condition in which you expect to be true. If you have an assertion and it turns out to false, it will throw an AssertionError.

2019-03-30 16_55_19-Clipboard.png

If an assertion is caught it's a good idea to see why. Doing so will allow you to catch bugs that you may not have been able to catch before which is why having assertions are helpful.

Effective Functions - *args and **kwargs

When starting out in Python you may come across a method like the below:

def main(*args, **kwargs):
    print(args)
    print(kwargs)

Seeing something like this for the first time and, like me, you'll wonder what in the world that means.

*args are extra positional arguments you can pass in. The * in front tells it to gather all of those into a tuple. So if we take the method definition from above we can print the *args.

main("hello", "world")
2019-03-30 17_36_06-Clipboard.png

The **kwargs parameter does the same thing, but instead of a tuple it will be a dictionary since the kw in front of the args stands for "key word".

2019-03-30 17_36_50-Clipboard.png

Classes - Named Tuples

Tuples in Python are essentially a collection that is immutable. That is, once it's definied it can't be changed. To easily spot a tuple, the values in it will be enclosed by parentheses.

t = (1, 2, 3, 4, "five")
t
2019-03-30 17_48_47-Clipboard.png

However, if we want to get access to get access to the first item of the tuple, there's no dot notation to give us access to it.

2019-03-30 17_50_58-Clipboard.png

Though, we can use slicing to access it.

t[0]
2019-03-30 17_57_26-Clipboard.png

With a NamedTuple we can create a tuple and access items in it with the dot notation.

from collections import namedtuple

t = namedtuple("t", ["one", "two", "three", "four", "five"])

items = t(1, 2, 3, 4, "five")
2019-03-30 17_59_51-Clipboard.png

Data Structures - Sets

Sets are a data structure that simply gives unique values. This can be quite useful if you want to remove duplicates from a list.

set([1, 2, 3, 4, 2, 5, 3])
2019-03-30 18_07_38-Clipboard.png

Loops - Comprehensions

List comprehensions are perhaps one of my favorite things in Python. It is essentially sytactic sugar on top of using a for loop and, once understood, can be easier to read since it is only in one line. For example, let's say we have the below loop:

item = []
for i in range(0, 10):
    item.append(i + 1)

print(item)
2019-03-30 18_43_38-Clipboard.png

We can rewrite it using a list comprehension:

[i + 1 for i in range(0, 10)]
2019-03-30 18_44_09-Clipboard.png

What if we need an if statement in the loop, like below?

item = []
for i in range(0, 10):
    if i % 2 == 0:
        item.append(i + 1)

print(item)
2019-03-30 18_44_39-Clipboard.png

That can also be broken down into a list comprehension.

[i + 1 for i in range(0, 10) if i % 2 == 0]
2019-03-30 18_45_05-Clipboard.png

Dictionaries - Default Values

Often, when checking if a value is in a dictionary, it's not always known if that value is in the dictionary in the first place. The get method on dictionaries is a good way to get the value if it is in the dictionary or to return a default value if it is not in the dictionary.

For example, let's say we have the below dictionary.

d = {"x": 1, "y": 2}

We can get the y value with the get method.

d.get("y")
2019-03-30 18_56_17-Clipboard.png

But if we try to get the value from z which doesn't exist in the dictionary, we can give a second parameter to the get method to return that value as default if the key doesn't exist.

d.get("z", 0)
2019-03-30 18_56_53-Clipboard.png

Also, if we don't specify the default value and the key doesn't exist in the dictionary, the get method won't return anything.

d.get("z")
2019-03-30 18_57_36-Clipboard.png

Productivity - dir

While Python is a great language it is also a bit weird to work with when trying to explore through code what methods or properties a variable can have. That's one of the nice things with C# and it being a typed language. I can use the dot notation and intellisense to see what is available on a variable. With Python, though, that may not always work even in great editors such as PyCharm and Jupyter.

This is where the dir method comes to the rescue. Using this method we can see exactly what method and properties are on a variable.

For example, let's say you wanted to see what all is avilable on a list object.

x = [1, 2]
dir(x)
2019-03-30 19_06_30-Clipboard.png

The dir method has saved me a lot of time trying to find what's available on objects instead of having to hunt down the documentation.


I consider myself a beginner to intermediate in Python. Some of the tricks in here I've seen before, such as asserts and list comprehensions, but most of the ones in this book I haven't. I definitely learned quite a bit more about using Python. Both for cleaner code and to utilize what the language has to offer whether than defaulting to what I already know from another language.

Whether you're just beginning or a pro in Python, there's something in this book to learn from. Maybe there'll be a second edition soon.

Book Review: Becoming a More Effective Developer

A lot of programming books teach you about a new framework, language, or computer science theory, but very few teach you how to actually be effective at your day job. The book, The Effective Engineer is a great one to learn all the ways in which you can be the best developer you can be.

 
 

This book goes through three main points:

  • Developing the right mindset
  • Executing effectively
  • Building long term value

Each of these has some really good and actionable insights on how you can become better as a programmer.

Developing the right mindset

As Carol Dweck mentions in her book Mindset, the most successful people have a certain mindset in terms of how they view their learning. They believe that your brain can be changed and you can learn anything once you put in the work. That's definitely true for programmers.

Continuous Learning

A large part of being a software developer is that you are continuously learning new things. Whether new frameworks, languages, or software theory, there is no shortage of things to learn.

A majority of the time this learning comes from actual work on the job. No longer being able to learn on the job is a reason a lot of developers change jobs, so it's definitely cared about. Sometimes, though, that learning may need to be supplemented outside of the job. This is where you hear some developers doing projects and learning during nights and weekends.

The book goes through a few ways developers can actually do this learning, such as reading code from developers who are more experienced and to have them review your own code.

Prioritize

One of my favorite authors, Tim Ferriss often talks about being efficient vs. being effective to help boost productivity:

Focus on doing the right things (efficiency) vs doing things well (being efficient).

Doing things to be efficient may include items such as replying to emails, updating status reports more than they need to be, and other tasks that make it seem like you're busy but doesn't actually contribute much to the project you're working on.

That's where prioritization comes in. Once you take some time each day or week to prioritize what needs to be done, you'll have a clear way to move forward with the actual project.

This is similar to Getting Things Done in that you define clear tasks and prioritize the ones that need to be done. I would also argue to break up bigger tasks into much smaller ones.

Executing effectively

Now that we have the right mindset for our productivity, we also need to know how to execute them. A few things from the book stand out in what I believe will help the most.

Master Your Environment

Do you use Visual Studio for all of our development? Then knowing as much as you can about it can save you so much time in terms of keyboard shortcuts or knowing when to move to the command line for certain tasks. Speaking of the command line, knowing PowerShell or bash can save you a ton of time as there are snippets and commands that can do a lot that you may not even know of.

Improve Your Estimation Skills

All too often you, as a developer, will get asked by your boss or a manager how long a certain task will take. How often have you said, "I don't know?" Improving your estimation skills is an easy way to be thought of as a senior programmer.

The main way to improve this is to just keep track of your tasks. Once you are asked to estimate you can refer back to your tasks and get an idea of how long it took you to do something similar.

There's also the book Software Estimation that can give a lot more details in improving your estimation details.

Building long term value

To be the best programmer you can be is to build long term value for your company and your clients. The book offers some great ways in order to help you build that long term value.

Balance Quality with Practicality

How often have you come across this scenario: you implement a new feature and the deadline is very close, however your boss wants you to go ahead and get it in to start testing. You mention how many more tests you need to write, yet your boss says to not worry about that and just check it in. Often referred to as technical debt, us programmers can perfectionists in that we want our code to be perfect before we send out for all to work on and see.

Having this type of balance on having your work be perfect vs. being practical in your work can be beneficial in terms of providing value to your company or clients.

Invest in Your Team

I think the biggest thing you can do for long term value is investing in the team. This can be done in many ways, such as the following:

  • Providing a nice way to onboard new team members: Having a good onboarding solution will make new team members so much more productive and have them committing code within their first week on the job. This leads to higher morale overall across the team.
  • Collaborating on all aspects of the code: This includes having efficient code reviews on all pull requests, and team members not afraid to volunteer for certain bug fixes or features.
  • Building a great culture: This can be a hard one to accomplish, but if done correctly this will build higher morale with the team which will reflect team members making sure they give everything their best.

Of course there are other ways to help invest in your team, but these are some of the ways that can have the most impact.


This book is definitely worth reading for a lot of ideas on how you can easily improve your effectiveness as a programmer. For even more you can checkout the book's blog.

Book Review: Coders at Work

There are quite a lot of interviews with software developers out there. Though, I doubt there are many that feature such an array of accomplished developers as Coders at Work does. In this book, there are quite a few words of wisdom from developers who have been through the tough bugs and the long projects.

 
 

When I first got this book, most of the names I didn't recognize. In fact, there were only just a couple I did recognize by name - Donald Knuth and Douglas Crockford.

It was very interesting getting to know the other programmers in this book. Perhaps the most interesting reading in it, I felt, was the blurbs that introduce each person. Telling what they accomplished, what they're currently working on, and a sentence or two of what they talk about in the interview. The most fascinating thing is learning how each individual person being interviewed contributed to the world of computer science.

There were quite a few take aways from this book that may be applicable to everyday work. The biggest of these, though, is that most of the people being interviewed, when asking about how they debug a program, still use the very reliable print statement. In fact, there's this MIT open courseware lecture on debugging that just goes over exactly that!

Here are a few other items of note that I learned while reading this book:

Jamie Zawinski gives advice to not be afraid of what you don't know and that it's ok to ask someone who does about it.

Joshua Bloch says that it's important to know what you're trying to build before you get started. He suggested a talk he gave a quite a while ago now - How to Design a Good API and Why it Matters.

Joe Armstrong has a few nice pieces of advice.

  • He gives a really good debugging technique for finding errors which is that all errors will be three statements before or after the last place you changed the program.
  • He mentions that documentation tells you what the code is supposed to do. "Just read the code" will tell you what it does. Sometimes they aren't the same thing.
  • He mentions a nice talk by Richard Hamming, "You and Your Research", that has a lot of advice such as...

If you don't do good stuff, in good areas, it doesn't matter what you do.

Simon Peyton Jones mentions an interesting paper on "Why Functional Programming Matters". Which has been turned into a talk!

Ken Thompson knew for a long time that working 60, 80, or even 100 hours a week will definitely generate burnout. External deadlines also definitely generate stress.


There's a ton more to learn from this book. From here you can step into the shoes of programming greats and learn the lessons they have learned.

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.

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.

Book Review: Elon Musk Biography

I've done a few book reviews in the past here, but I admit I've been slacking a bit. Not on the reading, though. I've actually been reading even more. I've been slacking a lot in writing about my thoughts and notes on each of the books. It's time to change that.

 

 

For those who are a bit out of the loop and doesn't know who Elon Musk is, he's the CEO of both SpaceX and Tesla as well as a chairman of SolarCity. From those credentials alone you can definitely tell that this guy knows what he's doing! One thing I like to tell people when describing Elon Musk is that I do believe he's the biggest innovator of our generation. This book, Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future, will definitely describe how that statement is true.

From the start you get a sense of Elon as he was as a young kid. The biggest thing to hit me was just how much he read at a young age. This is actually not very surprising as I've always heard that the best leaders and innovators are voracious readers. Of course, that's not the reason I like to read, but it is nice to know that you share this habit with people like Elon.

What is interesting is the story of Elon's earlier companies, Zip2 and X.Com. X.Com eventually did merge with PayPal and Elon was the largest shareholder in the company. These two companies gave Elon his first millions.

SpaceX

With the money from the previous companies, Elon started SpaceX. This was brought on by a life-long dream to go to Mars. The book details the innovations and early failures of the company that builds their own rockets right in the US.

The innovations being that all parts of the rocket were built in-house at the SpaceX factory which turns out to be much cheaper than buying them from other countries. They continue to innovate by building rockets that can be reused by coming back to earth and land by themselves.

They did have early failures when they tried to launch the first version of their Falcon rocket which almost brought the company into bankruptcy. Thankfully, they were able to get a successful launch and able to win a lot of bids from NASA to keep the company going.

Tesla

Tesla is definitely a company I've been following for a while. Ever since I got to test drive a Model S in Houston a year ago, I've been interested in them.

A bit of a detail of Elon and Tesla is that he's a co-founder because he was the first investor into the company. If he didn't do this, then the company would have gone bankrupt long ago and due to that, I would consider him a co-founder. With that said, Elon probably did do a lot for the company as its CEO. He helped get the initial Roadster out and had a lot of input into the Model S.

I'm definitely looking forward to what this company will bring, especially with them making their gigafactory that should help bring down the cost of the batteries and, overall, the cost of the car.

Conclusion

Overall, I thoroughly enjoyed this biography. I already thought Elon Musk is an interesting person and definitely someone I'd want to meet one day. This book gave a bit more insight into him as a CEO and innovator as well as the histories of SpaceX and Tesla.

I'm pretty sure there will be more to come from Elon and I'll be waiting anxiously for another book on the rest of Elon's innovative career.