Hey there!

Hiya! I'm Jonathan Maltz, and this is my personal website. I'm a software developer currently working at Stripe building tools to help fight fraud. I also frequently geek out about engineering culture, process, and how to make teams be more effective. Over the past few years, I've ocassionally written down things I've learned that I hope others find useful. Those are collected on this website.

Flashcard prep

Managing Documents In a Hybrid World

When teams shifted to remote + hybrid work, they also needed to adopt a much greater emphasis on having a written culture. On our team, this came with an additional problem: we ended up with so many documents it was hard for us to understand which ones were important/unimportant. Shortly after that, we had a new manager joining our team and he gave us a few tools to manage this document explosion.

A Hub and Spokes Model for Documentation on Large Projects

As projects grow it can be difficult to keep track of all of the documentation associated with them. Between product requirements documents, design documents, meeting notes, and architecture decision records it can be easy to find yourself lost in a forest of Google Documents trying to find that one document which has the information you need. A while ago a friend told me about a simple model to manage this complexity on large projects, something he called "the hub and spokes" model of project documentation.

How Teams Change At Different Sizes

During my career I've had the chance to work on teams of a lot of different sizes. During that time I've come to realize there are really six "buckets" of team sizes. At each bucket, ICs + team leads need to operate a little differently in order to be successful within those teams. The sizes are:

When Should You Spend Time on Technical Vision

One of the challeging things about being a technical leader is knowing how much time to spend on big-picture vision setting vs. writing code and solving the problems of today. Spend too much time on vision setting and you may start designing solutions which are disconnected from reality. However, if you don't spend enough time on vision your team will sputter over the long-term. Over the last couple of years I've found a few heuristics to apply which let you know when it's time to jump into "vision setting mode".

Collaborating Effectively By Focusing on Understanding

A while back a friend gave me some important, but hard to hear feedback. She told me something to the effect of "you always assume other people are wrong, and it limits your ability to collaborate with people." I'd always considered myself a strong collaborator, so hearing that I actually had a long way to go was humbling. For the rest of the year I worked on breaking this habit with a simple mental framework: whenever I'm surprised by something, assume that the other person has already done what they believe to be the exact right thing." This simple idea was incredibly powerful for pretty much everywhere, but it's most handy in a few situations.

Some thoughts on "organizational neutral"

