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:
- the application works and doesn’t crash
- the application works and supports a few input cases
- the application works and supports a variety of input cases
- 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
#
Question
#
How can you make people more productive?
Answer
#
Start by asking your teammates to assess whether they are at their peak productivity or not. If they already are, ask them what you could do to help them be more productive. If they are not at their peak productivity, ask them what is making them unproductive. Make it your goal to help your teammates be as productive and efficient as possible.
Being unproductive is like slow software. If you want to improve it, you have first to start with profiling the program to have an idea of what is making it slow. Once you have a general idea of the cause of the slowness, you will want to focus on your biggest sources of slowness because they are likely to be the ones you can help improve.
In software development, the biggest source of productivity loss is meetings. Meetings break the flow of developers, they consume time and are generally easy to replace with a properly written document. If you can act as the proxy for multiple members of your team so that they do not have to attend all the same meetings you are attending, you can help them reduce this meeting fatigue.
Another source of ineffectiveness is back and forth code reviews. If you need to do multiple iterations of review to close a PR, this PR was too big. If you also end up having to do more than two back and forth, you should simply reach out to the author of the PR and do a pair programming session with them to resolve most of the issues you have with the PR in a single session.
Code depends on other code. It should be your first priority to make sure that code that is developed by others is not stuck in the PR queue for a long period of time because the author might be building on that code. The code in that PR may actually be used by code the author is already writing while waiting for the PR to be reviewed. If he needs to go back and fix things because of delays in the PR, this will make his whole development process inefficient. Having to wait or being blocked is an important source of productivity loss.
Help others avoid working on too many tasks at once. The brain does not handle multitasking very well and it generally leads to lower performance and higher error rate.
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
#
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
#
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").
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 want to quickly take notes in the same file throughout the day using VS Code. How do I do that?
Solution
#
My approach has been to use my VS Code extension
Run Me, which I use to bind a keyboard shortcut to one of the commands I created. In my particular case, on any VS Code window I can press CTRLNumpad 2 and it will open a file under the following path: buffer/YYYY/MM/DD.md, where YYYY/MM/DD is replaced with the year/month/day. In this file I record all my notes within the day.
I use the following snippet, which I can trigger using dt, then pressing TAB. This replaces the dt string with a string of the form YYYY-MM-DD HH:MM:SS, which is the current year-month-day hour:minute:second.
{
"Datetime": {
"scope": "",
"prefix": "dt",
"body": [
"$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE $CURRENT_HOUR:$CURRENT_MINUTE:$CURRENT_SECOND"
],
"description": "Date time"
}
}
I also use the
Script Commands extension to do something slightly more complicated, which is to create strings of the form 2020-03-02 21:19:05 [nid://952], where nid://952 represents a unique note id (nid). The number that is generated is unique and is tracked by storing the last generated number in a text file that is read/written on each call to this command. A cheaper approach could have been to simply use the timestamp as unique note id. One downside of the timestamp as note id approach is that you don’t have an idea of how many notes you’ve recorded so far, other than searching your notes and then counting the number of unique instances.
References
#
Question
#
How do you estimate the size of a project roughly?
Answer
#
When I am asked to provide a rough estimate of the required effort on a project with a lot of requirements or user stories, I first want to make sure that my estimate is in the right order of magnitude. That means that I want to estimate a project that takes 1-10 weeks to be in that range, but not estimate less than a week or more than 10 weeks. Similarly, a project that takes one or more years should not estimated as a job of a few weeks.
My orders of magnitude are as follows:
- 1 day
- 1 week (5 days)
- 1 month (20 days)
- 1 quarter (60 days)
- 1 half-year (120/125 days)
- 1 year (250 days)
As such, when estimating a task, I will say that the task will either take 1 day, 1 week or 1 month. In general, any task that is estimated at 1 month long (or above) needs to be broken down into sub-tasks as it indicates that the task is hiding a lot of complexity.
With this kind of approach, one can estimate that a developer can do approximately 250 small tasks (1 day), 50 medium tasks (5 days) or 13 large tasks (20 days) per year.
Start by creating an estimate of the overall project without thinking about any of the underlying tasks. This is done to have a quick idea of the scale of the project.
Then list and estimate the tasks that will need to be accomplished to complete the project. You might be forgetting a few, but it is fine at that moment. Think mostly of the most important tasks and also the riskiest.
If the sum of the efforts you estimated is in the same order of your original project estimate, then you are done. If not, then you need to investigate and explain what led you to either over or under estimate. Did you forget to estimate some tasks? Did you ignore some tasks when you did your initial estimate? What were the assumptions you made that were right/wrong? Once you are satisfied with your explanation, you are done with estimating.
Problem
#
I use VS Code and I’d like to insert templates into my documents. How do I do this?
Solution
#
In VS Code, the concept of templates is called
snippets. It is fairly easy to
create a snippet, so I won’t go into the details. Here’s an example of a snippet I use to insert the date and time quickly into my documents.
{
"Datetime": {
"scope": "",
"prefix": "dt",
"body": [
"$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE $CURRENT_HOUR:$CURRENT_MINUTE:$CURRENT_SECOND"
],
"description": "Date time"
}
}
With this snippet, I only have to type dt and then press TAB and dt gets replaced by the current date and time.
I use snippets to create the template of my questions and problems articles. My current approach is to open a non-existent file by calling code /path/to/new/file and VS Code opens the editor with this file. I can then write the content of this file, which will not automatically save until I manually save. Once I’m happy with the content of my article, I manually save, which means that in the future, any edit I make and then have the editor lose focus will be automatically saved and commit to git (my current workflow).
One of the things I don’t particularly like with the current implementation of the snippets system is that the body needs to be a list of strings, where each item represents a new line. It is possible to create a single entry and use \n and \ to format the string, but that is not a clean approach. Those are limitations of jsonc. If it was possible to link to a file, then it would be “easy” to create a clean template.
References
#
Question
#
How can I read more books?
Answer
#
Make it a priority to read books. Replace some of the existing habits you have with reading books instead.
If you like to spend time reading reddit or hackernews or watching videos on youtube, replace that with reading a book. Of course, it’s easier said than done. The best way I’ve been able to transition from those activities to reading books was to progress slowly. Don’t replace reading hackernews one day by reading a book instead. Instead, simply spend 5, 10, 15 minutes reading a book, and then the remainder of the time on reading hackernews. Spend the same amount of time every day reading a book for a week. When a week has passed, increase that amount of time slightly (e.g., go from 5 minutes per day to 10 minutes per day).
As you increase the amount of time you read, you will find it easier and easier to spend time reading instead of doing other activities you might consider harmful or less valuable.