You may be working on the wrong task because priorities have changed. To determine if that is the case, you should ask yourself whether completing the task provides value, either to you or your users. If the answer is no, drop the task. If the answer is yes, you should determine if it is the utmost important task at the moment. If the answer is no, then figure out which task is. If the answer is yes, then proceed.
You may be working on the wrong task because you don’t have the necessary information to complete the time in an appropriate amount of time. If you find yourself spending most of your time gathering information instead of accomplishing the task that should be done with the information you need, then it may not be the right time to do the task yet. You may have to create a prior task which is to acquire the necessary knowledge to execute the original task.
If you notice that to complete your task there are pre-requisites that should have been completed, then you should work on those instead of the task with those dependencies. In some cases you may realize that you can’t accomplish a task because you don’t have the tooling necessary or the technology to accomplish the task is not available yet.
As I suggest in my article Given that you define a ROI on a task, when should you stop working on a task and abandon it given its cost?, you should estimate how long you expect for a task to take. At the half time, you should evaluate whether you’ll be able to complete the task by the estimate’s deadline. If you can’t, then you should either drop the task (if you can), or look for alternative ways to get the task completed, either by asking a more experienced person or by simplifying the task.
A fairly cheap solution is to use parallelization to run your tests on multiple CPUs instead of the 1 cpu used by default. To do so, you can install pytest-xdist. Once the extension is specified, all you need to do is add -n auto when you call pytest.
Another thing you should do that requires more effort is to investigate which of your tests are consuming a lot of CPU time to execute. To do so, use the --durations=0 flag when you call pytest. A report will be generated after your tests have run that lists how long setting up, running and tearing down each specific test took. The list is ordered from longest to shortest durations, meaning that the tests that have the most potential for being optimized will be at the top. You should focus on these tests because the longest one will determine how long it would take to run your tests even if you had an infinite amount of CPU cores.
Investigate why certain tests take a while to execute.
Are some tests computing something that takes a while and is computed exactly the same way by multiple tests? Precompute this result once and share it between the different tests (think of it as a fixture).
Are calls to a slow external API done? If you are not testing that the remote API is changing, store example responses and emulate receiving them.
Is there a loop in the test that runs hundreds of thousands iterations while the same test could be executed with only a thousand iterations?
Create a minimalist configuration of mypy such that it will list issues that need to be fixed and return a non-zero exit code. Based on the problem definition, we assume that at this step you have more than 100 issues that are listed and that fixing those issues will take many hours you’d rather invest in improving the code than to fix typing issues.
Add a step in your CI pipeline that runs mypy and list all those issues. Verify that it indeed breaks the build.
Once you’ve satisfied yourself that CI fails, we will “fix” the mypy issues by adding the #type: ignore and/or # noqa comment after the offending lines with issues. This will have the effect of resolving all the currently found mypy issues, such that mypy should now return a zero exit code. With this, any future code that fails to pass the mypy check will break the build. This will allow you to use mypy from this point forward to check your types.
I suggest adding an additional comment such as # FIXME: TICKET-ID, where TICKET-ID refers to the id of a ticket in your issue tracking system that explains that you need to take care of this technical debt.
Always prefer to fix the issues instead of ignoring them. However, also consider whether fixing those issues is an appropriate use of your time when you want to introduce mypy (which should be as soon as possible in my opinion).
If you are building technical software for your users, you need to know what their level of expertise and experience is. If you can use a job title to describe their position, that is a great start.
You should define the users’ strengths and weaknesses, that is, what you expect them to excel at and where they will require more of your assistance to succeed at their task.
Define the scenarios in which your users use the software you will build. What information do they have available? Which information do they need to gather? What kind of decisions do they need to make? Which decisions can be automated for them? Do they need to run the software in a specific environment? Do they need access to data to do their task? How is this data made available to them? When do they use the software? How frequently do they use the software? How much of their time is spent on the task they are solving using the software you’re building?
Define what the users’ goals are. You might be creating a text editor, if your users’ goal is to transmit information between companies, they may not care at all about making the text fancy but they might appreciate your editor helping them correct grammatical mistakes.
You want to be as specific as possible when describing your users so that your decisions are guided by this persona you’re creating. What kind of company are they working in? Startups, PME, large enterprises? Do they have multiple responsibilities or are specialized?
With all this information about your users you should be able to make more judicious decisions. This will help you scope your work.
In 2013 I wrote Rotten Tomatoes ratings exporter for the purpose of exporting the movies I had rated into a format I could read and also store.
To automate the process of acquiring the ratings, I wrote a small class which needs information available in the site’s cookies once you are logged in. With this information in hand, it is then possible to fetch the ratings from the website and store them in any desired format, given that the data returned to you is a plain PHP array.
In 2013 I wrote IMDb ratings importer for the purpose of importing ratings I had created in another system (Rotten Tomatoes). I wanted to import my ratings into IMDb so that I could use their statistics reporting tools, which let you see your distribution of ratings and the distribution of the release year of the movies you’ve seen. A friend of mine also had his bot send a message to our discussion channel whenever one of us would update their ratings after watching a movie.
The library is pretty straightforward. It expects you to provide it with a string that uniquely identifies your cookie on the server side. With an array of all the titles and ratings that you have, you can submit those ratings and the library’s importer will take care of calling IMDb by finding the closest movie title and assigning it the desired rating.
You need to know who your audience is. You need to know what they should know so that you can make assumptions about their knowledge. You should also be able to tell what they won’t know. It is mainly this lack of knowledge that you need to fill when you write your documentation.
Once you have established who your audience is, you should state it clearly. This way, readers will be able to determine if they identify or not with the target audience, which can help them better frame how to read the documentation.
The purpose of documentation should be clear. Is it to describe a specific use case, provide a getting started guide, answer specific questions regarding functionalities?
You need to state explicitly what you will cover and not cover in the documentation. Readers may start reading your document which contains assumptions about their knowledge, but if they do not have this knowledge, they should know where to acquire it.
It should be easy for readers to know where to reach the author of the documentation or people knowledgeable enough to guide them to the right people.
I use Visual Studio Code as my main editor and I am on Windows 7. I like to use emojis but those aren’t properly rendered under Windows 7. Can I have pretty emojis in Visual Studio Code somehow?
I developed an extension in 2018 called Emoji which uses EmojiOne emojis to replace their non rendered equivalent in Visual Studio Code.
To do this, the extension makes use of the createTextEditorDecorationType method available on the window object in order to inject CSS that adds a background image where the text emoji would be rendered.
The extension listens to two events to determine in which editor it needs to do the replacement: window.onDidChangeActiveTextEditor and workspace.onDidChangeTextDocument. In the first case we update the editor that is now the active one, in the second, we update the active document when the text content changed.
