End of Summer Book Review

One of the great things about no longer having a company or a farm to run is that I’ve been reading a new book every week or two. I’ll save the fiction reviews for Goodreads, but a few of them are worth writing about here.

  1. Lean UX: Designing Great Products With Agile Teams

I’ve worked at giant companies where everything was so hierarchical and top-down that if the employees wanted to get anything cross-functional done, they basically had to bribe co-workers from other departments with favors or after-work drinks. I have also worked at a tiny start-up where everyone worked on everything, all ideas were considered, and we moved extremely fast. I knew we used tools like Trello and Asana and Google Docs, but I found that I had trouble explaining why we did it that way. When people threw terms around like Waterfall or Agile, I Googled them, but until I read this book, I never really understood the history behind these vastly different methodologies. When I mentioned this gap in my understanding, a friend suggested I check out the Agile Manifesto, the Scrum Guide, and read Lean UX, and I’m really glad I did.

The book borrows heavily from existing Scrum concepts, but expands on it to ensure that research and design (and legal and whoever is needed to ensure the thing works) have a voice within that ritualized framework. There are a lot of great examples of how to incorporate diverse thought into the ideation process, and how to ensure that the desires of the end user (and not just developer bias) are honored in the final product. Best of all, there is no dogma. They recognize that some organizations are hierarchical, and maybe it’s ok to be inefficient in certain contexts. The point is not to adhere to some perfect process, it’s producing great products quickly, and realistically.

As an intuitive autodidact, I’m all for faking things until you find yourself making things, but there comes a time to backfill whatever you figured out on your own with some book learning. When I have cluttered, unorganized thoughts, and I know everything seems to work, but I don’t really know why, I absolutely love it when a book comes along with a framework that allows me to tidy all those thoughts up, declutter my brain, and store them away. Lean UX is like the Marie Kondo of software development. It’s a framework for working with a team, keeping just the bare bones of what’s needed, and chucking all the unnecessary documentation and bureaucracy. To borrow from Marie, it brings me joy to know that the next time someone tells me about the pain of their waterfall process, I can simply hand them my copy of Lean UX.  P.S. Go read this too.

2.   The Challenger Sale: Taking Control of the Customer Conversation

One of the hardest things about stepping up from my back-office analyst roles to client-facing executive roles was learning to sell. My method of selling was to learn everything I could about a problem, then walk into a conference room and drop a knowledge bomb on my prospective client. I’d deliver a fully-fleshed out analysis of what they were doing well, what they were doing wrong, and a plan to fix it, then shake hands and walk away. I think this approach terrified my co-workers, who were afraid I’d offend the client. We were all a little surprised to discover that my approach worked about 75% of the time. But why?

In my mind, sales people are supposed to be annoyingly nice, calling all the time, bothering people, never taking no for an answer. I, on the other hand, encouraged clients to tell me no. I considered myself the anti-sales guy. This dissonance of disliking sales yet having to sell, and yet somehow having it work out… it was a problem for me. I couldn’t wrap my head around what was happening. So, I decided to face things head on and be the best darn sales guy I could be. I made an effort to be friendly and bought lunches and emailed interesting articles…and I sold nothing. What was I doing wrong?

I asked my friend Alex Boyd, CEO of RevenueZen.com, to suggest some books that would help me learn how to finally be one of those nice but annoying sales people. Instead, he told me to read The Challenger Sale. What I found was not a how-to guide to bug people, but hard data that helped me understand why my no-nonsense style had worked, while my overly-friendly style had failed.

The premise of The Challenger Sale, to paraphrase aggressively, is that the best sales people tend to do the hard work of becoming experts before they try to sell anything, then fundamentally challenge the way the client is doing business, reframing the way their clients think about their business. Before pitching anything related to what you have for sale, you need to make sure the client understands the solution – not your solution. It turns out I had meandered accidentally into doing the right thing, but I needed a book like this to give me a framework in which to think about it and help me understand why being direct worked, and why my attempts to “act like a sales person” generally failed. Right or wrong way, I have a lot more empathy for sales people these days, and no longer experience that dissonance when it’s time for me to sell.

