Problem

There are no tests on the project I joined. How do I get started?

Solution

When joining a new project without tests, here is the value you need to provide through the addition of tests:

1. the application works and doesn't crash
2. the application works and supports a few input cases
3. the application works and supports a variety of input cases
4. the application works and is robust to most input cases

Start by finding the main entrypoint of the program and call it in a test. Your test doesn't have to do much, other than ensuring you can start the program and possibly exit. Your goal should not be to assert anything yet, but to exert the code. Create a few tests that do very few things other than starting and terminating the program. Once you've covered a few use cases, you can use those tests to ensure that the application can start, do a few things, then terminate without crashing.

Start unit testing the various parts of the code that are critical. To determine what is critical, you'll have to dig into the code. With the tests you initially wrote you will get a sense of the "critical" pieces, simply due to the fact that they are executed whenever the program starts and stops, which are two things you always want to work.

When writing unit tests, always aim to write a test case that covers the happy path first. You want to demonstrate that the functionality a class or function is supposed to provide is there first and foremost. Then you want to test its robustness and its ability to handle a variety of input cases. Given a large codebase, start by covering most of the code with the happy paths before you start to dig into the special cases.

References

• Writing tests

Question

What is the most important part of a meeting?

Answer

The agenda.

If you get invited to a meeting that only has a title, ask for an agenda. If the agenda is only the title of the meeting, ask for a detailed agenda.

If people cannot prepare an agenda for a meeting, then there is no point in meeting. A meeting with no preparation will generally be ineffective simply because it will be spent either sharing information, something that could have been done without meeting, or actually doing preparatory work for something that would deserve to be done in a group, but not as a meeting in itself.

If you need to make some decisions with a few people, then prepare the list of decisions that will be made during the meeting.

Make sure that your meetings have an agenda. You will get a lot more out of your meeting because you will know the outcome you expect out of them.

References

• Meetings
• What does a productive meeting look like?

Problem

I use poetry as my python package manager and I'd like to know the packages that I depend on that are currently outdated.

Solution

An easy way to get this list is to run poetry show --outdated. This will return you a list of all the packages that are outdated, their current version, the latest version, as well as a description of the package.

There are in my opinion three missing features here:

• having the command respect the semantic versioning constraint and only letting you see the latest version according to those constraints
• having a flag to switch between showing the latest version available without semantic versioning constraint vs the latest version constrained by semantic versioning
• having a flag to list only the packages that are direct dependencies (listed in the pyproject.toml file)

References

• Poetry show command

Question

How can you tell between noisy and useful code refactoring?

Answer

The classical adage in software development is that "if it ain't broke, don't fix it". Code may not be in an ideal state, but you should not focus on refactoring it if you aren't working to change it to do something else or so that it can be used in other parts of the code. It is fine to do code refactoring from time to time, especially if you have free cycles and know about a few pieces of code that have been bothersome. However, spending time refactoring systems that are already working but a bit clunky may not be the best use of time, especially if you or your team don't have free cycles to spare to review your changes. A better use of time may for example to help others on their tasks or to prepare future work so it goes smoothly.

In a business environment, a refactor also means implicating other developers to review your changes. As such, this introduces distractions in those developers that could be more focused.

In this case, whether a refactor or other changes to the code is noisy is a matter of timing.

Problem

I use mypy but it doesn't seem to scan all my files. Why?

Solution

You might be using implicit namespaces in your code (see PEP 420). Support for implicit namespaces in mypy is rather flaky as of 2020-03-03.

One solution for the moment is to add __init__.py and make all your namespaces explicit.

Another solution is to replace your calls to mypy some-path with mypy $(find some-path -name "*.py").