What I Learned at Stripe
steinkamp.us
steinkamp.us
This seems utterly unacceptable to me.
Firstly, taking private things public is a breach of trust. There was a reason this wasn't public.
Secondly, this seems massively counterproductive. I can't find the story here anymore, from a few weeks ago, where the guy who worked at a laser factory tried to tell people that their laser aim wasn't stable, and the company only fixed it after the customers complained - because the colleagues were aghast at such a "non-positive" attitude from the new guy.
Also, I'm German, where all this US "be nice and smile all the time" thing seems at best naive, but also a form of torture and company overreach to try to emotion control employees into this drugged up alice in wonderland facade. "Crowdsourcing" company culture emotion control to a system of shaming and doxxing only makes this worse, as it removes the central point of responsibility for it and allows the company culture control to hide behind the employees for it. This is vile.
There's more positive or constructive ways to raise that complaint, and I can see the value in not just having a toxic cycle where people are venting about other people in private with no actual action about it ever occurring. Constructive doesn't have to mean you're some drugged up worker drone that's ignoring security faults in a product, it just means actually trying to work out what to do about the issues you're seeing.
It was terrible and I hated it. Sometimes I just want to talk with one person instead of the entire engineering org.
My next job I assumed they would be the same so I defaulted to never talking to anyone, which caused its own problems, as you can imagine.
The entire public by default thing is toxic, imo.
In general, I think it's one of those policies that can absolutely be toxic, but can also be healthy, and it's dependent on the surrounding culture and team and how absolute the policy is.
How I'd love for the default expectation to be just "get the job done," do it professionally, and that's it. Sachlich, to use a German term.
While people like me try to do their job itself as best as possible, while maintaining a healthy work-life balance and don't get burned out.
But it's not the way.
At least it’s kinda okay in engineering land. We have our wry jokes and witty remarks. But poke your head outside that bubble and the amount of verbal gymnastics you have to wade through just to figure out what someone was trying to say … urgh.
edit: This reminds me of when my sister came to visit and we went to a farmer’s market. Someone bumped into her and said ”Excuse me” and she later said ”Aw Americans are so nice!” … no dear, that means “get out of my way asshole”
What would you think is more honest? Someone bumps into you and cusses you out? Says nothing and ignores that the may have hurt you or caused you to drop something?
And yeah in a crowded place with people having very little personal space? Just ignore it and move on. It’s not a big deal. Obviously there are levels of crowdedness, but somewhere between empty room and front row at a concert, you stop acknowledging small bumps.
Either way, I don’t think I’ve seen anyone use “excuse me” as an apology in SF. It’s more like the Minnesotan “ope” – said while you’re already shoving your way past someone purposefully. An apology sounds more like ”Shit, I’m sorry! Are you okay?”
I'm mostly curious because I've been living with a variety of German travelers in the US for the last 10 years for reasons and have, if anything, found them to be overly polite to the point of annoyance relative to my American instincts.
It's just cultural norms. Inability to know what someone was trying to say is a feature, not a bug.
Sure, in engineering and science, it is a bug, but in everyday life, what a great feature. It forces people to translate vague-speak into my-worldview-speak, which helps bridge the culture/worldview gap. You can always drill down and double-check that you've interpreted correctly but communicating in vague-speak avoids so many sharp corners people tend to have - it's great stuff.
Can you imagine what hell places with lots of immigrants would be if all of them thought their culture was the way to go and looked down upon all that is unfamiliar and foreign?
That depends entirely on the tone of voice used. Typically, people mean "excuse me".
I believe you’re referring to this comment, from the discussion about normalisation of deviance:
People start private chats for whatever reason they like but they assume it's private. Until there is an agreement by both sides for it to be public it shouldn't. It shouldn't matter whether that's online (via Slack) or in person (via a private room).
To be charitable, "speak up to take the conversation" could actually mean "I propose we move this conversation to #public_channel."
Personally, I don't even consider it unhealthy. DMs are for convenience, work conversations are better off with more visibility.
Have you been involved in a deposition or a legal hold? If you're worried about your colleagues seeing your DMs, then perhaps ponder on the consequences of the same messages becoming part of the public record via the courts or regulatory body.
Nothing communicated in the execution of your duty is truly private: check the fine print in your organization's policies.
> someone would speak up to take the conversation to a public channel, and things returned to a more constructive tone.
That's literally "hey, let's take this to a public channel?"
The top level reply is from someone who presumably speaks a different language primarily, and may have missed the nuance of the statement.
But it's almost like the 15+ replies are from people who didn't read the article and took this person's wrong interpretation as the truth.
In my experience, the required performative cheeriness is a feature of newer companies that have over-hired. I’ve worked with several US companies with established international presence where being direct and honest was the expectation.
I’ve also worked at smaller startups where toxic positivity was basically company policy. I’ve been reprimanded for my tone not being positive enough in a meeting where we were discussing a serious and urgent issue. I’ve had an employee who couldn’t handle even the slightest bit of feedback that wasn’t glowingly positive. These experiences were rare, though, and they were all associated with companies that had hired a lot of middle managers with vague directives who had little to do other than attend meetings and cheerlead. In each case it was a sign that the company valued perceptions more than reality, and it led to poor company performance.
Step outside of those companies, though, and it’s common for moderately high pressure environments with blunt, direct feedback. I’ve also had several outright abusive bosses who would disparage me personally, threaten firing at the slightest issue, and one CEO who even fired people on the spot if he was in a bad mood. The US doesn’t have a uniform work culture.
In friendly-social environments, it is all about avoiding overly negative topics. It is not lying, but just keeping the conversation track on things that are positive and interesting.
In engineering environments, logic is king. You need to be able to tell an engineer that their rocket designs will not fly and put ego's aside.
In software(!) engineering opinions are important though.
Software is less like traditional engineering as there are no "right" ways to do things.
This is hardly a universal US thing, though. The vast majorities of companies I've worked at weren't like that.
The excessive positivity and no one being accountable for anything were conscious adaptations US management brought in around 2010 or so after there was so much press and academic pressure that everything had to be changed or millenials would refuse to work at any company that didn't change. It's possible the whole thing was a charade and that none of it was necessary to attract millenials or a more diverse/equitable employee mix.
Things in software are utterly unrecognizable compared to the 90s and early 2000s when people would yell at people for failures and there was far more accountability around failures and analysis of why things weren't working. It used to be a very "tell it like it is" culture. The way it is now there's pressure to sweep everything under the rug because of a fear that low performing employees will be offended.
Everything is hush hush and weird and the low performing employees are allowed to skate until they suddenly disappear.
The weirdness IME has even extended to where you're not allowed to talk about someone making a colossal mistake even if everyone knows who made the mistake due to a git blame or something. Not talking about it just leads to the mistake being made again and again till management makes the offender mysteriously disappear.
I'd somewhat suspect this trend in the US is probably not as prevalent in some sectors like maybe defense, though I have heard some crazy stories about useless employees being allowed to skate in that sector as well. Those are often huge companies where lots of this stuff happens.
A lot of Elon Musk's antics at twitter are basically just clumsy attempts to roll things back to the way they used to be. A lot of the excess of modern tech companies would have been unimaginable before the first .com boom. My early experiences were almost nothing was free in the office except coffee. When the team had a massive success there would be a big party, but other than that the company wasn't giving away all the free stuff all the time.
How does this solve problems more effectively, aside from making a few people feel bad?
> there was far more accountability
Do you have a source or any kind of metric for this, or is this based on gut feel?
> you're not allowed to talk about someone making a colossal mistake even if everyone knows who made the mistake
IME why are mistakes allowed to get through the codebase in the first place? The whole idea is that we should now have processes to catch and deal with these mistakes (code reviews, pull requests, automated tests, different environments). If your co-workers are cowboy coding and committing, then sure, have at them.
The free stuff in the office isn't meant just to coddle employees. At scale, perks are cheaper than higher comp. It becomes hard for smaller companies to compete on them. It also improves productivity. Free lunches mean people are back their desk within 30 minutes, instead of taking an hour to drive off-campus. If you have the profit margins to fund this stuff, and a scarcity of talent, it's a no-brainer.
There is no breach of trust if there is no expectation of privacy: we are at work, everything is logged and recorded[1] and you shouldn't be ashamed to stand by your work/words. Depositions, subpoenas, a lowly HR complaint or a curious IT drone can blow away the illusion privacy. As the saying goes: Don't write anything you dont want published in the New York Times
> Also, I'm German, where all this US "be nice and smile all the time" thing seems at best naive
Hard disagree: you don't have to smile - but you have to meet a baseline of professionalism. I had a non-American colleague who loved to criticize my work in public but requested that I send my critical feedback to him via 1:1 emails. His aggression only stopped when I continued to make all our conversations public - warts and all. Sunlight is the best disinfectant.
1. Go ahead and read your organizations electronic communications policy if you think I'm wrong.
This is only true if the branch touches things that other engineers are actively working on. Which shouldn't really happen since each team owns specific folders. If it does happen it means that the branch can be broken down to smaller deployable PRs.
> If there is an issue with a single deploy, it stops the whole company from shipping changes.
Unless the deploy is a giant monolith or the issue occurs in shared library/infra code, this shouldn't prevent shipping changes. If you are deploying microservices, if a single microservice have an issue, you can still deploy the other microservices since they can be deployed independently. (Unless of course the issue is with shared library or infrastructure code then it would affect all microservices that uses those library/code)
In the spirit of sharing What I learned at X, here's What I learned at Shazam:
Part 1: https://umaar.com/blog/lessons-learned-from-working-at-shaza...
Part 2: https://umaar.com/blog/lessons-learned-from-working-at-shaza...
Really cool that Stripe considers something other than gender or race when hiring for diversity. Every tech company I’ve worked for has a very specific definition of diversity and it was considered and weighed even before the interview.
I personally don't see the reason for fear mongering about diversity.
1. https://static.googleusercontent.com/media/diversity.google/...
Taste is highly objective, and in the professional setting that's a huge pitfall for people being in the in- or outgroup.
Track record could go either way, but I have yet to see companies that for example value steep positive progress after a downturn. Whenever track record has been mentioned at other companies, they've expected it to be monotonically increasing aka "steady performers".
Potential is notoriously difficult to judge. Aspirations are easy to BS.
Is your definition something other than what's in this report?
1. https://static.googleusercontent.com/media/about.google/en//...
Gitlab, apple, and many other companies employ this model. I'm not surprised Stripe does too.
Personally, I think autonomous teams may be slower but tend to make better decisions/create better results over the long term when compared to a sampling of DRIs.
It’s still the PMs, Eng managers, and higher ups making most of the decisions*
*At least at my current company
Honest question if your team also does this. How do you differentiate real thanks from the thanks of the week? I ask because in my experience kudos at a regular interval works for a while when it is launched but stops being effective over time, in some cases producing the opposite of intended effect.
Maybe things Just Work so long as you avoid hiring jerks, and people feel secure enough in their jobs that they don't see the need to anxiously compete with their teammates. (Some company cultures definitely go the opposite direction, favoring cold-blooded ambition over prosocial cooperation.)
If there are regular weekly kudos, it'd be a team-specific thing.
/++ were really common before a couple of years ago, but I get the vague feeling it's usage is declining. It used to report the accumulated number of pluses you got... So you could tell who have been the really helpful folks (or really tenured folks) out there, and for great contributions, you'd really want to chime in to a wave of ++s to show your appreciation.
Without the numbers, usage seems to have declined a bit, since there isn't the satisfaction of seeing a colleague's karma go up by, say, 10pts after a great presentation.
Still, it's a great culture tool, and something I'd want to spread at my next employer's if I leave the company.
We have all probably experienced working really hard on something that isn't very visible and receiving very little credit for. We have also probably experienced working on a flashy but relatively simple feature and getting lots of praise for it.
It would be a good way to quantify small things like answering questions, giving good code reviews, etc. that can go unnoticed.
I suppose the main issue with this kind of approach is cost - a powerful enough AWS instance is really expensive. But you can get beefy dedicated servers from Hetzner for 100/mo that might be a good option for smaller shops.
I find devboxes hold a few advantages over running Docker locally:
1. We can have multiple devboxes to aid switching between branches.
2. Services are more easily spun up and down as needed. If I’m only working on the API, I don’t have to waste local resources on the frontend.
3. Devboxes replicate more of the service networking (Consul) to aid debugging (versus using container networking).
The benefit of remote dev, along with standardizing on an editor, is that the company and IT department can say "here is a thing that works, use this one", instead of debugging weird issues on individual developer laptops.
If you're IT and someone comes to you and says their mouse doesn't work, do you break out the screwdriver and open it up to try and fix their mouse, or do you just give them a new one that you know works, so they can get back to work while you look into the problem later.
Local dev is great when you're at a small company and just starting out, no support, but once you're a software dev working alongside other software devs, most of whom are smarter than you, and then there's a whole other team of devs dedicated to your experience as a developer; local dev feels like a little folksy hometown sort of endeavor.
Don't get me wrong, local dev has its place, and some things like writing firmware will always want that, but the industry's moving past it for big picture reasons.
That's why having a remote VM doesn't really solve anything, there will always be employee-specific issues.
I guess it's less important when working in mostly hermetic languages/runtimes like Java. But for things with native dependencies or lots of required tooling where local setup can be a large pain, it really does help a lot.
For the dev it becomes: Install VSCode, request VM, done.
Both in the author's resume and in the article they felt the need to clarify that Stripe layoffs hit new hires primarily (... it wasn't due to their own performance).
Is this true? ~6 people I know who were hired in 2021 and 2022 are still there.
Just wondering what other services Blind now offers to employers.
Ignorance on how management processes work due to lack of exposure doesn't seem to support you hinting at there being a mismatch of aptitude.
In a previous job I would always offer "e-bux" for fixes. I was half tempted to write a quick backend to track these e-bux, but gamifying that sort of stuff has its own consequences as well...
> If there is an issue with a single deploy, it stops the whole company from shipping changes.
This definitely feels odd to me. Monorepo shouldn't mean mono-artifact! Perhaps this is more theoretical/one point, but if Stripe engineers feel this and this person felt this after less than a year... Bazel is nice y'all. (EDIT: I'm being too harsh here, CD in particular probably makes the calculus on rollouts very tricky)
I don't agree with this characterization. There is a way to 'lock' an entire repo from deploys, but it's not very frequently used. Single-service deploy blocks are common (if an autodeploy fails, or a team is aware of an issue and actively fixing it).
Stripe uses Bazel heavily.
> there was a project well underway to pull some core product / business functions into specific repos
This quote from the post is also not true to my knowledge: new repos are not allowed and teams are actively working to migrate small repos into the monorepo(s).
Depending on how it's done. I've seen similar systems where it became an additional metric to measure an engineer. Engineers became upset if they helped a coworker but did not receive any gratitude. (not receiving gratitude means that the help is not documented, so the helping engineer can't claim it during perf reviews)
At a past company we had a new lead designer come in and write a huge friction log but nothing happened because we’re already busy with tons of other higher priority stuff
This is something extremely scary when we know the data that Stripe deals with, not something I would classify as a positive.
A project in the Atlas team was considered done when a Shipped email was sent. ... It’s not uncommon for a project to begin with writing (but not sending!) the Shipped email, serving as a north star for understanding the scope and goals of a project.
This is The Correct Answer™.
Front load as much as possible. Transmute product releases from fire drills to just another boring day at the office.
Back in the day, my team's first (draft) deliverables, in rough order, would be press release, release notes, demo, installer, misc docs, .ISO image.
The press release and release notes would be socialized to all stakeholders at project kickoff. Early feedback, expectation setting.
The (scripted) demo would become "more live" as features were implemented (merged).
Our docs were part of the build process. eg Automatic screen shots. As the UI firmed up, the manuals, training material, etc. were always current (ready to ship).
Direct user feedback
Again, The Correct Answer™.
I've only experienced problems when "business analysts" fully mediate between customers and teams. Something always gets lost in translation. aka Game of Telephone.
Additionally, everyone on my teams would rotate thru every other role, over time. So (most) anyone could build the product, run meetings, do a demo, answer tech questions, etc.
This started as a way to bridge the gulf between developers and tech supp/QA/test. But it evolved into something fun, cross training, and career building. Like having a marketing person run the Go-NoGo meetings for a release, or a tech supp person running a release's post mortem.
Empowered everyone, built trust, created high emotional engagement, greatly reduced drama. Compared to our other product teams/groups.
I really really hate this idea that the most important skill about an engineer is being a good communicator. I know why people say that, but honestly, being a good communicator is the _last_ thing that makes a good engineer. The best software engineers are good at - I know this comes by a huge surprise - writing code. It's strange, but people who's job is to mainly write code also should be mainly good at writing code. In fact, people who are good at communicating tend to turn everything into discussions, debates, meetings and do very little actual work. Software developers don't need to be good communicators. They stare at a screen and need to be good at being content by solving problems by writing code. If they get happiness from that and they are fast learners then they will be good developers. Managers need to be good communicators. Team leaders who need to explain concepts to juniors or discuss architecture with others need to be good communicators, but not your regular junior/mid/senior developers. If a software engineer is a good communicator they will quickly be put into a role which will make them something that is not a software engineer anymore, so it's arguably a skill that is important for other roles and not coding.
EDIT:
Lots of people here trying to berate me on effectively what boils down to being a normal person and describing it as a "good communicator". Sure I agree with that, you have to have some basic humans skills, being able to read things, understand basic shit and being able to speak to other people like every other normal person who functions in society. I personally don't call that a "good" communicator. Just a person. Just like I don't automatically assume that if someone is not a good/great communicator that they automatically are poor communicators. By the same measure that everyone berates me here we are all good athletes if we can run 10 metres or kick a ball down the hill. Personally I set the bar slightly higher than just being normal when I describe as something to be good or great but perhaps that is just me.
That has nothing to do with communication but either with an inability to read and understand the specification which is an issue with intelligence or they have an attitude problem thinking they know everything best. None of this can be fixed by them being a good communicator, you will have the same just with a lot of extra debate.
The best engineers disappear for 1-2 days in quiet and then deliver exactly what you needed, do a bit of review/refinement with 1 or 2 other team members to tidy things up and polish the quality and then they'll pick up the next task and disappear again for a day.
The what? Sorry? If you had the specification you could just give it to the latest ChatGPT et al and it would create 90% of the code for you (just kidding, but kinda not).
No, the most important task of a software engineer is to help gathering requirements, understanding them and then translating them to code, considering internal and external constraints. Actual coding is usually the smallest part of this process. Communication may not be THE most important, but it certainly is important.
Communication is hard, and what someone communicates what they want is very rarely exactly what they actually want (or need). Sure, sometimes the stars align and you have perfect communication of exactly the needed specification and a dev who can perfectly translate that to code. But in most real world conditions you need good communication skills at both ends. Language is full of ambiguities, and it's possible to have a perfectly reasonable interpretation of something that is totally wrong.
I've worked with plenty of competent people who have had plenty of bad ideas. If I wasn't competent at communicating my issues with these ideas I would have spent many more weeks of my life on unnecessary or poorly thought out features.
I'd say that being able to read and understand what others want is part being a "good communicator", alongisde understanding reviews and comments from other devs and addressing those.
Also, good code is good at communicating what it does to future readers, via comments, variable names, and structure. And if you do that, you're being a good communicator.
I must have a different definition for the word "communication" than you. If person A writes a spec, and then person B reads the spec, isn't person A communicating with person B about the specifications?
If persons C D and E also read the spec and only person B doesn't get it, wouldn't you say person B has a communication problem?
i'm over a decade in at this point and couldn't disagree more with all of your points. nothing makes me want to run away faster than dealing with some genius who "disappears" or argues around a ton of things/has no EQ.
Stripe Atlas, to take the author's example, is in the fundamentally communication-based business of helping new companies legally incorporate. The vast majority of their technical challenges are going to sound less like "how do we write code that does X" and more like "should the code do X or Y"? So people who see only the former as "actual work" are going to have a hard time producing any value.
The way you’re characterising communication shows that you’ve been unfortunate enough to work in environments where volume of communication has been mistaken for a measure of quality. Good communication is characterised by the ability to share in the understanding of others, effective communication makes a group of people more than the sum of their parts. Effective communication leads to less communication.
I hope someday you’re fortunate enough to find yourself in a positive environment that is able to demonstrate all of this to you, because effective communication will improve your output more than any programming experience ever could.
Not being a good communicator doesn't make you a poor communicator. My point is that you don't have to be a good communicator, I never said you can be a poor communicator. Just being normal, not poor or good at communication, but just being normally capable of speaking and good at coding is better than being a great communicator with average coding skills.
But as soon as you lose one of those engineers (e.g., internal tools teams often pick up those tasks and so to build the right thing requires better than average communication skills.
I think you may be confusing a medium (speaking) with communication itself. Successful communication is as much about the choice of medium as it is what you're communicating. Communication is the method through which we extract thoughts from our own brain and share them. Code is a form of communication! You can be a fantastic speaker and a terrible communicator, likewise you can be a terrible speaker and a fantastic communicator. The right environment for you is an environment in which you're able to choose to communicate in the medium that has the best outcomes.
For example, spoken communication is my weakest form of communication and yet it has not hindered me at all, in fact, I am considered an excellent communicator by the people I work with. Sometimes, you have[1] to use a method of communication that you're not confident with, so you can develop strategies to help you communicate more effectively in that situation. When I'm speaking, I take notes in advance to flesh out my thoughts, and if I find myself struggling during a conversation, I'm honest about it and recommend next steps -- e.g: "I'm not sure about that off the top of my head, so after this call I will put together some thoughts and get back to you by the end of the day".
The people you work with benefit most when you succeed :) You're clearly a very capable communicator based on your comments here, you don't need to argue against the fundamental importance of communication, rather, you need to find an environment where you're encourage and rewarded for embracing the communication methods that work best for you.
I couldn't have spoken this comment out loud and that has zero impact on my communication ability.
[1] Dyslexia is a common example of this that I've encountered. If a colleague prefers listening to reading due to dyslexia, I will choose to speak with them because even though I'm bad at it that is the most effective means of communicating with them.
Engineers at Stripe wear many hats, depending on the project. My best example is Paper Checks. I’ve been an engineer, project manager, sales support, designer, support personnel, docs writer, and even visited lockbox facilities. I learned and did a lot on the project, and loved it. None of that happens if engineers just sit and code. We don’t get all the information about the flow of data and paper, and we build a poor product.
The same goes for internal projects. I was a DRI for a complex rewrite of our system. I regularly worked with six other teams to ship that project. That project doesn’t happen without communication.
A senior engineer should be making an impact outside of their own team and to do that you need to be an effecitve communicator.
Surely you're not measuring how good the engineer is based on number of lines of code he produces per day.
If LOC is not the metric, what is the difference between 1000 LOC written by good engineer vs 1000 LOC written by bad engineer?
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
It seems people misinterpret you as saying you don’t need any communication skill which is clearly not what you meant.
Everyone at Stripe is nice, we show gratitude, we value diversity, the founders sit at open desks and eat lunch with the employees but at the end of the day, it's all a thin facade. A thin facade masking the fact that Stripe is a company, like any other company is.
For all the talk about wellness, the founders of the most valuable private company in the US brutally fired 10% of their workforce a couple weeks ago. The Collisons did not give up their equity, they did not take a pay cut, their executives did not take a pay cut, their executives were not laid off.
People like patio11, Jeff Weinstein, the author vocally and repeatedly praise Stripe. But Stripe doesn't reciprocate their adulation. It doesn't feel the same way. They 're intelligent people, so this should be obvious, but I guess it's not.
Stripe doesn't care about them at all outside of their ability to produce for Stripe. And if they stopped producing, sure, the Collisons would give them some grace period. But then they would fire them mercilessly (as they have already done).
> Keeping team channels public helps to keep everyone on the straight and narrow in avoiding badmouthing other people or teams in the company. Shit-talking was culturally unacceptable in the team. If a private DM conversation started to go in that direction, someone would speak up to take the conversation to a public channel, and things returned to a more constructive tone.
The intention isn't bad here, but if it isn't said on Slack, it will mostly be left unsaid or will be said in closely knit groups. It's not always possible to be critical of someone on a public channel. The culture of everything must be public can easily result in perpetuating bad hires. Of course, no reason to worry if everyone is 10/10 employee, but this isn't always the case. I mean, are you suggesting that there were no mumblings of mismanagement after Stripe laid off 10% of workforce?
> The Atlas team does track date estimations, but those dates are always accompanied with a confidence level in that date. It is understood and embraced that these numbers will change over time, and changes are always communicated clearly in writing, and sometimes discussed in weekly “Ships Review” meetings.
This just becomes another field that employees have to fill, without adding any real value. Software development is simply a messy process. How can I estimate my chances of reaching the due date? It all depends on unexpected roadblocks, and the problem being more complicated that I initially estimated.
> The Atlas team also reinforces this in their Friday wrap-up meetings in a segment called “Mad Props”. The /++ feedback is collected by the meeting DRI (see below) into a meeting doc, and others from the team can add their own kudos and mad props to that section. The person doing the thanking reads or mentions their items for the team to hear in the meeting.
Again this isn't problematic, but a mechanism for gratitude isn't unique to Stripe either. In fact, I have only few companies where it wasn't there. The problem is that it quickly becomes where everyone is thanking everyone. And maybe even thanking for not the right reasons. Let's say Employee A thinks that creating lots of UML diagrams is a good quality and they thank Employee B for working that way. But I simply think it's a waste of time. Since you publicly thanked someone for that, it'll make everyone believe that's the ideal way to work. It's possible that I might be wrong, but public gratitude unintentionally signals what is valued at the company, which may or may not be in best interests of it.
For any language with explicit imports the typical hotspots are the top parts of large, shared files. Git can resolve all the mid file edits but needs a diaper change when it encounters conflicts in the header.
For example: if two people edit stripe/utils/common.py to add def f(x) and def g(y) then you’re likely to encounter a merge conflict not in the function definitions, but in any new imports each function requires. The solution is to break this file up into many smaller modules.
The same goes for any overly large bazel dependency, or common go file, etc.
As the saying goes, the only thing worse than a monorepo is two monorepos.
The culture seems to reflect with the systems created. Conway's law applies heavily here.
The friction logs also seem beneficial from a UX lens. Almost like a light version of a heuristic evaluation.
> Y Combinator, an accomplished investment fund, and startup incubator has published a list of its top 100 graduate companies ranked by valuation as of October 2019. 8 out of the 10 most valued companies in the ranking were built using Ruby on Rails.
https://spreecommerce.org/ruby-on-rails-most-popular-among-t...
I'm not entirely convinced, but my main point is that polemic based on individual experiences is wholly subjective.
You, on the other hand, are moving the goalposts.
Not to mention that a lot of the hardware costs are language-agnostic: database servers, disk volume.
You can easily reach "scale" (earn millions of dollars, serve millions of customers) while still running on 2-4 web servers.
But I've done it with Python and I can't see why Ruby would be any different.
Why is that so surprising? Nobody sane does anything CPU-intensive in their webapps.
Looking from the outside, all I can say is that both Github and especially Stripe have continued to churn out features and entire product lines well after they reached global scale…
Regarding their economics, I’d have to see a serious study proving that that the effect in infra and server costs is not only real but also non-negligible, ie, it has a real impact on the bottom line, shareholder value, company efficiency, competitiveness, or what-have-you…
The proof is in the limitations of the language. If you have a 4 CPU server and you want to run a web application, you would be able to process far more transactions per second in a Java or Go application than Ruby. This is because Ruby has a GIL which means it can't truly multithread, so to get parallelization you need to multiprocess. These days kernels can spawn threads in 5ms (or with Green threads that can be in nanoseconds), but a new process takes 50ms to spawn. Then, there's the issue of Garbage Collection pauses. Java is one of the best with some very low latency (<10ms) GCs. Ruby far from the state of the art GCs. Then there's the runtime, which Ruby can be 10-100x slower than Java or Go.
It's just a matter of this logic being scaled to big levels
Of course if we had a few billion users , diff story, but approximately no one does.
We should all be so lucky
Usually what happens at scale is that the SQL database starts slowing down as more data is loaded in. Partitioning, indexes and painful refactorings aren’t prioritized. Engineering will champion “a faster language”—that incidentally allows them a new data model where they add in proper indexes at the start. They aren’t really incentivized to realize they could see the same gains by just improving their existing data inside the Rails monolith.
Source: experience improving performance (including latency) with multi-billion-dollar Rails monoliths
This does seem to at least rhyme with twitter's experience, and maybe also github, at least as observed from outside, where a pretty innovative initial product has difficulty progressing after a period of massive scaling.
But also: Is the lesson maybe just knowing when to pivot to more efficient runtime environments? For instance, I believe facebook had a similar experience with php, and pivoted to running it on a custom vm. Did stripe wait too long to do that kind of pivot? Or perhaps you were just there in the middle of it, which is bound to be a messy time.
For my part, my intuition is that my last project, in java, seemed to be more productive than the current project in go, and another current project, in python, also seems to be working better. But there are so many variables, it's impossible to untangle causality.
Engineers love to pull out the "it doesn't scale" card with alternative language suggestions that usually align with whatever pet/fad language they've been playing with because its new and shiny (I accuse myself here as well). At some point a business is successful enough, like Stripe, where the risk of changing out an entire tech stack outweighs any perceived benefit.
For instance, just today I was asked when I could finish a task. I answered "I'm 80% confident I can deliver in two days". If I leave my confidence measurement off of that and just say "two days", it could lead others to make inflexible schedules and a delay could derail things. Giving a confidence level gives them an additional bit of information that can be very useful.
Sometimes, I've said something like "80% chance of 2 days", and the response was "what would it take to make that 90% (or whatever)." That's also very valuable, because then we can have a realistic discussion about tradeoffs/prioritization in scope or quality to gain more certain scheduling.
Anytime I'm tasked I make sure I understand exactly what's expected and when it's due. I get it in writing until we've established trust. Then I deliver.
I'll agree to work that I know, barring any unforeseen circumstances, I can accomplish in two weeks. Thirty hours. Ninety hours? Whatever it takes to complete the work.
I would ask people that were agreeing to work, that if they were comfortable quitting their job or refunding me all the contract money if they failed. Sometimes they would say yes, other times no, other times they would look at me with bewilderment. I would ask them only to take on work that they knew they could complete. Sometimes they would adjust the estimate, and I would thank them for it. Everyone wins when people hold their word. There have been times when I have had management, very upset, demanding to know why I did not complete a task. I asked them if I ever agreed to it? They would say no. And I would say then, why would you expect me to complete it?
While I do not ask for a percentage completion, I look for a binary response. We can adjust the scope, we can adjust the timeline. We cannot adjust the completion status after the deadline has elapsed.
I have agreed to work not knowing how to do it, only with the confidence that I knew I could get it done, or subcontracted out at zero gain.
As for project management tools to capture this, no. I did develop my own team tracking methods. We had a internal facing fail board. If you failed, you made a public note. This was encouraged. We fail, we learn, we do not lie. Others would ask, how did you fail? We would tell a story and we would all learn. The goal was to have less fails than days in the week.
I've never worked at a company that required this sort of thing, so I'm just trying to wrap my head around it. It seems odd to me.
> most people don't need to have their arm twisted to show a little appreciation.
Absolutely. This was the point I was trying to make -- someone expressing appreciation because they felt moved to do so means a whole lot more than someone expressing appreciation because there is a social expectation that they do so.
Maybe other similar employee review systems have a Slack integration you can turn on - it sounds like maybe it is a common feature now.
Of course, access is restricted to people whose jobs relate to the data (i.e. developers), and the data that is accessible is also controlled.
The point I was trying to make was that there is a difference from other organizations where I've worked, where access to relevant product data in the warehouse is given by default to dev teams, and is accessible both interactively (for debugging or decision making) and from batch/cron jobs.