19 Burst results for "Kent Beck"

Waste in Software Development

Test & Code : Python Testing

02:03 min | Last week

Waste in Software Development

"Heard that agile methodologies like td scrum were a reaction to previous ways of making software including big design up front and waterfall before the manifesto for agile soffer development. These were called lightweight methods. I started reading about all of this. In the early two thousands. At the time i was writing embedded code for an calms test instrument specifically the code that sits between the protocol stack and the. Pj's in eight six another hardware long lists of registered of were needed. Lots of room for error testing was needed and needed during development. It was reading in some order. That i don't remember the pragmatic programmer. The lean suffer development book test. I programming then. Td mostly from w to see which was worse. Cutting him zwicky and also from kent. Beck's book extreme programming from various posts in books in also at the time my company had everyone takes some six sigma training so i was thinking about all of these things at the same time in so they kind of blend together and i think of them all together the only part of six sigma that's stuck was to make. I think it stuck. Because i tried out. Small process. improvement project for my team is an acronym for define measure analyze improve control normally. It's used to save money on a large scale. But i wanted to save developers time and effort on daily level. The process improvement project was just our code change process. The process was make. Sure you have current code creative branch. Make a change build load. The compiled code onto instrument restart the instrument run a smoke test to make sure it all passes commit. The change merged from maine to your branch. If there are any conflicts or any changes on main resolve conflicts build load smoke test again merged from your branch to made if there's any

Zwicky Beck Kent Maine
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

07:18 min | 8 months ago

"kent beck" Discussed on Software Engineering Daily

"Show with trevor noah is addition. Subscribe now facebook. My understanding. is that around that time. Facebook really didn't have much testing and it's kind of ironic because you were the creator of extreme programming. It was highly dependent on the process of writing unit tests and then writing the features facebook clearly reversed that process and was able to be successful despite the fact that they wrote their features before they their their tests. You you often hear that you need. Unit tests in order to build things like continuous integration. Continues to degration. Lets you move much faster because you have this battery of unit tests that runs at every new build. But i don't think facebook had that stuff until later. How is facebook able to move so fast with such a low amount of unit testing. Yes so that was. That was part of the puzzle. One when i arrived one of those. Hey this isn't what's in the books and yet it seems to be working and the answer that came to is that while the there's a couple parts of it one is. How many of your problems can you test for. And how many problems. Only show up in production so if if problems like if you're writing a simple calculation but it might not scale in production you you can't write unit tests for it so the facebook cancer is don't that's part of it is depending on the ratio of. How many problems is it possible to test for before. Production versus after if that ratio is skewed towards. Hey stuff only fails in production then. Don't write any tests. The second part of the answer is tests are a form of feedback and facebook. Engineers had many many other forms of feedback. So you'd right on your development server and you'd try stuff out and then it would go through code review his second form of feedback and then it would at that point it would roll to the internal site. So you get more feedback from that and then it would go through the deployment process where it would get rolled out to a small number of machines and then and more and you get feedback from that and then A logging and like operational awareness was just part of the engineering culture. So you'd get feedback post production of like how your feature actually was was behaving so. There's a bunch of feedback loops in place. Unit tests occupied for most development facebook. Just the cost benefit the amount of feedback. They added the timeless timeliness of that feedback and the cost of achieving that feedback. Just wasn't worth it the so in bootcamp. You're supposed to put code in production. The first week. And i was very careful to write tests than do everything properly. So i got in a fair amount of of. He got a fair amount of heat. Because my first feature didn't land for three weeks and people are like well. I don't know how this is gonna work out. One i was. I was wondering that too. I had a huge case of imposter syndrome. When i when i landed at facebook and realize just how different everything was and then the tests that i had written broke almost immediately and they were deleted. That was one of the things that surprised if if you had if you had a test and it failed but the site was up. They'd just delete the test. If you had tests that were intermittent that that were non deterministic. There were just deleted. And at first i was shocked. Like deleted attest. This is producing noise. And it's not producing signal if you eliminate this this noise production per definition. The situation is clearer all of a sudden the fact that you kinda wish that you had to test for something while you didn't and so yet just chuck it. Let's move on now. You probably wouldn't want to take that approach to nuclear power plant software or electricity grid software. That seems like a practice. That is uniquely useful. Four kind of early facebook where this thing wasn't yet a communications utility. It was more of a fun thing to do akin to television. So there's another lesson. I learned at facebook is the difference between reversible and irreversible decisions. So if you if you roll out a feature in new zealand say and people don't like it and you can easily turn it off. Then that's a reversible decision. Facebook engineering spent a lot of effort on a making decisions. Reversible like sometimes you have to do quote unquote extra engineering. To make a decision. Reversible talked with one of the managers and the network infrastructure and he said when they got a new piece of networking gear in it went to the characterization labs just to like put it through its paces. They mostly didn't care about its performance. What they cared about was. Can we turn this thing off safely. So and that's an investment in reversibility all the feature flag stuff. That was one of the lessons. I had to learn a people in code reviews would say oh you definitely need to put this buying a feature flag wool. What why my attitude is lemme test. It make sure that it works. And then i'll just put it out well. The learned hard learned wisdom. There was the. There's a bunch of stuff you can't test for so yes you have to introduce additional complexity to to put the flags and but if you don't you're going to roll something out and the you're only recourse is going to be a hot fix rollout. Which makes the release engineering grumpy. And you did not want to make release engineering grumpy. What's the role of a manager at facebook. So that changed a fair amount. In the time. I was there when i got there engineers. All at all levels were expected to exercise a lot of initiative. There's a beautiful article by shanggong about facebook's early engineering management philosophy and can't the title of it maybe we can find it later but the the upshot is facebook deliberately chose to make engineering easier and management harder. If.

