Thursday, February 23, 2017

The User-Agent Switcher Has A New Owner: Google!

For those of you who are users and/or fans of the extension that spoofs user-agent strings, I wanted to share some news about it, and an explanation of why it hasn't changed much over the past year.

When Chrome originally launched, the number one issue that I found prevented users from browsing sites was those sites' poor user-agent sniffing.  The browser rendered and ran these sites fine, but the sites blocked it whenever they saw its user-agent.  Often, this was because they either needed to update their sniffing javascript (the site didn't understand what Chrome was), or they intentionally blocked it for "we-haven't-tested-it-yet" reasons.

I wanted to make an extension that helped everyone work around sites' bad user agent sniffing.  (I also thought users would want to share their lists of 'broken' sites with each other, so that everyone's browsing experience would be smoother automatically, but I never actually got around to building that part.)  But people ended up using it for lots of reasons -- as a development tool for quickly testing mobile web sites, for working around "improved" site UIs, for admins to work around legacy web apps, etc.  In any case, I feel it accomplished what it was meant to do -- make people's browsing better.  And it has matured to a stable -- although admittedly somewhat stale -- point.

But -- the big news!  The user-agent switcher extension has been acquired by Google.  Yes, that Google (see the "offered by google.com" in the description.)  I didn't make any changes during the process to keep it as stable as possible.  Sorry for any lingering bugs or year-old feature requests :(

I'm not directly working on it, so I don't have any more details.  But it is probably safe to say you won't see a ton of changes, and it is in the best hands it could be.  I imagine any future announcements will come in some other forum rather than this one -- maybe one of Google's blogs.  If I see anything about it, I'll link to it from here.

More thank anything, I want to say THANK YOU to everyone who has ever submitted feedback, reported bugs, posted on my Google+, and emailed me for suggestions.  It was immensely valuable and your feedback helped make the experience better for everyone using it (1.2 million people!)  You probably want to keep submitting feedback on the extension's feedback page, but if you want to keep on posting to Google+/emailing me, that's cool too -- I'll pass it along.

There's a subsequent post about what I learned during the whole 7-8 year experience, but I wanted to make sure this post got out first.

Thank you all once again, and happy spoofing!




Tuesday, December 6, 2016

Validating Mistakes



How do we typically validate or rationalize our mistakes?  I've been thinking about this recently, as I've wanted to learn more about what I'm doing right and wrong in work/life.

Our human brains are wired to naturally blame outside factors: I was deceived, something changed unexpectedly, I had different constraints... or we even rationalize: my life is better because I failed, or the failure wasn't that painful.  But haven't we still failed?  Shouldn't we still learn from it?

Many of the decisions we have to make in life and work are "51/49" -- the choices are extremely close and we just have to choose one.  Either by factor of time, or others making the choice for us, or making the choice ourselves, the choice gets made.  But do we ever go back and evaluate what led us to that decision?  For very close choices like these, if they don't work out, it's almost easy to simply say, "it was such a close choice, we had to make a decision and move on".  But I almost always revisit these decisions and wonder what would have happened had I made the other choice -- perhaps a twisted and romanticized fantasy of what could have been.

I've taken to rationalizing my choices by blaming the data quality and availability.  I can say, "I made the best decision I could at the time with the data I had".  The fault of the wrong choice is no longer my own deficiency; the fault lies in the data being incomplete, or misleading.  This approach probably has its own faults: we all have human biases that make us overlook obvious data looking us in the face, as Nate Silver wrote in The Signal and The Noise.  But it at least forces me during each choice to consider whether I have enough data to reasonably rationalize later that I had all the [good-quality] data I could and made a reasonable choice given that data.

How do you validate/rationalize your mistakes?



Thursday, December 1, 2016

Self-Driving Trucks and Beacon Navigation

If self-driving trucks are indeed going to be a mainstay of our shipping in the future, as is widely predicted, there have to be some rough edges in replacing human drivers.  A human driver can do things like take shortcuts, memorize a route taken many times before, and ask for directions if lost (human pride nonwithstanding.)

