Accidentally in Code

Tag: pycon

  • Pycon AU: Planting Open Source Seeds

    Pycon AU: Planting Open Source Seeds

    Plant Growth Stages
    Credit: Flickr / AJITH ACHUTHAN

    I found this talk by Kenneth Reitz one of the most interesting at Pycon. There was a comprehensive breakdown of the different strategies people take to create and nurture (or not) open source projects, and tales from maintaining them. You’re probably better to just read Kenneth’s notes, but for what it is worth – here are mine!

    Started with the story of the Facebook SDK which allowed developers to access Facebook APIs from Python. It was rarely updated, and one day just stopped working. So developers opened issues, and it ended up on hacker news – the issue got 50 comments. So… Facebook disabled the issue tracker.

    This was the worst possible scenario. The project wasn’t open source, it was public source.

    Public Source: Company puts out a chuck of code with an Open Source License on it, hoping that it will be useful. This is better than closed source, but can easily end up abandoned due to lack of interest or change of focus. The motivation for sharing is unclear.

    GitTip is a platform for sustainable crowd-funding. It takes open-source to the extreme, striving to be the world’s first truly “open company”. It’s run by Chad Whitacre who said “I’m not building Gittip. I’m building a community that’s building Gittip.”

    Extreme Open Source means:

    • There’s a GitHub issue for everything.
    • Major decisions are voted on GitHub.
    • Interviews with journalists are live-streamed.
    • All formal discussions are publicly documented and shared.

     

    Shared investments: Shared ownership, and extreme transparency. New contributors can follow a documented process. It is low-risk, with a high bus-factor.

    Requests is HTTP for humans – one of the most installed PyPI projects. It’s different because project decisions are made by Kenneth (the owner).

    Dictatorship project: Totalitarian “Benevolent Dictator for Life” (BDFL) owns everything. They are responsible for all decisions. Feedback is encouraged, but users shouldn’t have any expectation of change. Their extreme opinions will guide the project, and they will be able to make quick, precise decisions.

    Downsides: Low bus factor, risk of burnout is high. If the BDFL loses sight of goals, the project will be ruined.

    Lessons from a Dictatorship Project

    Be cordial or be on your way.

    Contributors:

    • Be as respectful as possible.
    • Remember, they don’t owe you one moment of their time.

     

    Maintainers:

    • Be thankful.
    • Contributors are the lifeblood of your project.
    • Ignore non-constructive suggestions.
    • Remember that some people take things too seriously.
    • Be cordial.
    • Contributors take what you say personally.
    • Take the opportunity to educate the user.
    • Remember, you could be their first interaction with an Open Source project.
    • A little kindness goes a long way.

     

    You could be their first interaction with an Open Source project – this is a really important point! Don’t scare people away from Open Source!

    Burnout

    Sustainability is the biggest challenge in Open Source. Everyone has limited time, and it is easy to become a bottleneck.

    Wesley Beary: “Open source provides a unique opportunity for the trifecta of purpose, mastery and autonomy. By recognising the power of these factors, we can keep ourselves motivated and continue to increase our impact.” (Worth reading the entire article there).

    Learn to do less. Lead-Contributors triage issues. This saves a lot of time. Focus time on larger issues, and help make the best of their time and efforts. Faster for contributors and users – only good things happen.

    JUST SAY NO.

    This is really difficult. Sometimes people send crazy features disguised as practical pull requests – they are trying to help. But it is a use case, not for library. If you say yes too often, the project will be ruined – tragedy of the commons.

    Pieter Hintjens: “Simplicity is always better than functionality”

    • You cannot support every use-case, look for the 90% use-case, not the 100% use-case.
    • If a new pull request adds complexity – say no.
    • Plugable, modular system – pass it in as an argument, and everyone wins.
    • Simple code is good.
    • Code solves problems created by humans.
    • Less code = less to maintain.
    • Negative diffs are the best diffs.
    • Complex code is bad.
    • Tight coupling.
    • Technical debt.
    • High maintenance.
    • Self-serving, rather than project based.

    Open Source makes the world a better place – please don’t make it complicated.

    Audience Question: “Is forking ever a good thing?”

    Answer: Sometimes – see Hudson/Jenkins – forking might be required for political reasons. But don’t fork instead of contributing, talk first.

  • Pycon AU: Making Python More Fun for Everyone

    Pycon AU: Making Python More Fun for Everyone

    Screen shot from Spy Who Coded game
    Screen shot from Spy Who Coded game

    Interesting talk from the creators of SingPath – games to help people learn to code. Left me wanting to try the game! Some insights about women and what they find off-putting – nothing unexpected. Notes below:

    Intrinsic vs. extrinsic motivation: autonomy, mastery, purpose (Dan Pink’s book – Amazon).

    Want to extrinsically motivate people without killing intrinsic motivation. This is really hard. Decided to focus on extrinsic.

    Quests: “The Spy Who Coded Javascript” – it’s a first person coder.

    Games are hard fun. They:

    • Have clear goals.
    • Require concentration.
    • Give immediate feedback.
    • Deep, effortless involvement.
    • Uncertain outcome.

     

    Hard to find balance – some people find it too easy, others too hard. Answer: adaptive difficulty (difficulty changes, depending on how you’re doing).

    A setting easier than easy – drag and drop. This is not intimidating. Also allows for tablet based – an iPad app.

    Individual learner – try to maximise classroom efficiency.

    Tournaments – everyone in the room is solving the same thing, at the same time.

    Idea: “Tournament based teaching”. First 5 minutes are close-book, after that open book. Peer based learning – first 10 finish, then go and help people who haven’t finished. There will always be some students who are very fast – these students then get to explain/mentor.

    First pro tournament at Pycon APAC.

    Collaborative learning – fun round, then prize round. No qualitative judging, the most efficient coding wins.

    Team-based tournaments.

    Pair-programming tournaments.

    Contemplating: mixed doubles (one female, one male on the team) – encourage peer-based learning, diversity.

    How do you balance carrot/stick with things that people are intrinsically motivated for?

    Women less likely to participate in the competitive rounds – the fun round, yes, prize round no.

  • Pycon AU: Solving problems by sharing them… with Python!

    Pycon AU: Solving problems by sharing them… with Python!

    IMG_2041

    Tennessee Leeuwenburg’s keynote on Sunday morning was about sharing and collaborating, communicating and working with non-developers, but also about getting the best out of the people you work with in general. Themes: bringing things together without needing to overlap. Charts are a universal way to communicate.

    My notes:

    Global cost of debugging is $312 billion annually – this is 5 times the market value of Facebook. [See: press release from Cambridge University].

    Be more transparent with what you put in front of people to gain credibility.

    Major advantages in software (compared to other engineering) persist, if you can figure out what you want early enough.

    Myth that early decisions are cheaper. They might be, but you lack visibility.

    Leaders are prepared to be different. Don’t believe everything you think. Don’t get stuck in a rut.

    Being a manager is like being a chef – you put the whole meal together.

    Dunning-Kruger effect, “if you think you are any good at anything, read it cover to cover. Four times”. In order to assess competence, you have to have competence.

     

    Antidote to a sense of self confidence, the Dan Pink Drive RSA Animate video.

    • Mechanical skill: better pay = better performance.
    • Requires at least rudimentary cognitive skill: better pay = worse performance.
    • Replicated over, and over.

     

    How do we design teams around Autonomy, Mastery, Purpose?

    Need to give customers some control, but retain control.

    Information introduced whilst building is annoying. More likely to accept information when “done”.

    Groups of people working together will engaged in a coordinated matter. If not synchronised (not communicating) it will be worse. Disconnects lead to this situation.

     

    Team disconnect:

    • Motivation.
    • Delusion of competence.

     

    Manager disconnect:

    • Technical manager.
    • Domain expect manager.

     

    Domain disconnect.

     

    Productivity of teams:

    • Diversity is a solution to local minima.
    • Development of trust.
    • Performing as a group.
    • Getting in the “idea elevator”.
    • Equality of access to information.
    • How to divide up thinking amongst a group.
    • Individual productivity and flow state.

     

    Transparency at all costs.

    It’s about credibility and reputation.

     

    Examples:

     

    Convert to outcomes:

    • Empathy
    • Maturity
    • Learning

     

    Overall

    I don’t think this talk had the strongest storyline to it, but I think the themes of transparency and communication are helpful. I didn’t really see quite how relevant the discussion about Drive (Amazon) was to it – great book, and one a lot of people I knew were talking about… 4 years ago.

    My main takeaway was about how to listen well enough that you can communicate with people in a way that best makes sense to them – speaking to their priorities, and values, and strengths.