Feedback in case anybody from stripe is tuned in: I'd love to read these stories but not 6 around the same theme all at once. Like that it will take years (at your rate of publication, 4 times per year) to cover even the basics of running a complete operation. Please consider mixing different aspects for a single issue, both in the name of variety and to cover some ground in a reasonable time.
Other than that: thanks for publishing this, I've often wondered why there isn't a central repository (like a wiki or something like that) with the various recipes you can use to tackle a given problem and what works and what doesn't in practice.
I'm willing to ride with this format. Magazines tend to be disposable except for when they have a particularly impactful in-depth piece or themed issue. This format is all themed issues with in-depth pieces. It also allows Stripe to focus resources more effectively on the supposed goal of delivering evergreen authoritative recommendations. This is something that is sorely lacking in the current environment where anything over 6-months old is often unusable.
The internet currently provides more breadth in the area than a single person could possibly need. I laud the focus on depth.
The focus on a theme reminds me of another magazine I subscribe to: Lucky Peach. Their issues focus on chicken, or pho, or power vegetables, or breakfast foods... or more abstract themes like "Versus", "Fantasy", "Gender", "Apocalypse", and "Obsession". It's high-quality content that goes narrow and deep — so I rather appreciate that Increment is going with the thematic approach.
I would expect that Increment will run less risk of burning through many important topics quickly and having their later issues tread the same ground, just shallower. We already have plenty of venues to get news about bleeding-edge developments in the tech world — HN, for instance! I wouldn't be upset if the topic of on-call weren't covered in Increment for another 2-3 years, so that the content can be more substantive and battle-tested.
yeah, I would've liked to see some more diversity in the content as well. I do like the concept though. It's nice to see companies putting resources towards efforts like this.
Agreed. I opened the page expecting to see a lot of different ideas, and instead found a topic I had little interest in repeated 6 times over. Not great for a first issue at the very least.
+1 I like the idea, the format, the style and design. The theme of dev ops and being on-call isn't interesting to me at all. The GitLab article jumped out at me but after I started reading it realized I'd heard the details already via HN when it happened. But I'll read a different topic or a variety issue.
That would be nice, as well as a 'one year in' perspective on the cultural differences between those two companies. Getting the company culture right is a lot harder than getting the tech right.
Stripe is my top design company these days. Just looking at their landing pages [1], [2], I'm deeply impressed by their effort on making the web beautiful.
Huge inspiration for me. Kudos to their front-end / design teams.
You pesky android users are always complaining about my beautifully designed pages. They look great on my iPad. There must be something wrong with your droid /s
It doesn't work on my Nexus 6 with a modified DPI to emulate a tablet, so yes, this is likely the case. I'm not sure how they missed such a major set of screen resolutions.
I've been travelling for a while in areas with slow internet and the best site for me has to be HN. No BS, it just loads and gets out of my way so I can access the content.
I'm in China atm, which is probably an area that Stripe would want to target with both atlas and connect (there's a ton of marketplace/ecommerce sellers based here, and a lot of tech innovation), and both those sites take a stupid amount of time to load.
That animation also destroys my mediocre laptop.
The pages look nice and are rich in content, but those animations and all the superfluous fonts and stuff cause them to be almost unusable if you're not on reasonably new hardware with a reasonably fast internet connection.
> probably an area that Stripe would want to target with both atlas and connect (there's a ton of marketplace/ecommerce sellers based here, and a lot of tech innovation)
Tbf, I think their target for Connect is services that would be built to target those sellers by SV brats running mid/high-end laptops, but it's a good point nontheless.
You have an expensive intel core? If you're running in battery mode, it's slow.
Real case story: I have 10 cores Xeon at work with 32 GB of memory and the highest quality of IPS screens. Same thing for designers. They will never ship an application suitable to mobile/tablets/laptop. The gap in processing between mobile, desktop, workstations and servers is tremendous.
> I've been travelling for a while in areas with slow internet and the best site for me has to be HN. No BS, it just loads and gets out of my way so I can access the content.
When you'll send a link to that new payment provider you're interested in (Stripe) to your manager/boss/coworker. He might very well open that on the move on a tablet with a 3G connection.
You're not making a good first impression if the only feedback you have is the site didn't load, and I speak from experience ;)
Both of these sites rendered BEAUTIFULLY on my phone. Honestly, I don't understand why we aren't capable of expressing appreciation for beautiful websites. I am personally so tired of the boring drudgery that most of the internet consists of. I hope to see a lot more of these alive and interesting sites in the future.
Totally agree, I actually even opened an account just for that (though haven't used it yet). Not only the landing pages, the documentation is also beautiful and totally readable.
I wonder what the trade-offs of designing like this are, if any.
As a front end dev, I once told my colleague Stripe's landing pages are absolutely delightful to look at, but I personally will not develop something similar if I had to.
Thanks Stripe for advancing the industry by generating this content. I'm impressed with how broad they interpret their mission of increasing the GDP of the internet. Their Atlas program is the best example.
Off-topic, but that about page is pretty awesome. Is that everyone who works at Stripe? If so--kudos, what a nice touch. Most start-up "About Us" pages just show smiling head shots and bios of the founder and senior execs, as if they're the only people doing anything in the company.
> It's more that if you put all of your employees up there, they start getting poached.
I hope you're joking, because that seems like a very silly reason in the age of LinkedIn and recruiter databases. It's probably very easy to find a relatively up-to-date list of employees for any given company out there.
My guess is that most small companies don't do this simply because they don't even consider that it would be a nice gesture to publicly recognize more than just the top execs.
Speaking from experience, it's actually worries about poaching, letting the competition know the size of your various teams, and possibly privacy for employees too.
You are right that with things like LinkedIn you could probably get a lot of this information, but it's enough of a hurdle that execs still think it's worth it.
Well, then this is superstition on the part of those execs. LinkedIn is the one tool that every recruiter uses. They are more likely to map out your employee network on LinkedIn than to even visit your company website at all (much less count on it for having accurate up-to-date information).
Do you have HW acceleration enabled? I found that I had to ignore the GPU blacklist[1] in order to get HW acceleration on linux. While on the same card it worked out of the box on windows.
I was surprised to see no discussion of an oncall bonus or compensation in the first issue of Increment. This is a practice which is uncommon but not rare in the industry; Google, for instance, offers generous compensation to developers with a serious oncall shift.
It would be interesting to see a discussion of this topic, but I suppose this is expected if a publication is published by a company rather than by laborers directly.
Could you go into more detail? It seems like the goal of the magazine is "practical and useful insight into what effective teams are doing."
Is there any evidence that on-call bonuses or compensation affects the quality of work that a team does? Maybe there is, but most of the research I've seen doesn't support that conclusion.
Intuitively, I suspect that a generous oncall compensation plan would mitigate a harsh rotation to a certain extent, but that engineers would still burn out eventually. But that's just my intuition, and I have only personal experience to back it up: I wanted to hear what other companies were doing, and was disappointed the topic wasn't covered in this otherwise comprehensive issue.
I think employee retention would be a much bigger concern. On-call work is very disruptive and I suspect many developers would be quite unhappy to be asked to do that without some form of compensation. Compensation seems like an extremely important topic when trying to put together an on-call program.
Coversely, you can't dump all of the on call work onto your Ops/DevOps team unless you're compensating them appropriately (or the team is large enough that on call rotations are infrequent). Otherwise, say goodbye to retention.
Compensation, even token compensation, completely changes the game when it comes to swapping or filling in for shifts. There's a HUGE difference between a coworker "doing you a favor" versus taking on paid work.
As a sort of mini-rant - with so much 'incident transparency' with Slack, Email, Dashboards, Hangouts, etc high-sev issues can devolve into all hands events if you haven't nailed the culture as well. These can be intensely political - where you got random managers/execs who haven't touched code in years in the Slack channel trying to look engaged and competent offering suggestions like, "Have we tried rolling back the release?" and the smart engineers who could actually fix the problem are afraid to do anything because everything they do is broadcasted to the entire company. It's relatively easy to adopt the tools and processes of successful tech companies but it's hard to get the culture.
Yeah, there needs to be at least an RSS feed. An email subscription is just going to get lost in my inbox and otherwise I'm never going to see when new issues come out. Once there's an RSS feed, there are a variety of services which will read the feed and send it to a Kindle.
You can go to the Reader mode on Safari and export as PDF, then email the PDF to your Kindle (enabling conversion). I did that and it looks near perfect.
However, you have to do this for each article, which takes some time.
Well... not as smooth a process, but the articles are long-ish and worthy of preservation on your Kindle.
One of the things that stuck me when reading Susan Fowler's Uber article, was just how well written it was. It gives me a lot of hope for this magazine.
Not sure what to make of this, given the redundant, monochromatic content about being on-call. It doesn't appeal to me. A magazine format is not appropriate for such a narrow focus. You're not going to gain the continuing readership without a sufficiently broad appeal.
Also, the introduction of putting down the rest of the industry while simultaneously extolling your own ideas is very off-putting, especially if we haven't heard them yet. The strength of the Stripe brand matters not; I do not know who you are.
That said, Stripe is a great company and I'd love to hear more about how they are doing things. But please, if you want me to pay attention to you, sans the hubris self-congratulatory tone.
There are multiple ways to successfully organize teams of software developers.
What matters most is that the choices are consistent and coherent.
It's nice to read about practices that work in one environment, but you have to keep in mind how they integrate in to the big picture of all of the choices.
For instance, some teams branch everywhere, for everything. Which is fine, and some people do it to great success.
Some teams develop at head, for everything. Which is fine, and some people do it to great success.
But the tools you need to build around those two approaches are totally different. Reading about the tools and techniques, without understanding how they all fit together, and trying to adopt them because they work for other people, could be a recipe for disaster.
Every company I've ever seen, including the best ones has made at least one mistake of that calibre (or much, much worse) in their history. In most cases you never heard about it because it happened early enough that hardly anybody noticed. The only reason you know about this one is because DO is large enough to be newsworthy, or you might even be a customer of theirs.
The hard part of running a start-up is to get to that point where if you fuck up enough people will notice that it makes the press.
No criticism of DO was implied and I agree every company has such issues (I locked myself out of most of the servers the other day because I deleted id_rsa instead of id_dsa and then had to walk home to get my back up drive).
> No criticism of DO was implied and I agree every company has such issues (I locked myself out of most of the servers the other day because I deleted id_rsa instead of id_dsa and then had to walk home to get my back up drive).
Netflix never pre-announced their series of extremely useful videos because they were just useful and people watched them in droves often being top results on Hacker News. Youtube + articles are nice for that sort of thing and I don't see a reason to deviate from that if the content is actually worth viewing.
That's kind of surprising because the ACM content I receive via email is usually the trends but behind the times. There are plenty of good things about ACM but I've never felt that content was a strength.
I love how Stripe does so many things that provide value to the developer community from their awesome blog posts to their open source retreats and now finally to this magazine. They're a model to me of how to earn the good will of your users through providing authentic value.
It doesn't look like any off-the-shelf magazine theme. The source code is incredibly clean and not littered with organizational elements like Wordpress might emit.
It also most likely isn't an off-the-shelf magazine theme because there's no credit to any external author of the design in either the website or the code.
Also, the source for the page is in 1 single line. Doubt any off-the-shelf theme would do that!
Nice, I'd been wishing for a "devops" book full of case studies - what situations teams were in and how they handled it. Occasionally you get an engineering blog post, but most of those are just boasting unilaterally about a solution, and not any critical discussion of the problem or the myriad of bandaids most of us have to deal with.
"The interdependent disciplines of Continuous Delivery and DevOps are of immense value to an organisation, but they are hard. We have seen Continuous Delivery and DevOps work in the wild, as have other practitioners. We want to help people on their own Continuous Delivery and DevOps journey, by sharing the experiences of those who have done it – what worked, what didn’t, and the highs and lows of trying to build quality into an organisation."
I'm really sorry for my comment. Turns out I didn't check Stripe for a while. Bitcoin is now completely supported yes, and I see support for SEPA and other payment options incoming. Great guys!
Will Stripe discuss their choice to selectively enforce their own TOS? I'm sure many start-up business would like to know how to pick and choose when they enforce their own TOS
Other than that: thanks for publishing this, I've often wondered why there isn't a central repository (like a wiki or something like that) with the various recipes you can use to tackle a given problem and what works and what doesn't in practice.