So how would a self-driving vehicle have the same adaptability?  It can 'see' where the road is and use built-in, offline navigation to navigate alternate routes, and if it has connectivity, phone home and ask for help or directions.  

But what if it doesn't have connection, is taking a road it doesn't really know or is on any map, and gets lost?  There are certainly many places like this even in the US, and certainly in other localities less documented.

What if, in these cases, major routes used for shipping that are outside of a good connection had small bluetooth beacons next to the road that communicated basic location/map information?  The vehicle could use it to find its way to the next beacon, kind of like crumbs through a forest.  These beacons could be powered by small solar panels, which would be more than enough for the small amount of juice needed to keep them running.

It could be a relatively expensive solution in the short term, as each beacon can run $10-20 per, and the range is maybe 10-20 meters at best.  But if they become significantly cheaper or have much wider range, you could run them along major delivery routes not really on any map (and be used by navigational devices).

To illustrate how this could work, I give you... a double rainbow:



Tuesday, November 29, 2016

Fix It Yourself

My baby monitor, a 5-year old Motorola MBP 36 monitor broke yesterday, with the power socket popping off of the circuit board (this is where you plug in the power cord, so without it, it will eventually run out of power).  Some of the soldering must have eventually worn away after five years of being slammed around by children, babysitters, and my own oafish coordination.


The power socket is that black thing in the middle, it should actually be attached to the circuit board slightly to its left.  It has four prongs, one on each of the corners.

This raised the typical conundrum: do I just go out and buy a new one for $150-ish, or try to fix it myself?  Fortunately, the internets had comments from others who had the same problem and said they fixed it by soldering it back together, so I thought, what the hell -- if I can fix it cheap myself, great, and if I can't, I'll just buy a new one anyway.  But at the same time, you don't want to mess up the fix and have the unit explode in a fire-y explosion.

I'm slightly ashamed to say I didn't have a soldering iron on hand, so we had to buy one for $8.  And I admit, I haven't done a lot of soldering before, so I took a shot at trying to solder each of the four prongs back onto the board.  I was surprised at the sudden-ness of the solder wire melting onto the iron, and then having to dab the melted-on solder from the iron onto the board -- I expected the wire to melt immediately, rather than after a slight delay and whirl of smoke, which made it a bit tricky.


I got a small dab of solder on each corner, kind of by luck.  But it felt solid in place, so I figured it was as good as it was going to without me improving my soldering skills.  Snapping the unit back together, I plugged it in and it worked like a charm.

Great success!

Monday, November 28, 2016

Five ways to break into PM'ing

I've had this post drafted-but-not-posted forever, and since today was a particularly hard day to find time to write, I'm going to take advantage and post it.

I often get asked, "I want to get into product management, how do you recommend doing that?"  I think it's a good question, because once upon a time I had exactly the same question that no one really answered for me.  I want to answer this with my own experience, and hopefully that is helpful to someone to find their way into PM'ing, if that's what they really want to do.

When people ask about getting into product management, they typically ask about being a PM at a bigger company, like Google, Facebook, Apple, or wherever.  So I'll answer in the context of what I know, big-company-PM, and you can take it with a grain of salt.  Start-up people, feel free to comment on whether these also apply to start-up PM'ing...my instinct says "it's different".

This is not a "how to be a good PM" post -- those are already well covered by much better writers and long discussion threads.  I'll give my thoughts on "how to break in" -- I'm also not advocating one company over another, or startup vs. big company -- that's on you.  Every PM's job is totally different, so your mileage may vary.

The prerequisite, soul-searching question that you must answer first is, "Why do you want to PM?"  Is it because you're a business-y person who wants to work in tech, and PM seemed most adjacent to your skill set?  You like the title of "manager", but you are not technical?  Because those are not a great match -- if you aren't technical, there are much better jobs for you to do, like UX design, or general management, biz dev, or analytics (having a CS degree and being technical are not one in the same, and should not be conflated.)  You should do it because you understand how to build technology, want to be close to the execution, and want to build products, and you are really good at working with people and typically are a good generalist.

