Podcast appearances and mentions of Camille Fournier

Asanka Abeysinghe, CTO at WSO2, joins host Giovanni Asproni to discuss cell-based architecture -- a style that's intended to combine application, deployment, and team architecture to help organizations respond quickly to changes in the business environment, customer requirements, or enterprise strategy. Cell-based architecture is aimed at creating scalable, modular, composable systems with effective governance mechanisms. The conversation starts by introducing the context and some vocabulary before exploring details about the main elements of the architecture and how they fit together. Finally, Asanka offers some advice on how to implement a cell-based architecture in practice. Brought to you by IEEE Computer Society and IEEE Software magazine. Related Episodes SE Radio 396: Barry O'Reilly on Antifragile Architecture SE Radio 331: Kevin Goldsmith on Architecture and Organizational Design SE Radio 263: Camille Fournier on Real-World Distributed Systems SE Radio 236: Rebecca Parsons on Evolutionary Architecture SE Radio 213: James Lewis on Microservices SE Radio 210: Stefan Tilkov on Architecture and Micro Services SE Radio 203: Leslie Lamport on Distributed Systems

How do you create an effective platform team and optimize DevOps? Tobi interviews Camille Fournier about her career, technical insights, and best practices in platform engineering. Camille shares her journey from building her own computers and installing Linux in high school to becoming Managing Director at JPMorgan Chase and authoring influential books for engineers

Today's guest is Camille Fournier! Camille is an accomplished CTO and executive with 20+ years of experience in tech, and author of the timeless The Manager's Path, possibly the most influential book ever about engineering management. With Camille we talked about good vs bad management, the controversial new founder mode, career advice for managers and her next book about platform engineering. Here is what we talked about: (02:01) Introduction (03:51) About the founder mode (11:46) Good weed, bad weeds (17:49) Finding "the formula" (21:24) Managing at different levels (28:03) The identity war (32:55) The staples of management (39:53) Having a strong opinion (43:21) Staying valuable (49:53) Keep your skills valuable (55:15) Platform engineering — This episode is brought to you by sleuth.io — You can also find this at:

Camille Fournier is the author of The Manager's Path, which many consider the definitive guide for navigating one's career path in tech. Camille was previously the CTO of Rent the Runway, VP of Technology at Goldman Sachs, Head of Platform Engineering at Two Sigma, and Global Head of Engineering and Architecture at JPMorgan Chase. She is about to release new newest book, Platform Engineering: A Guide for Technical, Product, and People Leaders. In our conversation, we discuss:• What product managers do that annoys engineers• Why major rewrites are a trap• Why you should have fewer one-on-ones• Strategies for organizing and working with platform teams• Tips for new managers• Advice for transitioning from individual contributor to manager• Much more—Brought to you by:• DX—A platform for measuring and improving developer productivity• CommandBar—AI-powered user assistance for modern products and impatient users• Coda—The all-in-one collaborative workspace—Find the transcript and show notes at: https://www.lennysnewsletter.com/p/engineering-leadership-camille-fournier—Where to find Camille Fournier:• LinkedIn: https://www.linkedin.com/in/camille-fournier-9011812/• Website: https://skamille.medium.com/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Camille's background(02:17) Common annoyances between PMs and engineers(07:09) Avoiding the telephone game(08:05) Hoarding ideas and over-engineering(09:55) The importance of involving engineers in ideation(11:37) The middle-person dilemma(14:21) Rewriting systems: a big trap?(20:40) Engineering leadership lessons(36:02) Moving from IC to management(40:32) One-on-one meetings(45:10) Pushing beyond comfort zones(45:27) Building a balanced work culture(48:01) Effective time management strategies(54:15) Advice for platform team success(01:02:42) Platform team responsibilities(01:04:43) When to form a platform team(01:07:02) Thriving on a platform team(01:12:48) AI corner(01:17:03) Lightning round and final thoughts—Referenced:• Platform Engineering: A Guide for Technical, Product, and People Leaders: https://www.amazon.com/Platform-Engineering-Technical-Product-Leaders/dp/1098153642/• The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change: https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897• 97 Things Every Engineering Manager Should Know: Collective Wisdom from the Experts: https://www.amazon.com/Things-Every-Engineering-Manager-Should/dp/1492050903• Avoiding the Rewrite Trap: https://skamille.medium.com/avoiding-the-rewrite-trap-b1283b8dd39e• Levelsio on X: https://x.com/levelsio• Pieter Levels on the Lex Fridman Podcast: https://www.youtube.com/watch?v=oFtjKbXKqbg• GraphQL: https://graphql.org/• New Blue Sun by André 3000 on Spotify: https://open.spotify.com/album/33Ek6daAL3oXyQIV1uoItD• Musk's 5 Steps to Cut Internal Bureaucracy at Tesla and SpaceX: https://icecreates.com/insight/musk-s-5-steps-to-cut-internal-bureaucracy-at-tesla-and-spacex-you-may-say-it-s-his-algorithm/• Ian Nowland on LinkedIn: https://www.linkedin.com/in/inowland/• Studio Pulls ‘Megalopolis' Trailer Using Fake Quotes from Famed Movie Critics: https://www.huffpost.com/entry/studio-pulls-megalopolis-trailer-using-fake-quotes-from-famed-movie-critics_n_66c74046e4b0f1ca469413c7• Claude 2: https://www.anthropic.com/news/claude-2• What Got You Here Won't Get You There: How Successful People Become Even More Successful: https://www.amazon.com/What-Got-Here-Wont-There/dp/1401301304• When Things Fall Apart: Heart Advice for Difficult Times: https://www.amazon.com/When-Things-Fall-Apart-Difficult/dp/1611803438• Alien: Romulus: https://www.imdb.com/title/tt18412256/• Whoop: https://www.whoop.com—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

