Sunday, August 21
Adam was a great speaker. He was funny, gave an overview in the beginning and he used inclusive verbiage (he referred developers as both male and female, yeah!).
Adam showed three cases that has ‘magical’ code and asked if it was harmful. He classified magical code as code that violates our expectations or accomplishes something seemingly impossible.
- not usual way of creating classes
- unexpected use of exec
- Flask‘s request object
- global variable that access to appropriate information
- uses local proxy to locate thread identification in a unique magic storage dictionary
>>>_request_ctx_stack.top.request is request False >>>_request_ctx_stack.top.request == request True
- Django’s Models & Fields
- Using Meta classes to create classes and their field names
- has java like way of types on a class which are not expected
Adam made the argument for these three cases of using magical code are not harmful because they their complexity are contained and the people who need to understand this code are the maintainers.
Alex talked about cultural assumptions that there are different mindsets: strive for perfection and keep-it-simple/just-good-enough. In the python world, there are four things that the majority of the community agrees on: simplicity, correctness, consistency and completeness. Alex organized the importance of these values according to mindsets:
- takes advantage of the natural advantages of incremental development. Incremental improvement satisfies some human needs…
“The Right Thing” (MIT)
- is based on letting the experts do their expert thing all the way to the end before users get their hands on it.
Alex leans towards Good is Good Enough and he talked about what not to skimp on when developing:
- revision control, code review, testing
- proper release-engineering practices
- code style, clarity, elegance
My favorite part of this portion was that he encouraged rubber ducking… or teddy bear! It was adorable! He also stressed the importance of testing “never found the case not to do testing.”
When starting a project, Alex talked about technical debt – when you don’t do things at its best. It said that is okay to have technical debt as long as you have a ‘repayment’ plan. He did say security is something that you shouldn’t have technical debt in since you’ll have to include in, so keep that in mind in the beginning. Other things like modularity, plug-ings, API and scalability can refactored later.
Alex shared the Service Recovery Paradox – “Customers with the highest levels of satisfaction tend to be those who have had a problem resolved.” So having some technical debt is okay, as long as your responsive to your customers. He did joke that one could purposely put in bugs and then fix them when others notice it so make people feel more satisfied, but that wasn’t proper (teehee).
All this talk lends to the idea of less good code, but Alex addressed it in his “Lowering Expectations”? slide. NO! He said to dream big and the best way to make those dreams into reality is to ‘release early, release often.’ And to learn from real user’s interaction which will influence your next steps.
Less is more
Alex ended his talk with an invitation to help him with his real release of Python in a Nutshell and as real users to give him feedback.
There were 4 more sessions, but I was not feeling well so I couldn’t make it. To check out the full schedule go HERE. This weekend was so much fun and I deeply appreciate the hard work that the organizers put into this event. Thank you!