facebook trevor noah cancer chuck new zealand
Facebook Engineering Process

Software Engineering Daily

04:51 min | 8 months ago

Facebook Engineering Process

"Facebook. My understanding. is that around that time. Facebook really didn't have much testing and it's kind of ironic because you were the creator of extreme programming. It was highly dependent on the process of writing unit tests and then writing the features facebook clearly reversed that process and was able to be successful despite the fact that they wrote their features before they their their tests. You you often hear that you need. Unit tests in order to build things like continuous integration. Continues to degration. Lets you move much faster because you have this battery of unit tests that runs at every new build. But i don't think facebook had that stuff until later. How is facebook able to move so fast with such a low amount of unit testing. Yes so that was. That was part of the puzzle. One when i arrived one of those. Hey this isn't what's in the books and yet it seems to be working and the answer that came to is that while the there's a couple parts of it one is. How many of your problems can you test for. And how many problems. Only show up in production so if if problems like if you're writing a simple calculation but it might not scale in production you you can't write unit tests for it so the facebook cancer is don't that's part of it is depending on the ratio of. How many problems is it possible to test for before. Production versus after if that ratio is skewed towards. Hey stuff only fails in production then. Don't write any tests. The second part of the answer is tests are a form of feedback and facebook. Engineers had many many other forms of feedback. So you'd right on your development server and you'd try stuff out and then it would go through code review his second form of feedback and then it would at that point it would roll to the internal site. So you get more feedback from that and then it would go through the deployment process where it would get rolled out to a small number of machines and then and more and you get feedback from that and then A logging and like operational awareness was just part of the engineering culture. So you'd get feedback post production of like how your feature actually was was behaving so. There's a bunch of feedback loops in place. Unit tests occupied for most development facebook. Just the cost benefit the amount of feedback. They added the timeless timeliness of that feedback and the cost of achieving that feedback. Just wasn't worth it the so in bootcamp. You're supposed to put code in production. The first week. And i was very careful to write tests than do everything properly. So i got in a fair amount of of. He got a fair amount of heat. Because my first feature didn't land for three weeks and people are like well. I don't know how this is gonna work out. One i was. I was wondering that too. I had a huge case of imposter syndrome. When i when i landed at facebook and realize just how different everything was and then the tests that i had written broke almost immediately and they were deleted. That was one of the things that surprised if if you had if you had a test and it failed but the site was up. They'd just delete the test. If you had tests that were intermittent that that were non deterministic. There were just deleted. And at first i was shocked. Like deleted attest. This is producing noise. And it's not producing signal if you eliminate this this noise production per definition. The situation is clearer all of a sudden the fact that you kinda wish that you had to test for something while you didn't and so yet just chuck it. Let's move on now. You probably wouldn't want to take that approach to nuclear power plant software or electricity grid software. That seems like a practice. That is uniquely useful. Four kind of early facebook where this thing wasn't yet a communications utility. It was more of a fun thing to do akin to

Facebook Cancer Chuck
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

07:13 min | 8 months ago

"kent beck" Discussed on Software Engineering Daily

"Might understand. He's that around that time. Facebook really didn't have much testing and it's kind of ironic because you were the creator of extreme programming. It was highly dependent on the process of writing unit tests and then writing the features facebook clearly reversed that process and was able to be successful despite the fact that they wrote their features before they their their tests. You often hear that you need. Unit tests. In order to build things like continuous integration. Continuous integration. Let you move much faster because you have this battery of unit tests that runs at every new build but i. i don't think facebook that stuff until later. How is facebook able to move so fast with such a low amount of unit testing. Yes so that was. That was part of the puzzle. One when i arrived one of those. Hey this isn't what's in the books and yet it seems to be working and the answer that i came to is that while the there's a couple parts of it one is. How many of your problems can you test for. And how many problems. Only show up in production. So if if if you're writing a simple calculation but it might not scale in production you can't write unit tests for it so the facebook answer is don't so that's part of it is depending on the ratio of. How many problems is it possible to. Test for before. Production versus after if that ratio is skewed towards. Hey steph only fails in production then. Don't write any tests. The second part of the answer is tests are a form of feedback and facebook. Engineers had many many other forms of feedback. So you'd right on your development server and you'd try stuff out and then it will go through code. Review does second form of feedback. And then it would. At that point it would roll to the internal site. So you get more feedback from that and then it would go through the deployment process. Were it would get rolled out to a small number of machines and then more and more and you get feedback from that and then of a logging and like operational awareness was just part of the engineering culture. So you'd get feedback post production of like how your feature actually was was behaving. So there's a bunch of feedback loops in place. Unit tests occupied for most development facebook. Just the cost benefit the the amount of feedback. They added in the timeless timeliness of the feedback and the cost of achieving that feedback. Just wasn't worth it the in boot camp. You're supposed to code in production. The first week and i was very careful to write tests. Do everything properly. So i got an in a fair amount of of. He got a fair amount of heat because my first featured in land for three weeks and people are like. I don't know how this is gonna work out. One i was. I was wondering that too. I had a huge case of imposter syndrome. When i when i landed at facebook and realize just how different everything was and then the tests that i had written broke almost immediately and they were deleted. That was one of the things that surprise josh. If if you had if you had a test and it failed but the site was up they just delete the test if you had tests that. Were intermittent that that were non deterministic. They were just deleted and at first i was shocked like old. Delete a test. This is producing noise. And it's not producing signal if you eliminate this this noise production per definition. The situation is clearer all of a sudden the fact that you kind of wish that you add a test for something while you didn't and so yeah just chuck it. Let's move on now. You probably wouldn't wanna take that approach to nuclear power plant software or electricity grid software. That seems like a practice that is uniquely useful for kind of early facebook where this thing wasn't yet a communications utility. It was more of a fun thing to do akin to television. So there's an another lesson. I learned that facebook is the difference between reversible and irrevocable decisions so if you if you roll out a feature in new zealand say and people don't like it and you can easily turn it off. Then that's a reversible decision. Facebook engineering spent a lot of effort on a making decisions. Reversible like sometimes you have to do quote unquote extra engineering. To make a decision. Reversible talked with one of the managers in the network infrastructure and. He said when they got a new piece of networking gear in it went to the characterization. Labs just to put it through its paces. They mostly didn't care about its performance. What they cared about was. Can we turn this thing off safely. So and that's an investment in reversibility all the feature flag stuff. That was one of the lessons. I had to learn a people in code reviews sued. Say oh you definitely need to put this bind feature flag will what why my attitude is. Let test it. Make sure that it works. And then i'll just put it out. Well the learned hard learned wisdom. There was the. There's a bunch of stuff you can't test for so yes you have to introduce additional complexity to to put the flags end but if you don't you're going to roll something out and the you're only recourses going to be a hot fix rollout. Which makes the release engineering grumpy. And you did not wanna make release engineering grumpy. What's the role of a manager at facebook. So that changed the fairmount. In the time. I was there when i got there engineers. All at all levels were expected to exercise a lot of initiative. There's a beautiful article by ye shanggong about facebook's early engineering management philosophy and i can't recall the title of it maybe we can find it later. But the upshot is facebook deliberately chose to make engineering easier and engineering management harder..

