Thursday, September 24, 2015

Android vs. iOS from a User's Perspective

I've been an Android user for several years. I have also written Android apps. About 9 months ago, I decided to switch to iOS in order to learn how to do iPhone development.

You might be wondering what I think of iOS after switching. Ok, you probably weren't wondering, but I'm going to tell you anyway. I think it doesn't really matter very much. There are huge differences when it comes to developing for Android or iOS, but when it comes to usage, not so much.

Sure, there are differences between the OSs. Each has a few features that the other doesn't have. But how do they impact my life? Pretty much all of the apps I personally care about are on both platforms. There's a huge difference between having a modern smartphone and not having one. However, I think the choice of which one to have isn't really that significant.

The vicious cycle of co-dependent attention slavery

Don't you ever get tired of everyone in the world demanding your attention?

It's like we're caught up in some vicious cycle of co-dependent attention slavery. There are a million apps and companies notifying you all the time that you have to pay attention to them. If it isn't a notification, it's an email. You spend countless wasted minutes every day clearing these notifications and dealing with these emails.

On the other hand, companies are desperate to get your attention. They track things like monthly active users, views, likes, etc. The financial success of various companies is directly connected to how many users they can get to log into their products, and how often they can get them to log in. Furthermore, a linear growth in usage is not acceptable. Everyone wants a hockey stick of exponential growth.

Yes, I'll admit the hypocracy in my complaining about this considering I worked in developer relations for two years, and I worked at a social media company for another two years. Permit me to have a Jerry Maguire moment. Stop! What can we do to break this cycle of co-dependency? If these apps are so smart, why do I have to babysit them all the time? Why does my leisure not feel leisurely anymore? How do we make the pain stop?

Saturday, September 05, 2015

I think I need some career advice

I left Twitter several weeks ago. It looks like I need to not only decide where I want to work next, I might also need to decide what I want to specialize in as a programmer. Apparently, there's less and less demand for full-stack web developers or generalists. Most open positions are for specialists.

I've always been a polyglot. I really like learning new languages. Even though I'm mostly a Python expert, I love to learn as many new languages as possible. For instance, I accomplished the following just while I was at Twitter:

  • I built a custom supply chain management system in Python.
  • I technical edited two Scala books.
  • I learned Go fairly well.
  • I learned Android at a beginner to intermediate level.
  • I learned Objective-C and iOS at a beginner to intermediate level.

Another thing that sets me apart from most programmers is that I'm a friendly extrovert, and I like giving talks. Given the above, developer relations is a natural fit for me. I did that for two years at Google.

However, it seems like that's not enough these days. It seems like most companies and most recruiters are really only looking for specialists. It seems like these are the specialties I could conceivably go after:

  • Ruby backend programmer
  • Go backend programmer
  • Scala backend programmer
  • Developer relations (mentioned above)
  • Frontend developer (JavaScript, Angular, React, etc.)
  • Distributed systems engineer (cloud computing, AWS specialist, etc.)
  • SRE
  • DevOps engineer
  • Data scientist (machine learning, big data, etc.)
  • Hadoop specialist
  • Android engineer
  • iOS engineer
  • Software engineer in biotech
  • Contractor or consultant

As I mentioned above, I know lots of languages, including Python, Ruby, Go, and Scala. I know JavaScript and some frontend development (at least using the old-school approaches). I know Java and some Android programming. I know Objective-C and some iOS programming. However, aside from Python, I am not an expert in any of these things.

Developer relations is fun, but I'm not sure it's a good idea to bank my entire future on it.

Distributed systems, cloud computing, AWS, SRE work, DevOps, etc. are all interesting to me. However, I'm not sure I can convince anyone to give me a job doing these things. Furthermore, I'm also not sure these things are the right thing to bet my career on. On the other hand, I'm a lot more interested in cloud computing than, say, frontend work.

I have an interview at a biotech company. That could be promising. That could be really good for my career, or a dead end for my career. I'm not sure.

I'm reluctant to become a contractor or consultant. It seems to me that once you become a consultant as an older programmer, it becomes very hard to get hired as a normal engineer at many companies. One of my buddies is a brilliant older programmer (UNIX®, MIT AI lab, various wireless hardware and software systems, etc.) but companies like Google won't hire him anymore. I think being a contractor or consultant has a lot of pros and a lot of cons. I can't even wrap my head around whether or not it's a good idea to start doing.

I suspect one benefit of being a specialist is that it makes interviewing easier. If you only have to know a particular field really well, it's not that hard. In contrast, I read Python Weekly, Ruby Weekly, Go Weekly, Scala Weekly, JavaScript Weekly, HTML5 Weekly, etc. Trying to keep up with so many areas means that I can't delve too deeply into any of them aside from Python.

Furthermore, I've noticed that the fewer people have a skill, the easier it is to get the job. For instance, it used to be really easy to get jobs because I knew Python and whatever Python web framework happened to be popular at the time. These days, everyone knows Python, so it's really no help at all.

