Deliberate practice techniques for software developers
I’m building a webliography of competitive programming resources, and I’m currently focusing on Quora questions. So far, I have extracted questions from search engine results and from the All Questions page that Quora generates. But as I mentioned last week, only a small fraction of the available topic questions appear in those locations. Where are the rest?
Last week, I wrote about using search engine results to collect links to import into Webliographer. I used three search engine features: standard search, standard search with duplicates included, and site-specific search. Each of these features had pros and cons: Standard search returned results from more domains, but with fewer results per domain. Standard search with duplicates included reduced the number of domains, but returned more results from some domains. And site-specific search returned many results from a single domain, but not all of the results from that domain. All three techniques enforced a seemingly arbitrary limit of several hundred results. This week, I’m going to use a different technique for getting results from a single site.
The purpose of Webliographer is to collect and manage web references (URLs). A good way to get a baseline set of references on a topic is to import the results of a web search. But if you use a search engine this way, you’ll find some quirks that don’t appear when you’re searching interactively.
This week, I made my initial commit to the GitHub repository I’ll be using for my Webliographer project.
Last week I proposed, as a project for this year, a competitive programming FAQ (CPFAQ). As a first step, I suggested a tool to facilitate research on the Web. This week I’m starting to design that tool.
Happy 2018, everyone.
In my end-of-year post for 2017, I wrote a summary of the programming project that I worked on last year, along with lessons learned from the experience. For 2018, I have a new project in mind.
On January 4, 2017, I described a programming project that I would work on this year. That project is Time Tortoise, a Windows 10 app for time tracking. In this final post of 2017, I’ll review what I learned this year from the Time Tortoise project.
This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.
I’m wrapping up a year of working on my Time Tortoise programming project. Next week, I’ll post an overview of what I learned from the project. For this week, I have some ideas about where the project might go in the future.
But first, let’s review the current state of the project.
This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.
In two previous articles, I wrote about SystemWrapper, a library that makes it easier to test code that depends on .NET system APIs. In this article, I’ll provide more details on how I use SystemWrapper for Time Tortoise testing.
This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.
Last week, I upgraded the Time Tortoise projects to .NET Standard 2.0, and also upgraded related NuGet packages that had .NET Standard 2.0 versions. The upgrade was mostly successful, but it broke a few unit tests. In the process of fixing them this week, I had to find yet another technique for resolving dependencies.