facebook steph josh chuck new zealand
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

07:02 min | 8 months ago

"kent beck" Discussed on Software Engineering Daily

"While you're expanding reducing the number of servers by ten percent you know if you go from twenty to eighteen like who cares and you're if you're doing that you're not doing something else to actually scale it. So what. I noticed is informally projects in those three phases were managed completely differently so a couple of people would peel off and just start trying stuff in some area that they were interested in. That's the explore phase. Something they did would take off and start start growing quickly and then the infrastructure would follow her because it was a new some sort of new Demand people would join the project who didn't like trying out new things but loved diving into harry technical unprecedented technical problems. So the steve. Graham was an early facebook engineers. The first person that i. I mean when i walk through the door facebook and i talked with him about this and he said yeah. I just waited for the chance to have another unprecedented technical problem. But that expand phase was staffed differently managed differently funding. Wasn't i mean that's whole own whole topic but it was treated very differently. This would manifest. You would see a team. Go in for zach review and come out. You know bubbling in happy and ready to do the next thing and a month later they would go for a review and report that they've been doing the same kind of stuff for another month since that was working in. Come out just looking like their dog died. Because they'd gotten ream d- why are you still trying out all this stuff This thing is working and it's stalled. its growth. Is stalling focus in on that. Well it seemed kind of capricious. If i if once i could step back and say oh the tradeoff change. You've got this exploration phase expansion phase. If you don't notice that you've made the difference in you keep exploring trying out this and that you miss the opportunity to expand and underneath as a as a kind of an unspoken structure. This explore expand extract was going on all the time this culture of engineering at facebook. Is there something unique about facebook that allows that culture to work for the facebook set of products. Or would this work for any company for any set of products so facebook twenty seventeen very was very different beasts than twenty eighteen when i laughed then twenty eleven when i joined. I think the things this balance between exploring and extracting as you said that's that's a universal and and once you've gone through that curve once the natural tendency of everybody's to treat all projects like extract projects but the really successful companies feed back into more explorer projects and keep treating them as special as a different kind of project so key. Kpi's for example is a great thing to have in extract You know what the levers are you know. If you increases by four percent that goes down by six percent Whatever and that's fine. Kpi's in in explorer. Don't make any sense whatsoever. Talked to An ads manager who is really frustrated. Facebook's very metrics oriented company. he's an either. My projects shows zero improvement or a thousand x of what our goal was and that's very characteristic of explore projects. It's really binary and and if somebody says to you. Well we'll get a twenty percent. Roi on this completely speculative project. They're just lying either. This is going to give you zero or it's going to be spectacular and then you have to move into this expand style to find out. How spectacular did that. Answer your question. I think so. Let's go back to that depiction of the team. That builds a new feature and they go into a suck review and the first time they go into the design review. The review is is fantastic. They've built something new. It's gaining traction. And this the second time they come into zucker view maybe a month later. They've been doing the same thing. It's working but the review is not as positive. Help me help me understand. What what what exactly you're referring to there. Is there like some kind of adjustment that that a team needs to make win. Product is working to. They need to put it on maintenance mode to the need to start trying other new things. Wh what's what's going on in that in that shift. I i see so no. They don't need to put it into maintenance mode and no they don't need to explore more. What they need to do is to take a live video. as as an example it launched. It was far more successful than than people expected and it put new strains on the infrastructure. I mean at that point. Facebook had fantastic infrastructure. But even at that live video was not like latency was too long. The number of successful connections of the percentage of successful connections was too low and yet were people on the team wanted. Okay now we wanted to continue exploring. And so i had a conversation with folks on the team i said hang on. The game has changed. This is not about finding the next feature that might drive growth. You already have the feature that driving growth but the infrastructure is impeding that growth. So you need to say we yes we will get to all those cool exploratory features when the time comes but right now. We just have to make what were doing work. And if that means cutting features or artificially reducing the demand for the product in order to get over the next scaling barrier than than. That's what we'll do another analogy..

Facebook zach Graham zucker
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

01:56 min | 8 months ago

"kent beck" Discussed on Software Engineering Daily