Recently I had a shower-thought about the concept of "organizational neutral". "Organizational neutral" in my mind can be contrast with "Organizational fifth gear". You know you're in fifth gear when people are trying to pour gas on whatever thing you're working on. Users are flooding you with feature requests, your part of the org is getting as much headcount as you want, and people are generally very excited about what you have going on. The problem when you're in "fifth gear" is that you need to pick a generally correct set of things to work on and make sure that people are not stepping on each other's toes too much (there's probably a separate version of this for hypergrowth, where you just point a mass of people in the generally right direction and pray).

Some Thoughts on Rules Engines

Spend enough time working with domain experts on a problem and someone is bound to say "we should build a rules engine to solve this problem." Often this comes along with the goal of letting domain experts express rules themselves rather than having to evolve engineers. However, once you start to dig into this problem you'll discover that "rules engine" can mean many different things to many different people.

Communicating through uncertainty

Recently I've found myself in situations where there's no right answer. In these situations it can be hard to know how to proceed and even when you do make some decision, it can be hard to communicate that to a team in a way that builds confidence in spite of the uncertainty. I've recently been watching some great leaders do this, and I've found that doing it well boils down to a few simple steps.

Running Design Sprints for Engineering Teams

Sometimes engineering teams find themselves in a situation where they're tackling a cross-functional problem with no clear path forward. In these cases it can be challenging for individual teams to break out of their silos and see the global problems, resulting in local optimization while the larger problem remains unsolved. Fortunately, teams can follow the structured process of a design sprint to cut through these problems and quickly forge a path forward.

Raising Problems Without Raising Blood Pressure

As you move from owning individual problems to owning projects, you'll often find yourself in a position where you're surfacing risks to your manager or other senior folks. Doing this well can be an art; on one hand you want to stay stay aligned with authority and make sure that leadership is aware of the problems. At the same time, constantly surfacing risks without helping mitigate them can erode confidence in your ability to deliver. Striking this balance can be hard, but can be repeatedly done with the right communication strategy.

Book Report on Software Estimation - Demystifying the Dark Arts

Estimation is something that I've done for a long time, but I've never really felt like I've done it well. I started rectifying that by reading Steve McConnell's Software Estimation: Demystifying the Black Art. The book is chock full of great ideas, and I've summarized them here for anyone looking to quickly improve their estimation skills.

A Default Approach to Quarterly Planning

Teams often find themselves in a position where they need to figure out how much work they can commit to, most commonly in quarterly planning. If you've never done this before then wading through a world of possibilities to get to a commitment can feel impossible. Fortunately, I've found that a default approach can help you establish a plan reasonably quickly and with minimal overhead.

Evolving Communication Structures With Exponential Scheduling

One of my challenges at Nuna has been setting up team-level communications structures in the face of uncertainty. Going from 0 to 1 means that our understanding of the problem constantly evolves, and with that, our communications structures need to evolve with it. I've managed to grapple with that change through an approach I call exponential scheduling.

How do I get my ideas prioritized?

A while ago I was struggling with the question of "how do I get a project prioritized." I had an idea that everyone agreed was good, but it was languishing and other work was getting prioritzed. I talked to a mentor and he gave me a three-step process that I've since found very useful. The process goes something like this

Is Conference Speaking Worthwhile?

Over the past few months, a few people have asked me about my experience speaking and blogging, specifically through the lens of what type of opportunities it has opened up for me. My thoughts on this have been rattling around for a while, so I wanted to share them broadly in case other people have similar questions.

Roadmaps vs. Projects

I had lunch with a friend yesterday, and he shared an interesting story. He was leading a large technical project at his company, and it started off fairly normally. They saw some fruit they thought would be low-hanging, ran the ROI numbers, wrote a project plan with clear milestones that showed value along the path, staffed the project, and started to deliver.

Writing Good System Overviews

Over the years at Nuna, our data platforms have grown from small pipelines which served simple analytics, to large, polyglot pipelines which can help patients receive personalized doctor recommendations. As we’ve scaled, our inline documentation and README’s for specific libraries have been helpful, but haven’t been sufficient to help new hires understand how our whole system fits together. In order to help our “Newnas” get up to speed faster, we’ve written a different type of documentation: a system overview, detailing how the whole system comes together.

Start Side-Hustling

Back in university I worked in a media office, and it seemed like all the creatives had two jobs in their life: their real job, and the thing they did on the side. Our graphic designers would run a consultancy, our photographers would put together a magazine, and our videographers would were constantly shooting for events or contests.

Do You Really Need That JSON Array?

When building APIs, it’s common to run into a problem which is basically a form of “We want an API that will support a list of something.”. In situations like this, it can be tempting to just send back a JSON Array and call it a day. However, I've found that this is rarely the right decision, and by making a slight tweak to this design you can make your APIs much more extensible.

Practicing as a Software Engineer

Continuing to grow as a software engineer can become increasingly hard as you become more experienced. When you first learn to code, there are an infinite number of new things to learn; every algorithm, framework, or concept is brand new, so there’s learning at every turn. Best of all, this happens organically. If you've never written code before, the mere act of typing into a computer and making it work is challenging and pushes you to grow. Over time though, that growth path starts to peter out: there are only so many language features you can learn or libraries to master before you start hitting diminishing returns. Past that point, the skills you need to learn become abstract questions like “how do I design better software” or “how do I lead a team”, and to grow those we need to think a little differently about how we build skills.

Effective Feature Flagging on Mobile

Feature flagging is a great way to reduce risk by allowing features to be turned off remotely, but only if it's done correctly. I recently incorrectly feature flagged some code at Yelp! and wanted to share some lessons learned to help avoid similar issues in the future.

First, Some Context

Our team is currently working on migrating our App's analytics system to use a new event logging library.  Getting correct metrics is important, so we decided to start by dual logging all of our analytics through our legacy library and the new library and then comparing them for consistency. We had tested the new library, but we weren't totally sure how it would behave in production, so we decided to put it behind a feature flag in case anything blew up.

Wan't to Make a Change? Stop Talking and Start Listening at Android Makers

I recently had a chance to give a talk at Android Makers about how to work with cross-functional stakeholders to create change. While I'm not an expert on that by any means, it was a good learning experience for me to decompose my thoughts on how I work with others. The video is now live on Youtube.

Protecting Your Source Using Code Review To Improve Your Application Quality at Droidcon Boston

I recently had the chance to speak at Droidcon Boston about one of my favorite topics: code review. A video of the talk is now on Youtube.

Finding Mentorship After Onboarding

One of the first questions I got after giving my talk about mentoring new hires was (paraphrasing) "how do you deal with effectively mentoring people who are 1+ year into their time on the team?". This question has stuck with me over the past year, mostly because I didn't have a particularly coherent answer at the time, and I stumbled through answering it. Over the past year I've spent a lot of time thinking about my own process of acquiring mentorship, and I finally have a (more) cohesive answer to "how do you handle mentorship after onboarding". I wanted to take a chance to share those thoughts, in hopes that people who are 1+ year into their time on a team can chart their own path to getting the mentorship and resources they need to succeed

Adventures in Gradle Dependency Resolution

Currently at Yelp I'm working on building out our next generation experimentation infrastructure, a large part of which involves writing a Java wrapping library around a Rust library which does most of the heavy lifting of our experimentation. Yelp is mostly a Python shop, but we also have a few backend Java services; this meant that when we went to implement our Java wrapper, we decided to just write it once in pure Java and write a thin layer of Android code on top of that to provide Android-specific capabilities like logging to adb.

A/B Testing From The Ground Up At Droidcon SF

I recently had a chance to talk about A/B testing at Droidcon SF as part of a talk called "A/B Testing From The Ground Up". The goal with this talk was to give attendees an overview of all the moving parts needed to get an A/B test up and running on mobile. The video should be up in a couple of weeks. In the meantime, the slides for the talk are below.

Multiplying Your Impact Through Mentoring at Droicon UK

I recently presented a new and improved version of my talk on "Multiplying Your Impact Through Mentoring" presentation, this time at Droidcon London. A friend at Yelp suggests that the third time is the best time for any presentation, and after the fourth presentation it's time to retire the talk. I definitely felt like that was true this time, so I just need to find one last time to present this talk and ride off into the sunset.

The Benefits of Shipping Code In Small Chunks

One of the more unintuitive things in professional software development is the idea that you should break your code up into small, fully functioning chunks, rather than shipping it all as one big change. After all, wouldn’t more changes mean more code reviews, more pushes, and more opportunities for production to break, all of which slow down the time spent actually building useful features? Yes, shipping more changes does absolutely require doing more of all the above. However, it also has a myriad of benefits which make it the better and more scalable, approach to shipping code.

Discussions on Building Widely Adopted Infrsatructure

Every month, a group of engineers at Yelp get together for something we call the "technical roundtable", which is basically a big discussion group on technical topics that are challenging the company. Often, these focus on specific pieces of Yelp's technical infrastructure, but our most recent one touched on time management for mid-level to senior engineers. A lot of the takeaways were initially surprising but obvious in retrospect, so I figured I'd share them with the wider internet.

Ship Great Apps Faster By Collaborating With Designers

Whenever I hangout with mobile developers at meetups, I hear a bunch of misconceptions tossed around, but one of the most pernicious is the belief that designers are head-in-the-clouds artists, throwing pixels around without concern for what it will mean to implement their creation. On the surface, this comparison is apt; both artists and designers create visual artifacts out of ink, paper, and pixels. Dig a little deeper into what designers do every day though, and you will discover that that design is not art. Rather, design is a problem solving discipline which tackles a different, but complementary, set of problems to the ones engineers solve when creating a product. Once engineers internalize this idea of designers as problem solvers and not artists, it opens up a whole new mode of collaboration which allows for otherwise impossible products to be shipped.

Multiplying Your Impact Through Mentoring at Chicago Roboto

I recently presented an updated version of my "Multiplying Your Impact Through Mentoring" presentation at Chicago Roboto. The audience had some really great questions which made me realize I need to think more deeply about some aspects of mentoring and update my presentation the next time around. The slides that I presented are below

Effective Interviewing Through Storytelling

This weekend I had the pleasure of getting to attend the AI In Action Spring 2017 hackathon at Claflin University in Orangeburg South Carolina. AI in Action focuses on empowering K-12 students in rural South Carolina by teaching them to code. While I was there I gave a presentation on an aspect of interviewing that I think is really under-coached: communication. These are the slides from that presentation.

Supercharging your Code Review With Collaboration

Software engineers always talk about how code reviews are the single biggest thing to improve your code quality, but we often forget that putting your hard-written code up for review can be scary. We invest a lot of time in making sure that our code is perfect, so submitting it to someone for their critique can feel like putting part of our identity up for critique.

Fortunately for you, prospective code reviewer, there’s something you can do to help. By being conscious of the language you use when suggesting revisions, you can preemptively allay the concerns of your reviewee and supercharge your code reviews. Best of all, it only requires tweaking a few phrases in your vocabulary.

Getting started: Focus your critical feedback on the code, not the people who wrote the code.

One of the first keys to building safety as a reviewer is to make it clear that any feedback you give is not about the code’s author, but rather a comment on the code itself. This can seem complicated, but there’s a dead simple way to get started accomplishing this: remove the word “you” from your code review vocabulary.

It’s a little challenging to get started with this new, you-free lifestyle, but you’ll find that it pays huge dividends. In fact, once you’re aware of it, you’ll find the sneaky three letter word has been cropping up all over the place, making situations adversarial when they should feel collaborative. Worst of all, chances are, your “you’s” have probably been popping up when they’ve actually been referring to the code all along!

Let’s take a look at a fairly innocuous code review comment:

“You’ve really tightly coupled your classes here. That may cause some problems down the road.”

Slides From Multiplying Your Impact Through Mentoring

I gave my first big boy conference presentation today at DevFest Minnesota! The topic was "Multiplying Your Impact Through Mentoring", which has been rattled around in my head a while because I think we as an industry do a pretty poor job of training mentors. The slides are below.

Asking Great Questions on the Internet

We’ve all been there before: you’re chugging away on a technical problem and suddenly you hit a brick wall you just can’t seem to get over. You’ve turned down every imaginable path, but still you’re getting behavior that seems like it was created by some sort of deity just to spite you. Fortunately, there is hope! Many projects, both enterprise and open source, maintain chat channels and mailing lists that you can use to ask questions to get yourself unstuck on your current problem.

Making The Most Of Your Internship Slides

Over the past weekend I had the pleasure of mentoring at Hack The North in Waterloo, where I gave an updated presentation on how to have an awesome internship/co-op. The slides are live on Speakerdeck.

Slides From How To Have An Awesome Summer Internship

Today I had the pleasure of giving a presentation to students at stanford about how they can have a succesful summer internship. These are the slides from that presentation.

Some Tricks To Make You More Productive

Every developer has their own little kit of productivity tools which they constantly expand over time. Unfortunately, I've found that the only way these tools get shared is when someone has a problem someone else pipes up "Hey, I know how to do that!", and passes on their tribal knowledge, only for it to be lost until the next person has the same problem. In the spirit of "sharing stuff I wish I'd known last year", I wanted to share some neat things I've discovered over the past couple of months which have helped me solve various problems.

How To Have An Awesome Summer Internship

The Price of Inconsistent Code

have You ever read an english essay so riddled with errors its tough to read. i'm not talking your normal run of the mill errors; I'm talking about really systematic misunderstanding of how to use punctation!

From 0-350 In Three Years

Back when I first declared my CS major at Rutgers three years ago, the community was a far cry from the vibrant and passionate one that characterizes Rutgers today. When I started, Rutgers computer science was a disparate collection of students who scarcely got together in groups larger than four people.

Getting The Most out of your First Hackathon

It’s no secret that over the past three years hackathons have exploded across the country, bringing with them the opportunity for thousands of students to grow their coding skills and build a community of developers at their university. Despite this massive growth, it seems that hackathon knowledge is still spread by word of mouth, leaving some younger students wondering how to get started.