Be sure it's a job you want.  It really is a "janitor" job.  It's lots of meetings, communication, handling fires, having very little guidance or feedback, working with incomplete data, working with surly engineers, surly partners, surly customers, surly salespeople, navigating politics across all of them, handling the crappier parts of the product-creation process, etc.  Is that really what you want to do?

The guidance I usually always give is:  The best way to get a PM job is to already be a PM.   Which probably sounds kind of dumb, but it manifests in every path I've seen and is often reinforced by HR-enforced minimum requirements (i.e. "3-5 years product management experience" -- look familiar?).  This is probably true of many non-PM jobs; the best way to get an auto mechanic job is to already be one.  If you aren't one already, find a place to practice it.  But how do you get this experience without already being a PM?

#1. The education route.

This is the path I took -- you have a technical undergrad degree, maybe in CS, and eventually decide coding is not for you or you love it but know you'll never run with the really elite.  From there, you go back to school to get a master's degree, maybe in CS, maybe an MBA, and the big companies show up on campus to recruit PMs.  Your previous experience in tech is interesting to them, and your advanced degree gives you a "PM in training" 6-month pass in their eyes (it doesn't in practice, but maybe a topic for another post.)  Some companies will pluck "junior PMs" directly out of undergrad and train them up, too.  Not everyone wants to take this route, because it's risky to bet hundreds of thousands of dollars of student loan debt to not have a guaranteed PM job at the end of it.

I'd recommend *not* this route, unless you are already in working in tech.  You'll find most of the big companies that show up on campus are really just interested in your prior work history anyway.  This method is more sleight-of-resume to get around HR requirements, but if you fit the profile they're looking for, it's a surefire way of getting in somewhere.

#2.  The do-it-yourself route. 

I like this one the best.  How can you practice being a PM for side projects that would make that big company see you as having PM-like experience?  I recommend you start your own side project, and be the PM on it.  Do everything you'd normally do for someone else's product -- talk to customers, design features, write specs, track progress, do customer support, do whatever is necessary to launch and make it successful.  Pick something that you have the expertise to build yourself -- a simple mobile app, a browser extension, a website, a service, etc.  The bonus to this option is that if you do it right and it takes off, you effectively have the basis for your own startup, wherein you get to be both CEO and PM.  This is potentially a good route for current engineers, and is effectively free, modulo the opportunity cost of your free time and personal investment into your 'venture'.  You could also donate your time for free for a startup / non-profit, which I'm not totally well-versed in, but could probably be a route of it's own.

#3.  The small company route.

Smaller companies will sometimes be willing to give you a shot at PM'ing, especially if you have experience doing something pretty close to it, like program/project management, general management, analysis, and the like.  You may have to do lots of interviews and sell yourself as a PM many times, which they may not buy.  Or you may have to accept a job with a different title or different role, and work your way into it when the need inevitably arises.

You'll eventually get your foot in the door if you stick with it, and get to be a practicing PM at a small company, after which you can apply to larger companies (or they will seek you out.)  This takes a lot of perseverance and time, but the minute they give you a shot at being a PM, you have that on your record.

#4.  The PM rotation route.

Many companies have opportunities for engineers to either act as the informal PM for their teams, or formally rotate into the role for a limited time.  If you can get a different job at the company in question, there's a possibility of rotating / switching into the role.  Banking on a rotation opportunity seems kind of risky to me, because not everyone is 'allowed' to do a rotation, and you'll still face heavy scrutiny of your prior light-PM-ing experience.  Your better bet is to get on a team that doesn't have a de facto PM and just doing the role because no one else is doing it.  And quite honestly, this is as close to being a "real" PM as you can get -- shit has to get done and no one is doing it, so you do it.  Added benefit: you get to try before you buy.  If you don't like the job, you can just go back to doing your official role.

#5.  Just apply route.

There are lots of people, typically not already working at Google, who have asked me how to get a PM job at Google -- they have a complete resume, engineering experience, etc.  I always wonder, what are they asking me for?  What are they waiting for?  Don't ask people about applying -- just apply and see what happens.  The worst that can happen is they reject your application and you apply somewhere else.

There are probably other ways to get into product management -- selling your startup to a big company, being the foremost worldwide expert in topic X and the company really wants to invest in X, etc.  I'd be interested to hear if people found their way to being PMs through some other method.

Similarly, I'm also asked "do you need a technical degree or experience to be a PM?", but this is so juicy of a topic that I'm going to leave it for a follow-up post :)