"Kent beck is a legendary figure in the world of software engineering. Kent was an early advocate of test driven development or t d and he popularized the idea of writing unit tests before writing code that could satisfy those unit tests a unit test isolates and tests a small piece of functionality within a large piece of software practitioners of test driven development right tens or hundreds of tests in order to cover a large variety of cases that could potentially occur within their software when kent beck joined facebook in two thousand eleven. He was fifty years old and he thought he had seen everything. In the software industry. During facebook bootcamp kent started to realize that facebook was very different than any other company. He had seen facebook boot. Camp is the six week on boarding process that every new hire learns about the software practices of the company through after graduating from facebook. Bootcamp can't begin to explore facebook's codebase and culture. He found himself rethinking. Many of the tenants of software engineering that he had previously thought were immutable. Kent joins the show to discuss his time at facebook and how the company's approach to building and scaling products thoroughly reshaped his beliefs about software engineering. Today's show is sponsored by strong. Dm if you're working from home managing gazillion ssh database passwords and coober. Nettie search is difficult. Meet strong dm. You can manage an audit access to servers databases and kuban. Eddie's clusters no matter where your employees are with strong..

Kent beck facebook Kent kent Nettie Eddie
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

01:56 min | 8 months ago

"kent beck" Discussed on Software Engineering Daily

"Kent beck is a legendary figure in the world of software engineering. Kent was an early advocate of test driven development or t d and he popularized the idea of writing unit tests before writing code that could satisfy those unit tests a unit test isolates and tests a small piece of functionality within a large piece of software practitioners of test driven development right tens or hundreds of tests in order to cover a large variety of cases that could potentially occur within their software when kent beck joined facebook in two thousand eleven. He was fifty years old and he thought he had seen everything. In the software industry. During facebook bootcamp kent started to realize that facebook was very different than any other company. He had seen facebook boot. Camp is the six week on boarding process that every new hire learns about the software practices of the company through after graduating from facebook. Bootcamp can't begin to explore facebook's codebase and culture. He found himself rethinking. Many of the tenants of software engineering that he had previously thought were immutable. Kent joins the show to discuss his time at facebook and how the company's approach to building and scaling products thoroughly reshaped his beliefs about software engineering. Today's show is sponsored by strong. Dm if you're working from home managing gazillion ssh database passwords and coober. Nettie search is difficult. Meet strong dm. You can manage an audit access to servers databases and kuban. Eddie's clusters no matter where your employees are with strong..

Kent beck facebook Kent kent Nettie Eddie
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

04:48 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"That's horrible and stop doing that so yes. I think we can write useful stories about software development process but their stories are not recipes and the person listening to the story is going a half take it in and digested and apply it in their own specific context because every single day at every single company is a different different context so of course the answer's going to be different the inputs or different last question. What do you miss most about working at facebook scale. Just that that leverage the first that first feature that i that i shipped was a civil union. Domestic partnership were became relationship relationship types so you could say i am in a domestic partnership with such and so last time i checked that was in use by a million and a half people in their a profile and that ability to have a huge impact on the world you know was was intoxicating another boot camp project i just i looked at the photos code and i thought <hes> something's a little wrong with the data fetching i can make this more efficient and and i accidentally save five million dollars a year like woah as an engineer being able to to have that kind of leverage is just amazing at the same time watching the troubles of facebook has gone through reminds me that explorer and expand or not the same as extract when you get to extract. There's a big downside and you have to stop only looking at possible improvements in metrics however you're going to measure success and you have to start paying attention to the downsides of your actions in a way that you don't when you're little and scrapping you got nothing to lose and i think that's the that's the challenge that facebook faces and and honestly if i had to put money on it i don't because everybody is so focused on impact an impact is this magic word at facebook and if you don't have impact your fired and if you do have the impact you're rewarded. Everybody's looking for that upside. Those upsides are getting smaller and smaller. The downsides are getting bigger and bigger but like culturally how ya unwind that i would guess that they won't be able to kent beck. Thanks for coming on the show. It's really fun talking to you my pleasure when i was in college i was always looking for people to start side projects with. I couldn't find anybody so i ended up working on projects by myself and and then when i started working in the software industry i started to look for people who could start a business with and once again. I couldn't find anyone so i started a business myself and that's the podcast you're listening to but since then i've found people to work with on my hobbies and in my businesses and working with other people is much more rewarding than working alone. That's why i started find. Find collapse fine collapses a place to find collaborators and build projects on find collapse dot com you can create new projects checks or join projects that are already going. There are topic chat rooms where you can find people who are working in areas that you're curious about like crypto currencies france's or react or coober netease or view jay s or whatever software topic you're curious about and we now have get hub integration so it's easier than before to create a find collapsed project for your existing get hub projects if you've always wanted to work on side projects or you wanna find collaborators for your side projects checkout find ca labs. I'm on there every day and i'd love to see what you're building. I'd it also love if you check out what i'm building. Maybe you'd be interested in working on it with me. Thanks for listening and i hope you check out find collapse uh-huh <music> <music> and..

facebook kent beck engineer france jay s five million dollars
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

