03 Mar 2020

# Useful code refactoring

History / Edit / PDF / EPUB / BIB / 2 min read (~203 words)

## Question

How can you tell between noisy and useful code refactoring?

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.

03 Mar 2020

# Mypy and implicit namespaces

History / Edit / PDF / EPUB / BIB / 1 min read (~78 words)

## 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"). 02 Mar 2020 # Quickly recording notes using VS Code History / Edit / PDF / EPUB / BIB / 2 min read (~316 words) ## 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.

02 Mar 2020

# Rough project size estimation

History / Edit / PDF / EPUB / BIB / 2 min read (~345 words)

## Question

How do you estimate the size of a project roughly?

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.

01 Mar 2020

History / Edit / PDF / EPUB / BIB / 1 min read (~169 words)

## Question

How can I read more books?