I hope that helps point some people either towards the PM job of their dreams, and good luck!

Sunday, November 27, 2016

Back From Hiatus

I'm back!  It's been a while since I've been writing -- probably over a year since I've written consistently, in fact.  But I have good excuses: I moved back to Silicon Valley, had another kid, changed jobs...you know, just some small stuff.

After having discovered a ton of interesting content via Medium.com, it's clear I've been mired a bit too much in my current work and wrapped up with child-wrangling (and, admittedly, too many video games) to write or read as much as is needed to keep learning.  My brain feels sluggish and distracted by the typical daily grind, and I have more value to add for someone somewhere.

I am renewing my commitment to write daily if possible, and by proxy, read enough to write something of interest.  Hopefully challenging myself to do this will clear the underbrush of routine and keep me out of the trap of defaulting back to working through work email every night.

Just reading words is pretty boring most of the time, so I will conclude with this shot I took from Rancho San Antonio, overlooking Mountain View, Sunnyvale, Cupertino, and a sliver of the bay.  That white spec on the left-middle is the Shoreline Amphitheater, to give you a sense of distance.

Silicon Valley, looking northeast

Friday, July 31, 2015

30 Days Paleo: Lessons Learned

I finished my 30-day paleo challenge last week, technically last Monday, but because I took some liberties on the weekend before, stretched it until Friday.  The results are in...

Over the course of the ~5 weeks, I lost 10 pounds and some of my pants don't fit well anymore (had to go down one notch on the belt).  Part of that may have been to a 3-hour long "cardio tennis" session during the last week.  I didn't feel as sore in the mornings, and was able to work out 5+ times per week and still function.  I noticed a *slight* improvement in athletic performance, more in endurance than raw physical strength.

The 5 weeks ended up being a different experience compared to my prior strict-paleo experience.  Here are some things that I found:

  • Having the pre-made meals made staying on track much easier.  Zero prep time meant there was no excuse for eating something bad-but-quick.
  • Conversely, when not having the pre-made meals, it was much harder to eat right.  Restaurants, cafeterias at work, etc. have very few truly paleo options, and I had to go with salads.
  • Having something sweet / dessert-ish took a lot of the harsh drudgery off of eating strict. Making paleo pies every week was our trick -- we tried coconut cream, key lime, blueberry, peach, and cherry pies.  They all turned out surprisingly good -- like, I'd-eat-this-even-not-on-strict-paleo good.
  • I found my true enemy: Sugar.  Finding sugar-free but yummy food was challenging, but it meant not having big swings in hunger pangs, and not feeling crappy an hour after snacks.  I also learned there is a *ton* of sugar in fruit (apples!), so I stopped drinking OJ and cut down how many fruits I was eating as snacks.
  • Limiting my alcohol consumption, especially at night, probably had a bit part to play in the weight loss but I'm in denial on this one :)
In the end, I feel much better on a daily basis, look trimmer around the gut -- and the challenge wasn't hell, thanks to cheat days and paleo treats.  As a result, I'm going to keep at it for the foreseeable future.

Now, I just need to discover a paleo beer...not sure if I can switch over to sugary ciders...