05:31 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Breath not every startup has the growth pressures and the opportunity that facebook facebook has but there are definitely engineering practices that the average company can adopt from facebook. What are those engineering practices. What should the average startup the average company take away from facebook y- e._m._i. Snap answers nothing. People should figure out what their style is and do their style so i've been talking talking about software process for a long long time and something i notice is there are people who are uncomfortable taking responsibility and i'm one of those in my mind not not so saying moments. They want a process where they can say well. Oh hey we executed the process. We fail but you know we we executed the process and i think losing that and realizing sizing that there's no such thing as a technical success that you're all in it together and that your processes your process and you should play with it. You should experiment with it. You should try out a bunch of ideas but in the end it needs to be yours ours. I think that's the that's the real lesson facebook did that. They did things that weren't conventional not because because they were unconventional but because it made sense in the facebook context and everybody should be doing that not copying you you know spotify is the flavor of the month will. Let's copy this spotify. Manuel spotify didn't copy the spotify model so what makes she think. Copying is the right thing to do that said that there are some intriguing engineering policies that i wouldn't have have imagined would work that ended up working quite well like this allocation process where you got hired into the company and you chose your team from among the teams that had available headcount except there's short tangent when i when i got there teams would be over over or under staffed compared to their headcount quite regularly and that was a good thing <hes> the the team i eventually ended up joining being built in i called culture infrastructure built the internal tools and some managers were very happy that they were going to have a headcount allocation into all that would stop teams from like poaching engineers and i this is this is ridiculous like yes. It can't be random <hes> but if ninety percent of the engineer earth if ninety percent of the teams have sort of the number of people that we plan for them to have a year ago. Oh that's gotta be good enough or maybe the right number is eighty. If a hundred percent are adhering to decisions that were made on average six months ago. That can't be right so that was yeah. That was an interesting conversation that the day that came up. It's like oh we can enforce force our policies. I'm like maybe we shouldn't give him the you spent much of your career before facebook and during your time at facebook articulating software processes and despite that every pre pre-established notion that you had about software engineering was called into question in your first week at this new company penny. Does it make you question. What are we even doing writing books about software analysis software software practices and extreme programming. Can we really even say or code complete. Can we really even say anything concrete about a design practices or kanban planning or or anything. What can we even be sure of we you you can only be fairly certain certain of the things you've tried yourself in your contacts and only as at those decisions are like fish a month later you don't you should definitely questioned their value so if you if you let go of this well you know what's what should our process be and say what should our process ashby ford <unk> for refining our process if you let go of the need for an answer and you embrace answering answering as a continuous process than i don't think you can do better than that so that's part of my answer. The other part of my answer is just because because there isn't one way that works there are a bunch of ways that work really badly. There are a few ways that work well night think of them as as attractors actors in the space of process a few ways that work well and there are a whole bunch of ways that work horribly and the first thing to do is identify fi where you're doing something..

facebook spotify Manuel spotify engineer ninety percent hundred percent six months
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

04:29 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"I was there when i got there. Engineers veneers all at all levels were expected to exercise a lot of initiative. There's a beautiful article by you. Shanggong about facebook's books early engineering management philosophy and i can't recall the title of it. Maybe we can find it later but the upshot is is facebook deliberately chose to make engineering easier and engineering management harder. If there was ever a trade off they would make make the managers life harder and the engineers life and job easier and so- managers. The first role is to attract talent. A manager got a headcount allocation for their team but that was really loosey goosey in the early days just because you had allocation didn't mean the at engineers you you had to sell your project and if you couldn't then you didn't get any engineers veneers your product. Your project just didn't go anywhere. Nobody was going to force an engineering work on your team so the managers who had bad teams or they were bad managers. People just go do something else so managers tended to get weeded out quickly in in a way that i didn't expect to see so a certain amount of arranging for technical collaboration again. Dan was on the engineers to organize their work together. For the most part and differ managers were different. Some were more hands on technically technically and saw some less so to negotiate four <hes> headcount allocation and to end and can career encouragement for <hes> for engineers so advocating for engineers and the performance review process what distinguishes mark zuckerberg as a leader so i did not miss of a weekly q._n._a. For the first four or five years because something new for me would come out every week. It's a combination of in the this is in fact act. I never met him face to face in seven years there so i can't i don't have any of those good stories this implicit understanding <hes> that projects go through these phases and taste for when to shift gears like when when is when is something a blip hip and win. Is something a genuine evidence that this is worth expanding. There's a sometimes it's dead obvious and sometimes it isn't another is a willingness to abandon metrics that have served their purpose. That was a big surprise to me okay time. The interaction is good enough if now don't let it slip but that's not the priority anymore i was used to the the monty python style where the most important metric forgive a and b the most important metrics are a. b. and c. Right would just get piled on piled on and so to see see him. Stand up and say yes. We've harped on this issue and we're not gonna do that anymore. I thought was really remarkable. He's he's also very good at attracting very good people so so somebody doesn't get talked about in the facebook story is jeff rothschild who was an an the the early adult supervision engineer somebody exceedingly worth listening to there's a fantastic video presentation that he gave this only available inside of facebook that i insisted all my students watch because it was just like no this is concentrated concentrated essence of engineering right here and you're not gonna get this anyplace else but he was attracted to this project. I think there's a kind of there's there's a kind of geek charisma to the way <hes> zach presented so engineers would not roll their eyes mike. I think there's a there's a knack to establishing a presence in a room full of engineers and he definitely had that space.

facebook jeff rothschild mark zuckerberg zach Dan engineer seven years five years
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