Stephanie discovered a new book: The Staff Engineer's Path! Joël's got some D&D goodness. Together, they revisit a decade-old blog post initially published in 2013, which discussed the application of Sandi Metz's coding guidelines and whether these rules remain relevant and practiced among developers today. Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I picked up a new book from the library [laughs], which that in itself is not very new. That is [laughs] a common occurrence in my world. But it was kind of a fun coincidence that I was just walking around the aisles of what's new in nonfiction, and staring me right in the face was an O'Reilly book, The Staff Engineer's Path. And I think in the past, I've plugged The Manager's Path by Camille Fournier on the show. And in recent years, this one was published, and it's by Tanya Reilly. And it is kind of, like, the other half of a career path for software engineers moving up in seniority at those higher levels. And it has been a really interesting companion to The Manager's Path, which I had read even though I wasn't really sure I wanted to be manager [laughs]. And now I think I get that, like, accompaniment of like, okay, like, instead of walking that path, like, what does a staff plus engineer look like? And kind of learning a little bit more about that because I know it can be really vague or ambiguous or look very different at a lot of different companies. And that has been really helpful for me, kind of looking ahead a bit. I'm not too far into it yet. But I'm looking forward to reading more and bringing back some of those learnings to the show. JOËL: I feel like at the end of the year, Stephanie, you and I are probably going to have to sit down and talk through maybe your reading list for the year and, you know, maybe shout out some favorites. I think your reading list is probably significantly longer than mine. But you're constantly referencing cool books. I think that would probably be a fun, either end-of-year episode or a beginning-of-year episode for 2024. One thing that's really interesting, though, about the contrast of these two particular books you're talking about is how it really lines up with this, like, fork in the road that a lot of us have in our careers as we get more senior. You either move into more of a management role, which can be a pretty significant departure from what you have to do as a developer, or you kind of go into this, like, ultra-senior individual contributor path. But how that looks day to day can be very different from your sort of just traditional sitting down and banging out tickets. So, it's really cool there's two books looking at both of those paths. STEPHANIE: Yeah, absolutely. And I think the mission that they were going for with these books was to kind of illuminate a little bit more about that fork and that decision because, you know, it can be easy for people to maybe just default into one or the other based on what their organization wants for them without, like, fully knowing what that means. And the more senior you get, the more vague and, like, figure it out yourself [laughs] the work becomes. And it can be very daunting to kind of just be thrown into that and be like, well, I'm in this leadership position now. People are looking to me, and I have all this responsibility, but, like, what do I do? Yeah, so I'm kind of enjoying this book, that is...it's not a technical book, which is actually kind of what I like about it. It's actually more of a leadership book, which is really important for that kind of role. Even though, you know, they are still in that IC track, but it does come with a lot of leadership responsibility. JOËL: Yes, leadership in a very different way than management. But—and this may be counterintuitive for some people, especially earlier on in their careers—going further up that individual contributor track doesn't just mean getting more intense technically. It often means you've got to focus on things more like leadership, like being a bit more strategic, aligning technical initiatives with strategic goals. STEPHANIE: Yeah, and having a bigger impact and being a force multiplier, even in both the manager and, like, the staff plus role, like, that, you know, is the thing that ties the rising level. JOËL: Yeah, in many ways, maybe the individual contributor track is slightly misnamed because while, yes, you're not managing a sort of sub-organization within the company, it's still about being a force multiplier. STEPHANIE: Yeah, that's a really great point [laughs]. Maybe we'll be able to come up with a better [laughs] name for that. JOËL: I've mentioned several times on this podcast that I've been enjoying playing Dungeons & Dragons, D&D, with some friends and some colleagues. And something that was particularly fun that some friends and I did this summer is we hired a professional DM to run one shot for us. And that was just an absolutely lovely experience. Well, as a result of that, I am now subscribed to this guy's newsletter. And he'll do, like, various D&D events at different times. One thing that was really cool that I found out recently...as we're recording this, it's the week before election day in the U.S. And because a lot of voting happens in schools, typically, schools have the day off. And so, this guy sent out an email saying he was offering to run a, like, all day...effectively, a little mini-D&D camp for school-age kids on election day so that you can do your work. You can go vote, and you don't have to...basically, he'll watch your kids for you and, like, get them introduced to playing D&D, which I think is just a really cool thing to do. STEPHANIE: I love that. It's so heartwarming [laughs]. And it's such a great idea because, oftentimes, people are still working, and so they need childcare, like, on those kinds of days. And yeah, I think D&D is such a fun thing for kids to get into, too. You know, it requires so much, like, imagination, and I can imagine it's such a blast. JOËL: I got that email, and I was like, that is such a perfect idea. I love it so much. STEPHANIE: I wanted to plug my D&D recommendation. I'm pretty sure I have mentioned it on the show before. But there is a podcast that I listen to called Not Another D&D Podcast, which is, you know, a live play Dungeons & Dragons podcast campaign that's hosted by these comedians, formerly of CollegeHumor, and it's very fun. I always laugh. They have this, like, a kind of offshoot of the main show that they do called D&D Court, which is very fun. Because, as you were saying, like, you know, you hired a DM to run your game. And I know that...I'm sure lots of people have fun stories about their home games and, like, the drama that happens [laughs] with their friends. JOËL: Absolutely. Absolutely. STEPHANIE: And so, with D&D Court, listeners can write in with their drama or their conflicts and get an official ruling from the hosts about who was right [laughs] in the situation that they write in about. JOËL: So, you get to bring your best rules lawyering to the D&D Court. STEPHANIE: Yeah, exactly [laughs]. JOËL: That sounds kind of amazing. Recently, I had someone reach out to me asking about an older blog post that we'd written about the Sandi Metz Rules. This blog post was initially published in 2013, so ten years ago, and was talking about some guidelines that Sandi Metz at the time was talking about that she was using in some of her code. And we talked about how our experience was applying those to some of our work as well. And so, the question was, you know, ten years later, is that still something that thoughtbot developers like to follow in their code? We'll link to the article in the show notes. But I'll just read out the rules here real quick. So, there's four of them. The first one is a class can be no longer than 100 lines of code. The second is a method can be no longer than five lines of code. The third is pass no more than four parameters into a method, and hash options count, so no getting clever with those. And then, finally, controllers can only instantiate one object. You only get one instance variable. And views can only talk to that one instance variable. Had you or are you familiar with these rules? Is that something that you think about or use in your daily writing of code? STEPHANIE: Yeah. So, when you proposed this topic, I had to revisit these rules. And I can't recall if I had seen them before. They seemed familiar. And I've read, you know, a couple of Sandi Metz's books, so maybe those were places where she had mentioned them. But the one thing that really struck me when I was first reading the rules was how declarative they were in terms of, like, kind of just telling you what the results should be without really saying how. So, for example, the one where you said, you know, a method should not be more than five lines [laughs], I had the silly thought of, like, well, you could just, you know, stuff everything into a single line [laughs] and just completely disregard line limit if you wanted, and it would technically still follow the rule. JOËL: If they didn't want us to do that, they wouldn't give us semicolons in Ruby. STEPHANIE: Exactly [laughs]. So, that is kind of what struck me at first. Is that something you noticed? JOËL: I think what is interesting with them is that there's not always a ton of rationale given behind them. Our article talks a little bit about some of the why that might be helpful and how that might look like in practice. I'm not sure what Sandi's original...I don't know if it was one of her books or maybe on a...it might have been on a podcast appearance she talked about them, so she might go more in-depth there. But yeah, they are a little bit declarative. It's just like, hey, here's...it's almost basically the kind of thing that can be enforced by a linter, which is perhaps the point. STEPHANIE: Ooh, that's really interesting. It's like, on one hand, I like how simple they are, right? It's like, they're very obvious. If you're not following them, you can tell. But on the other hand, they seem to be more of a supplement to the gained knowledge and experience that you kind of get from knowing how to implement those rules. I think you and I will both agree that we don't want to stuff everything [laughs] into a single line with semicolons. But if someone who maybe is newer to development and is coming to these rules, I think they might be wondering, like, how do I do this? JOËL: Do you follow these rules in your own code? STEPHANIE: I think the ones that are easier to follow, for me, and that I think I've come to do more instinctually, are the rules about class line length and method line length just because I'm kind of looking out for opportunities to pull out a method or, you know, make sure that this class is just doing one thing. And if it's starting to seem to cover a couple of different responsibilities, I'm a little bit more on the lookout. But I do like these rules as like, you know, like, hey, once you hit, you know, 100 lines in a class, like, maybe that's your cue to start thinking about opportunities for extraction. JOËL: Do you sort of consciously follow these rules or have them maybe even encoded in a linter? Or is it more you're following other things, and somehow, it just lines up with these principles? STEPHANIE: I would say that, like, I'm not thinking about them very actively. But that could be a very interesting exercise, and I think, you know, that's what folks did in the blog post. They were like, hey, we took these rules, and we really kept them in mind as we were developing. But I think kind of what we were talking about earlier about, like, what we've learned or the strategies we've learned to implement kind of converge on these rules. And the rules actually are more of the result of other ideas or heuristics that we follow. JOËL: I mean, you dropped the keyword heuristics there. And I think that brings me back to an earlier episode we did where we talked about heuristics. And one of the things that came up on that episode was the idea that, oftentimes, we use heuristics as a way to sort of flatten a lot of experience and knowledge into sort of one, like, short rule, or short phrase, or something, one guideline, even though it's sort of trying to just summarize a mountain of wisdom. And so, oftentimes, you can look at something like these rules and be like, okay, well, what's the point? Or maybe you even just follow it to the letter without really thinking about the why behind it, and that can sometimes be problematic. And on the other hand, you might know all of the ideas that go behind them. And without necessarily knowing the rule itself, you just kind of happen to follow it because you're intimately familiar with all of these other software principles that converge on those same ideas. STEPHANIE: Yeah, agreed. I think that the more interesting ones to me are the no more than four method arguments and only one instance variable per controller. JOËL: Interesting. STEPHANIE: I'm curious if those are sparking anything for you [laughs]. JOËL: I think the no more than four method arguments, to me, is probably the least controversial. It's generally accepted that having many arguments to a method is a code smell. And there's a few different code smells that are related to that. There's forms of coupling incandescence; there are data clumps, things like that. I've often heard a sort of rule of three. And so, if you're going more than three, then you might want to revisit the structure of what you're building. Four is a bit of an arbitrary cut-off, I'll agree. Most of these are arbitrary cut-offs. But I think the idea to maybe keep your method to fewer arguments is generally a good thing to do. STEPHANIE: I liked that the rule points out that hash options account because I think that's maybe where people get a little more hand-wavy, or you have your ops hash [laughs] that can be just a catch-all for anything. You know, it's like, once you start putting stuff in there, I don't know, I feel like it's a like a law of the universe. It's like, oh, people will just stuff more things in there [laughs]. And it takes obviously more effort or, like, specific energy to, like, think through what those things might represent, or some alternative ways of handling those arguments. We definitely do have, I think, a couple of episodes on value objects. But that's something that we have talked a lot about before in terms of, you know, how can we take some kind of primitive data, hashes included, and turn them into a richer object that can then be passed on its own? JOËL: Right. And an options hash is generally...it's too much of a catch-all to really have an identity as its own sort of value object. It doesn't really represent any single thing. It's just everything else bag of data. One thing that's interesting that the article notes is that a lot of the helpers in Rails take a lot of arguments and that it is absolutely not worth trying to fight the framework to try to follow these rules. So, the article does take a very pragmatic approach, I think, to the idea of these rules. STEPHANIE: Yeah. And I think there is even a caveat to the rules where it's like, you can break them if you have a good reason, or if you're working with someone else and they give you the thumbs up [laughs], which I really like a lot because it almost kind of compels you to stop and be like, do I have a good reason of doing this? Just making sure, or I'll run it by a friend. And shifting that, I guess, that focus from kind of just coding from, like, your default mode of thinking to a more active one. JOËL: Right. There is a rule zero, which says you can break any of the other rules as long as you convince either your pair or your reviewer to give you a thumbs up on breaking the rule. So, you'd mentioned the fourth rule about a single instance variable in a controller kind of was one of the ones that stood out to you. What is particularly striking about that rule? STEPHANIE: I think this one is hard to follow, and I think the blog post mentions that as well. Because at least I've seen our web applications grow more and more complex. And it can be really challenging to just be like, what is this page doing? Like, what, you know, data does it need to know? And have that be the single thing. Because really, a lot of our web apps have a lot of things [laughs] that they're doing, and sometimes it feels like you have to capture more than one object or at least, like, a responsibility in this way. I think that's the one that I, you know, in my ideal world, I'm like, yeah, like, we have all these, like, perfectly RESTful routes. And, you know, we're only dealing with, you know, a single resource. But once you start to have some more complexity, I think that can be a little more challenging. JOËL: I think it's interesting that you mentioned RESTful routing because I think that is maybe one of the bigger things that does trigger having more instance variables in your controller actions. If you're following sort of the traditional Rails RESTful routes, every page is generally focused on a singular resource. Now, that may not necessarily line up with a table in your database, and that's fine. But you're dealing with a singular thing or perhaps, you know, in the case of an index page, a singular collection of things, which can be represented with a single instance variable. Once you start adding custom routes that may not be necessarily tied to a particular resource, now you can very easily kind of have a proliferation of all sorts of different things that interact with each other because you're no longer centered on a single thing. STEPHANIE: Yeah, that's true, which actually reminds me of something we've talked about before, too, when we were both reading Sustainable Rails. The author talks about custom routes and actually advocates for making all routes RESTful. And if you need a vanity URL or something like that, you can always alias it. That I liked, right? It's like, okay, even if, you know, your resource is not something that's like, ActiveRecord-backed, is there some abstraction or concept of a resource in there? And I actually did really like in the blog post in the example; that is one that I've used before, too. They were dealing with this idea of a dashboard, which I would, you know, say is pretty common in a lot of web applications these days. And it's funny because a dashboard can hold so much data, right? It's really, like, a composite of a lot of different things, you know, what is most, like, useful for the user to see in one place. But they were in the blog post. And this, again, this is kind of something that I've done before. They were able to capture that with the idea of, like, a dashboard as an object and that being codified using a presenter or a facade. JOËL: Right. So, instead of having a group, and a status, and a user, and all these, like, separate things that your page that you're showing is a sort of collection of all these different types of objects, you wrap them together in a dashboard object that's kind of a facade. And I guess that really does line up with the idea of RESTful routing because you're likely going to have a dashboard's controller show action that's showing the user's dashboard. So, it makes sense, you know, that show page is rendering a dashboard object. STEPHANIE: Can we talk a little bit about things not to do, or maybe things that might be a little more questionable [laughs], and if you've seen them and how you felt about them? JOËL: I think it is sometimes tricky to define your boundaries right in that sometimes you create a facade object that really is just...it doesn't really represent anything. It's just there to wrap around some other things. And sometimes that can be awkward. I think the dashboard works partly because it lines up so neatly with the sort of RESTful routing and thinking in terms of resources that you want to do at the controller layer. But drawing boundaries incorrectly or just trying to throw everything in some kind of grab bag object can...it's not a magic bullet, right? You've got to put some thought into the data modeling, even when you are pulling the facade pattern. STEPHANIE: Yeah, I think other things that I've seen before that could theoretically follow this rule maybe [laughs], you know, I'd love to hear your thoughts about it. When you start, you're like, oh, like, my controller action method does just, you know, set one instance variable. But it turns out that there's all these other instance variables that either through a hook or, like, in the parent controller or even in the view I've seen before, too [laughs]. And I'm just kind of curious if that kind of raises your eyebrow at all or if you've seen any good reasons for doing so. JOËL: I think setting instance variables in a view would absolutely cause me to raise an eyebrow. STEPHANIE: [laughs] Agreed. JOËL: Generally, don't put logic in the view. I think that we definitely have in parent controllers; we'll set other instance variables for things like maybe a current user, right? That's how we store that state. And I think that is totally fine to have around. Typically, we don't access that instance variable directly. We're referencing some kind of helper method. But yeah, I would not consider that a violation of the rule. I think another common one that might come up is when you have some kind of nested resource. And so, in your URL, you might have a nested resource where you're saying, "Oh, I'm looking at specifically this comment under this article or something like that." And then, you want to have access to both objects in the controller. So, I think that's a pretty common scenario where you might want to have both instance variables. Something that I'm thinking about...this is not a fully formed thought, so I'm curious about your opinions here. Is there an interesting distinction between variables in code that you want to use within a controller versus variables that you want to be accessible from a view? Because instance variables in a controller are kind of overloaded. They're a way of having state in a controller, but they're also a way of passing data into a view. And so, that sort of dual purpose there maybe causes them to be a little bit trickier to reason about than instance variables in a random Ruby object. What do you think? STEPHANIE: Yeah, I was actually having the same thought as you were going there, which is that it is kind of interesting that the view, you know, is that level of what you want to display to your user. But it can have access to, like, whatever you put in the controller [laughs], and that is...and, you know, in some ways, it's like, that connection needs to happen somewhere, right? And it's here. But I think that can definitely be abused sometimes, too. So, this, you know, fourth rule that we're talking about really has to do with a more traditional Rails app. But, again, with the complexity of web apps in 2023 [chuckles], you know, we also see Rails used just as an API a lot with a separate front-end framework. And your controller is rendering some JSON, which I think has that harder boundary between what is the data that the server is involved with and what we want to send to our client. And I'm curious if you have any thoughts about how this rule applies in that situation. JOËL: I think I tend to see not really any difference there. If I'm building an API, typically, I'm trying to do so in a pretty RESTful manner. Maybe I'm doing a GraphQL API, and things might be different for that. But for a traditional REST API, yeah, typically, you're fetching one resource or some sort of compound resource, in which case, you're representing that with a facade object. And yep, you can generally get away, I think, with a single instance variable with, you know, a few exceptions around maybe some extra context about maybe something like the current user, or a parent object, or something like that. I guess the view is really you're using a different mechanism for rendering JSON, and there are a bunch out there that the community uses. I think I don't really see a difference between rendering to HTML versus rendering to JSON, or XML, or whatever. How about you? STEPHANIE: That's a good point. I think I'm with you where the rule still applies. But I have also seen things get really loosey-goosey [laughs] when we decide we're rendering JSON, and now we're suddenly putting the instance variables into a hash along with other stuff. But what you said was interesting about, like, sometimes you do need that extra context, right? And, like, figuring out what the best way to package that requires a bit of, like, sustained thought, I think, because it can, you know, be really easy to be like, oh well, this is the one interface that I have to get data from the server. So, if I just sneak this in here [laughs], what's the matter? But yeah, I think, you know, that's probably why rules like this exist [laughs] to help provide some guardrails and make us think a little deeper about it. JOËL: I think sometimes, as a community, we maybe exaggerate the differences between, like, RESTful HTML view and a RESTful JSON API. I tend to think of them as more or less the same. We just have, you know, a different representation the V layer of our MVC framework. Everything else still kind of lines up. STEPHANIE: Yeah, that's a really good point. I actually hadn't thought about it that way. Because I think maybe I have been influenced by the world of GraphQL [laughs] a little bit, or it's kind of hard to have a foot in both worlds, where you maybe have to context switch a little bit about, like, the paradigms, and then you find them influencing you in different ways. Because I have seen sometimes, like, what maybe initially were meant to be traditional more, like, RESTful JSON APIs kind of start to turn into that, like, how do we get what we need from this endpoint? JOËL: I'm curious how you feel in general about the facade pattern. Is that something that you've used, something that you like? STEPHANIE: I think I would say that I don't actually reach for it, like, upfront, right? Usually, I'm still trying to maybe put some things in my models [laughs]. But I have used it before once; it kind of became clear that, like, a lot of the methods on the model had to do with more really server-side concerns. And I was, like, wanting to just pull out some presentational pieces. I think the hardest part with the facade pattern is naming. I have really struggled sometimes to think of, like, it's not quite the component that makes it up. So, what is it instead? JOËL: Right. Right. I think, for me, sometimes the naming goes the other way around in that I'll start more to kind of, like, routing our resource level and try to think about, okay, this particular view of the data that I want to have, or this particular operation that I want to do, what am I actually dealing with? What is the resource here? So, maybe I'm viewing a dashboard. Or maybe what I'm doing is creating or destroying a subscription, even though those are not necessarily tables in the database. And once I have that underlying concept, then I can start creating an object that represents that, which might be a combination of multiple ActiveRecord models that represent tables. STEPHANIE: Yeah. You're actually pointing out, like, a really great use case that we see a lot, I think, is when you start to have to reach for resources, you know, that are different ActiveRecord classes. And how do you combine them together to represent the idea that you want, you know, for your feature? JOËL: I think it's more of, like, an outside-facing perspective rather than an inside-facing perspective. So, instead of looking at, hey, these are the set of ActiveRecord classes I have because these are my database tables, how can I, like, tack on to them to make this operation work? I'll sort of start almost from, like, a zoomed-out perspective, blank slate to say, "Hey, this is the kind of operation that I'm trying to do. What sort of resource am I dealing with ideally?" And, you know, maybe the idea is, okay, I'm dealing with a dashboard. I'm trying to subscribe to something...a newsletter, so the idea is I'm creating a subscription. Then, from there, I can start looking at, okay, do I have the concept of a subscription in this application? Oh, I don't. There is no subscriptions table because that's not a thing that we track in our data mode. That's fine. But I probably need at least some kind of in-memory object to track the idea of a subscription, and then maybe from there, that grows. So, I'm kind of working from the problem towards the database rather than from the database out. STEPHANIE: Yeah, I like that a lot. The outside-in phrase that you used really triggered something for me, which is being product engineers, right? Like, having a seat at the table when the feature is in that, like, ideation phase, I think is also really important because that's where you really learn what that like, abstraction is at the user level. And also, it could be a really good place to give your input if the feature is being designed in a way that doesn't really support the, you know, kind of quality of code and, like, separation that you would like. That's the part that I'm still working on and still learning how to do. But sometimes, you know, it's, like, really critical to the job to, like, be in that room and be like, these designs; what are some places that we could extract it at that level even? And kind of, like, separate things out from there rather than having to deal with it [laughs] deep in your codebase. JOËL: I think what I'm really kind of hearing and emphasizing in what you just said is the importance of not just writing code but being involved in the product and how that really enriches you because you know the problem domain. And that allows you to then write the code that you need at the different levels of the app to best model the situation you're working with. So, we've kind of gone through all the rules and talked about them. I'm curious, though, for you, are these rules that you follow in your code? How closely do you adhere to this set of rules? Is this still something that's relevant to you in 2023 as much as it was to the authors of that blog post in 2013? STEPHANIE: I have to say they're not ones that I have thought about on a daily basis, but after this conversation, maybe they will be. And I am kind of excited to maybe, like, bring this up to other people on my team and be like, "What do you think about these rules?" Just, like, revisiting them as a group or just, like, having that conversation. Because I think that's, you know, where I am most interested in is, like, is wondering how other people incorporate them into their work and hearing different opinions from the team. And I think there's a lot of, like, generative discussion that ultimately leads to better code as a result. JOËL: I think for myself, I'm not following the rules directly. But a lot of my code ends up approximating those rules anyway because of other principles that I follow. So, in practice, while my code doesn't strictly follow those rules, it does look pretty close to that anyway. STEPHANIE: I almost think this could be a great, you know, discussion for your team, too, like, if any listeners want to...not quite a book club but kind of an article club, if you will [laughs], and see how other people on your team feel about it. Because I think that's kind of where there is, like, a really sweet spot in terms of learning and development. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Le Maroc endeuillé après le tremblement de terre qui vendredi soir à 23h11 locales a frappé le pays et en particulier la région de Marrakech. Depuis les premières heures samedi, l'antenne de BFMTV est quasi exclusivement consacrée à cette catastrophe, et à ses conséquences. Et nos équipes sont sur le terrain, au plus près de la population. La grande reporter Clémence Dibout, accompagnée de la JRI (journaliste reporter d'images) Camille Fournier sont les premières à être arrivées dans la zone de l'épicentre, dans des villages de montagne complétement détruits. Leurs images et leurs récits sont terribles. Dans cet épisode, elles racontent ce qu'elles voient depuis samedi, ainsi que leurs conditions de travail. 

Ever wondered what it's like to be a VP or Director of Engineering? Kendra chats with Alex Robson about leadership in technology, what you can get out of coaching or an MBA program (should you be interested), and what makes a high performing team. We'll also chat about recommended content to hone your tech leadership skills. Alex Robson's site and blog: https://robsonconsulting.services Alex's content recommendations for folks who want to think more about technical leadership: "I believe Camille Fournier and Will Larson are wonderful writers with invaluable insights and advice. For product thinking, I recommend folks read The Lean Startup by Eric Ries, Principles of Lean Product Development Flow by Don Reinertsen, Safer Sooner Happier by Jonathan Smart, and Accelerate by Dr. Nicole Forsgren. Be sure to read books on leadership that are outside of engineering. Dan Pink's Drive and Eliyahu Goldratt's The Goal are two of my usual recommendations. Last but not least - read books that are about human behavior. Both economists and psychologists ask important questions that may help you unlock better ways to relate to and understand others. I love Daniel Kahneman's Thinking Fast and Slow, and highly recommend Mistakes Were Made (but not by me) by Carol Tavins and Elliot Aronson."

Bailey and Jesse chat with Matt Kaufman, a Staff Front End Engineer at Afresh and 1608 FE Alum. They discuss love, Matt's background in control engineering, the benefits of the Turing community, mission driven companies, engineering management, staff level engineering, capitalism, performance reviews, and other topics. They mention a few books, including Managing Humans by Michael Lopp and The Manager's Path by Camille Fournier. If you or someone you know are code curious, we encourage you to attend a Turing Try Coding Event. You can register for a Try Coding class at turing.edu/try-coding.

OKRs here OKRs there. Every product team seems to have an opinion on how effective they are and their best approach to making best use of the metric model. We spoke with OKR expert Sten Pittet, to find out ways on how to get the most out of this goal setting strategy, and discuss where most product people go wrong.  Featured Links: Follow Sten on LinkedIn and Twitter | Tability | Slides from Sten's talk 'OKRs are the new Git' | 'OKRs are hard. But I still love them' feature by Camille Fournier | 'Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results' book by Christina R Wodtke | 'Measure What Matters: The Simple Idea that Drives 10X Growth' book by John Doerr

Dans la nuit de dimanche à lundi, un très violent tremblement de terre a frappé le sud de la Turquie ainsi que le nord de la Syrie. Des villes et des villages ont été complètements détruits et le séisme a provoqué la mort de plusieurs milliers de personnes. Deux équipes de BFMTV sont sur place pour décrire la situation, raconter les efforts des secours pour sauver des survivants, et recueillir les témoignages d'habitants qui en quelques secondes ont tout perdu. Couvrir une catastrophe d'une telle ampleur est un défi à la fois journalistique et logistique. Récit de deux de nos envoyés spéciaux en Turquie, Angy Louatah et Camille Fournier.  

Joël has been thinking a lot recently about array indexing. Stephanie started volunteering at the Chicago Tooele Library, a non-profit community lending library for Chicagoans to borrow tools and equipment for DIY home projects! It's the end of the year and often a time of reflection: looking back on the year and thinking about the next. Stephanie and Joël ponder if open source is a critical way to advance careers as software developers. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Chicago Tool Library (https://www.chicagotoollibrary.org/our-organization) Circulate and Ruby For Good (https://github.com/rubyforgood/circulate) Glue Work (https://noidea.dog/glue) Being the DRI of your career (https://cate.blog/2021/09/20/being-the-dri-of-your-career/) The Manager's Path (https://www.oreilly.com/library/view/the-managers-path/9781491973882/) Kingship (https://acoup.blog/2022/10/07/collections-teaching-paradox-crusader-kings-iii-part-iii-constructivisting-a-kingdom/) What technologies should I learn? (https://thoughtbot.com/blog/what-technologies-should-i-learn) Learning by Helping (https://thoughtbot.com/blog/learning-by-helping) "Comb-shaped" Careers (https://killalldefects.com/2020/02/22/specializing-vs-generalizing-careers/) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we are here to share a little bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been thinking a lot recently about array indexing. I feel like this is one of the areas where you commonly get confused as a new programmer because most languages start array indexing at zero. And what we really have here are two counting systems, either an offset so how many spaces from the beginning of the array, or a counting system where you count 1,2,3,4. At first, it feels like why would computers ever go with the offset approach? It's so illogical. Counting 1,2,3,4 would feel natural. But then, the more I think about it, the more I've started seeing the zero-based pattern show up in everyday life. One example, because I enjoy reading history, is how we talk about centuries. You might talk about the 19th century is the Victorian age, roughly. But you might also refer to the 19th century as the 1800s. So we've kind of got these two names that are a little bit off by one. And that's because when you're counting the centuries, you count first century, second century, third century, fourth century, and so on. But when we actually go by the first two digits, you start with the zeros, then the 100s, then the 200s, 300s, and so on. And so we have a zero-based counting system and a one-based counting system, and we sort of have learned to navigate both simultaneously. So that was really interesting to me to make a connection between history and programming and the fact that sometimes we count from zero, and sometimes we count from one. STEPHANIE: Yeah, I will have to admit that I always get confused when we're talking about centuries and making the mental connection that 19th century is the 1800s. It always takes me a bit of an extra second to make sure I know what I'm hearing, and I'm attributing it to the right year. I think another example where I get a bit tripped up is the numbering of floors because, in the U.S., we are counting floors using the one-based counting system, whereas I think in Europe and places outside of North America, to my knowledge, the first floor will be considered the ground floor, and then the second floor will be the first floor and onward. So that is a zero-based counting system that I can recall. JOËL: I never noticed there was a pattern. I just thought every building was arbitrary in where it counted from. STEPHANIE: Yeah, I do think it's a cultural thing. I would be really curious to know more about the history of how those counting systems get adopted. JOËL: So that's a fun thing that I've been exploring recently. What's new in your world, Stephanie? STEPHANIE: I am really excited to talk about a new real-life update. I started volunteering at the Chicago Tooele Library, which is a non-profit community lending library in my city for Chicagoans to borrow tools and equipment for DIY home projects. What I really like about it is they use a pay-what-you-can model so everyone can have access to these resources. It reduces the need for people to buy new things all the time, especially for little one-off projects. And they also provide education to empower folks to learn how to do things themselves, which I thought was really cool. And another thing that I think might be a little relevant to this audience is that I actually first encountered the Tooele library through its open-source software, which is a Ruby for Good project called Circulate. So the Tooele Library had previously been using this software that was built by community members to do all of their lending. And I got to see it in action when I saw a librarian use it to rent out tools to community members. And then I also interfaced with it myself as a member of the Tooele Library. I've borrowed things like saws, cooking appliances like air fryers that they also had. And when I was first a guest on this show, I borrowed a microphone from them to do this podcast because I was just a guest at the time and didn't want to commit to buying a whole new microphone, so that was a really awesome way that I got to benefit from it. JOËL: It's a fantastic resource for the community. STEPHANIE: Yeah, I love it so much. If anyone is in Chicago and wants to check it out, I highly recommend it. And even if you're not in Chicago, if the idea of a lending library interests you, you can check out the software on Ruby for Good. And it's no longer being used by the Chicago Tooele Library, but it would be really cool to see it be picked up by other people who might want to start something similar in their own hometowns. JOËL: So you mentioned you're volunteering here. So this means you're going in person and helping people check out items from the library. STEPHANIE: Yeah, I did my first volunteer librarian shift about a month ago, and right now, they're in the middle of moving from one location to another, so they've had a lot of in-person workdays to get some of that done. But even before that, I had contributed a little bit to the open-source repo, which is just a pretty standard Rails project, so I felt super comfortable with getting my feet wet in it. And it was, I think, my first open-source contribution. I find that some of the other open-source software, especially developer tooling, is a little scary to get into. So this was a really accessible way for me to contribute to that community, just leveraging the skills that I have for my day-to-day work. JOËL: Would you recommend this project for our listeners who are looking to maybe get their own first contribution in open source? STEPHANIE: The Circulate project is actually on a bit of a hiatus right now. But I would definitely suggest people fork it and play around with it if they want to. I also know that Ruby for Good has a bunch of other projects that are Rails apps and have real users and are having an impact that way. So if anyone wants to get into open source in a way that feels accessible and they're building a product that people are using, I definitely recommend checking that out. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: So, as we're recording this, it's the end of the year. It's often a time of reflection and looking back on the year and maybe even thinking about the next year and progression. I'm curious since you said this was your introduction to the world of open source, do you think that working on open source is a critical way to advance our careers as software developers? STEPHANIE: That's a good question. Honestly, I think my answer would be, no, it's not critical. I think it's one avenue for people to explore and increase their impact on the community and increase their technical knowledge, especially if it's in an area that they are not quite working in in their day-to-day, but they're really interested in diving deeper in. But I do think there's sometimes a lot of pressure to feel like open source is this shining beacon of opportunity for you to dive into and that it'll bring a lot of meaning to the work that you do. And people, obviously, and for a good reason, talk about how special it is that open source is part of the industry that we work in, but I don't necessarily think it's critical. I do certainly feel inspired by people who create open-source tools or contribute to Ruby or Rails. But I don't necessarily think that it's something that should be a rule and that everyone needs to get into it or contribute to it. Because there are many ways that people can have an impact having influence on the community, and that way is one. But there's also a lot of value, even just focusing on the team that you're on and your company internally. JOËL: I appreciate the nuance there because I think like you said, we often view open source as the main thing that everyone should be doing to get ahead. And there are a lot of different ways to improve your skill and then to get ahead in your career, which are not always correlated. One kind of really basic way that I was shocked at how much it helped me was I was learning a new language, Elm. I joined their online Slack community and just hung out in the chat room and answered the most beginner questions because I barely knew the language at the time. And most of these could be found just by looking up the documentation or by opening up a REPL and experimenting with a thing and giving an answer, which are skills that, as a programmer who's got some experience, I take for granted but that not everyone has that as a reflex. Because Googling, searching documentation, crafting experiments in the REPL those are all skills that you have to learn to build over time. But answering those very basic questions over and over over the course of a few months actually taught me so much about the language, and I'm not doing anything fancy. STEPHANIE: That's awesome. I have a friend who, during a time when I think she was struggling with her confidence in her technical skill and was feeling a bit stuck at work, spent an afternoon answering Stack Overflow questions on basic Ruby and Rails, and that gave her a lot of joy. Because she recognized that she was the person Googling those questions and needing to find answers many years ago, and that was one way that she could pay it forward. And I think she had a lot of empathy, like I said, for those people who are needing a little help, and it felt really good for her to be able to provide it. JOËL: It's a way to have an impact on other people while also solidifying your own knowledge. STEPHANIE: Yeah, exactly. JOËL: So we've mentioned a couple of different ways where you can level up your skills, that might be through helping out other people online, that could be through open source. But I'd like to zoom out a little bit and look at not just improving your technical skills but thinking about career in general when you're looking out over the next 10, 20, 30 years. Do you have an approach that you like to take when you're thinking that broadly? STEPHANIE: For me, I have had trouble thinking about a five or 10-year plan because things often don't turn out the way that I envisioned them. And so I think I've come to realize that leaning into how I feel about things in any given moment is more valuable and oftentimes more accurate to what I really want. Because I can have an idea of what I want my career to look like, but the things that ring most true are what I'm feeling in the moment. And so you mentioned we're releasing this episode at the end of the year. I do tend to do a little bit of recap about how my year went if I spent it doing things that fulfilled me and made me feel good, if I grew in the ways that I wanted, even separate from any performance review. I know that this is a time of reflection for a lot of people. And I don't personally ascribe to New Year's resolutions, but I do like to think about themes or intentions. And those are things that ground me rather than setting particular goals that I may or may not achieve; I may realize I want to change. So yeah, I really recommend just sitting with yourself and spending time thinking about what you want, and that could mean a promotion, but that could also mean a more interesting project using new technology. It could mean more responsibility and decision-making power. It could mean a move into management. I think it's different for everyone. And so when people have asked me about advice or what they should do in terms of coming to a crossroads between jobs or between projects, I think that you really can't tell anyone else what is the right move for them; only they can decide. JOËL: And tech, it's such a broad field. There are so many different roles and paths you can take through it. Well, there's junior engineer, engineer one, engineer two, engineer three, that's just the same everywhere. And there's only one way forward; it's up or stagnation, and that's it. Like you really get to choose your own adventure in this industry, and that's exciting and maybe a little bit terrifying. STEPHANIE: Oh yeah, for sure. I like that you brought up the different levels and roles that you could have because I have found companies that provide a career ladder or engineering ladder that has been useful for me in the past in figuring out if the next step at the company that I'm at is what I want. And it's helpful. It's very clear to me, okay, these are the skills that I need to get promoted into this next level. But other times, that description describes something that I'm not interested in, and that is also really helpful information. JOËL: Was there ever a moment in your own career where you had to navigate some of these decisions to decide what path you wanted to take as opposed to just following a ladder up? STEPHANIE: Oh yeah. I was presented opportunities to start getting a feel for management or overseeing a team as a lead. And people had really great feedback for me that that was something that I had shown leadership in, and they thought I would do a great job in that role. But I actually decided to kind of hit the brakes a little bit on that particular route because what I realized I wanted at the time was to focus more on being an IC and deepening my technical knowledge. And that was really tough. I do also think that a lot of women are pushed into management because they end up doing a lot of the glue work that comes with unblocking people, supporting people, and project management and those are all skills that, like, quote, unquote, "lend themselves towards management." But just because we do that work doesn't necessarily mean that that's the direction that we want our careers to go in. And so that was a really tough thing that I had to do was to make it really clear that I wasn't quite ready for that yet. And I might be in the future, but in that moment, just standing my ground and being like, actually, I want to focus elsewhere instead. JOËL: That's really valuable, knowing yourself and knowing where you want to go, what the next step is. Are there any exercises you like to do to try to figure that out for yourself? Because I know something that I've struggled with sometimes is not being quite sure what I want. STEPHANIE: I journal a lot in my personal life and also about work. I think I tend to revisit that in my notes, especially about things I've learned or things that I felt excited about in terms of projects and what I've been unlearning, and just going through all of the things that I've collected over the year and synthesizing that information. I also really like to lean on my friends and peers. So I really enjoy a good one-on-one when we just talk about those types of things, you know, dreams, hopes, goals. I like to lean on my manager a lot, too, because oftentimes, they're able to see things about my work over the past year that maybe I was just too in the weeds to be able to have that higher level perspective about. As a third-party observer, they see a lot of things that you might not be able to, either on your current project or even opportunities for you to step into at a higher level in the company. So yeah, I think that, in some ways, it's a solitary activity, but it doesn't always have to be. JOËL: I remember having a really good conversation with my manager as well, at some point, talking about that decision of am I interested in maybe moving into the management track? Do I want to stay on the IC side of things? And that was a really good conversation to have. STEPHANIE: So after having those conversations and kind of figuring out what direction you wanted to go, were there times when you had to actively make that choice or advocate for yourself? JOËL: Yes. One of the things that I realized that I care about is investing in other people, and sort of the mentoring, supporting side of things which you might think is kind of a management activity. But management is a little bit different than that. I prefer the coaching aspect than the management aspect. And so what I wanted to do at some point once, I realized that that's what I wanted and that a management position would not fulfill that desire, I started looking to see is there a way to craft that role within the company? A common thing that happens, I think, in workplaces is that you are given roles or titles for things that you already do. Clearly, if there's something that I care about, I needed to be doing it already in my day-to-day work, and I needed to be doing it at a fairly high level. And so I focused efforts there, trying to say I want to get better at this. I want to do this in the opportunities that I do have in my current role. And then eventually, I did go to my manager and said, "Look, this is what I am looking for in the next step." Had a discussion about whether or not management could be a fit or if we could customize a management role for this, and eventually decided that an IC role would be a better fit for that. And among other things, we introduce at thoughtbot the role of principal developer, which is kind of the next step on our career ladder. It can be a little bit different emphasis for different people on the team who have that role, but, for me, a big part of that was putting more impact on the broader team as its focus. STEPHANIE: That's really cool. I really appreciate that you were able to come to the table with what you wanted and able to have a discussion about, okay, so management might not be the right fit. But how can we create this new role that not only benefited you but also benefited the rest of the company because that hadn't been an area that they had quite figured out yet. But by doing that, you essentially did exactly the kind of coaching and making an impact [chuckles] that you had also shared you had been wanting because you just opened this new door for others to also eventually work towards. And I think that's really awesome. That reminds me a lot of the idea of being directly responsible for yourself and your career. There's a really good blog post by a woman named Cate, who is an engineering director at DuckDuckGo. I'll link it to the show notes. But she writes a lot about how you have to own your own career and find opportunities to have that agency. And you can always ask. Like, you might not get everything that you want, but by asking and by bringing it up, you at least can start the conversation rather than expecting or just hoping that things will turn out the way that you want without having said anything. A couple of things that she says in the article that I also really like is the idea of expecting less from your job and more from your career. JOËL: Hmmm. STEPHANIE: At any given point, your job might not check all of the boxes, but maybe they check some, and that is worthwhile. And once you get to a point where maybe the job is not really doing anything towards the direction you want your overall career to go, that might be time to reevaluate. And then she also mentions learning from feedback and asking for feedback, and making sure that beyond the things that you're able to identify, learning from others areas that you can work on to have a better impact on your team is also really important in progressing your career quickly. JOËL: So how is this mindset of owning your career path maybe different than the default that a lot of people might assume in our industry? It sounds like it's a much more proactive approach. We talked already about doing the work to figure out what you want out of a career, what you care about, as opposed to just being told what you should care about by others. Are there other aspects that you have to sort of own as part of owning that career? STEPHANIE: I mean, I think it's just vital to having a work experience that is fulfilling and brings you joy and doesn't bog you down. I know we all have to work, but we also all have the capacity to exercise our agency there. I know we did talk a little about management earlier, and I wanted to also plug a book, "The Manager's Path" by Camille Fournier, which is about management. But she has a really excellent first chapter about how to be managed and what you can expect from having to be an employee with a manager but also what power you have in that dynamic. She says that while you can be given opportunities and have areas of growth pointed out to you, your manager can't read your mind, and they can't tell you what will make you happy. And so I have seen a lot of people spend time worrying about if they're doing the right things to get to the next level. But oftentimes, we just haven't really talked enough about how that next level is really totally different. And there are so many routes that that could take, whether that is becoming an open-source maintainer, or producing content like blog posts or podcasts even, or speaking at conferences, or management. Once I realized that there were so many different opportunities available to me, I did feel a bit liberated because it does seem like, oh, you're just supposed to level up your technical skills until you've become this superstar coder. But that's not what everyone wants, and I think that's okay. JOËL: And, like you said, there are so many different areas where you might choose to focus or invest time into, and you don't have to do them all. You don't have to be the super prolific open-source person, and also keynoting at conferences, and also publishing the book, and also, you know, whatever you want to add in there. So once you know your goals, how do you make those goals a reality? We've been talking a lot about know yourself and have some goals. But at some point, you have to translate those goals into actions that will take you one step at a time towards those goals, and sometimes that translation step is hard. STEPHANIE: It is hard. I think this is another place where I would work with my manager on, especially if I'm on a project where I'm not quite seeing those opportunities. Like I said, usually having another perspective or another set of eyes on what you're working on can make it clear, like, specific and concrete aspects that you can spend your energy on. So if it's wanting to get better at testing, it's like, okay, what does the current test suite look like, and what are some opportunities that you can provide new value to the test suite to make an impact on the team? Or what are some refactoring opportunities you can make if you are wanting to have more of that experience outside of the regular ticketed feature work that you have to do? JOËL: I think it's interesting that you mentioned impact on the team because not only do you want to level up some skills, but if nobody knows about it, your odds of getting that promotion or getting recognized for it are very low. So not only do you have to get good at technical systems, you have to get good at social systems as well. I was recently reading an article about the role of kingship in medieval Europe and how it's very much a role that needs to play out in public in order to build legitimacy so that people will do what you say. You need to be seen to do the things that everybody has in their mental kind of checklist are things that a good king does. And some of those are somewhat divorced from the reality of what actually is effective governance. It could be various public rituals that you do that people see and are like, oh yes, you're doing this parade every year. You're looking the part of a good king; therefore, I think of you as a good king. It could be military campaigns because there are a lot of those in the Middle Ages. And there's this interesting cycle where kings that have long and effective reigns then get to influence what the next generation of kings are going to have to do in order to look legitimate because people will point back at you and be like, well, Stephanie was an effective ruler, and she did X,Y,Z. And so, in order to look the part of an effective ruler, you should be doing those same things. STEPHANIE: That's fascinating. In some ways, I struggle with the idea that you have to prove that you're, you know, doing the kingly things and worthy of that title. But I do think that there is some degree of truth to that in your career as well, where you want to make sure that the work you're doing is visible. And you also just, in general, bring up a really good idea about the importance of leadership in career progression. And I think that in my experience, and from what I've observed, that is a vital way to progress your career is to just start demonstrating leadership qualities, and that could look like reaching out to new team members and helping them with onboarding. That could mean updating the documentation, just taking the initiative, and doing that. That could also mean starting to voice more of your opinions about risks or red flags about a certain technical implementation or a project because you have amassed the experience to be able to make those decisions and put in your two cents and then making sure that the choices that are made are the right ones. JOËL: Additionally, I think even when you're doing things that are a little bit more inward-focused, like learning something new, you can generally find some kind of artifact that you can take and share more broadly with a team. So maybe you experimented with something, and you wrote up a small code example to showcase the thing that you're trying out; make a Gist on GitHub and share it with your team. If you learn something new, maybe write a blog post about it. Maybe even just start a thread in Slack and start a conversation on something that you learned recently. These can be really low effort, but I always look for opportunities to take things that I have learned, things where I'm sort of working a little bit more inwardly on myself and see how can I share that with the rest of the team? Both because it benefits the team, they get to benefit from the impact of some of what you've done but also, it helps a little bit with making sure that your work is visible. STEPHANIE: Yeah, absolutely. JOËL: So we've been talking a lot about improving ourselves technically, but there's one question that we've danced around that we haven't actually addressed, and I'm curious about your thoughts here. For someone who's early career, do you think it's more valuable to be a specialist, someone who goes all in deep on one technology and becomes great at it? Or is it better to go more broad, become a generalist, and know a little bit about a lot of things? From the point of view of what will help move my career forward. STEPHANIE: I personally do think there is an aspect of being a generalist for a little while, a few years maybe, to get a taste of what is available to you. I think that is valuable before really committing to decide, okay, like, this is what I want to specialize in. Honestly, as a generalist myself, I still do feel a bit like I don't know what I want to dive deep into and commit myself a little bit to being like, okay, I'm going to have to sacrifice learning all of these other things to really focus on this one aspect. So I have found that being a generalist also kind of gives me the flexibility to work on different projects that might require learning a new language, or at least one that I am less familiar with. And I know that that's a skill in and of itself, being able to move on to different things and gather information and the skills you need to start contributing and working effectively quickly. So, honestly, I think I can really only speak to that experience, but it has served me well and is, for the most part, enjoyable to me at this present moment. What about you? Do you have any thoughts about generalist versus specialist? JOËL: I think, in a certain sense, there's no right answer. Like we said earlier, there are multiple paths to a career in tech, and you can go through both. I think something that I've seen be less effective, especially very early career folks, is trying to go too broad, jumping on every new language or framework every couple of weeks, every month, and just dipping your toe in it and then moving on to something else and never really learning deeply, or synthesizing, or building a mental model of things. And so you're kind of stuck in the shallow end forever, and it's hard to break through into that initial level of expertise. So I think, especially very early career people, I tend to recommend pick one language or technology and focus on getting good at that and then branch out. And, of course, you're never doing everything in a vacuum because there are a bajillion dev skills you need to learn beyond a language or framework. So I often categorize three areas to focus on that I like to recommend for people; one is pick a primary language or framework and get good at it. Two, learn some evergreen skills, these are things like version control, so Git, SQL, using the command line. And these are not things that you need to master on day one because you're going to use these your entire career. So learn a few things, move on, come back to them next month, learn a few more things, and just keep coming back there every now and then over the course of your entire career to deepen those skills, and that will serve you very well. And then, finally, some random thing you're interested in. I find that I learn so much faster and so much more deeply on topics that I'm interested in or passionate about. And that interest can be very random sometimes, and it can also be fleeting. It can be, oh, I was interested in a thing for a little bit, and I dug into it, and then I moved on to something else. If I have a career or learning plan, I like to leave that room for spontaneity to say there will be things that are maybe not strategically important as my next step, but I can learn them because I'm interested in them because they bring me joy. And then later on, maybe that will actually be the foundation of something important two years down the line where I can draw on that knowledge. STEPHANIE: You bring up a really interesting point. I do think my interpretation of generalist did line up more with the idea of those evergreen skills. So I think also about debugging and testing, and those are just part of the things that you're doing every day. And that might look different from project to project depending on what language or framework you're using and what testing philosophy people on your team abide by. But yeah, those are areas that I do think investing in will serve you well across projects and help put you in a position where you can jump into anything and be like, okay, I have these core foundational beliefs and skills about this work and now, okay, let me figure out how to apply them to the task at hand. JOËL: Are you familiar with the metaphor of the T-shaped developer? STEPHANIE: I don't think so. JOËL: So the idea is that you want to balance out a broad set of skills that you're a generalist at, that you know a little bit about them with a few things that you are a deep expert in. So you have that horizontal bar, but you also have a deep area of expertise which creates a kind of a T shape. In a sense, maybe that's just trying to say, like, do both. But I was recently reading an article that was advocating for not only a T-shaped developer as a sort of starting point but then also beyond that, over the course of a long career, you have plenty of opportunities to develop more than one specialization. And so now you start having a very broad base of general knowledge as well as multiple areas that you have spent significant time becoming an expert in. And this article referred to this idea as a comb-shaped developer, and that's something you work up to over the course of years or decades in tech. STEPHANIE: That's very cool. I love the idea that you might start out as a T-shaped but what you're doing is kind of like adding to your harness of skills and it being an additive process. You'd have more teeth in your comb [laughs] rather than it replacing something or a set of skills. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

How do you shape a career you love? Why should you pursue software engineering especially if you don't want to sit behind a computer all day? Meet Victoria Kirst, an incoming software engineer at The Browser Company, former software engineer at Google for 8 years, former lecturer at Stanford, and most recently the Director of Platform and then VP of Engineering at a startup, Glitch. Victoria is passionate about software engineering and education, and in our conversation, she shares insights about her career journey to help others succeed in software engineering. In this episode, Victoria discusses what she loves about software engineering, what stops people from choosing software engineering, how to shape your career, choosing the right career, when to leave a job, how to define a startup, differences between working at a big company versus a startup, and the responsibilities of a VP of Engineering. We also talk about her new project that you can get involved in to stay on track with your learning goals: Everybody Study Club. Mentioned in This Episode: Code In Place Call for Teachers: codeinplace.stanford.edu/teach Ashley C. Ford Quote (Twitter): bit.ly/2OnJeOM "Somebody's Daughter: A Memoir" by Ashley C. Ford (preorder): amzn.to/2OmLaHg "What the Hell is a Startup Anyway" Techcrunch Article: tcrn.ch/3tkHJ2j "The Manager's Path" by Camille Fournier: bit.ly/2OxpRm9 Connect with Victoria: Twitter: @heyvrk LinkedIn: /victoriakirst Everybody Study Club: everybodystudy.club Follow Blossoming Technologist: Instagram: @blossoming_tech Twitter: @blossoming_tech LinkedIn: /blossoming-technologist Connect with Marisa: Twitter @marisahoenig LinkedIn /marisahoenig Credits: Podcast Production by Marisa Hoenig Social Media Marketing & Episode Cover Art by Lucy Zheng Podcast Logo by Kendal Goodell @goodelldesigns

En mission à Kiev Clémence Dibout, Camille Fournier et Clément Grosdenier voient, entendent et témoignent des crimes de guerre. Comment parler de cette vidéo de drone où l'on voit un civil abattu ? Ou encore cette conférence de presse où des soldats russes prisonniers se repentissent à visage découvert ? Les récits de nos reporters dans ce nouvel épisode du Service reportage.

Engineering Manager oder Team-Lead: Eine Position die sehr motivierend, aber auch abschreckend wirken kann.Was erwartet einen? Was ist die Aufgabe einer Engineering Managerin? Wie verändert sich der Arbeitsalltag? Ist die Stelle überhaupt etwas für mich? Und was passiert, wenn ich doch lieber Software Entwickeln möchte? Gibt es einen alternativen Karrierepfad?All das und noch über viel mehr Erfahrungen sprechen Andy und Wolfgang in Episode 05 vom Engineering Kiosk.Bonus: Warum Andy Muskelkater im Arsch hatFeedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKioskErwähnte ArtikelMitchell's New Role at HashiCorp: https://www.hashicorp.com/blog/mitchell-s-new-role-at-hashicorpTom Bartel mit "A Year Ago, I Stepped Away From a Leadership Position. Here Are 7 Things I Learned From That": https://www.tombartel.me/blog/leadership-position-to-individual-contributor-what-i-learned/ "What is a Staff (or Staff-Plus or Principal) Engineer?": https://mikemcquaid.com/2021/10/01/what-is-a-staff-plus-principal-engineer/ Bücher über das Engineering Management"The Managers Path" von Camille Fournier"Turn the ship around" oder "Reiß das Ruder rum!" von David Marquet"Drive" von Daniel H. Pink"Start with Why" von Simon Sinek"High Output Management" von Andrew S. Grove"An elegant puzzle" von Will LarsonSprungmarken(00:55) Hörer Feedback(01:43) Wann bist du das erste mal in eine Teamlead-Stelle gerutscht?(03:15) Kann man bereits Aufgaben eines Teamleads übernehmen, ohne ein Teamlead zu sein?(04:18) Wie viel Zeit hast du mit Hands-On und wie viel mit People Management verbracht?(04:52) Wie lang warst du Individual Contributor bevor du Teamleiter wurdest?(05:42) Was hat sich am meisten an deinem Arbeitsalltag geändert?(09:22) Was ist ein 1 on 1 Meeting und warum ist dies sinnvoll?(13:27) Was ist eine gute Teamgröße für den Start als Engineering Manager?(14:50) Woher wusstest du, was du als neuer Engineering Manager machen musst?(20:51) Empfehlungen um die Entscheidung "Möchte ich den Job einer Engineering Managerin machen?" treffen zu können(24:25) Feedback-Loop eines Software Engineers und eines Engineering Managers(25:50) Was solltest du nicht wollen, wenn du ein Engineering Manager werden möchtest?(27:42) Ist es ab und zu notwendig, seine eigene Entscheidung im Team durchzusetzen?(28:36) Schwierige Konversationen als Engineering Manager(30:49) Ist es ein Rückschritt wenn man als Engineering Manager zurück zum Software Engineer wechselt?(34:42) Wie sieht ein möglicher Karriereweg aus, wenn der Engineering Manager-Weg nichts für mich ist?HostsWolfgang Gassler (https://twitter.com/schafele)Andy Grunwald (https://twitter.com/andygrunwald)Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Interview with Camille Fournier, Managing Director and Head of Platform Engineering at Two Sigma. She talks about the role of platform teams, the most important skills for platform engineers, creating smooth communication with product teams and more! https://codingsans.com/engineering-management-newsletter?utm_source=Podcast&utm_medium=platforms (Sign up to the Level-up Engineering newsletter!) In this interview we're covering: Definition of a platform engineering team Differences between product and platform engineering Priority differences for product and platform teams Communication channels between product and platform teams Communication challenges in platform teams Necessary skills for platform engineers The time to create a platform engineering team Excerpt from the interview: "Communication works best when a product team reaches out directly to a team in the platform organization. They can communicate quickly about what they need and find a solution. The more you involve senior leadership in early stages, the slower and more complex the process can be. Sometimes you don't have a choice but to escalate the situation because the platform team you're in contact with lacks the bandwidth to address your problem. I aim to provide flexibility for my platform teams to work with their product counterparts, but it has to be balanced. If the platform team is constantly working on fulfilling one-off requests, it hurts productivity. If you see that happening, you need to figure out what the product teams are trying to do, and plan ahead to provide the necessary tooling." https://codingsans.com/blog/managing-platform-teams?utm_source=Podcast&utm_medium=platforms (Click here to read the full interview!)

About CliffCliff is an Agile Consultant and self proclaimed “computer botherer.”Links: Agile Manifesto: https://agilemanifesto.org Twitter: https://twitter.com/moonpolysoft TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part my Cribl Logstream. Cirbl Logstream is an observability pipeline that lets you collect, reduce, transform, and route machine data from anywhere, to anywhere. Simple right? As a nice bonus it not only helps you improve visibility into what the hell is going on, but also helps you save money almost by accident. Kind of like not putting a whole bunch of vowels and other letters that would be easier to spell in a company name. To learn more visit: cribl.ioCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today has done an awful lot of things over the course of his career: startup engineering; software work; founded two startups; has been an engineering manager a bunch of places; has been the CTO at UpGuard, for example; and consulted at one point on HBO's Silicon Valley. Also of note, he is now these days, a renowned Agile consultant. Cliff Moon, welcome to the show.Cliff: [laugh]. Hi, Corey. Thanks for having me.Corey: So, you and I have had energetic conversations about Agile, and based upon that context calling you an Agile consultant for enterprises is basically a deadly insult at this point. Let's get some context on that. For those who have not heard of the term because they live wonderful, blessed lives. What is Agile? A lot of people talk about it, but always the presupposition that people listening know what it is.Cliff: Yeah, that's a great place to start. So, let's go back into, sort of, prehistory. What we call Agile today is, I guess, several generations removed from the original thoughts of Agile. So, in case folks aren't aware, to kind of lay the background, there was a group of software developers, I think it might have been in 2000, might even have been earlier than that, who came up with what they call the Agile Manifesto. And I'm not going to go through a point by point, one, because I don't remember it; two, it's not germane. But—Corey: But it's called a manifesto. I mean, if you take a look at things that have been written historically that are called manifestos, very few of them are good. Like, generally ‘manifesto' sounds like something you wind up writing in a cabin somewhere, right before you wind up doing some sort of horrible crime that winds up living in infamy for 30 years.Cliff: Yeah, yeah. Manifestos, they get a bad rap for good reason. Anyway, let's not go down that [laugh] that rabbit hole. But yeah, so Agile Manifesto, right. Basically, it was this group of people, they said, “Hey, we don't think we're developing software the right way. This is unnecessarily painful. We're doing things in kind of a silly fashion. Let's refocus it around the customer. Let's do this,” yadda, yadda, yadda.And again, like you're saying, it's a manifesto; it's not very prescriptive about what to do to solve the problem, it really just points out problems and then gives a bunch of vague statements about, “Here's the things we should value,” or whatever. And so again, like we're saying, as a manifesto it kind of mutates from there, and then everyone agrees; they say, “Yep, this is the wrong way. Let's try a better way.” And down through the line, what ended up happening was a lot of people figured out that they can make money doing this, and make money being an Agile consultant, or an Agilist, if you're, [laugh] if you like that title. So, it's people who come in, and I guess, try to teach you how to do Agile the right way.And the problem is that the right way usually ends up being Scrum. And so Scrum, if we can get into that, is this idea of having a two-week sprint, you plan out the work you're going to do for that sprint, there's a bunch of meetings you have to do that are kind of mandatory: you do a stand up every day, you do a retrospective, you do sprint planning, et cetera, et cetera. And so it's this, like, cake-in-a-box, right? So, it's like a ready-made thing. And, like, ta-da, now we have Agile, we've implemented Agile, we've done this Scrum thing.The problem, of course, is that most people when they implement this—and it's certainly not the Agile consultant in most cases because they're basically there to just bake the cake, and then keep soaking hours until they're forced to leave.Corey: The problem that I had, whenever I wound up dealing with, I guess, Agile consultants in large enterprises, they always looked a lot like Agile trainers. And I don't know what they were charging because it doesn't matter what they were charging; they wound up gathering the entire engineering department in part of the building for two or three days to talk about how tickets worked, and how planning worked, and how to iterate forward, and how to wind up planning for spikes, and all the various terminology, and how to work with different tooling and the rest. And the reason didn't matter what these people cost was because it was absolutely dwarfed by the sheer cost of every engineer in the company sitting through this nonsense for the better part of a week.Cliff: Oh, absolutely. And then it's an ongoing thing, right?Corey: Well, it's supposed to be an ongoing thing.Cliff: Yeah, it's an ongoing concern. You end up having all of these meetings that you have to do every two weeks or, God forbid, every one week, or whatever the iteration speed that they've laid out is. And the thing that gets lost in the sauce here is, why are you doing this? What is the point of all of this? And I think one of my favorite things to do if I'm at a company that they're implementing Scrum, and they've got their sprints, and then we have our retrospective, one of the things I love to do is I love to touch the third wire during retrospective because that's when you're supposed to bring up, “Hey, what can we do better? What could have gone well?”And that's what I like to say, “Hey, can we just not do this?” [laugh]. And the response that I get is usually an indication of how hard of a job I'm going to have of trying to deprogram people. Because what it ends up being is that—and especially if you have an Agile consultant, and Agile teacher, whatever, they're not going to like the sound of that at all, right? It's like, “Why are we doing any of this? What is the point?”And when you dig into it, especially when we talk about Scrum, it sort of confuses a bunch of different goals that a lot of companies don't even necessarily have anymore. One of the tenets of Scrum is that every two weeks—or whatever your iteration speed is, whether it's one week, two weeks, whatever—the whole system has to be shippable. So, that means that everything has to work together correctly, and then you can ship an entire, like, vertical, or monolith, or whatever. The problem with this is that, especially related to if people are deploying to the cloud or if they're running some sort of SaaS service, this is a meaningless statement; the way that people develop software in that arena today is things get shipped immediately. The system is always shippable because the system is always up because prod is always up.And so you ship your component, everything is backwards compatible, and then your features are behind a feature flag. So, the idea that, oh, everything has to be set in stone on a two-week cycle or whatever, it doesn't mean anything anymore, unless of course, you have a physical artifact that you actually send to a customer, like a CD, or an image to download, or something. But if you're doing cloud-based software—Corey: Or a giant rocket.Cliff: Yeah. Or giant rocket, yes. Oh, God. [laugh].Corey: For some things, you always using waterfall. It's like, giant rockets going to space or—more realistically for most of us or more prosaic at least—is billing systems; people don't generally tend to iterate forward on things that charge customer credit cards. It's a lot of planning, a lot of testing, and they roll it out, and everyone's sweating bullets for a while.Cliff: Right. And I would submit that, at least in my experience, most companies which have tried to implement a Scrum-type process, what they're actually doing is they're running a two-week waterfall. Because a lot of times they've got a lot of technical debt, so the idea that you can ship things immediately might be a little bit shaky, and so what you end up doing is you have this iteration speed of, like, two weeks, and then you have to plan everything out for that, and then you have to go through testing, QA, acceptance. The whole cycle has to run in a two-week sprint. And it truly is a sprint in that case because it's too much work, it's too much stuff, and everything just falls apart. And then they wonder why they can't ship any software anymore. Well, it's because you adopted this process. [laugh].Corey: Oh, I've been in environments where we'll sit down and do quarterly or, God forbid, annual planning about what we're going to build this year, via Agile. It seems a little unlike what Agile professes to be. Now, other than the sheer aspect of hypocrisy surrounding all of this, you take it a step further and say that it in many ways causes harm.Cliff: Yeah. It causes harm in a couple of different ways. One of the ways that I think it is most harmful is the effect that it has on junior engineers, so people who are just starting their career, folks who are just coming out of college, and, you know, in most colleges, they don't really teach you software engineering processes, or software engineering practices beyond the nuts and bolts of the code, or the theory of the code, or whatever, but they don't teach you how to work in a professional environment. And so then you get a lot of folks just entering their first job, and they learn the way to do things at that job. And then they go on, they move to another job.And someone might have, you know… they might go through ten different companies in their career, maybe some more, but they learn a certain way of doing things, and then all of a sudden, it's like, “Yeah. I know how to do Agile. We did it at company X, Y, and Z.” And then they cargo-cult it and take it to the next place if they don't already have it. And so it's this sort of inculcation of younger engineers into this way of doing things that is completely harmful because most places, they don't sit you down and tell you why we're doing this because they don't necessarily know why we're doing it either.Like I said, a two-week sprint with Scrum, the system is shippable every two weeks, you have to go through testing, and yadda, yadda, yadda, this may actually make sense in some cases. And professionally, in my experience, I've designed certain processes that are similar to that. Longer timeframes, but they were designed towards both the product and the team, and, sort of, the interval that they had to ship on. But in most places I've been, no one's thinking about it from that perspective; they're not thinking, “We have to design our processes around the software, or customers, or whatever.” They just kind of do, either whatever the Agile consultant tells them or whatever they learned at the last place. And so it has this effect of replicating a cargo-cult mentality throughout the entire industry, which is sad.Corey: I've talked to a number of relatively Junior folks who have not heard of Agile or Scrum or any of these higher-level concepts about software development methodologies. They just walked into the workplace one day, and everyone's doing two-week planning sessions. I've had people ask me six months into their career, “Why is it called a sprint?” Or, “What is up with the swim-lane style things? It seems weird, but everyone I talk to is used to it. Is it this company thing, or is this an industry thing?” And, on some level, it's, “No, it's just a terrible thing [laugh] that's sort of like a mind virus that wind up taking root in an awful lot of people's minds.”Cliff: Yeah, absolutely. And so when we talk about the damage being done, I think that's the worst. When you think about new people getting into the industry, having a fresh perspective, and that perspective or having an opportunity to forge a new way to do things, that kind of gets ground out of them immediately and they have to do things this set way. And this especially goes for people who end up at large companies where it's just like, you're not going to change anything. You're going to get in there and you're going to do it their way and then that's it.In the rare case when someone comes out of college or comes out of a training program and then they go to a startup that doesn't have as much structure, those are really the only sorts of areas where you even have an opportunity to innovate in terms of the process of how we develop software. Because otherwise, it's just set in stone at this point.Corey: So, you're given a blank slate—or a blank whiteboard, as the case may be, or God forbid, a blank Jira board—how would you structure it instead? How would you advise companies to think about software development? Since I think it's pretty clear that an awful lot of what they're doing today either isn't working or is some weird bastardized hybrid of different methodologies that doesn't really have a name other than something cynical, like ScrumBut.Cliff: [laugh]. Yeah, so that's a great question. So, I think where I'll take this is, I can talk a little bit about—I mean, I've done this before, right, so I've been hired into several different startups as either, like, an engineering manager, or a director, or basically, like, hired management, and typically when a start-up hires an engineering manager or someone on that management chain, they only really do so when the pain has gotten so bad that they want to throw money at the problem. So, I specialized in that for a little bit; very thankless job, but it was interesting because what happens is that every team fails in its own unique and beautiful sort of way. [laugh].So, one of the first places where I did this, there was a person running product; he had learned his Agile methodology from being at Booz Allen Hamilton, which, I mean, it is a nightmare factory in every metric you can measure it on. But apparently, they specialize in Agile as well as the military-industrial complex, so great. [laugh]. He was running things on a one-week sprint. And it was a shippable system, so it had a cloud component but it also had a component that was forward-deployed into a customer network.So, he was running this where basically everyone would work on a one-week sprint; they would then do a bug-bash every Friday, and it was very much a case of, you keep doing the same thing and you keep getting the same results, and you keep doing it to see if you get different results. And they were very much in that kind of mode. So, they would do this every single week. You would have a bug-bash where the same bugs came up every single time; they wouldn't get fixed, no one would triage them. So, the same bug was in the system in maybe, like, 10 or 15 different tickets.No one was triaging it. And it was just a mess. And so when I got there, part of my job was to just kind of break apart this crazy structure that was happening, and again, try to design something that would actually work, again, for the product. You have to design something that has to work for how the product gets deployed. So, as I said earlier, if you have cloud services, they can deploy whenever so structuring them around some sort of timeframe doesn't really make a ton of sense.However, when you have something that gets deployed into a customer network, like an agent, or some kind of desktop software, or anything that's on machines that you do not have direct control over, you have to factor that into the speed at which you ship, you have to factor that into your engineering process. Because if you can only ship out that executable once every quarter, or—it's like, how fast can your customer actually consume these things, right? Most places, if you give them updates every two weeks, they're going to say, “What are you doing? Why are you making my life hard?” In a lot of places, the fastest—especially if you're selling to an enterprise—the fastest they can consume a forward-deployed component is once a month at the very fastest.Usually, they prefer on a quarterly or even a six-month basis. But if that's the case, you have to design your engineering process to account for that. Then the other part is that when you land in a place like this, you can't just pull the rug out from everybody immediately. It's similar to saying, “Oh, we got to do a rewrite.” It's like, well, you can't just do a rewrite of your engineering process either; you have to incrementally make changes to it so that people are not confused about what they're supposed to be doing, but you're making changes towards things running in a more smooth fashion.So, what I typically try to do is I try to design a process, and then get the team bought into it, and then hopefully get them moving faster. And the first time I tried this, it was a disaster. That was the company I was just talking about where they were running one-week sprints. I did not know what I was doing at the time; that was a very difficult situation. Landed at another place after that where this one was a two-week Scrum; similar problems around okay, frequency of testing, you have a component that gets deployed into a customer network, how fast can we deploy that?And similar sorts of problems, and so now that I could see what the pattern was, I could now develop a—I had a much better time developing a process that actually worked and helped the team ship with confidence. Which is really what you want the process to do is you want the process to be something that takes burden off of the engineering team, as opposed to something that makes your job as the engineering manager easier, which I think a lot of engineering managers approach it from that perspective of, “Oh, I can get a report at Jira and then I don't have to talk to everybody every day,” or whatever. If you're trying to make your job easier through the process, you are necessarily putting more burden onto your team.Corey: Your company might be stuck in the middle of a DevOps revolution without even realizing it. Lucky you! Does your company culture discourage risk? Are you willing to admit it? Does your team have clear responsibilities? Depends on who you ask. Are you struggling to get buy in on DevOps practices? Well, download the 2021 State of DevOps report brought to you annually by Puppet since 2011 to explore the trends and blockers keeping evolution firms stuck in the middle of their DevOps evolution. Because they fail to evolve or die like dinosaurs. The significance of organizational buy in, and oh it is significant indeed, and why team identities and interaction models matter. Not to mention weither the use of automation and the cloud translate to DevOps success. All that and more awaits you. Visit: www.puppet.com to download your copy of the report now!Corey: It feels like this is almost the early version of a similar political machination playing out where, we see it now with—there are these large companies that, once upon a time, had these big mono repos, and they had 5000 developers, and every one wound up causing problems because a group of developers is collectively referred to as a merge conflict. Then they wound up building out, “Ah, we're going to break the monolith apart into microservices and it solves that political problem super well.” And then you wind up with a bunch of startups with five engineers working there, and they have 600 microservices running in their environment, and it feels like someone took an idea outside of the context in which it was designed for and applied it to a bunch of inappropriate areas and just bred an awful lot of complexity while actively making everything worse. Please don't email me if people disagree with that statement. But it feels like an echo of that, doesn't it?Cliff: Oh, absolutely, yeah. I mean, I think a lot of this is a reflection of our relative infancy as an industry. When you think about the amount of time software engineering has been around, and has been a going concern of itself, as opposed to other engineering disciplines, I think we are still very much in our infancy. Like I was saying, they don't really teach this sort of stuff in school, and certainly not the theory behind why you would structure things this way versus that way. In fact, most people who get promoted as a manager, you get promoted from being an engineer—someone who codes all day, or codes and does design work, but basically, someone who works as an individual contributor—then you get promoted to being a manager, and very few places give you any training or education or anything at all about how do you even do this job. And so you either sink or swim.Corey: It's an orthogonal skill set that basically bears little relation to what you were doing before?Cliff: Exactly. The thing that sort of gives you any sort of ability to swim in that type of job is having the clout or the respect of your former peers as you get promoted into that. And the people who do well with that, they basically learn on the job and rely on that inbuilt respect to basically screw up a lot until they can get the hang of it. But yeah, most of the time, you don't get an education and management or any of the other things that are not just specific to people management, but people management for software engineering, which I do think is its own discipline.Corey: And some, I guess, almost borderline ridiculous level, it feels like no one really knows what they're doing when it comes to management, especially in engineering. In other disciplines, it seems that management is treated as a distinct key skill, but very often—the way my management strategy evolved—and those people think I'm kidding whatever I say this, but I assure you I'm not—it came out of looking at what my terrible managers had done in the past and what didn't work for me, and what made me quit slash become demoralized slash convince others to quit, et cetera, et cetera; or, you know, steal office supplies. Whatever it is that—how it is that you act out, and then I just did the exact opposite of those things. And I've been told repeatedly, “Wow, you're a great manager.” Not really. I just don't do all the things I hated. It gets you surprisingly far.Cliff: Well, yeah, absolutely. But that gets you far with your own reports. There's a whole other side to being a manager, which is dealing with the outside world. And then that's, especially if you're in a large organization, even in some smaller ones as well, there's a whole dimension to the job that you as an individual engineer, you don't even see.That's the politics part of the job about how do you justify what you're doing? How do you advocate for your team? How do you operate as a quote-unquote, “Shit umbrella” for your team? And all these sorts of other things where you provide a safe harbor within the company for your team to operate, and then try to procure resources and make sure that the decision-makers above you understand the importance of what you're doing. And no one teaches you how to do that.Corey: Oh, never. You're absolutely right on this. I was mostly focused on managing my reports. I completely failed in those roles managing up and, in some cases, managing sideways as well, just because that was never clear to me when I was an independent contributor working on engineering problems. It's an evolution, on some level, of figuring out what it is that the role really is.And all this stuff is not that complicated to teach people, but for some reason, culturally, we don't do it. We take the Hacker News approach to things and try and figure out complex forms of interaction from first principles. And it really feels like there are some giants upon whose shoulders we could stand.Cliff: Yeah. I mean, I agree with that. I mean, there's definitely people in the industry who've written books and who are starting to try to put down that first layer of institutional knowledge to share with other folks. You got people like Camille Fournier and other folks who've written books specifically for engineering managers who work in the software world. Which I think is a really great first step.But yeah, when it comes down to it, it's like, “Okay, we're going to implement this process; we're going to do these things; I don't know why.” It's almost like no one got fired for buying IBM; no one got fired as an engineering manager for implementing Scrum. But if you try to go and do some other weird stuff, you're running the risk of getting fired, if you fail.Corey: There is the question of whether someone at IBM will get fired for buying Red Hat, but that's not the analogy that people always fall back on for the last 25 years. I think that there's also the idea that people will try and build their own thing where it makes sense for them. In complex engineering areas, that often makes sense, and sometimes it doesn't, but then they try and approach human interaction like it's an engineering problem, and that can lead to a lot of, frankly, disastrous outcomes, on some level. I feel like this does tie into the, I guess, almost unthinking adoption of Agile and similar methodologies or perversions of those methodologies in many large enterprises. Do you see a fix for this, or is this something that we all more or less have to live with, and watch people continue to make the same mistakes for another ten years?Cliff: I think, for the most part, you have to—I guess, change starts at home. [laugh]. What I would advocate for is that if you have problems or qualms with the process that your particular organization is following, and you have ways you think you could fix it or changes that you'd want to make to it, then start advocating for those. And you'd be surprised about how far you can get sometimes with just saying, “Hey, can we just stop doing this, or can we do this a different way?” But I would also say that, like—one of the things you just said sort of knocked something loose from my mind, which is that even when companies share, like, “Oh, we've done something amazing here. We've designed this amazing new process, it really works well for us.”And they write a big blog post about it, turns out if anyone ever follows up on that, they either never did it or it was never as described. And they certainly don't do it today. So, I think a good example of this would be like when Spotify put out there—this was a number of years ago—Spotify put out their big creed about, like, “Here's how Spotify develops software.” And they had this whole bespoke thing about they've got these pods of people, and you've got a matrix management, and they reinvented a whole bunch of stuff. And then you talk to anyone who was at Spotify during that time, and they're like, “Yeah, we tried that; it didn't work.” But they still put out the blog post. So. [laugh].Corey: And I think it's still up and hasn't been taken down yet. It's, “Yeah, did this work for other people?” “No, absolutely not. But it might work for us.”Cliff: [laugh]. Yeah, it's the same kind of trick that companies do with open-source, which is you open-source something to a bunch of fanfare and try to get people to adopt it when it hasn't even been adopted internally. And anyone who tries figures out it's not the right thing, and they don't even like it. And so, but it's like, “Oh, yeah, we can open-source it and then it comes with the imprimatur of whatever company it comes from.” I mean, this is a pretty classic joke. It's like that old movie, The Gods Must Be Crazy, you throw the Coke bottle out of the plane; someone on the ground picks it up, and eventually ruins your life, even though it's just a Coke bottle. Same thing with open-source; same thing with management processes.Corey: It seems like it's going to be one of those areas that continues to evolve whether we want it to or not. Or at least I hope because the failure is, it doesn't.Cliff: Yeah, I mean, hopefully it evolves. And like I said, I would say change starts at home. Try to advocate for changes on your own team and think outside of the box; try to figure out what you can get away with and try to figure out, I guess, ways to break down the walls and the rituals that the Agile consultants have set up.Corey: Ugh. [sigh]. I hope you're right. If people want to hear more about your thoughts on these and many other matters, where can they find you?Cliff: Yeah, so typically, I'm just usually tweeting. So, my Twitter account is @moonpolysoft, and that's usually where I'm doing most of my stuff. Yeah.Corey: And we will, of course, include a link to that in the [show notes 00:25:15]. Thank you so much for taking the time to chat with me today. I really appreciate it.Cliff: Yeah, Corey. It was great, and thanks for having me.Corey: Cliff Moon: absolutely everything except an Agile consultant. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a comment that you're going to continue to iterate on and update every two weeks, like clockwork.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Le podcast qui donne la parole aux agriculteurs par Camille Fournier et Ambre Germain. Ambre et Camille mettent les bouchées doubles vers toujours plus de farfelu et de folies agricoles.Pour leur 9ème ferme, elles font étape dans le Jura, chez Émilie et Aurelien, un couple d'éleveur de chèvres, de porcs et de poules pondeuses. Mais ce n'est pas tout, ils transforment tout le lait du troupeau en fromages qui existent et qui n'existent pas. Ils confectionnent des petits frais, des bûches, des secs, demi-secs, pyramides cendrées, mais aussi des types reblochons, bleus, monts d'or, fêta, polinois, camemberts, tommes... L'innovation est le leitmotiv d'Aurelien qui invente et façonne en permanence des nouveaux fromages ! Emilie enchaine les marchés et ne cesse de surprendre les clients avec son étale bien garnie et 100% chèvres.Leurs 15 porcs valorisent le petit lait, co-produisent des fromages, et les poules fournissent des bons œufs frais plein air qui garnissent l'étale.Immergées dans leur petit mobile home, bercées par les bêlements des chèvres, les ronflements des cochons et le chant du coq, elles nous emmènent à la découverte d'une ferme pas comme les autres... « C'est simple, quand on veut faire de la qualité, il faut être dedans. On ne peut pas se dire je veux faire de la qualité et y être 1 heure par jour. »Pour en savoir plus sur La ferme des Cabrotins :https://www.la-ferme-des-cabrotins.fr/ Pour contacter Emilie et Aurélien :Par mail : contact@la-ferme-des-cabrotins.fr Pour contacter Camille Fournier et Ambre Germain :Sur le Champ

Révolution verte avec Raphaël Colicci, fondateur d'OleathermLa huitième étape d'Ambre et Camille se niche sur les hauteurs du Languedoc, la nature y foisonne, le printemps colore et pigmente progressivement les quatres coins de la ferme. Elles sont à Oleatherm, chez Babeth et Raphaël Colicci, qui ont quitté leur Bretagne et leur Italie natales pour venir s'installer ici, il y a 30 ans. Et à cette époque, ils étaient pris pour des fous, à vouloir faire pousser des oliviers et des fruitiers sur une terre rocheuse et stérile. Mais avec patience et persévérance, la biodiversité a fleuri, les arbres ont grandi, et Oleatherm est devenue une magnifique exploitation et une ferme qui soigne la Terre et l'Homme.Ce beau couple cultive oliviers, grenadiers, agrumes.. mais aussi de l'asimine, des feijoas, et d'autres noms farfelus qui doivent sonner comme du chinois pour vous, mais qui pour Raphaël représente le travail de toute une vie et un trésor inestimable.Tout leur travail est orienté vers la préservation d'une biodiversité qui soigne, l'entretien de ce merveilleux conservatoire et les soins dans leur centre de bien-être. Autant vous dire qu'ici, il fait bon vivre et qu'Ambre et Camille partagent un petit bout du rêve de ce couple inspirant. « Quand j'ai vu que les 600 premiers oliviers qui faisaient 30 centimètres ont pu subsister dans cet amas rocheux, je me suis dit qu'il y avait de l'espoir. » Pour en savoir plus sur Oléatherm :Oleatherm - Centre de bien-être - oleatherm.com  Pour contacter Babeth et Raphaël Colicci :Par e-mail : contact@oleatherm.comLa Ferme Qui Soigne Oleatherm (@la_ferme_qui_soigne) • Photos et vidéos Instagram  Pour contacter Camille Fournier et Ambre Germain :Sur le Champ

In Season 2, Episode 1 of Lead Time Chats, Jean Hsu, VP of Engineering at Range, talks to Camille Fournier, Managing Director of Two Sigma and author of The Manager's Path, about boring stuff — specifically building boring tech and making boring plans. Camille and Jean discuss: Limited innovation tokens and how to decide where to spend them (hint: it's not on cool tech)! What boring plans actually look like, especially when you do need to upgrade to more interesting tech so your team doesn't fall behind. Rolling out company-wide platform updates as rigorously as you would plan for an external launch How to manage up and build credibility that you're delivery value when undertaking long-running technical projectsAdditional Resources: The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change  Make Boring Plans by Camille FournierChoose Boring Technology by Dan McKinley

Ambre et Camille sont villageoises du Village Potager depuis bientôt 3 semaines !Il y a 3 ans, Hélène et Etienne se lançaient dans ce projet un peu fou : réunir sur un même lieu impact social, impact environnemental et rentabilité. C’est ainsi qu'est né le Village Potager, une ferme de plus de 40 hectares dont 11 destinés au maraîchage biologique, située au cœur de la forêt de Fontainebleau, à Saint pierre les Nemours. Aujourd’hui ils pilotent cette exploitation grandissante avec ses 12 maraîchers, au sein d’une équipe plus large d’une vingtaine de personnes.On le devine facilement à son nom, le Village Potager est bien plus qu’une ferme maraîchère, c’est un vrai village. Certains y habitent, d’autres y passent pour faire leurs courses, y séjournent le temps d’un week-end, de vacances, ou d’un séminaire…En ce début de printemps, nous avons enfilé nos gants et aiguisé nos sécateurs pour découvrir les plaisirs de la plantation, la récolte, le désherbage, la préparation des paniers… Mais aussi pour comprendre l’aspect innovant de cette exploitation, développée suivant le modèle d’une startup et alimentée par les expériences de management des fondateurs.« On veut arriver à démontrer au marché qu'on peut faire tourner une exploitation maraîchère rentable et avec cette mission sociale qui est de créer de l'emploi maraîcher et de créer de l'impact territorial sur le plan alimentaire. » Pour en savoir plus sur Le Village Potager :Bio, Local et Solidaire, une ferme maraîchère et des séminaires nature (levillagepotager.com)  Pour contacter Hélène et Etienne Falise :Par e-mail : bonjour@levillagepotager.comLe Village Potager (@levillagepotager) • Photos et vidéos Instagram  Pour contacter Camille Fournier et Ambre Germain :https://www.instagram.com/surlechamp2020/ 

We've been made to believe that most successful products in the techosystem were built by companies that had great engineering leadership and that is why in today's episode we invited Olaoluwa Faniyi to chat about Engineering management and leadership. In this episode, our guest shares some of the valuable lessons learned from managing engineering teams as well as some widely unspoken discussions that need to be heard more in the techosystem. You can reach out to Olaoluwa, our guest, on Twitter, @gofaniyi Follow #InsidetheTechosystem on Twitter & Instagram: (@insidethetechos) Send any questions or feedback you have to insidethetechosystem@gmail.com Follow @Cnwadiogbu and @olaoluwa_98 on Twitter Show Notes & Resources [01:31] - Olaoluwa Faniyi - https://www.linkedin.com/in/gofaniyi [13:20] - Unblocking - https://codeclimate.com/blog/how-to-unblock-engineers-and-boost-engineering-productivity [14:34] - Episode where we interviewed a Product Manager - https://anchor.fm/insidethetechosystem/episodes/Episode-12---Inside-the-Mind-of-Product-Manager-With-Seun-Daramola-eudu2g [30:36] - GoTo conferences on Youtube - https://www.youtube.com/user/GotoConferences [31:53] - Jeff Bezos, founder of Amazon - https://en.wikipedia.org/wiki/Jeff_Bezos [38:10] - Continuous delivery - https://en.wikipedia.org/wiki/Continuous_delivery [40:52] - RESILIENT MANAGEMENT by Lara Hogan - https://www.amazon.com/RESILIENT-MANAGEMENT-Lara-Hogan/dp/1937557820 [41:09] - The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier - https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897 [41:44] - Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp (Slack's CTO) - https://www.amazon.co.uk/Managing-Humans-Humorous-Software-Engineering/dp/159059844X [42:45] - Victor Asemota (Venture Capitalist) - https://www.linkedin.com/in/asemota [48:00] - Online course platforms - coursera.org, pluralsight.com, udemy.com, udacity.com, frontendmasters.com [48:52] - Performance review - https://www.bamboohr.com/hr-glossary/performance-review [50:19] - Olaoluwa's twitter & IG handle, @gofaniyi Subscribe to our newsletter: tinyletter.com/insidethetechos

Aujourd’hui, Ambre et Camille font une petite halte à Dolomieu en Isère, pour découvrir la jolie ferme laitière d’Elsa et Jérôme. Depuis quelques mois, ils ont décidé de produire eux même leurs yaourts, à la ferme. Et pour cela ils ont fait appel au concept innovant d’une jeune entreprise : Né d’une seule ferme. C’est une solution clé en main pour la transformation de produits laitiers, de la fabrication à la vente. Et cela a piqué notre curiosité, donc on a fait un petit crochet pour aller à leur rencontre…« On est juste là pour produire, transformer notre bon lait en yaourt et c’est eux qui gèrent tout le reste. » Pour en savoir plus sur la ferme des Bergeronnettes :Ferme des Bergeronnettes, https://www.facebook.com/Gaec-des-bergeronettesPour en savoir plus sur Né d'une seule ferme :Né d'une seule ferme, https://neduneseuleferme.fr/Pour contacter Né d'une seule ferme :Sur Instagram : https://www.instagram.com/_nusfSur LinkedIn : https://www.linkedin.com/company/nusfPour contacter Camille Fournier et Ambre Germain :https://www.instagram.com/surlechamp2020/Pour découvrir l'origine du podcast Sur le Champ :https://businessofbouffe.com/podcast/sur-le-champ 

Setting your sights high for a career in engineering management might be an appealing endeavor, but it also means that you will be making a lot of assumptions about future roles without really knowing what those roles are truly about. In this episode, I sit down with Camille Fournier - a veteran CTO, speaker, and entrepreneur, to learn more about ways to map out the path to becoming a CTO (or not).

Bienvenue à l’Abbaye de Boulaur (@abbayedeboulaur), une abbaye de sœurs cisterciennes fondée en 1949 dans le Gers. Bien plus qu’une ferme, l’abbaye de Boulaur est un lieu unique où se rencontrent agriculture et spiritualité, travail et prière, terre et ciel.Ambre et Camille sont allées à la rencontre de cette communauté, constituée de 31 sœurs, entre 25 et 94 ans, au sein de laquelle règne un bel équilibre entre retour à la terre et tradition monastique. Fidèles à la règle de Saint Benoît, nos journées sont bien remplies, rythmées par les 7 offices et le travail agricole. Puis le soir “complies et au lit !”L’objectif de la communauté est de tendre vers une autosuffisance, c’est pourquoi à Boulaur, on trouve des vaches, des poules, un potager, un verger, une fromagerie, une meunerie… et bientôt les cochons feront leur grand retour ! Le magasin de l’abbaye, lieu de rencontres et de partage, propose une palette de produits, confectionnés par leurs soins, allant de la confiture à la farine en passant par le pâté.Nous découvrons chaque jour cette symbiose moniale, harmonieuse et fructueuse. Nous apprenons à prendre le temps, à privilégier le beau au rapide, la fécondité à l’efficacité, le durable à l'instantané. Ici, à Boulaur, on construit pour la vie, on cultive la vie et on célèbre la vie.« Être en contact avec la création, et avec les créatures, les bêtes, les animaux, nous aide à être en louange avec le créateur. Tout ça n’existe que parce que ça nous est donné. » Pour en savoir plus sur l'abbaye de Boulaur :Abbaye de Boulaur, https://www.boulaur.org/Pour contacter les sœurs cisterciennes :Par e-mail : contact-web@boulaur.orgSur Instagram : https://www.instagram.com/abbayedeboulaur/Pour contacter Camille Fournier et Ambre Germain :https://www.instagram.com/surlechamp2020/Pour découvrir l'origine du podcast Sur le Champ :https://businessofbouffe.com/podcast/sur-le-champ

In this week’s show, Phil talks to Camille Fournier, an engineering executive, author of the books “The Manager’s Path” and “97 Things Every Engineering Manager Should Know.” She began her career with Microsoft in 2001 as a Software Design Engineer and by 2014 had been appointed Chief Technology Officer of Rent the Runway. She is now the Managing Director of Two Sigma, with responsibility for management and strategy. Camille talks about the value in becoming comfortable with the uncomfortable tasks that can energise our career paths. She also discusses why setting the right goals will lead to a more balanced life. Show notes can be found at https://itcareerenergizer.com/e291

Ambre et Camille vous emmènent au cœur de l’innovation, dans une ferme pilote de 1 600m2, fondée par Félix Haget, un expert en aquaponie, et son équipe de choc.L’aquaponie est un système qui unit la culture de plantes et l’élevage de poissons. Elle s’organise autour de 3 compartiments : un élevage de poissons, un élevage bactérien et des cultures végétales. Ils forment ainsi un cercle vertueux : les poissons vont générer des nutriments dans l’eau, qui vont être convertis par les bactéries pour les rendre assimilables par les plantes. Concrètement sur la ferme d’Eauzons, on développe un élevage de saumons de fontaine, relié à la culture de salades, fraises, tomates, poivrons, piments…., le tout vendu en circuits très très courts. Et l'avantage avec une culture en hors sol c’est que qu’on peut l’implanter n’importe où, même en ville, dans des zones industrielles ou sur des sols pollués. Pour en savoir plus sur Eauzons :Eauzons, http://eauzons.com/ Pour contacter notre invité :Félix Haget, https://www.linkedin.com/in/felix-haget-aquaponics-expert/ Pour contacter Camille Fournier et Ambre Germain :https://www.instagram.com/surlechamp2020/ Pour découvrir l'origine du podcast Sur le Champ :https://businessofbouffe.com/podcast/sur-le-champ 

How do you shape a career you love? Why should you pursue software engineering especially if you don't want to sit behind a computer all day? Meet Victoria Kirst, an incoming software engineer at The Browser Company, former software engineer at Google for 8 years, former lecturer at Stanford, and most recently the Director of Platform and then VP of Engineering at a startup, Glitch. Victoria is passionate about software engineering and education, and in our conversation, she shares insights about her career journey to help others succeed in software engineering. In this episode, Victoria discusses what she loves about software engineering, what stops people from choosing software engineering, how to shape your career, choosing the right career, when to leave a job, how to define a startup, differences between working at a big company versus a startup, and the responsibilities of a VP of Engineering. We also talk about her new project that you can get involved in to stay on track with your learning goals: Everybody Study Club. Mentioned in This Episode: Code In Place Call for Teachers: codeinplace.stanford.edu/teach Ashley C. Ford Quote (Twitter): bit.ly/2OnJeOM "Somebody's Daughter: A Memoir" by Ashley C. Ford (preorder): amzn.to/2OmLaHg "What the Hell is a Startup Anyway" Techcrunch Article: tcrn.ch/3tkHJ2j "The Manager's Path" by Camille Fournier: bit.ly/2OxpRm9 Connect with Victoria: Twitter: @heyvrk LinkedIn: /victoriakirst Everybody Study Club: everybodystudy.club Follow Blossoming Technologist: Instagram: @blossomingtechnologist Twitter: @blssmngtchnlgst LinkedIn: /blossoming-technologist --- Support this podcast: https://anchor.fm/blossoming-technologist/support

En este episodio hablamos con Natalia Bernarte, Engineering Manager en Grafana Labs, SCRUM Master y Frontend Developer, que viene a resolvernos todas nuestras dudas sobre la metodología de los OKRs, pros y contras, qué hace una Engineering Manager en su día a día y qué tenemos que hacer si queremos convertirnos también en una. Los libros que recomendamos durante el episodio son: The Manager's Path, de Camille Fournier. The Making of a Manager, de Julie Zhuo. Si te ha gustado, quieres añadir algo, o compartir una duda, coméntanos en twitter @techandladies ¡Nos encantará leerte!

Short Byte: Camille Fournier - Managing a product focused engineering orgCamille Fournier is perhaps best known for her amazing book “the managers path” - a guide for tech leaders navigating growth and change. But she also has a degree from Carnegie Mellon, was a VP at Goldman Sachs, and then was the CTO at Rent The Runway before eventually returning to the finance world as Head of Platform Engineering at Two Sigma.  Today she discusses her experiences in managing a product focused engineering org.Thank you to our friends at Carbon Five for sponsoring today’s episode. For over 20 years, Carbon Five has helped businesses build, launch and scale digital products and teams. They’ve helped brands like Signal, Masterclass, Stitch Fix, Chime, and more, design and develop some of the most successful apps and platforms on the market today. So whether you’re looking to build your first app, fix a broken development process, or to scale your successful engineering team — the folks at Carbon Five are ready to help. Visit carbonfive.com/ctoconnection for special access to free product development guides and technical team resources.”

Vendredi 19 février 2021, SMART TECH reçoit Sylvestre Maurice (Astrophysicien, CNES) , Francis Rocard (Responsable du programme d'exploration du Système solaire, CNES) , Didier Schmitt (Responsable exploration robotique et humaine, Agence spatiale européenne) et Camille Fournier (étudiante, aspirante astronaute)

Nous vous emmenons sur le plateau du Larzac, à Saint Maurice Navacelles pour être exact grâce à Ambre et Camille. On peut se demander qu’est ce qu’on vient faire ici ou plutôt qui on vient rencontrer ? Et bien, cela fait maintenant 4 semaines que nous partageons le quotidien de Nicolas Brahic, un sacré personnage. Sur le plateau du Larzac, pas grand chose ne pousse, les grands espaces broussailleux et inoccupés offrent un cadre propice à l’élevage extensif. C’est pourquoi Nicolas s’est installé ici avec son troupeau de cochons et de brebis, élevés en plein air toute l’année et quasiment sauvages. Il a reçu plusieurs distinctions pour sa viande de porc, produit d’exception prisé par les plus grands chefs.Mais Nicolas ne s’est pas arrêté la ; désormais il se concentre sur une autre mission, de la plus haute importance : faire revivre les sols. Pour cela il a fondé Buxor, une entreprise qui valorise la broussaille de buis au service des sols vivants. La mission de Buxor c'est d'accélérer le processus à l'œuvre dans un sol forestier en utilisant de la broussailles de buis, qui, en se décomposant crée un humus riche. Celui-ci permet de restructurer le sol et favoriser le foisonnement de vies de donc de nutriments. Pour ce faire, l'équipe Buxor fourmille d'idées et leur ingéniosité se concrétise par la conception de machines du futur facilitant la récolte et le broyage du buis.Vous l'aurez compris, ce sujet est aussi complexe que passionnant, nous vous laissons le découvrir à travers cet entretien mêlant technique, philosophique, et humain.« La priorité c'est de faire comprendre aux agriculteurs qu'il faut qu'ils génèrent du sol. » Pour en savoir plus sur Terres Libres et Buxor :Terres Libres, http://www.terres-libres.fr/Buxor, https://www.buxor.fr/ Pour contacter Nicolas Brahic :Nicolas Brahic, https://www.linkedin.com/in/nicolas-brahic Pour contacter Camille Fournier et Ambre Germain :https://www.instagram.com/surlechamp2020/ Pour découvrir l'origine du podcast Sur le Champ :https://businessofbouffe.com/podcast/sur-le-champ 

Camille joins us on Develomentor to talk about her path in technology. She offers incredible insight to anyone navigating the world of technology with an engineering background, especially those looking to manage and lead. Camille was on the fast track to becoming a booming success in technology - she graduated from a prestigious university with a shiny master's degree and had experience working for a major company. But instead of looking for a cutting edge tech company, Camille chose to work for Goldman Sachs. Paradoxically, she attributes this decision to saving her career in tech. After succeeding at Goldman Sachs, Camille joined a startup ‘Rent The Runway’ where she learned to manage and lead people. After wearing many hats in the organization, Camille became the CTO. But the startup life came with a cost, and Camille found herself overworked and drained. Instead of jumping into another job, Camille took some time to reflect and eventually decided to write her first book ‘The Manager’s Path’. The book offers practical advice to technical managers solving problems in the real world. It was a success, and not only for managers, but also, somewhat surprisingly, for younger employees interested in management. Camille currently works as the head of platform engineering at Two Sigma, a tech hedge-fund. For full episode show notes click hereCONNECT WITH CAMILLE FOURNIER HERELinkedinWebsiteCONNECT WITH GRANT INGERSOLL HERELinkedInTwitterSupport the show (https://www.patreon.com/develomentor)

¿Qué deberíamos esperar de un manager? En este podcast hablaremos y desarrollaremos los 3 puntos fundamentales que debemos esperar de un manager, ya sea de ingeniería o de cualquier sector.Este podcast es el primero de una serie de episodios en los que hablaré sobre el libro The Manager's Path, de Camille Fournier: https://amzn.to/3iCoJZ0

¿Qué deberíamos esperar de un manager? En este podcast hablaremos y desarrollaremos los 3 puntos fundamentales que debemos esperar de un manager, ya sea de ingeniería o de cualquier sector. Este podcast es el primero de una serie de episodios en los que hablaré sobre el libro The Manager's Path, de Camille Fournier: https://amzn.to/3iCoJZ0

En este episodio nos encontramos con Guido Marucci Blas, ingeniero informático del ITBA y co-fundador y CTO de Wolox, una empresa que crea productos digitales que ayuda a distintas empresas a conducir procesos de transformación digital. Wolox hoy cuenta con más de 300 colaboradores y con oficinas en Argentina, Chile, Colombia, México y Estados Unidos. Guido va a compartir como el libro "The manager's path", de Camille Fournier, lo ayudó a tener perspectiva, estructurar el equipo de Wolox, y escalar el equipo de ingeniería. Un episodio especialmente recomendado para cualquier ingeniero, diseñador o gerente.

For Christmas week 2020, we have a special treat for you. Yves Hanoulle and I interview great Agilists and Scrum Masters that you will probably not hear from in your local Agile conference.  These are people that are really pushing the state of the practice, and we want to bring their forward-looking, and hopeful ideas to you in our Christmas Special Week for 2020.    Katrina is the author of A Practical Guide to Testing in DevOps, a book that offers direction and advice relevant to anyone involved in testing in a DevOps environment.   She started her Agile transition after a long stint within a waterfall organization, and she shares some of the most contrasting changes she experienced when moving to an Agile organization. Ultimately, she reminds us, the Agile approach is much closer to the final purpose: solving a problem for a customer out there. And she reminds us that we should try to keep that purpose front and center at all times.  Learning to be persuasive: a key lesson for Scrum Masters and all agile practitioners When we dive into Katrina’s most important lesson learned in her Agile journey, we discuss the need to bring our best persuasive game with us. We discuss some of the reasons why the ability to persuade others is so important, for example testers will often be outnumbered in an Agile team, and their ideas are less likely to be followed if they can’t “bring others along”. In this segment, we refer to a key book for all wanting to learn more about influencing colleagues and building collaborative relationships: How To Win Friends And Influence People by Dale Carnegie. Books for Agilists and Agile leaders The books that Katrina chose to recommend remind us that often we need to express our leadership abilities, and we can do that only if we cultivate those through reading and practice. We talk about Lara Hogan’s Resilient Management, The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier, and Accelerate by Nicole Forsgren et al.    About Katrina Clokie Katrina is an accomplished and experienced IT leader. She is a regular keynote at international conferences where the main themes include leadership, knowledge sharing, and communicating change. In 2017 Katrina published her first book, A Practical Guide to Testing in DevOps. Katrina was a finalist for the Inspiring Individual of the Year Award at the 2018 New Zealand Hi-Tech Awards. You can link with Katrina Clokie on LinkedIn and connect with Katrina Clokie on Twitter.

We talk a lot about quantitative trading on the podcast, but typically from a rather big picture perspective, and not at the level of actually building the systems needed for trading and data analysis. On this episode, we speak with Camille Fournier, the head of Platform Engineering at Two Sigma, the financial services firm that, among other things, runs a large hedge fund. Fournier, previously the CTO at Rent the Runway, discusses how her job works, the challenge of managing software engineers, and how tech within a financial services company is different than tech within a consumer-facing startup.

Sur le Champ : le podcast qui donne la parole aux agriculteurs par Camille Fournier et Ambre Germain. Stéphane est paysan et Meunier, il est la 7ème génération de sa famille installée à la ferme de Saint-They. Sur 40 hectares de parcelles, il cultive ses céréales en conduite biologique : du blé, du sarrasin, du seigle, et de l’épeautre. Le tout semé avec ses propres graines ou des graines achetées localement.Ses céréales, il les transforme sur place à la meunerie, travail minutieux pour obtenir des farines biologiques, de douze types différents. Il fournit des crêpiers, des boulangers, des pizzaïolos, mais aussi Pierre Hermé ! Et depuis peu, sa femme Stéphanie a rejoint le navire : elle a quitté la blouse d’aide-soignante pour adopter le tablier de boulangère. Elle a repris la boulangerie de Pouldavid avec le projet ambitieux de développer une gamme de pains bio élaborée avec la farine de son mari. Un couple d’agriculteurs et artisans qui vit à mille à l’heure, et qui cherche à faire des liens : entre les agriculteurs et les citadins, entre la santé et l’environnement, et entre terre et mer...

Sur le Champ : le podcast qui donne la parole aux agriculteurs par Camille Fournier et Ambre Germain. François, 29 ans, a repris cette ferme de Baugé en Anjou de 92 ha en 2018. Il élève 80 génisses et une centaine de cervidés. Passionné d’élevage et d’agronomie, François dénote dans le paysage Baugeois. Il pratique l’agriculture de conservation des sols sur ses parcelles de méteil, luzerne, blé et maïs entre autres. François prend grand soin quotidiennement de ce qu’il appelle son « troisième cheptel » : ses nombreux vers de terre qui travaillent sans relâche son sol très riche. Au cours de cette épisode, nous parlons élevage, bovins, cervidés, pratiques agricoles, vie du sol… Et plus encore, François nous fait part de son quotidien, ses projets, ses convictions. Nous parcourons la ferme : sa production, la transformation à la ferme et la vente en direct. Comme il aime dire : «  chez nous c’est 100% local » ! François nous fait part de son amour pour son métier : « j’adore la polyvalence et du coup je trouve que c’est un métier où on ne s’ennuie jamais ! » ! Enfin, nous revenons sur les moments partagés au cours de ces trois semaines, très denses, riches en rencontres et fortes en apprentissage !

Aujourd'hui, nous avons le plaisir de vous présenter la nouvelle émission "Sur le Champ" qui sera diffusée sur Business of Bouffe et animée par Camille Fournier et Ambre Germain, deux étudiantes d'HEC Paris.Il y a quelques semaines maintenant, nous avons découvert le projet d'Ambre et Camille, qui,  dans le cadre de leur projet de fin d'études, ont décidé de sillonner les routes de France pendant un an pour partir à la rencontre des agriculteurs innovants et découvrir les métiers de l'agriculture.  Suite à cela, nous avons eu l'idée de leur proposer de créer un podcast ensemble afin qu'elles puissent partager au plus grand nombre leurs rencontres inspirantes. Dans cet épisode de présentation, Ambre et Camille évoquent le déroulement de leur tour de France, leurs objectifs et le financement d'un tel projet. En plus du podcast, elles nous expliquent également leur ambition de créer une émission qui sera diffusée sur CultivonsNous.TV,  la chaîne qui traite des sujets liés à l'alimentation, du champ à l'assiette, créée par Edouard Bergeon et Guillaume Canet.

For most organizations building an internal platform team can be a challenge when your internal customers are engineers and you don't have any type of formal product management. How do you go about keeping up with the product side of things when you're knee deep in Kubernetes, storage systems and configuration management and other frameworks for services? In this latest episode of the “Art of Modern Ops” Camille Fournier, Managing Director at Two Sigma and Cornelia Davis, CTO at Weaveworks discuss what it takes to build an internal platform within your organization. Many organizations might not think they need an internal product management procedure to identify the key features from their customers to prioritize and build into the platform. At Two Sigma the platform team's customers are other engineers, who generally work on data engineering, building tools for financial operations, as well as for systems that trade in the markets.

We discuss how to handle outages and how to measure productivity for managers. Imperial Radch series of books (https://www.goodreads.com/series/113751-imperial-radch) Terry Pratchett Discworld novels (https://www.terrypratchettbooks.com/book-series/discworld/) Pyramids by Terry Pratchett (https://en.wikipedia.org/wiki/Pyramids_(novel)) The Manager's Path by Camille Fournier (https://www.goodreads.com/book/show/33369254-the-manager-s-path) You can reach us via email at hosts@expandingbeyond.it (mailto:hosts@expandingbeyond.it). Where to find Monica on the internet: Twitter: @KFMolli (https://twitter.com/KFMolli) Github: @nirnaeth (https://github.com/nirnaeth) Blog: dev.to/nirnaeth (https://dev.to/nirnaeth) Where to find Urban on the internet: Twitter: @ujh (https://twitter.com/ujh) Github: @ujh (https://github.com/ujh/) Blog: urbanhafner.com (https://urbanhafner.com/) The intro and outro music is Our Big Adventure (https://freemusicarchive.org/music/Scott_Holmes/Happy_Music/Our_Big_Adventure) by Scott Holmes (https://freemusicarchive.org/music/Scott_Holmes). It's licensed under Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) (https://creativecommons.org/licenses/by-nc/4.0/).

On this episode of Techsetters, co-hosts Samantha Wiener and Jenny Wang interview Camille Fournier. Camille, currently managing director at Two Sigma, a hedge fund, shares thoughtful advice on leadership on engineering culture, how tech transforms industries and the importance of understanding data. Before joining Two Sigma, Camille was CTO at Rent the Runway, where she spearheaded the technology to rent clothing from a “closet in the cloud”. Camille has published two books on management. The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change, and her most recent book 97 Things Every Engineering Manager Should Know. Camille doesn’t just talk about management tips, she shares advice that you can use wherever you are in your career. Techsetters is Executive Produced by Kode With Klossy and made possible by If / Then. This episode was recorded in May 2020.

Growing and managing technical teams during hypergrowth is hard, let alone during a global pandemic. So today Maggie talks to Camille Fournier, Managing Director and Head of Platform Engineering for Two Sigma and author of The Manager's Path, to learn what pitfalls to look out for, how to build effective relationships, and her perspective on how to manage through a crisis. Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends! You can connect with Maggie on Twitter @maggiecrowley @HYPERGROWTH_Pod

Growing and managing technical teams during hypergrowth is hard, let alone during a global pandemic. So today Maggie talks to Camille Fournier, Managing Director and Head of Platform Engineering for Two Sigma and author of The Manager's Path, to learn what pitfalls to look out for, how to build effective relationships, and her perspective on how to manage through a crisis. Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends! You can connect with Maggie on Twitter @maggiecrowley @HYPERGROWTH_Pod

Sponsored By: Show Notes [00:00:47] The live questions have started on Slack Chat, and the first question asked is what are your impressions of Vite and Vite Press? [00:01:49] Since Nuxt and the content module is stable, what kind of markdown editor do you suggest? [00:02:37] Speaking of projects, what projects do you think are best for Gridsome and what’s the most interactive type of site you might make with Gridsome? [00:03:46] It’s question three, so time for a promised Batman voice reveal☺. For a progressive web app, where PWA, that would be largely used on a phone, how would you make the decision between making a Vue app versus a Nuxt app? Batman answers! [00:04:45] What’s your take on Vite and will it be the future where build time will be much lower? [00:05:41] Have any of you guys used GraphQL with Vue projects and what did you think of it? [00:08:55] Ben talks about composing requests. [00:11:56] What’s it like being on the Vuejs core team, what are the team’s workflows like, and how often does the team meet? [00:14:33] When writing software what is the best way to identify the design pattern that works best for your application and how do you go about coming up with the best way to structure the project? [00:25:52] For what kinds of projects would you suggest using Typescript? Is it only for big projects or can you also use it for smaller projects? Sponsor: Linode (https://promo.linode.com/vue/) Segment (https://segment.com/) Picks of the week: [00:36:01] Ari’s pick is a song called “Storm” by Godspeed You! Black Emperor. [00:36:31] Chris has four picks: Community (TV show-I know I’m late to the party). Also, a book called, “Untamed” by Glennon Doyle, Miro, a flowcharting web app, and a podcast called, We Have Concerns. [00:38:15] Matt’s pick is a book called, “An Elegant Puzzle,” about the art of managing in software companies. [00:38:32] Ringo’s pick is Sky, an adventure game (Android, IOS) [00:38:52] Ben’s pick is Whimsical- Wireframe/Whiteboard Collaboration [00:39:34] Tessa’s has two picks: A book called, “The Manager’s Path,” by Camille Fournier and a show called, Lost in Space, on Netflix. Resources mentioned: Enjoy the Vue-Episode 16 (feat. Jack Koppa) (https://enjoythevue.io/episodes/16/) Joi-The most powerful data validation library for JS (https://github.com/hapijs/joi) GloomyLumi Twitter (https://twitter.com/gloomylumi?lang=en) GloomyLumi Twitch (https://www.twitch.tv/gloomylumi) “Storm” by Godspeed You! Black Emperor (https://www.youtube.com/watch?v=5eZ_TgE3x_A) Community-TV show (https://en.wikipedia.org/wiki/Community_(TV_series)) “Untamed” by Glennon Doyle (https://bookshop.org/books/untamed-9781984801258/9781984801258) Miro (https://miro.com/) We Have Concerns-podcast (https://www.stitcher.com/podcast/anthony-carboni/we-have-concerns) “An Elegant Puzzle” (https://lethain.com/elegant-puzzle/) Sky adventure game (https://play.google.com/store/apps/details?id=com.tgc.sky.android&hl=en_US) Whimsical (https://whimsical.com/) “The Manager’s Path” by Camille Fournier (https://bookshop.org/books/the-manager-s-path-a-guide-for-tech-leaders-navigating-growth-and-change/9781491973899) Lost in Space-Netflix (https://www.netflix.com/title/80104198)

Robby speaks with Camille Fournier, Head of Platform Engineering at Two Sigma and author of The Manager's Path. They discuss the importance of avoiding overly clever code, onboarding developers to existing software projects and teams, and how to start approaching mentoring others and be a good mentoree. They also discuss topics from her book, like determining if a path toward management is right for you and navigating career growth in a technical role.Helpful LinksFollow Camille on TwitterCamille on MediumThe Manager's Path: A Guide for Tech Leaders Navigating Growth and ChangeCamille's Blog: Elided Branches[Book] What Got Your Here Won't Get You There by Marshall Goldsmith and Mark Reiter97 Things Every Engineering Manager Should Know: Collective Wisdom from the Experts

Diana Pojar Staff Data Engineer at Slack April, 2020 blog, twitter, linkedin Tell us a little about your current role: your title, the company you wor... https://staffeng.com/stories/diana-pojar blogtwitterlinkedintechnical leadershipJosh WillsStan BabourineBogdan GazaTravis CrawfordCamille Fournier Lara HoganJosh WillsVicki BoykisDavid GascaJulia GraceHolden KarauJohn AllspawCharity MajorsTheo SchlossnagleJessica Joy KerrSarah CatanzaroOrange Bookmy Goodreads accountReady to read another story?

(https://codingsans.com/state-of-software-development-2020) Discussion about the latest trends in the software industry, including the effects of the COVID-19 pandemic with Camille Fournier (Managing Director at Two Sigma) and Juan Pablo Buriticá (taking a break, running his consultant company, ex-VPE at Splice) based on the State of Software Development 2020 report. In this panel discussion we're covering: The effects of COVID-19 on the software world The state of remote work The top industry challenges The latest recruitment trends And more... Follow our guests, Juan Pablo Buriticá (https://twitter.com/buritica) on Twitter!

Join us in this episode of Humans+Tech as we chat to the incredible Camille Fournier, managing director of Two Sigma and author of the books The Manager's Path and 97 Things Every Engineering Manager should know.

In software development when capacity is the problem, most managers think they need to hire more developers. But you can push engineering productivity higher by creating the right context for your existing developers. We interviewed Camille Fournier on the topic of productivity, to learn what she's been doing as a tech leader to keep it high in her developer teams. In this interview we're covering: Defining engineering productivity How to measure engineering productivity Challenges for managers with engineering productivity On-boarding for maximum engineering productivity Effects of mentoring on engineering productivity Keeping engineering productivity high How to improve engineering productivity Excerpt from the interview: "Many engineering managers struggle with setting goals. They think about goal setting in a way that’s inspiring to their team without making it easy or pushing too hard. Some managers say the way to build a productive team is to hire smart people and get out of their way. I have never seen that work. It might work in theory if you have clear goals and if you motivate people to achieve those goals. Most managers aren’t good at setting clear goals. When you're always adjusting your goals, you can’t expect to just hire smart people, get out of their way, and watch them be productive. Most engineers don't learn how to be productive on a team without having experienced it. If you've never been an engineer on a hyper-productive team, you won’t know what it’s like or what you could do to make a productive team happen."

​In this episode of Programming Leadership, Marcus and his guest, Camille Fournier discuss some points from her book, The Manager's Path. They discuss the importance of time management and how to effectively manage employee turnover in a leadership role.    Show Notes A day in the life of a manager varies, but it is a lot of meetings. @3:58​ As a manager, you have to be on for all the hours you are in. @5:07 It's important to make time for your "thinking time." @7:14 The big problems are the intersection of technology and people. @10:24 You need a strategy to keep your team focused on the important things. @12:07 Learn how to balance a team's time between basic maintenance work and new things. @14:09 Different managers track time and work in different ways. @19:06 Look for disengagement as a sign that someone is fixing to leave. @20:37 When you notice a difference in a team member's engagement, address their concerns early. @22:41 "Money is rarely the first straw, but it's usually the last straw." @23:54 Employee retention and hiring retention is one of the most important things you have to do as a manager. @24:56 When someone leaves, there should be a conversation between upper management and that person's manager. @25:51 Internal mobility is a great way to keep employees at a company. @29:10   Links: Sponsor: Gitprime.com Camille’s Twitter: @Skamille Camille’s blog: Elidedbranches.com Podcast home: Programmingleadership.com

Camille Fournier is best known for being the former Chief Technology Officer of Rent The Runway, former vice president of technology at Goldman Sachs, and author of The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change. Currently she is the Managing Director at the hedge fund, Two Sigma. Today we're talking to Camille about Manager Readmes, a doc used to introduce yourself to your team. Are they good or bad? We're getting to the bottom of it today. If you like what you hear, subscribe to the whole season, and please give us ⭐️⭐️⭐️⭐️⭐️ in the reviews.

Camille joins us on Develomentor to talk about her path in technology. She offers incredible insight to anyone navigating the world of technology with an engineering background, especially those looking to manage and lead. Camille was on the fast track to becoming a booming success in technology - she graduated from a prestigious university with a shiny master's degree and had experience working for a major company. But instead of looking for a cutting edge tech company, Camille chose to work for Goldman Sachs. Paradoxically, she attributes this decision to saving her career in tech. After succeeding at Goldman Sachs, Camille joined a startup ‘Rent The Runway’ where she learned to manage and lead people. After wearing many hats in the organization, Camille became the CTO. But the startup life came with a cost, and Camille found herself overworked and drained. Instead of jumping into another job, Camille took some time to reflect and eventually decided to write her first book ‘The Manager’s Path’. The book offers practical advice to technical managers solving problems in the real world. It was a success, and not only for managers, but also, somewhat surprisingly, for younger employees interested in management. Camille currently works as the head of platform engineering at Two Sigma, a tech hedge-fund. For full episode show notes click hereCONNECT WITH CAMILLE FOURNIER HERELinkedinWebsiteCONNECT WITH GRANT INGERSOLL HERELinkedInTwitter

In this podcast we discuss a holistic approach to technical leadership, and Pat provides guidance on everything from defining target operating models, cultivating culture, and supporting people in developing the career they would like. There are a bunch of great stories, several book recommendations, and additional resources to follow up on. * Cultivating organisational culture is much like gardening: you can’t force things, but you can set the right conditions for growth. The most effective strategy is to communicate the vision and goals, lead the people, and manage the systems and organisational structure. * N26, a challenger bank based in Berlin has experienced hypergrowth over the past two years. Both the number of customers and the amount of employees have increased over threefold. This provides lots of opportunities for ownership of product and projects, and it creates unique leadership challenges. * A target operating model (TOM) is a blueprint of a firm's business vision that aligns operating capacities and strategic objectives and provides an overview of the core business capabilities, internal factors, and external drivers, strategic and operational levers. This should be shared widely within an organisation * Pat has curated a “trident operating” model for employee growth. In addition to the class individual contributor (IC) and management tracks, he believes that a third “technical leadership” track provides many benefits. * People can switch between these tracks as their personal goals change. However, this switch can be challenging, and an organisation must support any transition with effective training. * Pat recommends the following books for engineers looking to make the transition to leadership: The Manager’s Path, by Camille Fournier; Resilient Management, by Lara Hogan; Elegant Puzzle, by Will Larson; and Leading Snowflakes by Oren Ellenbogen. Pat has also written his own book, Talking with Tech Leads. * It is valuable to define organisation values upfront. However, these can differ from actual culture, which more about what behaviours you allow, encourage, and stop. * Much like the values provided by Netflix’s Freedom and Responsibility model, Pat argues that balancing autonomy and alignment within an organisation is vital for success. Managers can help their team by clearly defining boundaries for autonomy and responsibility. * Developing the skills to influence people is very valuable for leaders. Influence is based on trust, and this must be constantly cultivated. Trust is much like a bank account, if you don’t regular deposit actions to build trust, you may find yourself going overdrawn when making a deposit. This can lead to bad will and defensive strategies being employed.

Camille Fournier is a Managing Director at Two Sigma and the former CTO of Rent The Runway. She’s also the author of The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change.You can find her on Twitter @skamille.If you’re interested in doing Startup School this year, signups are open at StartupSchool.org. The course begins on July 22nd and goes for 10 weeks. Select companies who complete the course will also receive 15,000 dollars in equity-free funding.The YC podcast is hosted by Craig Cannon.Y Combinator invests a small amount of money ($150k) in a large number of startups (recently 200), twice a year.Learn more about YC and apply for funding here: https://www.ycombinator.com/apply/***Topics00:00 - Intro00:47 - Why do many individual contributors (ICs) never experience a good manager?3:27 - How did the ideology of management being bad become pervasive in startups?5:27 - What should a new manager do in their first 90 days?8:57 - Getting better at 1:1s11:17 - More tips for the first 90 days13:17 - Remote management15:12 - Mistakes rookie managers make19:27 - Letting people go23:37 - Being a manager and still wanting to write code27:57 - Feeling overwhelmed as a manager31:27 - Getting a team to gel38:42 - Giving people kudos39:57 - Non-engineers running engineering teams42:07 - Staying legit technically as a manager43:27 - Management vs leadership

mayuko さんをゲストに迎えて、WWDC, 英語、ドキュメンテーション、エンジニアリングキャリア、Imposter Syndrome, Playdate などについて話しました。 Show Notes Washington's Birthday Rebuild: 211: Too Real To Be Funny (mayuko) AltConf LAYERS 2019 次へつなごう— Extending a hand to the next generation of Apple developers try! Swift Tokyo 2016 - Boundaries in Practice Women Who Code Tokyo Explain Like I'm Five How to Kickstart Your Software Engineering Career 世界で闘うプログラミング力を鍛える本 エンジニアのためのマネジメントキャリアパス Knock Down the House Parks and Recreation 外務省: 在外選挙の投票方法 Behind The Curve Playdate. A New Handheld Gaming System mayuko

Camille Fournier is the author of The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change and is the Head of Platform Engineering at Two Sigma. She sits down with Scott to talk about how managing people in the technical industry is a technical discipline! How do YOU go from tech lead to CTO? What does it take to be a good mentor and a good leader? The Manager's Path On Being a Principal Engineer

On the podcast this week Charles Humble talks to Camille Fournier about running a platform team, how her current role differs from the CTO role she had a Rent the Runway, the skills developers need to acquire as they move from engineering to management positions, tends like Holacracy, and her book "The Manager's Path" Why listen to this podcast: - When looking for platform engineers Camille looks for people who understand what it takes to build and run distributed systems - network, availability, data - and customer empathy. - The team needs to be focussed on taking the time do build robust software for operational excellence. - The technical skills were different at Rent the Runway - these would tend to be more full-stack engineers who worked in a more iterative way. - Much of what we do at work is really about human relationships. One thing about relationships is that they tend to be better when you have one on one conversations with people on our regular basis. A lot of the value of one on one meeting is that you are reenforcing the social connection you have with the other person. - One of the most important things we do as engineering managers is stay abreast of how to make teams effective in the context of delivering software. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2RJdwYR You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2RJdwYR

Camille Fournier joins the Local Maximum today to discuss her book on engineering management, Rent the Runway, company culture, engineering ladders, and more! Plus, learn about Foursquare for Good and Max responds to listener messages about ads and censorship.

Christopher (@stoneymonster) and Elecia (@logicalelegance) talks about vacations for learning and hobbies then answered listener questions. Chris’ toys include the Prusa I3 Mk3 and the UAD Arrow. Elecia likes Camille Fournier’s book, The Manager’s Path. She also got to plug her own book, Making Embedded Systems: Design Patterns for Great Software.   Pacific spiny lumpsucker (Eumicrotremus orbis) at the Seymour Science Center

Camille Fournier is the head of Platform Engineering at Two Sigma, a financial company in New York City. Prior to joining Two Sigma she was the Chief Technology Officer of Rent the Runway, a transformative brand that offers unprecedented access to designer fashion, disrupting the way millions of women get dressed. She is an open source contributor and project committee member for both Apache ZooKeeper and the Dropwizard web framework. Prior to working for Rent the Runway, Camille served as a software engineer at Microsoft, and most recently, spent several years as a technical specialist at Goldman Sachs, creating distributed systems for managing risk analysis and firm-wide infrastructure. She has a BS in Computer Science from Carnegie Mellon University and an MS in Computer Science from the University of Wisconsin-Madison. Camille is a well-respected voice within the tech community, speaking on a variety of topics such as engineering leadership, distributed systems, scaling teams, and technical architecture. In 2017 she released her book, “The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change.” Contact Info: Twitter: @skamille Medium: https://medium.com/@skamille  Camille Talk: http://www.camilletalk.com/ Show Notes: Thanks for the Feedback: The Science and Art of Receiving Feedback Well Harvard Business Review Turn the Ship Around!: A True Story of Turning Followers into Leaders What Got You Here Won't Get You There: How Successful People Become Even More Successful The Effective Executive: The Definitive Guide to Getting the Right Things Done The Five Dysfunctions of a Team

Our Guest On episode 1 of Elevatd Life, we have Morgan Meredith a Senior Release Manager at Jellyvision! This episode really dives in to how careers can take many twists and turns but at the end of the day if you keep working at your craft and constantly apply yourself you can jump and right where you want to be. Morgan went from studying hearing science and sound acoustics to working at Yello in Chicago, IL and now leading the Release Management team at Jellyvision. She gave awesome thoughts around overcoming imposter syndrome and building up her technical skills. Our Highlights How to go from a non-traditional major (Speech Acoustics) to becoming a Release Manager for a team of 2. Ways to "zoom out" in a new role and find pain points you can work to solve, whether that's through new processes or clearer structure and expectations. Where do you go after being a Release Manager? For Morgan, that's developing her programming skills to one day land in a Dev Manager role. It's all about initiative. How 'imposter syndrome' is real pain in the tech industry and ways to overcome it. Find Morgan Blog https://www.morgan-made.com/ Twitter @mo_leigh Links for clicking Stephanie Hurlburt - find her online Lara Hogan for posts on how to organize meetings - find her work online Thoughts on becoming a self-taught engineer by Lexis Hanson - read here Camille Fournier, The Manager’s Path - buy the book here FlatIron School (if you’re interested in programming) - check them out here FlatIron Scholarships to receive aid for tuition - read more here AWS Learning: A cloud guru solution architect course - course here Women in Tech chat - join here Follow Elevatd Life Twitter @elevatdlife Instagram @elevatdlife

Our Guest On episode 1 of Elevatd Life, we have Morgan Meredith a Senior Release Manager at Jellyvision! This episode really dives in to how careers can take many twists and turns but at the end of the day if you keep working at your craft and constantly apply yourself you can jump and right where you want to be. Morgan went from studying hearing science and sound acoustics to working at Yello in Chicago, IL and now leading the Release Management team at Jellyvision. She gave awesome thoughts around overcoming imposter syndrome and building up her technical skills. Our Highlights How to go from a non-traditional major (Speech Acoustics) to becoming a Release Manager for a team of 2. Ways to "zoom out" in a new role and find pain points you can work to solve, whether that's through new processes or clearer structure and expectations. Where do you go after being a Release Manager? For Morgan, that's developing her programming skills to one day land in a Dev Manager role. It's all about initiative. How 'imposter syndrome' is real pain in the tech industry and ways to overcome it. Find Morgan Blog https://www.morgan-made.com/ Twitter @mo_leigh Links for clicking Stephanie Hurlburt - find her online Lara Hogan for posts on how to organize meetings - find her work online Thoughts on becoming a self-taught engineer by Lexis Hanson - read here Camille Fournier, The Manager’s Path - buy the book here FlatIron School (if you’re interested in programming) - check them out here FlatIron Scholarships to receive aid for tuition - read more here AWS Learning: A cloud guru solution architect course - course here Women in Tech chat - join here Follow Elevatd Life Twitter @elevatdlife Instagram @elevatdlife

Camille Fournier, author, speaker, and Managing Director at Two Sigma, discusses her path from Director of Infrastructure Engineering to CTO, lessons learned from tech team management, and the importance of defining core-values. Two Sigma Rent the Runway The Manager's Path David Cancel on Giant Robots Camille on Twitter Become a Sponsor of Giant Robots!

Stefan Tilkov talks to Camille Fournier about making a career as a manager in a software development organization. Camille shares her insights about when or why someone would want to become a manager and how to become good at it. Other topics include different levels of management from tech lead to CTO, the role of one-on-one meetings, and how managers influence company culture.

MRS O11 Greg Baugues This episode of My Ruby Story features Greg Baugues. Greg has been on two previous episodes, episode 142 where he discussed mental illness, and episode 258 where he discussed Twilio. Greg has been at Twilio for three and a half years. He worked on the developer/evangelism team for three years. A couple of months ago he became the lead developer of the community team. He lived in Chicago for eleven years, where he first started using Ruby. He moved to Brooklyn, New York a year ago. How did you get into programming? When he was five or six his parents owned a TRS-80 when he was five or six. It had a cassette drive and when turned on it booted into basic. He wrote programs in basic on this computer and it was an instant gratification to him. On a back cover of a magazine, he read there would be a code printed in basic that he would copy line by line. Later, his family bought a PC that had MS-DOS with QBasic, and his friends introduced him to Pascal, C, and C++. When he graduated high school he started PHP and got into web stuff. How did you get from PHP and web stuff to Ruby? In 1999 Greg used PHP to start a dot-com company with which they sold eight months later for all equity. He jokes that he “started and sold a company and all I got was a polo shirt out of it.”  This reinforced that he always wanted to work in programming but that he would never be happy just programming. He wanted to be involved working on the people side of things, too. He got a job at a consulting agency at Table XI where he was a sales guy. He claims that he wasn’t good at sales, so stopped programming for one and a half to two years in order to become better. Then he traveled with his wife in Europe for a while. This showed him that he spent his free time programming. After this he picked up Ruby for the first time. Ruby was his first language of choice because Table XI and most of Chicago was using Ruby at the time. He also fell in love with it. What was it about Ruby that you thought was cool? Greg finds Ruby beautiful and expressive. He believes that it makes more sense than for loop and believes that you can explain it to someone who’s never done coding before and it makes sense to them. Writing Ruby is the closest you can come to writing pseudo code that actually runs. Ruby doesn’t look much different from pseudo code. He thinks it is a joy to write in Ruby. What contributions do you feel like you’ve made to the Ruby community? Greg believes that his biggest contribution would be in the vein of mental health. He has Bipolar Disorder and was on a Ruby Rogues podcast where he spoke about it. Because of his disorder, he failed out of college, had trouble with relationships, getting out of bed, paying bills, and a lot of guilt. He finally got treatment in 2007 where medication slowly helped. Four years ago he had a coworker who overdosed that had been showing symptoms of the same disorder. The next day instead of doing a lightening talk he had scheduled about fantasy football, he gave a talk about mental illness and started giving talks about mental illnesses everywhere in the Ruby community. Charles tells Greg that he heard someone speak about him and said he’d decided to go get help and have a relationship with his family again. He said that Greg’s episode of the podcast had helped him, and others have emailed him about it too. He explains that changing the way someone lives is just as important as writing source code. Greg says that he has learned that we are not alone in this community. There is a value of sharing your story and being vulnerable. It is easy to underestimate the compassion and empathy people have in the Ruby community. What are you working on now? Greg just had a conference called Signal for Twilio two weeks ago. There were 2,000 developers and 100 speakers at the conference. He was part of the team that organized speakers. Two months ago he started a leadership role with the developer community team for the first time. He’s trying to learn how to be in a management role for the first time. There were a million developers that signed up for Twilio so he is trying to figure out how to organize a community of developers instead of just having customers. Picks Greg: Phil Nash: https://philna.sh/ The Manager’s Path by Camille Fournier: http://shop.oreilly.com/product/0636920056843.do The Tim Ferriss Podcast with Jamie Foxx: https://www.youtube.com/watch?v=YGnnEfmP8K4 The Ezra Klein Show: https://www.vox.com/ezra-klein-show-podcast Charles: Ruby Dev Summit: https://rubydevsummit.com/ Links: Email: gb@twilio.com Twilio Voices: https://www.twilio.com/docs/api/twiml/say Twitter: https://twitter.com/greggyb

MRS O11 Greg Baugues This episode of My Ruby Story features Greg Baugues. Greg has been on two previous episodes, episode 142 where he discussed mental illness, and episode 258 where he discussed Twilio. Greg has been at Twilio for three and a half years. He worked on the developer/evangelism team for three years. A couple of months ago he became the lead developer of the community team. He lived in Chicago for eleven years, where he first started using Ruby. He moved to Brooklyn, New York a year ago. How did you get into programming? When he was five or six his parents owned a TRS-80 when he was five or six. It had a cassette drive and when turned on it booted into basic. He wrote programs in basic on this computer and it was an instant gratification to him. On a back cover of a magazine, he read there would be a code printed in basic that he would copy line by line. Later, his family bought a PC that had MS-DOS with QBasic, and his friends introduced him to Pascal, C, and C++. When he graduated high school he started PHP and got into web stuff. How did you get from PHP and web stuff to Ruby? In 1999 Greg used PHP to start a dot-com company with which they sold eight months later for all equity. He jokes that he “started and sold a company and all I got was a polo shirt out of it.”  This reinforced that he always wanted to work in programming but that he would never be happy just programming. He wanted to be involved working on the people side of things, too. He got a job at a consulting agency at Table XI where he was a sales guy. He claims that he wasn’t good at sales, so stopped programming for one and a half to two years in order to become better. Then he traveled with his wife in Europe for a while. This showed him that he spent his free time programming. After this he picked up Ruby for the first time. Ruby was his first language of choice because Table XI and most of Chicago was using Ruby at the time. He also fell in love with it. What was it about Ruby that you thought was cool? Greg finds Ruby beautiful and expressive. He believes that it makes more sense than for loop and believes that you can explain it to someone who’s never done coding before and it makes sense to them. Writing Ruby is the closest you can come to writing pseudo code that actually runs. Ruby doesn’t look much different from pseudo code. He thinks it is a joy to write in Ruby. What contributions do you feel like you’ve made to the Ruby community? Greg believes that his biggest contribution would be in the vein of mental health. He has Bipolar Disorder and was on a Ruby Rogues podcast where he spoke about it. Because of his disorder, he failed out of college, had trouble with relationships, getting out of bed, paying bills, and a lot of guilt. He finally got treatment in 2007 where medication slowly helped. Four years ago he had a coworker who overdosed that had been showing symptoms of the same disorder. The next day instead of doing a lightening talk he had scheduled about fantasy football, he gave a talk about mental illness and started giving talks about mental illnesses everywhere in the Ruby community. Charles tells Greg that he heard someone speak about him and said he’d decided to go get help and have a relationship with his family again. He said that Greg’s episode of the podcast had helped him, and others have emailed him about it too. He explains that changing the way someone lives is just as important as writing source code. Greg says that he has learned that we are not alone in this community. There is a value of sharing your story and being vulnerable. It is easy to underestimate the compassion and empathy people have in the Ruby community. What are you working on now? Greg just had a conference called Signal for Twilio two weeks ago. There were 2,000 developers and 100 speakers at the conference. He was part of the team that organized speakers. Two months ago he started a leadership role with the developer community team for the first time. He’s trying to learn how to be in a management role for the first time. There were a million developers that signed up for Twilio so he is trying to figure out how to organize a community of developers instead of just having customers. Picks Greg: Phil Nash: https://philna.sh/ The Manager’s Path by Camille Fournier: http://shop.oreilly.com/product/0636920056843.do The Tim Ferriss Podcast with Jamie Foxx: https://www.youtube.com/watch?v=YGnnEfmP8K4 The Ezra Klein Show: https://www.vox.com/ezra-klein-show-podcast Charles: Ruby Dev Summit: https://rubydevsummit.com/ Links: Email: gb@twilio.com Twilio Voices: https://www.twilio.com/docs/api/twiml/say Twitter: https://twitter.com/greggyb

MRS O11 Greg Baugues This episode of My Ruby Story features Greg Baugues. Greg has been on two previous episodes, episode 142 where he discussed mental illness, and episode 258 where he discussed Twilio. Greg has been at Twilio for three and a half years. He worked on the developer/evangelism team for three years. A couple of months ago he became the lead developer of the community team. He lived in Chicago for eleven years, where he first started using Ruby. He moved to Brooklyn, New York a year ago. How did you get into programming? When he was five or six his parents owned a TRS-80 when he was five or six. It had a cassette drive and when turned on it booted into basic. He wrote programs in basic on this computer and it was an instant gratification to him. On a back cover of a magazine, he read there would be a code printed in basic that he would copy line by line. Later, his family bought a PC that had MS-DOS with QBasic, and his friends introduced him to Pascal, C, and C++. When he graduated high school he started PHP and got into web stuff. How did you get from PHP and web stuff to Ruby? In 1999 Greg used PHP to start a dot-com company with which they sold eight months later for all equity. He jokes that he “started and sold a company and all I got was a polo shirt out of it.”  This reinforced that he always wanted to work in programming but that he would never be happy just programming. He wanted to be involved working on the people side of things, too. He got a job at a consulting agency at Table XI where he was a sales guy. He claims that he wasn’t good at sales, so stopped programming for one and a half to two years in order to become better. Then he traveled with his wife in Europe for a while. This showed him that he spent his free time programming. After this he picked up Ruby for the first time. Ruby was his first language of choice because Table XI and most of Chicago was using Ruby at the time. He also fell in love with it. What was it about Ruby that you thought was cool? Greg finds Ruby beautiful and expressive. He believes that it makes more sense than for loop and believes that you can explain it to someone who’s never done coding before and it makes sense to them. Writing Ruby is the closest you can come to writing pseudo code that actually runs. Ruby doesn’t look much different from pseudo code. He thinks it is a joy to write in Ruby. What contributions do you feel like you’ve made to the Ruby community? Greg believes that his biggest contribution would be in the vein of mental health. He has Bipolar Disorder and was on a Ruby Rogues podcast where he spoke about it. Because of his disorder, he failed out of college, had trouble with relationships, getting out of bed, paying bills, and a lot of guilt. He finally got treatment in 2007 where medication slowly helped. Four years ago he had a coworker who overdosed that had been showing symptoms of the same disorder. The next day instead of doing a lightening talk he had scheduled about fantasy football, he gave a talk about mental illness and started giving talks about mental illnesses everywhere in the Ruby community. Charles tells Greg that he heard someone speak about him and said he’d decided to go get help and have a relationship with his family again. He said that Greg’s episode of the podcast had helped him, and others have emailed him about it too. He explains that changing the way someone lives is just as important as writing source code. Greg says that he has learned that we are not alone in this community. There is a value of sharing your story and being vulnerable. It is easy to underestimate the compassion and empathy people have in the Ruby community. What are you working on now? Greg just had a conference called Signal for Twilio two weeks ago. There were 2,000 developers and 100 speakers at the conference. He was part of the team that organized speakers. Two months ago he started a leadership role with the developer community team for the first time. He’s trying to learn how to be in a management role for the first time. There were a million developers that signed up for Twilio so he is trying to figure out how to organize a community of developers instead of just having customers. Picks Greg: Phil Nash: https://philna.sh/ The Manager’s Path by Camille Fournier: http://shop.oreilly.com/product/0636920056843.do The Tim Ferriss Podcast with Jamie Foxx: https://www.youtube.com/watch?v=YGnnEfmP8K4 The Ezra Klein Show: https://www.vox.com/ezra-klein-show-podcast Charles: Ruby Dev Summit: https://rubydevsummit.com/ Links: Email: gb@twilio.com Twilio Voices: https://www.twilio.com/docs/api/twiml/say Twitter: https://twitter.com/greggyb

Stefan Tilkov talks to Camille Fournier about the challenges developers face when building distributed systems. Topics include the definition of a distributed system, whether developers can avoid building them at all, and what changes occur once they choose to. They also talk about the role distributed consensus tools such as Apache Zookeeper play, and whether […]

Stefan Tilkov talks to Camille Fournier about the challenges developers face when building distributed systems, whether the can avoid building them at all, and what changes occur once they do.

Distributed systems products are often marketed with terms like “real-time data” and “hassle-free scaling”, but what do those terms actually mean? Is data in a distributed system ever reliably “real time”? Do we ever have strong enough plans about our scalability strategy to say that scaling will be “hassle free”? Camille Fournier joins us today The post Distributed Systems Tradeoffs with Camille Fournier appeared first on Software Engineering Daily.

What is it like to be a CTO? This week Paul and Rich talk to two former chief technology officers: Camille Fournier, who was previously at Rent the Runway, and Kellan Elliott-McCrea, who was previously at Etsy. They discuss the CTO’s role within a company, share experiences from the trenches, compare managing engineers versus managing CEOS, and swap stories about the most colossal technical outages that happened on their respective watches (Kellan took down Yahoo Messenger; Camille ruined everyone’s Thanksgiving).

Camille Fournier is CTO at Rent the Runway with a toddler son.NotesElided Branches@skamille on TwitterRent the RunwaySponsorGitHub See acast.com/privacy for privacy and opt-out information.

Apache Zookeeper, Distributed Systems, Open Source and more with Camille Fournier