How to Keep Learning about Machine Learning

Eugene Yan has watched machine learning tools rise and fall fast enough to give anyone whiplash. Word2vec displaced one-hot encoding in 2013. Transformers upended sequential training in 2017 and then swallowed computer vision and recommendation systems too. Spark buried Hadoop by 2014. TensorFlow and PyTorch retired Theano and Torch within a couple of years. His question isn't really about any single tool — it's about how a working engineer keeps from being permanently behind.

His answer is less about clever shortcuts and more about built-in friction. Try something different on every project, he says, even if pandas already does the job — reach for Spark or Dask anyway, or swap decision trees for a neural net you haven't touched before. Most of the time this detour won't pay off immediately. But it quietly builds the muscle you'll need later, when a dataset finally doesn't fit in memory or the data stops being neatly structured. He's adamant about capping the exploration, though, so curiosity doesn't quietly wreck the actual deadline.

Personal projects get the same treatment, just longer leashes. Yan aims for one project a year, stretched over three to six months, deliberately picking something that scares him a little — his logic being that if failure isn't a real possibility, you're probably not learning much. He tracks progress the way an engineer tracks anything: milestones, lines of code, lessons written down. And he always closes the loop with a blog post or a meetup talk, partly to cement the learning and partly because a portfolio doesn't build itself.

Meetups, conferences, and papers round out the routine — one or two conferences a year, a meetup every month, and a standing habit of running new work through a quick literature review before writing a line of code. He leans on the old three-pass method for papers: five minutes to check relevance, an hour for the core idea, half a day if he's actually going to reimplement it. None of this is exotic. It's just repeated often enough that it becomes reflexive.

The part that's easy to skip past is mentorship, and Yan is specific about who actually helps. Not a CTO, not someone five career steps ahead — someone two or three steps ahead, close enough that their recent transition still contains usable detail. He suggests one new contact a month, treated less like networking and more like a slow-building relationship you check back in on a quarter later.

He wraps it all in a phrase borrowed from Shunryu Suzuki: a beginner's mind sees many possibilities, an expert's mind sees few. Yan's challenge to himself, and to readers, is to learn one new thing a week — a paper, a tool, a rough prototype — and trust that a year or two of that compounds into problems that once looked impossible now looking almost routine.