3.  Animal, Vegetable, Miracle: A Year of Food Life

OK, so I know the last two were business books, and this is a book about what Barbara Kingsolver ate for a year. I promise, there’s a reason for this.

This book follows the Kingsolver family as they grow or locally source all their food for a year on their small Appalachian farm, preaching about the absurdity of flying bananas 6000 miles, or the even more absurd practice of trucking lettuce 3000 miles when there’s perfectly good lettuce available at a farm down the road, or in your own backyard.

The good: I love the insistence on thinking about petroleum as an input when growing food, both when used on the field as a fertilizer or pesticide and as gas in transportation. I love the idea of eating food that’s been grown locally without pesticides. I love the idea of eating heirloom varietals of plants that were bred for taste rather than ease of transport. I agree that processed foods are a huge part of the obesity epidemic and think we should shift our diets towards high quality foods. I agree that we, as a society, need a much better understanding of where the ingredients in our food are coming from, even if it’s just to become better shoppers.

The bad: The book really downplays just how much work this family of four had to put in to extract roughly half of their yearly calories from the animals and plants they cared for. The work of farming was presented as a benefit: it’s like meditation, yoga, and you can cancel your gym membership for the price of a shovel! Nope. I had a farm. I grew my own food. It was really, really hard, and the reason I stopped going to the gym was because my joints hurt too much after all that repetitive physical labor.

The frustrating: There is a puritanical insistence on eating extremely seasonally throughout the book. Mason jars and freezers are offered as the only acceptable way to consume warm-weather plants during cold-weather months. While I get that seasonality is important to think about when picking up a tub of strawberries in January at a grocery store in Minneapolis, real farmers use all sorts of greenhouse-esque contraptions to grow plants out of season, and are rewarded for doing so. It’s very normal to extend the growing season in cold climates with hoop houses, shield the sun in hot climates with screens, use hydroponics in dry environments…etc. If the Kingsolvers had employed a little technology, they might have been able to grow their own indoor oranges and bananas, and they definitely could have been eating fresh greens in February, the lack of which was much lamented throughout the book.

Now, why am I writing about this at all? I can’t stop thinking about the idea of employing tech in urban agriculture. If 2 out of 3 Americans live in cities, and we all agree that eating locally sourced food makes sense, why aren’t we growing food for cities in or immediately around them? Is it really easier to fly food across the world than to figure out how to grow it on your roof? I am fascinated by startups in this space, and have been checking out a bunch of them. I think whoever figures out how to grow high-quality veggies on a large scale, year-round, in a place like Chicago, using winter sunlight (or other low-energy methods), inside dense, automated growing facilities, is going to revolutionize how we eat, and where a big chunk of our food comes from. I think it’s very telling that Jeff Bezos, the proud new owner of Whole Foods, has invested in Plenty.ag, and that IronOx.com came out of Y Combinator. This is very exciting stuff, and I think scaled urban agriculture is an industry that is just getting started.


Coding Bootcamp: The Best Terrible Decision

When yet another friend asked me “is coding bootcamp worth it,” wondering whether they should learn to code too, I found myself giving a very long and convoluted answer that I realized would probably be better off written down. I know that before I signed up for bootcamp, I had trouble finding a straight answer myself. So, my answer is: Yes, but…

1. Upon graduating, be prepared to be a specialist of limited use or a master of little

Building a decent software app is kind of like building a house. The electrician knows very little about installing plumbing or sewage. The roofer probably can’t lay the foundation. A software app combines lots of independent skills. As a developer, you have to make a choice whether to be a decent plumber right away (focus on one thing) or be a general contractor, and know a little bit about everything, but not really be expert at anything for a very long time.

2. It takes a huge amount of time