04:47 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Engineers. He's had many many other forms of feedback so you'd right on your development server and you'd try stuff out and then it it would go through code review <unk> second form of feedback and then it would at that point it would roll to the internal site so you get more feedback from that and then it would go through the deployment process where it would get rolled out to a small number of machines and then more and more and you get feedback from that and then a logging and <hes> like operational awareness was just part of the engineering culture so oh you'd get feedback post production of like how your feature actually was was behaving so there's a bunch of feedback loops in place unit tests occupied for most development of facebook just the cost benefit the the the amount of feedback they added in the timeless timeliness of that feedback and the cost of achieving that feedback just wasn't worth it the so in in bootcamp you're supposed to put <unk> code in production the first week and i was very careful to write tests than do everything properly so i got in a fair amount have of he got fair amount of heat because my first feature didn't land for three weeks and people are like well you know. I don't know how this is gonna work out when i was i was wondering that too. I had a huge case of imposter syndrome when i when i landed at facebook and realize just how different everything was and then the tests that i had written broke almost immediately and they were deleted that was one of the things that surprised if if you had if you had a test and it failed but the site was up they'd just delete the test if you had tests that were intermittent that that were non deterministic there were just deleted and at first. I was shocked like old delete a test. This is producing noise and it's not producing signal. If you eliminate this this noise production per definition the situation is clearer all of a sudden the fact that you kind of wish i the you add a test for something well. You didn't and so yeah just chuck it. Let's move on now. You probably wouldn't wanna take that approach to new nuclear power plants software or electricity grid software. That seems like a practice that is uniquely useful for kind of early facebook where this thing wasn't yet a communications utility. It was more of a a fun thing to do akin to television so there's another lesson i learned facebook is the difference between reversible and irreversible reversible decisions so if you if you roll out a feature in new zealand say and people don't like it and you can uneasily turn it off then that's a reversible decision facebook engineering spent a lot of effort on one making decisions reversible like sometimes you have to do quote unquote extra engineering to make a decision reversible talked with <hes> one of the managers in network infrastructure and he said when they got a new piece of networking gear in it went to the characterization labs just to i'd like put it through its paces. They mostly didn't care about its performance what they cared about was. Can we turn this thing off safely so and that's an investment in reversibility all the feature flag stuff. That was one of the lessons i had to learn people in code reviews would say oh. You definitely definitely need to put this behind. A feature flag will what why my attitude is. Lemme test it make sure that it works and then i'll just put it out well. The learned hard learned wisdom. There was ee. There's a bunch of stuff. You can't test for so yes you have to introduce additional complexity to to put the flags in but if you don't you're going to roll something out and the you're only recourse is going to be a hot fix rollout which makes the release engineering grumpy and you did not wanna make release engineering engineering grumpy. What's the role of a manager at facebook so that changed the fairmount in the time..

facebook chuck three weeks
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

04:50 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Service. This facebook was so open to exploring new technologies and picking up random key value stores. Why haven't they adopted any cloud technologies allergies because nothing works at that skit facebook scale nothing off. The shelf works at facebook scale. If you buy networking equipment facebook facebook is going to put that equipment through hell in a way that nobody else does how just like and and that is just. That's a consequence of working working at this unprecedented scale. It wouldn't make sense for a vendor to make a product good enough for facebook because has the they they only. Have you know they would only have three customers in the world. It's much better for them to have a product. That's not quite as capable capable and they can sell thousands of people so how did facebook but i'm not sure if you're the person ask but since you kind of had a tour of the company company how did facebook adapt to unprecedented scale in the expand phase in these vertical growth phases where you're you're hitting unprecedented unprecedented barriers to growth they had the world's leading technical expert available available to jump in this another part of facebook engineering culture that maybe a little subtle so that person was working on some extract act project that was very profitable you know so you're tuning some database say or or <hes> improving some network equipment or something like that that project they're working on very profitable and they but that engineer here's over hear somebody talking about whatever's failing lying about the hot new feature and it's their responsibility because nothing is facebook is somebody else's responsibility. Is their irresponsibility say oh i would like to work on that and that engineer then says to their manager hey. I'm going to go work on this. It's growing quickly. It's their manager's job than now. The the the ba- you're leading technical expert just told you that they're off. The project checked to work on this thing which even hasn't even achieved scale yet. It's just growing fast. It's that manager's job to say. Okay good bring bring in the next person and to take over whatever important responsibilities that that that expand her just left behind in order to jump on the next the piece of of scaling that otherwise wouldn't happen. Did that answer your question. Yeah does so when you joined facebook. My understanding is that around that time facebook really didn't have much testing and and it's kind of ironic because you were the creator of extreme programming it was highly dependent on the process of writing writing unit tests and then writing the features facebook clearly reversed that process and was able to be successful despite the fact that they wrote wrote their features before they wrote their their tests. You often hear that you need unit tests in order to build things like continuous integration continues to degration. Lets you move much faster because you have this battery of unit tests that runs every new build but i don't think they have that stuff until later how is facebook able to move so fast with such a low amount of unit testing yes so that was that i was part of the puzzle one when i arrived one of those hey this isn't what's in the books and yet it seems to be working and the answer that i came mm two is that while there's a couple parts of it one is how many of your problems can you test four and how many problems only show up in production so if if problems like if you're writing simple calculation but it might not scale in production action you you can't write unit tests for it so the facebook answer is don't that's part of it is depending on the ratio of how many problems is it possible to test for before production versus after if that ratio is skewed towards hey steph steph only fails in production then don't write any tests. The second part of the answer is tests are a form of feedback and facebook engineers..

facebook engineer
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

01:34 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Move into this expand band style to find out how spectacular they get lab. Commit is get labs. Inaugural community event get lab is changing how people think about tools and engineering best practices this and get lab. Commit in brooklyn is a place for people to learn about the newest practices in devops and how tools and processes come together to improve improve the software development life cycle get lab. Commit is the official conference forget lab. It's coming to brooklyn new york september seventeenth twenty nineteen if you can make brooklyn on september seventeenth mark your calendar forget lab commit and go to software engineering daily dot com slash commit it. You can sign up with code. Commit s. e. d. that's c. O. m. m. i. t. s. e. d. and save thirty percent on conference passes. If you're working in devops and you can make it to new york. It's a great opportunity to take a day away from the office. Your company will probably pay for for it and you get thirty percent off. If you sign up with code commit s._a._d. They're great speakers from delta airlines goldman sachs northwestern mutual t mobile and more check it out at software engineering daily dot com slash commit and use code. Commit it s e d thank you to get lab for being a sponsor..

