Since the announcement of the new 15-Inch MacBook Pro there have been lots of criticism about its limitations and flaws. I’m not going to refute the criticism because I have some of the same misgivings, but I want to share my thought process for why I bought the particular configuration I decided on.

Need

First and foremost I needed a new computer. Multiple, daily GPU panics are not a recipe for a happy computer user and in the last 9 months as I waited for Apple to release new computers my frustration had turned to dread. Not what a software developer should feel about his main tool.

Is It a Great Computer?

I don’t know. I haven’t used the Touch Bar and I don’t know if I’ll be frustrated by the lack of an escape-key. The 16GB limit doesn’t faze me because I wouldn’t have gone with 32GB as that would have probably pushed the machine toward $4K. Did the price point move up? Yes, I was planning on going without the discrete GPU because of my GPU panic problems, but without that option my price point got bumped up a couple hundred dollars. Is USB-C only going to be a problem and are dongles of the devil? I have Firewire 400 devices and deal with projectors that are old and only have VGA inputs so I’ve had and will have adapters and dongles for my many years.

Existential Crisis

Most of the criticism I’ve heard isn’t really about the machine but about what signals Apple is sending because of the choices it made when designing the machine. While this type of analysis can be useful, it doesn’t really factor into how I buy a computer anymore. My buying decision is based on hardware build quality, capabilities, and software quality at a price point I can justify. What the computer says about the future prospects of the company would only concern me if it limited the useful life of it. I feel comfortable in saying that the choices Apple made with the 15-Inch MacBook Pro won’t limit the 5-7 year useful life expectancy I have for it.

What and Why

I bought the higher-end 15-Inch MacBook Pro because I wanted the 512GB SSD. I could have gone with the lower-end model and bumped up the SSD and saved a couple hundred dollars, but decided that the higher-end stock configuration was a better balance with the faster CPU and GPU. I got it in silver because Space Gray looks dirty in my eyes after using my current MacBook Pro for 6 years and a Titanium PowerBook for 5 years before that.

Next

Buying the new machine was the easy decision. The next steps of deliberately deciding what software to install and intentionally integrating it into my life are much more important.

I have the most difficult time with procrastination during the times between two things. In this case, the time between now and getting my new MacBook Pro. I’ve put off updating to macOS Sierra for purely pragmatic reasons, but I’ve also put off some tasks I should be doing because it’s easy to say, “I’ll just wait to set that up on my new system instead of doing it twice.” I almost used this procrastination technique with this blog.

I’m going to try to intentionally and thoughtfully setup my new computer and part of that process is blogging about the move and that includes my thoughts about this current machine and the thoughts behind moving to the computer I selected. After the last post that kicked off this process, I found that my installation of Ruby, which is necessary to generate the blog, had been corrupted. At that point I nearly gave up on the idea of walking through this process and just waiting to start blogging after I had the new machine. That certainly would have been the easy thing to do, but I decided that blogging the process was important and did the grunt work of fix my Ruby installation.

I don’t think that procrastination during times of transition is unique but the biggest danger I have is that I can turn almost anything into a time of transition. The end of the month, the end of the week, etc. are such easy times for me to say, “Well I’ll just wait put it off until the start of next (week, month, year),” or “I’ll wait till the new version of the (device, app, os, framework, language) comes out and then I’ll dig in.” I am aware of this thought process in myself and yet I have trouble overcoming it. Anyone have any thoughts on overcoming it?

I could make this a post about turning over a new blogging leaf, but I’ve broken that promise too many times to kid myself into thinking this time I’ll stick with it. No the “new era” for me is the move from my 2010 15” MacBook Pro to a new 2016 15” MacBook Pro. This will be one of the last posts from this old workhorse which has served me well.

It is amazing to me that this computer has served me so well and for 6 years. The only upgrade I’ve done is the 512GB SSD drive. It has held up wonderfully except for the GPU panics that have always plagued it, started getting worse a year ago, and finally became a near daily occurrence 3 months ago. When I got the machine I paid extra for the matte screen and I feel like I’m going to really miss it, but getting a Retina display and brighter colors should balance out my screen concerns.

One of my goal is to become and essentialist which means I want to make more deliberate and intentional choices. To that end I plan to make future posts discussing my choice of the MacBook Pro, how I’m migrating to the new machine, the software I install, and any of the other myriad of choice I make. My typical M.O. is to make a well thought out and carefully planned initial decision, but once things get rolling I start doing things haphazardly, letting momentum take me where I don’t necessarily mean to go.

A while back I was test infected. On a side project I was saving myself tons of time, making good progress, and writing high quality code. It was really exciting, I was really happy, and it is one of my favorite moments of working on side projects. Then I hit the UI portion of the project and BDD became harder. Not only was the UI code not driven by tests, I would have to make changes to my tested code to support the UI and then instead of updating the tests, I would ignore the test case or worse, comment out the existing tests to get things working.

Since then every side project I’ve ever started has gone through the same loop, but I’ve become more resigned to abandoning unit testing as soon as the rubber hits the UI. I want to do better. I’m going to recommit myself to BDD on my side projects. I’m going to make a concerted effort to fall of the band wagon when UI testing becomes hard. And if I happen to slip I’ll get back on right away. No more commenting out tests to make things compile. The only tests that will be removed are those that no longer test the system.

If I’m using Angular which is a framework to build Single Page Applications (SPA), maybe I should understand what an SPA is.

Of course there is the Wikipedia article, but I like this discussion of SPA’s. It addresses my misconception that an SPA could house a simple CRUD workflow but it would take multiple “pages” to create a full fledged application. In actuallity a “single page” is the entry into the application. Then through the combination of HTML, HTTP, and JSON that single page is transformed is into the various views of the application. You don’t link to other pages to get different functionality.

You also don’t lose browser navigation which surprised me. I thought doing DOM manipulation on this level would break the web paradigm, but it doesn’t so I’m going to need to learn how Angular does this.

On a funny note, the author likes the term Rich Web Application which makes me think he didn’t live through the horror of Rich Internet Applications. Nobody in their right mind would want any connection with Flash, Silverlight, or any of the other abominations that polluted the web.