Last week, Fedora contributors proposed to change the meaning of “python” from “python2” to “python3” starting with Fedora 31. This makes sense in the context of Python 2’s upcoming demise. But some feedback on the mailing list, including mine, wonders why we’re perpetuating it.
Should there also be no “pip”, no “pytest”, no “pylint”, … command? I would say “yes”. Admittedly, it’s avoiding future pain in exchange for some current pain. But we’re already dealing with a disruption, so why enable the same issues when it’s time for Python 4?
This is bigger than Python, though. If you’re following semantic versioning, I argue that you should name your interpreters and any ecosystem executables with the major version name. Unless you’re promising to always maintain backward compatibility (or to just stop working on the project), you’re eventually setting your users up for pain.
What about non-programming languages? This is probably good advice for anything with a client-server model (e.g. databases). Or anything else where the command is separated from other components of the ecosystem. You could extend this to any executable or script that may be called by another. That’s not wrong, but there’s probably a reasonable line to draw somewhere.
Wherever you draw the line, doing it from the beginning makes life easier when the new, incompatible version comes out.
Amazon famously has meeting attendees read documents at the beginning of the meeting. It seems to work well for them (I’m not sure that’s the secret sauce, but that’s for another day). Tech exec Jason Crawford recently had a Twitter thread promoting this concept.
When you have a doc to review in a meeting, you should do a really counter-intuitive thing:
DON'T send it out beforehand.
Instead, share the doc at the *beginning* of the meeting and have everyone read it, silently, *in the meeting*.
Her arguments are right on and sufficient on their own. But there’s a broader point too: this is solving the wrong problem.
[ed note: The previous paragraph does not sufficiently express my intent. The exclusionary effect that Julia points out are reason enough to not engage in this practice. Full stop. My point about “solving the wrong problem” are more along the lines of “even if it weren’t exclusionary, here’s why you shouldn’t do it.” Thanks to Ruth for the comment that calls this out.]
Is your document too long for people to understand and digest? Fix that! Identify people who can act as editors that can help others within your organization write better documents. Or better yet, pay for writing training for your employees. It costs money, but it produces real (but hard-to-quantify) savings. Not only will you save time by having more understandable documents, but you may even have better ideas.
Are people not reading it because they’re too busy or don’t care? Fix that! Maybe it’s irrelevant to the person; that’s an indication that they don’t need to be invited to the meeting anyway. Or maybe they’re overworked, or mis-worked. That’s a management problem that will manifest elsewhere. Or maybe they’re just not doing it. Again, that’s a management problem — if that doesn’t show up in their performance evaluation, then you’re showing that it’s not actually important to you.
Jason suggests scheduling a 90 minute meeting if the document takes 30 minutes to read. That’s a waste of 30 minutes. Yes people should absolutely read the document. But they should also have the flexibility to do it when it makes sense to them. Maybe they have a train ride home that they’d rather do reading on. Maybe they like to block out time around their other meetings. It’s not valuing their time to decide when they get to read the document.
He also says it avoids “negotiation” about how soon in advance a document should be sent. This is a cultural norm that you can set. All of this comes down to a shortcut to avoid the hard work of setting a culture that gives people flexibility while still holding them accountable.
Gatekeepers are a problem in communities. They decide — often arbitrarily — who can and cannot be members of a community. Are you a true Scotsman? A gatekeeper will tell you. And if there’s something they don’t like about you, or they’re feeling particularly ornery, they’ll keep you away from the community.
Gatekeeping is a problem in open source communities. More experienced (or just louder) contributors set a bar that new contributors cannot meet. This is bad for folks who want to contribute to the project, and it’s bad for the project’s sustainability.
A recent Opensource.com article asked “What is a Linux user?“. In the initial version, it left open the possibility that if you’ve only used a Linux desktop that doesn’t require a ton of tinkering, then you’re not a real Linux user. Fortunately, the comments called this out quickly. And the author, to his credit, did not hold this view. He quickly updated the article.
The revised article does a much better job of closing the door on gatekeeping, but I would rather it have never run at all. By engaging in debate on the question, you give it validity. It’s best to deal with gatekeeping by not even acknowledging that the question is valid.
When working in a group, you may sometimes struggle to get the group won over to your way of thinking. It’s a challenge. Sometimes you can’t state your case in a compelling manner. Sometimes your idea is terrible. Sometimes the group just won’t listen. But there’s a shortcut you can use to give your opinion a head start: write it down.
Blank pages are scary. They contain infinite possibility. It turns out that infinity is a really big, daunting concept. People don’t like them. This makes the blank page your opportunity.
Undoubtedly, the team will edit your draft heavily. It may get to the point where nothing remains of your original work. That’s okay. By having your opinion be the starting point, you give it some extra weight. You’re framing the discussion. If you’re particularly sneaky, you can even go a little beyond your actual position so that when it gets edited more toward the “middle”, it lands where you wanted.
This isn’t a fool-proof method by any stretch of the imagination. But you’re giving your idea a little bit of a boost. Even if your position isn’t the one the group settles on, being willing to write that first draft sets you apart. It doesn’t particularly matter if it’s good or not, because it’s going to be revised and revised and revised. So do you yourself a favor and just write the damn thing.
I don’t remember how it crossed my field of view, but I recently read a blog post from the CEO of Carta. In it, he talks about their company culture and how new employees get introduced to it. Since I have had a few conversations on this general topic with my colleagues who are in charge of such things at my employer, I read it with great interest.
Until I got to the sports team analogy.
Most companies find role models in other companies (e.g. Facebook, Google, GE). They aspire to be like “Company X”. I propose an alternative model for Carta. We don’t model ourselves after companies. We model ourselves after professional sports teams. My question for you is, “What is the difference between a company and professional sports team?”
What?
There are many similarities between Carta and a professional sports team. For starters, our entire company meets everyday at 8:30am to begin the day together. Everyone — engineering, sales, services, office management. Nobody is exempt. In sports, even the goalie, who may have a completely different practice schedule from the rest of the team, still meets at the same time to warm up.
[…]
Most people think it’s crazy that we make everyone be in the office at 8:30am every morning. We think it is crazy not to. The New England Patriots would never tell players, “Show up for practice when it is convenient.” If you want to be the best in the world at what you do, start every day together.
This is bad. It is so bad. What I read when I see this is “if you’re a parent, we don’t want you.” Or any other number of reasons why being in the office regularly at 8:30 might not work.
Now don’t misunderstand me: it’s important to be a reliable coworker. But the idea that the entire company needs to start the day together is ridiculously exclusionary. Sports teams practice together because they need to work closely together in split-second situations. They need to develop an almost telepathic understanding of what their teammates will do. They also get paid millions of dollars a year.
Your office manager does not get paid millions of dollars a year. The success of your company does not depend on the perfect, split-second timing of your lead developer and East Coast sales representative. You should develop team rapport and trust but in a way that makes sense for the work they do. Not exclusionary Valley Bro crap.
There are some really good ideas in the post: the full-day culture orientation, the idea of not taking too much capital in an attempt to grow as fast as possible, the idea that everyone contributes to customer success. But the shadow of the crappy sports analogy is deep enough to overwhelm the good parts.
“We welcome our customers,” Best Buy training supposedly says, “not greet them.” First off, if you’re doing this, fuck you. This is silly word-lawyering for any job, but particularly for retail. They’re already relatively low-paid and high-bullshit, why are you making it worse?
But even apart from treating your employees like they’re people, there’s a business argument for this. Over-engineering customer service interactions makes them less serving of the customer. Empowering the employees to serve the customer leads to better service. And it turns out better service can help you keep your customers.
By coincidence, I had to deal with a couple of financial firms earlier this week. The first interaction boiled down to “welp, I can’t really do much for you. Go away.” The second, with Fidelity, made me feel like my problem was their problem, too, and it would get solved. Every time I’ve needed something from Fidelity, I’ve felt that way.
The same is true for T-Mobile. Even when it’s possibly not their problem, they do as much as they can to help me solve it. As a result, I’m still a T-Mobile customer, even though the coverage map isn’t as coverage-ful as I’d like. This is in no small part due to the quality of service I’ve received.
In both of these cases, the customer service representatives don’t feel like they’re mindlessly reading from a script. I get the sense that I’m talking to an actual person who wants to solve my problem, not close my case. They don’t seem to be judged on the difference between “greet” and “welcome”.
Chris Siebenmann recently wrote a post about Golang where he said: “Go is Google’s language, not the community’s.” The community makes contributions — sometimes important ones — but does not set the direction. We frequently use “community project” to mean two separate ideas: a corporate-lead project that accept community input and a project (that may have corporate backing) lead by the community.
Neither one is particularly better or worse, so long as we’re honest about kind of project we’re running. Community-contributed projects are likely to drive away some contributors, who don’t feel like they have an ownership stake in the project. Chris mentions that Go’s governance has this effect on him. And that’s okay if you’re making that decision on your project intentionally.
Some community-contributed projects would probably welcome being community-led, or at least somewhere closer to that. But technical or governance barriers may inadvertently make it too difficult for would-be contributors to ramp up. This is one area where I don’t think GitHub’s position as the dominant code hosting platform gets enough credit. By having a single account and consistent interface across many unrelated projects, it becomes much easier for someone to progress from being a bug filer to making small contributions to becoming (if the project allows it) a key contributor.
Jessica Liebman wrote an article for Business Insider where she shared a hiring rule: If someone doesn’t send a thank-you email, don’t hire them. This, to be blunt, is a garbage rule. I don’t even know where to begin describing why I don’t like it, so I’ll let Twitter get us started.
Don’t accept a job offer from a company that didn’t send you a handwritten thank you note after the interview. You’re the person adding value. Not the other way around. https://t.co/2hLg546FUc
Seriously though, this sounds problematic. Insofar as it's a recognized social norm to send a thank you note, it'll be a meaningless formality, hopeless for distinguishing good candidates. Insofar as it's not, you should infer *nothing* from the fact that someone didn't send one!
This is an arbitrary bit of gatekeeping that is both culture- and generation-specific. In doing this you’re also gong to skew results to people who act and think like you, thereby decreasing intellectual diversity on the team. A thank you is classy, but not a disqualifier.
When I’ve been on the hiring team, a short, sincere “thank you” email has always been nice to receive. But I’ve never held the lack of one against a candidate. It’s not like we’re doing them some huge favor. We’re trying to find a mutually beneficial fit. And employers hold most of the power, in the interview process and beyond.
You can lament it if you want, but the social norm of sending thank yous for gifts is greatly diminished. So even if it would have been appropriate in the past, it’s no longer expected. And, as noted above, it’s culture-specific anyway.
Until employers see fit to offer meaningful feedback to all applicants, they can keep their rule requiring thank you notes to themselves. And even after that. If an employer wants to use arbitrary gates that have no bearing on performing the job function, I don’t want to work for them.
Over the years, I’ve received a lot of feedback on my writing. Some of it has been helpful, some less so. Little of it has coalesced into rules that I could easily share, but once piece of advice stands out: delete the last sentence.
I first received this advice when I was in high school. A young and idealistic NJROTC cadet ensign, I wrote several memos to our commanding officer about various incidents. I had a tendency to close with a request that he take the action I desired. Ryan Brown was remarkably kind and mature for a high school senior — instead of ignoring it or getting angry and dismissing me out of hand, he took me aside. “Cotton,” he told me, “the next time you write a memo, delete the last sentence.”
I thought of this again recently when I was replying to a message on a community mailing list. I don’t remember what the person wrote, but it was off-topic. I was going to say “This is off-topic for the devel list”, which is benign on its face, but didn’t really add anything except an implied “fuck you, go away”. My experience is that the last sentence in a reply like that is almost always inflammatory.
I get it. When you’re writing something, you want to have a good close that really drives your point home. I catch myself doing that all the time. But if you’re writing well, particularly in email, you don’t need a punchy ending because you’ve already made your point. In the above, other parts of my reply already indicated that the message wasn’t suitable for the list, and I explained why. Repeating myself there didn’t add any value to my reply, it was just repeating myself for the sake of repetition.
“It’s on the roadmap” was a common expression when I worked in customer-facing roles. That statement is a delightfully vague response to feature requests. It might mean “it will be in the next release.” More often, it was as close as I could get to saying “yeah, there’s no way in hell we’ll ever get around to implementing that” without getting myself in trouble. Cowardly? Probably. But at least it was tactful.
At a previous company, we did actually have a product roadmap. It looked forward through the next year, broken down by quarter. The first quarter was generally pretty accurate, even if some of the work slipped a bit. The second quarter was okay. The third and fourth quarters? Well they didn’t really reflect anything approaching reality.
But for me, it’s all about how the road map is used. “Road map” is a pretty lousy term, when you think about it. I spent a lot of time looking at road maps as a kid (I’m so cool!) and they almost always gave an accurate representation of what was coming a mile or a hundred miles ahead. Product road maps, if taken that way, lead to lies and broken promises.
For me, a better framing is a product forecast. When the National Hurricane Center forecasts hurricane tracks, they don’t just draw a line and call it a day. The forecast graphic shows an area of uncertainty that expands with time. When a storm is a few hours offshore, you can generally be fairly certain where it will make landfall. When it is days away, the potential landfall area is much larger.
Example hurricane forecast graphic from the National Hurricane Center
The analogy isn’t perfect, of course. Products can pivot much faster than hurricanes can. And storms are things that just happen to us, whereas the product is something we can consciously effect. But in general, I like this idea. In the short term, you know what you’re working on and what you’ll be able to deliver. Beyond that, you know where you’d like the product to go, but something may happen between now and then to change it.
I like the “Yes, No, Maybe” model that Ben Balter wrote about last year. In his post, Ben limits the roadmap to the next three months and categorizes work as “yes we’re doing that”, “no we’re not doing that”, and “maybe, but we need more information”.
The advantage of the three-month window is that it prevents the roadmap from becoming a giant lie. But extending a product roadmap (or forecast) beyond three months helps give some context to the work being done in the short term. People benefit from having a longer-term vision, even if they change direction before they ever reach it. Forecasts are wrong sometimes, but they represent the view of the future from the best information available at the time.
