Question

What does a productive meeting look like?

Answer

There are a few people invited, less than 6 ideally. Everyone invited knows why they are in the meeting and will contribute to the discussion.

An agenda for the meeting has been set, with a pre-determined amount of time for each item on the agenda. One person is responsible to make sure that the agenda is followed and that the time is respected.

Notes are taken by the different individuals that are part of the meeting.

Items that appear to require more discussion than anticipated are noted and the involved individuals may spend additional time outside of the meeting to make their point, either through another meeting or by writing a document explaining their position.

A list of actionable items is defined at the end of the meeting and responsibles are assigned to those items. Deadlines are also assigned to those items so that people can expect those items to be completed by the defined date.

References

• Meetings

Problem

I need to know what the users of my library need, but I don't have any users yet. What should I do?

Solution

When you are defining who your target audience is, it can be rather difficult to decide who your users will be. If you've been building capabilities in a certain domain for a while and can solve specific problems with those capabilities, then you will likely want to look for users that may have those problems. You may even end up creating personas or prototypical users who have the problems that your library might solve.

Once you've established those prototypical users, you should try to find them in person and confirm your assumptions. You do not want to be building features that they don't need. In the event you cannot get access to any real users, you can still make use of user proxies. User proxies are people that can somewhat act as the true end-users, but are not the true end-users, so that you have to be careful about what they tell you they need since it is likely to be biased by their actual position. Some potential user proxies are:

• The users' manager
• Salespeople
• Domain experts
• Former users
• Customers
• Trainer and technical support
• Business or system analysts

In User Stories Applied: For Agile Software Development, Mike Cohn suggests to use more than one user proxy to mitigate the bias from any specific user proxy. Make sure that the user proxies are of different types. This technique is comparable to using ensembling in machine learning.

Reference

• User Stories Applied: For Agile Software Development

Problem

I want to analyze a python script to extract something from it. How do I do that?

Solution

Python has an abstract syntax tree like most programming language.

You can use the ast module to parse a string that contains the code you want to analyze.

A simple example is as follow. It will read a file defined in the file variable, use ast to parse it, returning a tree that can then be traversed using the visitor pattern. Defining visitors lets you separate the responsibility of each of them, making the code that analyzes code easier to understand.

import ast

class ClassVisitor(ast.NodeVisitor):
    def visit_ClassDef(self, node):
        # Do some logic specific to classes
        self.generic_visit(node)

class FunctionVisitor(ast.NodeVisitor):
    def visit_FunctionDef(self, node):
        # Do some logic specific to functions
        self.generic_visit(node)

visitors = [
    ClassVisitor(),
    FunctionVisitor()
]

with open(file, "r") as f:
    code = f.read()

    tree = ast.parse(code)

    for visitor in visitors:
        visitor.visit(tree)

Reference

• https://greentreesnakes.readthedocs.io/en/latest/index.html

Question

Why aren't we always working on the most important task?

Answer

For bad reasons:

• We don't want to work on the most important task.
• The most important task feels overwhelming.
• The most important task seems too risky.
• The most important task doesn't seem fun to work on.
• We want to work on fun tasks, not hard tasks.
• We want to work on what interests us, not what provides the most value.
• We think that the task we're working on is more important, but it isn't.
• We don't know how to solve the most important task.

For acceptable reasons:

• We don't know what is the most important task at the moment.
• We don't understand what is important to our clients.

For good reasons:

• The most important task has prerequisites that need to be completed before it can be done.
• The most important task is being done by someone else already.
• The importance of tasks is likely to change soon due to a change in objectives.

Question

When is it appropriate to abandon a pull request?

Answer

Assuming that this is in a business context, you should abandon working on a pull request if getting the pull request merged is taking away too much time from others and it requires a lot of additional changes, creating a lot of back and forth between the creator and the reviewers.

You should abandon it if the feature/bug it fixes is not important enough compared to other more important ones. One should always work on the most important task rather than to work on tasks of lower importance. Furthermore, working on low importance pull requests will also "force" your coworkers to review those low importance pull requests, reducing the overall productivity. As such, always think of the impact you will have on others.

Many developers often think that bugs are of the utmost importance and should be fixed as soon as possible. However, implementing a good fix might require a lot of effort on the part of the person that will fix the issue, as well as a good amount of effort on the part of the reviewers which could have spent their time on features or bugs that are more important. Like anything else, bugs should be prioritized based on how important they are, not just that they are a bug.