brooklyn devops goldman sachs northwestern delta airlines new york official c. O. m. m. thirty percent
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

02:58 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Kent beck welcome software engineer daily. Thank you very much jeff. It's a pleasure to be here. You joined facebook in twenty eleven. What did you initially do at the company. So oh a toward the end of twenty ten. I got a call from a recruiter at this company facebook which was like it was known to be very successful but it wasn't like a thing especially in the engineering world and i went and interviewed and i saw an engineering culture. That was very very different than anything that i had seen before and so i know my last interview of the day was with mike trump for and i said you know this. This culturally is unique but maintaining it and evolving is going to be hard work and i would like to come and do that so my initial pitch to the company was as kind of a culture carrier amplifier observer commenter tweaker. What makes you say that the facebook culture as of twenty eleven would be hard to scale bill so what was clearly going to be hard to scale was avoiding mean reversion so it was two thousand employees total seven hundred engineers. I was obviously going to grow very quickly as these things do in the valley and a bunch of the people they were going to hire in then would be coming in from the googles and microsofts of the world and would bring a very different set of values and a very different set of practices and and would be the natural tendency would be for facebook engineering culture to just revert to the kind of the least least common denominator which everybody seems like that's that's the attractor everybody falls back into lots of planning and in long cycles and more handoffs and bigger batches and all the stuff that makes short-term small-scale sense in that in kills long-term effectiveness talk about that in more detail. It sounds like you have a perspective that there's some kind of overly process s. laden engineering structure that is endemic to companies get big and not even as they get big so so sometimes they start out that way which really astonishes me. Why would you put the shackles on before you dove into the pool the first time that doesn't make any sense but every software process has to be shaped by context and facebook's context was in some ways absolutely unique because you had the scaling component opponent just insane trying to make computers do things that they had never done before in terms of the number of people and the.

facebook Kent beck software engineer jeff mike trump
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

01:35 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Kent beck is a legendary figure. In the world of software engineering kent was an early advocate of test driven development or t. d. and and he popularized the idea of writing unit tests before writing code that could satisfy those unit tests a unit test isolates and tests a small piece lisa functionality within a large piece of software practitioners of test driven development right tens or hundreds of tests in order to cover a large variety heidi of cases that could potentially occur within their software when kent beck joined facebook in two thousand eleven he was fifty years old and he thought he had seen everything in the software industry during facebook bootcamp kent started to realize that facebook was very different than any other company he had seen facebook. Boot camp is the six week on boarding process that every new hire learns about the software practices of the company through after graduating graduating from facebook bootcamp can't begin to explore facebook's code base and culture he found himself rethinking many of the tenants of software engineering during that he had previously thought were immutable kent joins the show to discuss his time at facebook and how the company's approach to building and scaling products thoroughly thoroughly reshaped his beliefs about software engineering when i'm building new product g two. I is the company that i call on to help me.

facebook Kent beck fifty years six week
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

04:48 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"That's horrible and stop doing that so yes. I think we can write useful stories about software development process but their stories are not recipes and the person listening to the story is going a half take it in and digested and apply it in their own specific context because every single day at every single company is a different different context so of course the answer's going to be different the inputs or different last question. What do you miss most about working at facebook scale. Just that that leverage the first that first feature that i that i shipped was a civil union. Domestic partnership were became relationship relationship types so you could say i am in a domestic partnership with such and so last time i checked that was in use by a million and a half people in their a profile and that ability to have a huge impact on the world you know was was intoxicating another boot camp project i just i looked at the photos code and i thought <hes> something's a little wrong with the data fetching i can make this more efficient and and i accidentally save five million dollars a year like woah as an engineer being able to to have that kind of leverage is just amazing at the same time watching the troubles of facebook has gone through reminds me that explorer and expand or not the same as extract when you get to extract. There's a big downside and you have to stop only looking at possible improvements in metrics however you're going to measure success and you have to start paying attention to the downsides of your actions in a way that you don't when you're little and scrapping you got nothing to lose and i think that's the that's the challenge that facebook faces and and honestly if i had to put money on it i don't because everybody is so focused on impact an impact is this magic word at facebook and if you don't have impact your fired and if you do have the impact you're rewarded. Everybody's looking for that upside. Those upsides are getting smaller and smaller. The downsides are getting bigger and bigger but like culturally how ya unwind that i would guess that they won't be able to kent beck. Thanks for coming on the show. It's really fun talking to you my pleasure when i was in college i was always looking for people to start side projects with. I couldn't find anybody so i ended up working on projects by myself and and then when i started working in the software industry i started to look for people who could start a business with and once again. I couldn't find anyone so i started a business myself and that's the podcast you're listening to but since then i've found people to work with on my hobbies and in my businesses and working with other people is much more rewarding than working alone. That's why i started find. Find collapse fine collapses a place to find collaborators and build projects on find collapse dot com you can create new projects checks or join projects that are already going. There are topic chat rooms where you can find people who are working in areas that you're curious about like crypto currencies france's or react or coober netease or view jay s or whatever software topic you're curious about and we now have get hub integration so it's easier than before to create a find collapsed project for your existing get hub projects. If you always wanted to work on side projects or you wanna find collaborators for your side projects checkout find ca labs. I'm on there every day and i'd love to see what you're building. I'd it also love if you check out what i'm building. Maybe you'd be interested in working on it with me. Thanks for listening and i hope you check out find collapse uh-huh <music> <music> and..

facebook kent beck engineer france jay s five million dollars
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