This may seem laughably naive to long-time software developers, but I don’t think regular people realize the sheer volume of information a person needs to absorb in order to be even a mediocre developer. To be a decent coder, you need to learn three to six code languages and be able to read and write them with some fluency. Code languages are just as hard to learn as, say, a European language. If you wanted to learn to speak French, German, Spanish, Italian, Greek, and Portuguese all at once, would you try to learn them all in four very intense months? No? Because that is essentially what I tried to do.

Too many screens!
Too many screens!

My bootcamp was four months, or sixteen weeks long, with five hour classes every weeknight (fridays too). To keep up with the pace of the class, I had to read coding books, do online coding exercises, and write code for my class projects outside of class. When you add in all that study/coding time outside of class, it added up to about fifty hour weeks spent coding. In other words, it’s about as difficult as a mentally demanding full-time job.

I was freelancing and working part-time, and I was completely brain-fried and had no social life during those four months. I felt incredibly sorry for my fellow students who had full-time jobs on top of school. I watched them put on weight and grow increasingly haggard by month four. We all agreed we were seeing ones and zeros in our dreams.

3. It’s expensive

I’ve heard people say that coding bootcamp is a waste of money since you can teach yourself everything online for free. The thing is, even in coding bootcamp you’re still teaching yourself to code, and you’re still using those free resources. The difference is that in bootcamp you have an experienced developer guiding you and a structure that limits the complexity and chaos of coding. Realistically, a coding bootcamp is just going to take months 6-18 of your coding education and compress them into months 6-10. What is the price for 8 months of your life? That’s really up to you. I spent $3,400 on tuition, and that seemed like a bargain to me. If you have more time than money, by all means, figure it out on your own.

4. The hard way is probably the only way

Zed Shaw’s “Learn Python the Hard Way” is generally considered the best course for those trying to teach themselves Python. He intentionally makes the course difficult. When a piece of code doesn’t work, his answer is “Google it”. Realistically, learning to code is as much about rote memory as it is about training yourself to be patient and resilient. You have to first spend lots of time practicing writing code so that you can memorize and internalize the patterns. However, that’s the easy part. The hard part is figuring out what to do when you think you’ve done everything right and your code still won’t run correctly. It’s easy to copy and paste someone else’s code. It’s hard to know why it isn’t working in the context of your project.

I heartily recommend going all-in. The more time you can invest, the better. I spent 50 hours per week, but I recommend spending 80 hours per week the first few weeks you’re learning. Mix it up, and read books on coding, then go to online practice sites like Codecademy.org or Treehouse.com, then write some actual code. Every program does something different, so when you’re done with one, write another one. Tear apart an old program you wrote and write it better. Like playing the violin, the more you practice, the more you’ll internalize the skill. If you want to learn quickly, the only way to do so is to devote yourself.

5. Pick your language carefully

Back in high school I decided to learn Italian. In college, I took Japanese. Not to knock these languages, but I use them so rarely I’ve forgotten most of what I learned. In retrospect, I really should have learned a practical language I can use all the time like Spanish. Picking a coding language works similarly.

Before you pick a flavor, know that everyone needs to learn HTML and CSS. Before you even think about enrolling in a bootcamp, teach yourself these languages. Once you can construct a static HTML page writing raw HTML and CSS code and get it up on a server, you’re ready to pick a path.

Python, JavaScript, and Ruby are currently the most common open-source options offered by bootcamps, but they are by no means the only languages out there. You can write software using any of these three languages, but committing to one is sort of like choosing Apple vs. Microsoft. They can work in parallel, but for the most part are incompatible, and the software written for one won’t work on the other. As owners of Microsoft Phone users know well, none of those awesome apps that work great on iPhones have been written for their Windows phone. Code generally works the same way. Personally, I deal with a lot of data, and much smarter people than me have written great libraries for handling data in Python. I decided to code primarily in Python to take advantage of libraries like iPython and Pandas, which do complex math for me. It’s sort of like plugging in a calculator app into your raw code.

