26 May 2019

Task management

History / Edit / PDF / EPUB / BIB / 4 min read (~783 words)

  • Give it a title
  • Give it at least one label
  • Give it an assignee
  • Decide if it's important or not
  • Decide if it's urgent or not
  • Estimate the effort required to accomplish the task (in hours)
  • Estimate the value the task brings (in $)
  • Give a rough estimate of effort
  • Give a description if necessary
  • Set a deadline if possible
  • Set status to Unprioritized

Task creation

Task states

  • Go through the tasks in the Do section, then the Decide section, then Delegate

Use Eisenhower matrix to determine task importance/urgency

  • Tasks that are not important/not urgent are moved to the backlog
  • Tasks that are not important/urgent are delegated to someone else
  • Tasks that are important/not urgent should be scheduled
  • Tasks that are important/urgent should be done ASAP

Using the estimated effort and estimated value of a task, you can compute the return on investment (ROI) of the task as estimated value divided by estimated effort. For example, a task you estimate is worth 100 $ and takes 2 hours to complete will have a ROI of 50 \$/h.

Use the ROI of your tasks to prioritize them. You will want to complete the tasks which are likely to have the best return on investment.

The ROI metric will also give you clues about the task you should probably not spend your time on. If you are paid 50 $/h and a task has a ROI less than 50 \$/h, then it should probably be moved to the backlog and only reconsidered if its ROI changes.

  • Unprioritized tasks should be moved to Queued, given their priority compared to already queued tasks
  • You should attempt to keep the Unprioritized tasks count to 0
  • A task that is Queued should have a deadline date
  • Work on tasks In progress first, then take tasks from Today, then from Queued

Task processing loop

If you've never done task management before, I suggest you do not start by applying all the above at once. First, start by simply recording the tasks you need to get done (title only). Once you've recorded most of the tasks you have to deal with, start giving them an important/urgent assignation. It will help you rapidly determine which tasks should be done and which ones are nice to have, but not critical, or even not really useful if you think about it. Once you are able to have this information for most of your tasks, then you should start giving them effort and value estimates. Once you've reached this point, you will have a much better grasp on the importance of your tasks, as well as their potential impact in terms of value, as well as to the amount of effort it will require from you.

26 May 2019

Writing bug tickets

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

  • Summary
  • Software version
  • Reproducible in latest version?
  • Environment details: compiler/interpreter, operating system, etc.
  • Steps to reproduce
  • Expected results
  • Actual results
  • Screen capture (if relevant)

25 May 2019

Reviewing code

History / Edit / PDF / EPUB / BIB / 3 min read (~450 words)
  • Verify that the build/tests pass
  • New code
    • Understand the feature and associated requirements that are supposed to be implemented
    • Verify code implements the desired feature and that the requirements are completed
  • New/Changed code
    • Check code contains tests
      • Is all the new code covered by those tests?
    • Verify the location of new/moved files
      • Are the files in the right directory?
      • Are they appropriately named?
    • Verify classes, methods, functions, parameters naming
      • Are they significant of their purpose?
      • Are they clear enough?
      • Are they respecting the naming convention?
    • Does the code respect SOLID?
    • Consider that when functions/methods signature change, code may now be backward incompatible.
      • Discuss whether this is necessary
      • Backward incompatible changes should be documented
    • In a weak typed or type hinted language, are parameters and return of functions/methods typed?
    • Are there TODOs that should be completed within this review?
    • Check code for code style issues
  • Bug fix
    • Verify that the fix is applied at the right location and will not "fix the symptoms, not the cause"

When reviewing

  • Provide specific and actionable feedback
  • Clearly mark nitpicks and optional comments
  • Assume competence
  • Provide rationale or context
  • Consider how comments may be interpreted
  • Don't criticize the person, criticize the code
  • Don't use harsh language

25 May 2019

Web applications

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

  • 3 different environments: development, staging, production
  • Write migrations for schema changes
  • Use ORM if possible over raw queries
  • Always make it possible for testers to report the version they tested against
    • Simplest is to have a meta field in the head section

  • Mockups
  • SRS
  • Database and software architecture
  • Implementation
  • Test/QA
  • Deployment

25 May 2019

Software project basics

History / Edit / PDF / EPUB / BIB / 1 min read (~143 words)
  • Code changes are stored in git
  • Setup continuous integration
  • Have a testing framework
  • Use dependency management
  • Define a code standard
  • Prefer function/method typing over dynamic types
  • On every push to git
    • Code quality check
    • Code style check
    • Unit/functional/integration/system tests
      • Code coverage should be recorded during tests and a report made available
  • A project repository must have a README.md explaining how to run the project on your own computer
  • A project repository must have a RELEASING.md explaining how to release the code
  • Responsibilities are made explicit in terms of roles
  • Critical roles, such as project lead, must have a backup/shadow individual