04:50 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Service. This facebook was so open to exploring new technologies and picking up random key value stores. Why haven't they adopted any cloud technologies allergies because nothing works at that skit facebook scale nothing off. The shelf works at facebook scale. If you buy networking equipment facebook facebook is going to put that equipment through hell in a way that nobody else does how just like and and that is just. That's a consequence of working working at this unprecedented scale. It wouldn't make sense for a vendor to make a product good enough for facebook because has the they they only. Have you know they would only have three customers in the world. It's much better for them to have a product. That's not quite as capable capable and they can sell thousands of people so how did facebook but i'm not sure if you're the person ask but since you kind of had a tour of the company company how did facebook adapt to unprecedented scale in the expand phase in these vertical growth phases where you're you're hitting unprecedented unprecedented barriers to growth they had the world's leading technical expert available available to jump in this another part of facebook engineering culture that maybe a little settle that person was working on some extract act project that was very profitable so you're tuning some database say or or <hes> improving some network equipment or something like that that project they're working on very profitable and they but that engineer here's over hear somebody talking about whatever's failing lying about the hot new feature and it's their responsibility because nothing is facebook is somebody else's responsibility. Is their irresponsibility say oh i would like to work on that and that engineer then says to their manager hey. I'm going to go work on this. It's growing quickly. It's their manager's job than now. The the the ba- you're leading technical expert just told you that they're off. The project checked to work on this thing which even hasn't even achieved scale yet. It's just growing fast. It's that manager's job to say. Okay good bring bring in the next person and to take over whatever important responsibilities that that that expand her just left behind in order to jump on the next the piece of of scaling that otherwise wouldn't happen. Did that answer your question. Yeah does so when you joined facebook. My understanding is that around that time facebook really didn't have much testing and and it's kind of ironic because you were the creator of extreme programming it was highly dependent on the process of writing writing unit tests and then writing the features facebook clearly reversed that process and was able to be successful despite the fact that they wrote wrote their features before they wrote their their tests. You often hear that you need unit tests in order to build things like continuous integration continues to degration. Lets you move much faster because you have this battery of unit tests that runs every new build but i don't think they have that stuff until later how is facebook able to move so fast with such a low amount of unit testing yes so that was that i was part of the puzzle one when i arrived one of those hey this isn't what's in the books and yet it seems to be working and the answer that i came mm two is that while there's a couple parts of it one is how many of your problems can you test four and how many problems only show up in production so if if problems like if you're writing simple calculation but it might not scale in production action you you can't write unit tests for it so the facebook answer is don't that's part of it is depending on the ratio of how many problems is it possible to test for before production versus after if that ratio is skewed towards hey steph steph only fails in production then don't write any tests. The second part of the answer is tests are a form of feedback and facebook engineers..

facebook engineer
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

02:58 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Kent beck welcome software engineer daily. Thank you very much jeff. It's a pleasure to be here. You joined facebook in twenty eleven. What did you initially do at the company. So oh a toward the end of twenty ten. I got a call from a recruiter at this company facebook which was like it was known to be very successful but it wasn't like a thing especially in the engineering world and i went and interviewed and i saw an engineering culture. That was very very different than anything that i had seen before and so i know my last interview of the day was with mike trump for and i said you know this. This culturally is unique but maintaining it and evolving is going to be hard work and i would like to come and do that so my initial pitch to the company was as kind of a culture carrier amplifier observer commenter tweaker. What makes you say that the facebook culture as of twenty eleven would be hard to scale bill so what was clearly going to be hard to scale was avoiding mean reversion so it was two thousand employees total seven hundred engineers. I was obviously going to grow very quickly as these things do in the valley and a bunch of the people they were going to hire in then would be coming in from the googles and microsofts of the world and would bring a very different set of values and a very different set of practices and and would be the natural tendency would be for facebook engineering culture to just revert to the kind of the least least common denominator which everybody seems like that's that's the attractor everybody falls back into lots of planning and in long cycles and more handoffs and bigger batches and all the stuff that makes short-term small-scale sense in that in kills long-term effectiveness talk about that in more detail. It sounds like you have a perspective that there's some kind of overly process s. laden engineering structure that is endemic to companies get big and not even as they get big so so sometimes they start out that way which really astonishes me. Why would you put the shackles on before you dove into the pool the first time that doesn't make any sense but every software process has to be shaped by context and facebook's context was in some ways absolutely unique because you had the scaling component opponent that was just insane trying to make computers do things that they had never done before in terms of the number of people and the.

facebook Kent beck software engineer jeff mike trump
"kent beck" Discussed on Software Engineering Daily

Software Engineering Daily

01:35 min | 2 years ago

"kent beck" Discussed on Software Engineering Daily

"Kent beck is a legendary figure. In the world of software engineering kent was an early advocate of test driven development or t. d. and and he popularized the idea of writing unit tests before writing code that could satisfy those unit tests a unit test isolates and tests a small piece lisa functionality within a large piece of software practitioners of test driven development right tens or hundreds of tests in order to cover a large variety heidi of cases that could potentially occur within their software when kent beck joined facebook in two thousand eleven he was fifty years old and he thought he had seen everything in the software industry during facebook bootcamp kent started to realize that facebook was very different than any other company he had seen facebook. Boot camp is the six week on boarding process that every new hire learns about the software practices of the company through after graduating graduating from facebook bootcamp can't begin to explore facebook's code base and culture he found himself rethinking many of the tenants of software engineering during that he had previously thought were immutable kent joins the show to discuss his time at facebook and how the company's approach to building and scaling products thoroughly thoroughly reshaped his beliefs about software engineering when i'm building new product g two. I is the company that i call on to help me.

facebook Kent beck fifty years six week