You will need to figure out what you want to do with the software you write, and which language will best support that task. If your primary goal is to make a lot of money right away, you could learn the languages that high-salary finance companies use, like Scala, Java, and .NET. If, on the other hand, you want to work at a hipster start-up, learn Ruby, Python, or C++. It’s not a bad idea to look at the job postings for the companies you want to work for first to see what they’re asking for.

Once you pick a language, then you have to pick a version of that language. New versions will be relevant longer, have cleaner code and do some cool new stuff, but old versions are more stable and have more libraries built for them. Every choice is a trade-off, and nothing will work 100% of the time.

6. Get used to frustration

One of the most profound things my teacher told our class is that we weren’t really learning to code, we were learning to debug. As normal consumers, even tech power-users, we’re used to stuff just working. Restarting a computer once a month to update some software seems like a huge hassle. Well, guess what, programming is about 10,000,000x more annoying. The code you write that works great locally won’t run on the server. Why? Who knows. And to find out, you’ll need to individually tweak each of the fifty things that could be causing a glitch until you figure out the cause, and when you finally fix that thing, your fix will probably break something else. That is coding.

Have you ever punched a hole in a wall, thrown your phone across the room, or (egads) sent a computer tumbling? If so, coding is not for you. But if you’re still with me, you must be a mellow individual that can handle frustration without smashing a screen. You have the calm demeanor to simply copy error messages, paste them into google, and spend thirty minutes reading five different and contradictory stackoverflow.com suggestions, trying three to find that the first doesn’t work with one of the drivers your app has running in the background and produces new errors, the second actually does the wrong thing, while the third sort of fixes your problem, but forces you to update some other seemingly unrelated part of your code for it to work.

When I was learning to use git and github, I was stoked to find out about the ability to clone projects in github and add them to my own. Similar to code libraries, you can just grab someone else’s code and incorporate it into whatever you’re working on. Sounds easy, right? So after weeks of work, customizing the clone with all my own code, I decided I would create a git repository and upload my project back to github, so other people could see my work. But, when I tried, there was a weird error telling me I had duplicate repositories. I hopped on stackoverflow, followed the directions I found, and… erased all my work. Yes, while attempting to back up my project, I erased it, all by following directions. It turns out, when you clone code from github, it automatically creates an invisible repository. This is just a thing you’re supposed to know, and since I didn’t know I had created a repository at the time I downloaded the clone, I didn’t understand that by resetting my repository, I would wipe out all changes made over the weeks since I added it. Want to know what I did? I sat down, and calmly spent the next three days recoding all my work from memory. And THAT is what coding is like.

7. Get used to very little help

I had a boss who once described his management style as “handing you a fortune cookie, then leaving you alone in the woods.” It turns out this was good training for coding. Most tutorials tend to fall into one of two types: those meant for week 1 beginners that are far too simplistic to be of much use, or those that are written by experts for other experts. These experts have been coding for decades and will intentionally leave out steps they find to be obvious (you will probably not find the missing steps so obvious). This is actually a big reason why I signed up for bootcamp, and why I recommend it. It is incredibly helpful to have someone around to fill in all those missing pieces for you and help guide you during that intermediary phase.

Much to my surprise, living a mostly digital life, coding books (made from trees!) are actually extremely helpful once you’re done being a beginner and get to the novice/intermediary phase. They provide a coherent level of structure that is hard to find online, and are good for reference when you forget something specific. However, they still assume a basic level of know-how that will constantly trip up the novice developer.

8. Bootcamp is just the beginning

Coding languages are constantly changing and evolving. Code you wrote a few years ago may not be supported in another few years. The code language you learn first may become out-dated or go out of fashion. A new code language or library may make a lot of the old code language obsolete. For example, JQuery is just a better, more condensed way of writing certain kinds of JavaScript, Rails does something similar for Ruby.

The point I’m trying to make is that bootcamp is a great way to kickstart a career change, and really a life change, but your first job out of school is probably going to be entry level, because your skills will only be entry level. If you make less than $50k now, you’ll probably be able to make that much or more with an entry-level software job after going through a bootcamp program. However, expecting to be a full-fledged software developer making six figures and signing bonuses after a four month program is sort of like expecting to be a successful novelist after a summer creative writing program.