What's certainly true is that interviews are getting much tougher! Every time I have to interview, I'm fighting against the best and brightest students from all over the world. They're mentally quicker than me, willing to work more overtime, and they cost a lot less. Furthermore, now that Python has become so ubiquitous at Universities, this battle is more fierce than ever. Furthermore, the amount of code companies expect you to be able to write in an interview is getting harder and harder.

On top of all of that, I think the cards are institutionally stacked against more senior engineers. I saw three principal engineers interview at my previous company. Two of them were buddies of mine, so I knew they were really good. That company turned down all three of them.

Some companies have also resorted to using timed programming tests like HackerRank. I like the fact that HackerRank is an objective measurement of a candidate's skills. However, it favors the young since it requires lightning quick thinking and ignores all of the other skills a more seasoned engineer has learned such as testing, design, scalability, requirements gathering, teamwork, agile, code review etiquette, etc.

Furthermore, anytime someone gives me a timed programming test, I completely fall apart. Usually, to be successful, you have to be creative enough to come up with an elegant (i.e. efficient) solution. However, having a gun put to your head is the enemy of creativity. I've been getting better by practicing at LeetCode, but I'll probably never be as good as a bright Russian kid who's been training for programming competitions for years.

The next problem is that the more companies you've worked for, the more hiring managers question whether you're a problematic employee. 2 years at Google right after college? You must be awesome! 2 years at Google, 2 years at Twitter, and 13 other startups? There must be something wrong with you! Forget about the fact that most of those companies don't even exist anymore ;)

The last challenge I'm facing is that the location of my house in Concord means I can really only work at companies in San Francisco or the East Bay. Unfortunately, the only thing harder than commuting to Mountain View (or other parts of Silicon Valley) is trying to buy a house there! Since we're in the middle of adding onto my house, I don't think we'll be moving anytime soon.

In summary, I'm pretty sure I can find my next job. What about after that? Will it keep getting harder and harder as I keep getting older, and there are more companies on my resume and more specialties? What should I do for the rest of my career? I just hit 40, and I'm wondering, am I going to keep on being able to put food on the table when I'm 50 or 60?

Finally, let me express my thanks to all of my friends who have been so supportive lately as I struggle with these questions. My buddies Ryan Larrabure, Alex Martelli, and Jarek Wilkiewicz and all my IronPort co-workers have been surprisingly encouraging. Love you guys!

Wednesday, August 05, 2015

Distributed Systems: Another Great Jeff Dean Quote

During the first year of a typical Google datacenter, there will be five rack-wide outages, three router failures large enough to require diverting processing away from connected machines, and eight network scheduled maintenance windows, half of which cause 30-minute random connectivity losses. At the same time 1 to 5 percent of all disks will die and each machine will crash at least twice (2 to 4 percent failure rate).

Dean, J. (2009), Designs, lessons and advice from building large distributed systems.

Friday, July 31, 2015

The Waterfall Model was a straw man argument from the very beginning

Over the years, I've read a lot of books on software engineering. Agile books in particular like to refute the "Waterfall Model". Every time I read about the Waterfall Model, I think to myself: I'm sure there must be companies out there that have tried this approach, but I have a hard time believing some software book would seriously propose it as the best way to write software. It must be the boogie man of software engineering methodologies.

I was reading The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, and I came across this quote:

Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. He wrote it is “risky and invites failure” because “design iterations are never confined to the successive step.” What Royce suggests as an alternative is similar to what we now call Agile. Sadly, multiple generations of software developers have had to suffer through waterfall projects thanks to people who, we can only assume, didn’t read the entire paper (Pfeiffer 2012) [p. 175].

I think this quote lends credence to my theory that the "Waterfall Model" has been a straw man argument from the very beginning. I know that there were companies that used it, and that there are companies that still do. However, I think this proves that no one ever wrote a book that proposed that the "Waterfall Model" was the best way to write software.

Monday, July 06, 2015

Tetris Over SSH

I wanted to try out Google Compute Engine, but I wanted to build something other than a simple web app. Hence, I setup a virtual server that runs tetris when you log into it, and I gave everyone the credentials :)

$ ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no tetris@ # Password: tetris

Here's the code. I set it up so that gotetris is the login shell, and the user doesn't have permissions to modify any files. Hence, it should be relatively safe to share with the world ;)

Friday, May 29, 2015


I finished reading "A Tour of Go", "Effective Go", and the entire language specification.

They were very well-written. My brain hurts ;)

Tuesday, May 26, 2015

Tetris Written in Go

I implemented a console-based version of Tetris in Go.

In general, it was a pleasant experience. I made use of the termbox-go library for console graphics, and it was enjoyable as well.

I've been reading a lot of blog posts recently about Go, and I think this blog post is the one that captures my opinions best. It's also a treasure trove of useful links to various other blog posts and tidbits.

Anyway, as I said, it was a fun experience :)