Alex Martelli, ""Good Enough" IS Good Enough!", PyBay2016

I hope they thesis I'm going to present actually holes cuz I'm not at my best but I hope I'll be good enough so you can get to the PDF of the talk at to that URL and you can always contact me at my Google Chrome address one thing I always like to do is to introduce levels that I'm addressing I think taxonomy is one of the great disasters of humanity so having to classify as one of three levels is absolutely absurd because I cover a certain range of levels incidentally the shoe hurry trichotomy eel comes from the know theater it was then applied to Aikido and other martial arts there's a stage where you learn the stage where you start detaching from the learning and then there's a state where you transcend the learning I believe the Western thought has a similar concept it was presented at the pro bad programming talk as a five level pyramid trying to draw distinctions between stages of learning and detaching but I think three are good enough so that's what I'm going for and if you've never thought at all about the nature of reality and technology you may not get much out of our talk at the other extreme if you've thought about it for more decades than I do then you'll probably be bored to death but I hope I'm still addressing most people so let's start by calibrating by show of hands who would roughly agree with this statement everybody should always be striving for perfection at all times any release that's not perfect is a waste of time do you mostly agree anybody show of hands whew the alternative extreme would be let's keep it simple just good enough keep launching lunch early lunch often get feedback listen improve interactively enhance refactor rinse repeat who mostly subscribes to this philosophy great I'm preaching to the choir my favorite kind so I presumably want one get much pushback so I chose although it wasn't really the first one to to choose the presentations start the presentation from Richard Gabriel a keynote at a lisp conference in 89 titled worse is better it was intended as a humorous interlude in a very deep serious technical conference where Gabriel presented and contrasted what he called the New Jersey approach also known as worse is better and the MIT Stanford approach also known as the right thing you can tell no by us there oh so after that intended as a quip short presentation years by now decades of debate have followed kindled by mr. Gabrielle himself which posted on both side of the issues sometimes using they not exactly secret pseudonym of Nicky Ben Bourbaki let's frame the debate in the simplest terms everybody agrees there are good characteristic of a system say a software release it doesn't have to be softer but software is mostly what he was talking about what we're talking about we all like simplicity correctness consistency and completeness four dimensions are a lot on which to optimize so the distinction comes in with how to exactly define each of the terms and what are the priorities when an if trade-offs are needed in worse is better simplicity focuses on implementation think of the then of Python import this at a Python prompt I'll forgive you for pulling out notebooks if you don't really remember it if it's simple to implement it's a good if it's complicated to implement it's a bad thing if it's simple to implement it may be a good thing that's one of the principles of Python also of course interface but implementation simplicity is crucial because it lets you be reasonably assured you all will not have bugs or fewer bugs and things and simplicity is the most important consideration in your design correctness matters but if you have to choose rather be simple than correct that's the worse is better by the way Gabrielle never mentioned the magic word UNIX but new jersey approach definitely pointed at the Bell Labs where you need what UNIX was emerging as the operating system to rule the world the level of consistency required is to not be overly inconsistent so it's not particularly demanding and completeness can be sacrificed to any of the other three and must be sacrificed rather than compromising simplicity simplicity simplicity simplicity the right thing also known as the MIT or Stanford approach focuses on simplicity of interface correctness as the absolute must the top priority of software development completeness important roughly as important as a simplicity but you can see the priorities are not exactly the same in the definition of simplicity varies so what's the trade-off between the two overall approaches well the right thing philosophy is based on letting the experts do their expert thing all the way to the end before users get their hands on it it didn't say grubby dirty little hands but it's obviously implied in the phrasing the experts know what's right and let them do it rather than having common people mess with it the worse is better takes advantage of the the rippity encoding so take advantage of natural advantages sounds a bit goofy but I think is good enough and it's not my fault anyway our incremental development and grudgingly admitting incremental improvements satisfies some human needs Oh G dark shall we let the expert do their expert thing or satisfy human needs what a difficult choice to make as I don't know if you familiar at all with GK Chesterton one of the great novelists of 20th century Britain they father brown stories in particular are absolutely also one of his quotes is anything worth doing is worth doing badly which kind of supports they in favor of bad programming thing the point is is worth doing badly because this way you reach some people earlier than if you wait until you're perfect which will never happen but if you keep striving for perfection you'll never actually release incidentally I had that in during one of the presentations of the Stoker somebody finally saying oh I see so that's why you're using Comic Sans well it's not as bad as that I don't use Comic Sans I use Apple chalkboard and you can debate whether Apple can do visual design at all I think they have a good proven track record so I'm going to stick with them but that's so that's not a part of the doing badly thing in them like completely off from the side of this mainstream debate Eric Raymond the guy who's widely credited with coining or at least popularizing the term open source' in is the 97 book and previously on the web and in conferences showed two models of software development based on a different distinction but they're pretty much aligned the cathedral and the bazaar is also the title of his excellent book dated by now but it still applies to the way people develop software and you know while software has changed a lot people haven't that much we're still on the 1.0 beta release and upgrades are late incoming for human beings so we'll have to deal with them or with us rather but the cathedral is close to the so-called right thing approach experts are in charge they drive control they know what's right because hey they're experts in the bazaar it's a chaotic launch and iterate new very new jersey like model the crowds in charge so that's pretty much the New Jersey approach the core bizarre idea is actually focused on bugs at least it's really a big part of the motivation for going cows like bizarre like given enough eyeballs all bugs are shallow if an even an expert can be staring at a piece of code which he knows isn't working right even though he's designed the code himself actually it especially if is being the designer he may be too close to actually understand what the flip is going wrong but give another thousand people the motivation and the ability to stare at the same piece of code somebody will spot the back given enough eyeballs or bugs or she'll now some people may think this particular consideration doesn't apply to them because they never have any bugs and if I'd only it had only written one program in my lifetime I probably would agree because in 1974 I wrote my first ever program I was a freshman like I and two others our team of three people three freshmen in Hardware design we wouldn't get any software course except the mandatory in Fortran so we got advantage too of that to study up on four channel the reference bangle and then we were both we were all bridge fanatics and antics of the game of contract bridge and we thought hey we could compute conditional probabilities of suit division given everything wouldn't that be cool we had one chance to punch everything in two punched cards and then one chance to run it forget testing there's no such thing because that would require more than one run it has to be right the first time I think in the process we reinvented approaches more than pair programming we did triplet programming because while one guy who was carefully digitizing the other two had eyeballs earned that act you shouldn't take this and so on and that was my bug-free program I think you either get one per lifetime or one per 40 years in which case I'm due for another one soon and but but I'm not counting on it so there's more about it if you think your goal is perfection from the start you need what's known especially in the agile community as big design up front bduf be tough it sounds funny and it's supposed to you need big design up front because this way by the time you have actually got software running it's gonna be perfect as it must be everything must proceed top-down you perfectly identify all the requirements for your software before you don't anything about it then this gives you a perfect architecture which from which follows a perfect design firm which follows a perfect implementation and it takes forever and ever Amon so you've got a problem with that real life doesn't cooperate in particular stakeholders whoever's supposed to be using a program or if it's a commercial endeavor selling your program kind of objects to the forever part but to do it this way truly does take forever so what do you do instead what are you doing the real world well first of all you realize that that requirements change all the time there is no way to capture once and for all every single requirement of your program because by the time you're finishing even just the requirement analysis the requirements are already changing from under your feet tempura mutant or at requirements mutiny needless to paraphrase a famous Latin verse then architecture determines design but design choices feedback to make you want to tweak your architecture is not a waterfall there are all sort of loops back an implementation always have some box well always etc the once in 40 years case where it doesn't but you're only going no matter how careful you are in testing and specifying and so on you're only going to discover your box when you deploy in the real world there's a famous anecdote from the mailing list risks the risks of computers about an ambulance system that since it was alive in that situation understandably was designed to never have a bug in the implementation so it had a specification in a formal language I think it was Vienna could had been said one of the formal languages that were all the rage in the 80s and the implementation was mathematically proven to respect the specification it was launched and mostly worked well and once in a while they got desperate people who had just called 911 or whatever the local number would have been and for somebody having a heart attack and the responder had promised an ambulance and no ambulance ever showed up it kept happening so somebody went and checked surely we've specified against this well one of the specification says from the triggering moment the ambulance must be on location for this kind of emergency within 15 minutes so it specified well there's a problem with formal logic if you say from a must follow B then it means that not B must imply a given the ambulance is traveling on real streets with real traffic you cannot actually guarantee 15-minute so say that given crazy traffic the ambulance would normally get there in 15 minute in one second well when 15 minute trigger the ambulance isn't there so the logic in the system determines it must never have been called that's logic for you if it had been called it would have been there in 15 minutes it's 15 minutes is not there so it can't have been called so it gets rerouted so obviously being perfect in your specification and implementation doesn't actually work in the real world not if you're meeting any real-world constraints such as traffic traffic can completely aura maybe there's an accident or something can completely block you so the only way to go is iterative development you must deploy something find out the bugs fix the bugs missing features and them improve things just solve some user problems don't try don't even try to solve every user problem from the start because you don't know what they are and they will be changing so backwards incompatibility is your friend we've heard Raymond I don't know if is around explain that we can never afford it in the Python core well fortunately we can we could in the past I sure hope we still can because guess what the original design wasn't perfect we had mistakes and we had to fix them in backwards incompatible way and minor that incompatibilities kept happening on every release just not too many at the same time when a big bunch of backwards incompatibility became necessary we moved from Python to two to Python 3 the point is if you're constrained to remain backwards comfortable forever your hosts you're really really wholesome one little mistake you made 25 years ago will haunt you forever you have to be able to fix your mistakes those early stage design errors good enough is good enough if and only if you can make it better later one example you used to be able to raise a string which makes absolutely no sense but was in the early design of Python now you can't anymore if you try the race statement will inform you that you have a type error because you might the only thing you can raise is an exception not a string which makes much more sense so that's backwards incompatible it's how the this particular incompatibility was introduced in 2.6 in the hope that nobody was still raising strings instead of exceptions after all these years another way to think about it is think of perfect as a verb not as an objective perfecting your work is great keep doing it keep perfecting as in improving and moving to Ward's a better release n the only way you can do it productively is to have real data if nobody is using your program you don't really know much about it so you need to be out you need to have a release and real people using it if you can find any real people perfection is a process it's never a state you never reach section you keep moving towards it and as you do the goal posts keep shifting because people need change even when just by using your software they realize some needs some desires they didn't realize before your software we're solving some problems because solving certain problems uncovers others which is why you keep improving and releasing there's never any laurels to rest on so take that into account and release early release often this doesn't mean you just hack something together with no care for any aspects of quality there are things you do not want to skimp on ever first of all some lightweight process just hacking with no rhyme or reason for half an hour when you have nothing better to do or are finding some excuse to procrastinate another stuff is not good you need a lightweight process I'm not recommending something that holds you rigidly like an armoire or something just some lightweight process with well-defined steps and the number one thing you should never be without is a revision control system I mean it I keep getting now that I lead a support group ap keep getting people say okay so I uploaded this program to to your cloud and I need to make a fix but I've lost to the source code can i download the source code again like you what you lost to the source code don't you have it in I don't care subversion git mercurial wait revision control system is a second-order problem you must have some so that you can know what was going on before and you can check it out and and improve and check in the revised version unless you're all alone and even then code reviews are the second most important things in software development you shouldn't skimp on them I've had in the past the experience of developing real relatively complicated pieces of code on my own because I just couldn't get anybody else interested in both the subject area contract bridge and the development to like do code reviews for me so what I did I did code reviews for myself specifically i furnish myself with a rubber ducky very recommended accessory for any software development and after it finished a module or improved a function or something I put the rubber ducky next to me and explained to the rubber ducky exactly what I had been doing as in a interactive code review process you know what it helps I'm not going to say the rubber ducky spotted problems but maybe did but in this case it was keeping its it's quite but as I explained what I had been doing and why sometimes so I spotted the problem which I wasn't spotting when when actually coding it because I don't know I guess I'm no psychologist but there must be slightly different mental mechanisms involved in doing something versus explaining it so the explaining part is if you can't get a real code review the next best thing and you shouldn't do without it even if you have to develop something all on your own review it with your rubber ducky I am sure somebody will prefer teddy bears or so on that that's a technology discussion that that we can have separately much some appropriate soft toy I I think it should be soft if you try to explain the thing to that beautiful Python toy which isn't soft is probably gonna stare at you coldly and you'll well anyway sorry and third absolutely crucial thing possibly on a par with the other two is testing I've heard that one one thesis I've heard in the bad software talk which I strongly disagree with is that sometimes you can skip testing I have never found a case where that was the case it actually doesn't take you extra time it saves you time because the earlier you find a bug the faster by far it is to fix besides having done no damage at all if you don't have tests all the bugs will be found by end-users possibly losing their data or sending their credit card on the open net or other pleasant experiences you don't really really want to apply that they also very important but possibly hardest for all of us because it's never really taught properly is to follow proper release engineering procedures which include the ability to reconstruct exactly what software was running when you have a bug report because they say I do this and that happens and you try on the current release of the software and no it doesn't that doesn't mean that whoever told you about the bag is batshit crazy it means it's running in slightly different environment than you are you need to be able to reproduce the bug to have any chance of diagnosing and fixing it so you need to be able to reconstruct exactly what bit where being run on what environment and exactly how you go about it that's a whole talk on their own and I'd probably get 1/10 the audio because it's not the most exciting and interesting part of software but it's really a must if you want your software to actually help people properly is engineering next style clarity elegance you may think you're saving time by being sloppy and naming all your variables i j k l m n o p not really it's not going to help you the first time you have to go back and say what was i thinking here because if that's the kind of way you were programming you probably weren't thinking so it's kind of hard to elegance there's there's a reason we appreciate elegance it's it bespeaks of solid structure so never sacrifice that last but not least if that program is going to be used by anybody by yourself and even if you're going to be the only user document what you're doing it doesn't have to be anything fancy but at least good doc strings with doc tests inside them clear comments as to why you're doing something and then my colleagues thumb some famous comment in the original unix sources comment being you're not supposed to understand this is not the kind of thing i believe i mean it's very rough it's too clever for for normal human beings on the other hand in the Python community clever is not a compliment so don't if you find yourself wanting to write that try to be a little bit less clever you'll be grateful to follow that advice you in other words the fact that good enough is good enough is no excuse for cowboy coding it's just to take cutting is still a labor of love and you want to follow the main principles that have outlined next some things are some characteristic of your software depending on what that software is must been from the start believe me I've seen a thousand examples and all these life is a dating where the issues were not properly thought off from the first and people tried adding them later when it doesn't work and the main one is security if there's any possibility that your program your system is going to be handle data which is at all in need of security including privacy including auditability think about that from the beginning even as you sketch the first prototype why well I think the core idea is when you're doing security or it's appendices such as auditability and privacy you're mentally fighting against an adversary would be blackhat who'd like to get at I don't know financial data health data whatever it is that you need to keep secure and private and auditable maybe they'd like to skim some money off people's accounts and hide it so audits won't show it so you're going to be in a difficult position anyway because you are going to be fighting against an adversary you don't really know and who might well be as clever or more than you are and single-minded focusing on exploiting any weakness in your software that's what makes security such a difficult problem there are so many vectors of attack therefore the very least you can do is think about it from the start believe me if you have a successful program which is just about perfect except that anybody can hack in and then just get all the data about I don't know all the appointments this person has there by deducing something about their professional activity or whatever it is the appointments are going to do in breaker privacy and so on you are going to regret it your attempts to fix it after the fact by working security in that wasn't there from the beginning are more likely going to fail to more than likely going to fail to a strong determine adversary many other things would be nice to have from the start but you can refactor later because you're not actually fighting again actively against an adversary so you can refactor to get modularity accept plugins have an API I love API so I think every good piece of software should have one but it doesn't need to be in the zero point one alpha release hit the street with something that works and then refactor the API scalability scalability is crucial hey I work at Google we think that your application is only a billion users count yourself lucky it's easier to to scale that to that little but it doesn't have to happen in the 0.1 alpha release you can it's easier if you've thinking of it from the start but you can because nobody's actually well you could get a denial of service attack but that's a different a different issue you can still essentially summarize you can incur technical debt don't know if you any familiar with a term technical debt is stuff that's slightly wrong with my system I know it's wrong but I need to release or I need to add a feature so I incur debt the point is not ignore it do it with care do it deliberately and plan your repayment you don't want to leave the technical debt hanging around for ever another in appendicular way of looking at it okay so I may have a matter is the error going to be recoverable focus on avoiding errors that could provide irrecoverable losses that's why all my sympathy goes through the people who are designing and implementing that ambulance system because an error in ambulance routing as unfortunately happened can cost somebody's life and you have no way to bring them back to life that's an irrecoverable error on a slightly lower plane if an error can send you into bankruptcy well it's technically recoverable you can live after that but it's getting pretty close to where you don't want to risk it but as long as you can recover you're okay just call your release beta hey we're we're pretty good at that we admit is that all sorry I'm sorry there was this bad but it was a beta you know so cool we tend to do that one bit that people tend to trip on especially ones who are hidden perfectionist as despite the show of hand I suspect a lot of us are is what about reputational damage I mean if my program as a bug news about it will spread people will think I'm a bad person about programmer they want hate they would love me anymore it'll be oxandrolone reputational damage it depends but usually reputational damage is recoverable especially if you don't like close yourself in doing the next release and ignore your bug tracker issue tracker or whatever you have and have something when you release a piece of open source software or or a commercial one of course if you do purchase PD response if you offer service to go with your program get it right the second time is usually okay I now say wait what I've written a piece of open source software I'm donating it to the world and I also have to like listen to those whiners say that'd missing this and it breaks that and I'll forget it no get the right okay now I wrote this originally before I took my current role in technical support but it was true even before I did now that I am in technical support of course I see service as absolutely crucial there's a secret to customer service not that secret there's even books about it as I indicating one they study the specific study in sage babcom was specifically about hotels but there have been other studies for other industries and it kind of generalizes the customers with the highest level of satisfaction the one who are most likely to plan a return trip recommend the hotel or other products and service to their friends and so on are those who are about a problem during their stay in the hotel it was resolved cautiously and promptly and effectively they are happier and more satisfied than those who are never had any problem at all it is a paradox it's called the service recovery paradox and suddenly intended oh my god I could put in three or four bugs that I know about so I'll be very very bad bad but I think that's evil and and don't be evil is so so I've resisted that temptation but you have to be it's like when you know that no matter what you release your manager will be back to you and saying it's okay but make it faster having some do not include C R in there which you can surgically remove it voila your software is faster it is the same kind of temptation avoid it because it's not the proper professional behavior still this is worth thinking of in the pursue of fast release does that mean we should always do ad hoc point solutions and in general once that's what the intuition tells us is going to be faster right well not always specially not in Python where a little bit of meta programming goes a long way this is a very simple example we have a bunch of things in a some kind of tree or graph under under root and we want to find and yield all that are of a certain color say their shapes or all that are of a certain shape or squares or circles and so on so writing this and this almost identical functions except that what is called a checking root color the other one is checking root shape doesn't really take any less time than doing it right from the first it violates the dry imperative Diehr why don't repeat yourself this isn't literal repetition but as close as it gets so just generalize and take name and value as argument and use gedit or two to get the appropriate attribute and next time oh and I also need to do find by height or other characteristics you will already solved the problem in versus better versus the right thing I now want to offer some example of first of all with given up one of the great advantages of compiled languages used to have like C++ which was my codes compiling being the perfect excuse to slack off for a bit which with Python or actually modern languages like Go which compile and Link in a flash we've lost that but obviously we think it was worth it but more serious example how to model a network well there's tcp/ip with it rough consensus system and there's the iso OSI model which thousands of experts been two decades debating to make perfect rough consensus and running code have always been the principle of the Internet of tcp/ip and the phrase is due to David Clarke who actually was at MIT and worked on the project multics that Gabriel no doubt had in mind when he contrasted New Jersey versus the right thing but it was also in the internet Engineering Task Force for all he was worth guess what my daughter recently got her PhD in telecom engineering and she explains that yeah the first couple years courses are all isoldi to the core and then you start getting past your bachelor and into the real world of a telecom engineer work and everything becomes tcp/ip because except for a few big telecom apps where you probably wouldn't want to work anyway the world is tcp/ip everything is so simplicity and being there one similarly hypertext hypertext was hinted at even by Vannevar Bush back in the 14 as we may think great work which I strongly recommend reading but essentially hit in the 70s with the Xanadu system computer lib that was name of the book you can I think find it online also known as dream machines explaining how perfect hypertext should work and ten years later and 20 years later nothing had been released to make it real not because the guy had stopped working on it I've even had a friend who was a head system administrator for I think it was called Xanadu a they were just not releasing anything because it wasn't quite perfect yet one chemical physicist at CERN decided he wanted some hypertext to make it easier to share research results rather than going through they obviously old fashioned by the 90s paper route any hacked together something it wasn't a software developer he just invented essentially HTML and HTTP and the concept of a browser showed it at a conference and started releasing this very flowed full system full of defects just imagine links are one way meaning asking who's linking to me requires you to essentially get a copy of all the web to analyze that's what search engines do but it's absurd why aren't link to waste what if you want to link to one paragraph out of a long article you cannot there is no way HTML and dog just doesn't let you do it that and so on I could go on for an hour the crying what horrible design for hypertext they World Wide Web was from the start and despite 20 years of improvement it's still kinda thought however guess which system conquered the world and is running the world the perfect one that every Knepper was released because it wasn't quite perfect yet or the broken barely functional one that makes some human needs satisfied some real problems the question/answer itself an example gabriel actually gave what if a long-running system call gets interrupted well in the i TS and i believe in multics by design every long-running system call had to be interrupted and as atomic as feasible meaning every system call must be able to get the interrupt nor there's an interrupt and wind any stage changes that have been done so far resume user mode so that the interrupts can be serviced restart kernel mode and either redo all the original work or a store state as saved in the first point that meant writing for example a device driver extremely hard I imagine I've never done so particularly because it had all to be assembly language in early UNIX if a system call gets interrupted it sets the global variable ernõ to e inter the constant e enter and returns -1 that's it it's up to the application code which has not is not responsible for that interrupt but the application code must nee must know to check for they are being interrupted error and just redo the call which is if you think about it architectural e broke him but it works and it's extremely simple and writing a device driver for UNIX is a walk in the park it's simple it works and yeah it violates boundaries of perfect architecture who cares I'm going to skip the metaclass versus decorators cause I always get a lot of pushback on this one and the evolution of sorting in Python all the way from the original where you had to pass a comparison functional as you were doing natural comparison said it was always in place through the decorate sorting and decorate and then they sorted similarly other things generators started out as yield only because that was simpler then they became to a widths and finalization started with the goofy try finally then the width was introduced the punches you can almost always make things better so to find out what does better mean go ahead release something I needed unfortunately to censor xkcd to avoid violating the code of conduct but I recommend you go for the original since the xkcd doesn't have to obey a code of conduct let's branch out from sitting at a computer developing software and have some adventure for example what about making a firm Airy crease in the concept of lean startup the title being good enough neveress or is it as it is gonna be if you hit just the middle way to make the minimum viable product that has not it could be softer but it could be anything any kind of startup making a product should have something out on the market that is the minimum viable one meaning some people will use it meaning it solves some human need so you will get validated learning as as you put it feedback another way of putting of course I have to point out that Hansen of 37 signal disagrees and says why these complication just build something awesome and ship it if you can do that congratulations but we're not all 37signals level people of another idea everybody wants the perfect employee except it's a very broken idea if you are holding out for the perfect template you will delay by month you will miss market opportunities the assuming there is a person would be your perfect employee may well not be out there looking they might have a perfectly satisfactory job you'll probably end up over budget it costs to recruit and hire people rather pick a good fit not a perfect fit sure you're using twelve fancy technologies and this candidate only knows four of them in a third of another two and never heard of any of the other six does it really matter we're all pretty fast learners as long as the personality matches your culture your startup culture hire that person and let them learn on the job what they need to learning on the job is quite effective I all I got in college was hardware everything I know about software management and trepan ership I took myself on the job it's not well I took myself and got taught by colleagues it's not the only way then reference from the fantastic word of merchandising they this book the paradox of choice is definitely recommended essentially people fall with intermediate variants into two categories for the Maximizer 99.99 percent is not a hundred oh okay I thought it was 1215 sorry anyway the satisficer is for example the follower of Pareto law which knows that twenty percent of the effort gives you eighty percent of the result then there's a Gettysburg litigation it was officially given by this guy you probably never heard of Edward Everett even though he was governor of Massachusetts senator blah blah blah carefully Pandith 13th in a thousand I haven't actually counted them but I trust people who tell me that and spoke for two hours based on wings of paper the president was always also visiting and gave a very very short address 267 words he's been reported to have looked at a crumpled envelope in his pocket which he may have written on the train there two minutes 267 words not all of them true because one cent and from those is the word will little note nor long remember what we say here and yet we still study that in our schools so just to finish our I'm trying to lower your expectations for what you can do absolutely not your dreams must stay big somebody put it I wonder if anybody recognizes the quote rightly traced and we're older what of that speak up they please what does the mountain care this is an artist who's been praised for rightly tracing and well ordering his painting and is disgusted of being praised that way what he wants to do is grass people's hearts make a difference in the world not properly trace lines that my point is not that you shouldn't aim to change the world in grass people's heart it is that the best way to those greens is to release early and often to learn from real user interactions and keep making things better and keep ambitious hungry goals but a man's reach should exceed his grasp or what's a heaven for and of course the quotes in case you haven't recognized it our from browning Sandra del Sarto who also has nobody remember that but the first written occurrence in English of less is more and with that I guess we don't have time for Q&A if they curtailed my length this is again the URL this URL takes you to the early release of the third edition of Python in a nutshell ebooks only but in all formats and DRM free and if you buy today you will get about monthly refreshes so that you'll be all the way to final release you'll have the third edition of Python in a nutshell on all of your devices and at checkout use this code stands for other discount you get 50% off and the reason I'm really keen to do that is not to sell a few more copies is to get feedback remember my address are the oxide google.com I welcome feedback on the book and now is the best time to give it because if you wait until it's finalized to production and put on paper the amount of improvements I can do is tiny right now if you convince me a chapter should be split added removed completely reorganized I can still do it for the next couple months if you don't send me feedback I will not know that this wasn't good enough and that's it

Channel: SF Python

Views: 6,853

Rating: 4.7849464 out of 5

Keywords: PyBay, 2016

Id: _Ek3A2b-nHU

Length: 53min 25sec (3205 seconds)

Published: Sat Sep 24 2016