9. Learn to learn

The most important thing bootcamp taught me was how to teach myself. Learning to debug, see patterns in my mistakes, and knowing where to go for answers was absolutely worth the time, money, and effort. I am continuing my education by taking classes through Udacity, Coursera, Codecademy, Udemy and whatever other books or online tutorials make sense. I also continue to meet with my bootcamp teacher for mentoring. I’m still doing difficult stuff, but the pace of my learning is continually speeding up. While it may take a novice coder months to learn a language, an experienced coder can probably pick it up in a few days (or so I’ve been told). This virtuous cycle will continue the longer you code, but you have to keep at it for years.

10. Always be building

The best way to learn, and to keep learning, is to keep building. Pick a project and go for it. Start small with HTML and CSS. Tear it down and rebuild it better. Add something dynamic using JQuery or JavaScript. Make your CSS responsive for mobile devices. After a few months, your old code will look as dated and silly to you as the bad poetry you wrote in high school. Rewrite it. Learn backend languages and try incorporating dynamic forms and data. Then tear that down and make it better. Pick a backend framework and drop your old code into that…

You get the idea. Now go code something.  And remember…

The best time to plant a tree is 30 years ago. The second best time to plant a tree is today.

Adobe, 1: Tim, 0

I’ve been an Adobe loyalist for far longer than most of my developer buddies, but after seeing yet another $49.99 charge for Adobe Creative Cloud after another month of not really needing it, I finally decided to just kill my subscription and use other programs. At least, that’s what I thought I’d do. First, I clicked through about twenty screens, following the digital bread crumbs from click to click to attempt to find a screen that would let me cancel. I finally landed on a page that gave me two options, A) call and talk to a human, or B) chat with a human. No simple unsubscribe box. I tried calling first, but the person I spoke to could find no record of my existence. Next, I tried chatting. Spoiler alert: despite my best efforts I am still an Adobe customer.

You are now chatting with ‘Prabhudev’

Prabhudev: Hello! Welcome to Adobe Customer Service.

Prabhudev: Hi Timothy, I understand that you wish to cancel your subscription and I can take care of that for you.

Timothy McAtee: yes I’d like to cancel my account

Prabhudev: May I know the reason for the cancellation?

Timothy McAtee: I don’t use it

Prabhudev: I see that you have subscribed to Creative Cloud membership (one-year).

Prabhudev: We are sorry to see you go, If you are willing to continue the subscription and complete the annual commitment I can get you 2 months free subscription and you will not be charged for the next 2 months.

Timothy McAtee: Please just cancel the subscription

Prabhudev: Before I go ahead and cancel your subscription, May I ask if you are interested in continuing your plan if I make an exception and get you next three months free?

Timothy McAtee: Please stop. Cancel it.

Prabhudev: Timothy, I am sorry to say this, If you cancel the subscription now there will be an early termination fees, as you are under one year annual commitment.

Timothy McAtee: But I signed up more than a year ago

Timothy McAtee: What is the fee?

Prabhudev: An annual subscription requires a commitment for the full year and monthly payments. If you decide to end a one-year membership before the 12-month period is over, you are charged 50% of the remaining amount left on your contract. Which amounts USD 200+Tax.

Timothy McAtee: When is the 12 month period over?

Prabhudev: Your plan will end on Jun 26, 2016

Timothy McAtee: Well then, cancel it effective June 26, 2016

Prabhudev: we will notify you via email so that you can cancel from your end. [NOTE: I clearly can’t cancel it from my end, or I would have by now]

Prabhudev: Do you wish to continue your plan with three months free and complete the annual commitment?

Timothy McAtee: You don’t really give me much choice, do you?

Prabhudev: If you continue the subscription you will get next three months free and you can save 3 month’s subscription charges, you will also avoid paying the early cancellation fees.

Timothy McAtee: ok. let’s do that.

Prabhudev: I am glad that you are continuing your subscription