IT Staff / Developer Expectations

Time Tracking

We're not specifically interested in minute to minute breakdowns of our staff does in a day. We are however interested in where our time is going. We need visibility into if our time is being chewed up by answering user issues, or other unexpected areas. We need to make sure we're not letting minor issues distract us and absorb an entire day.

We also need to see if there are a lot of stops and starts in our development time. The context switching comes with a cost of at likes 5-10 minutes to get back into the heads space for development.

To this end, we need to use a simple time tracking system. All we need to record is the task we're starting, and the time we started it.

Make sure there are helpdesk tickets.

All user issues, like printer help, and other calls, should be given tickets. If the user hasn't created a ticket, ask them to create one, or create one for them. Tickets can be created after fact if it's an emergency.

A simple 4.5x5.5 notebook can be used for this. No tasks should take more than one line, maybe two. We're not looking for details. We also don't need minor breaks like stretching your legs or grabbing a drink. Only lunch really needs accounting for. Some days may only have 3-4 lines, that's perfectly fine.

Other tools can be used, like pomodoro timers, as long as your tracking where your time is going during the day.

Here's an example day:

Time	Task
9:00am	Divvy Receipts
9:30am	Shipment conf. dialog
10:15am	Derrek sid#208872 tkt#254
10:30am	Shipment conf. dialog
11:15am	Lunch
12:15pm	Product Profiles updates
12:30pm	Andrea can't print
	tkt#258
12:35	Product profile updates
5:30pm	End of day

Git Branches

Short lived branches

Development work and tasks should be chunked up. Each chunk should be chosen to be 1-3 days worth of work, or at most a week. There are of course pre-existing natural boundries between frontend repositories and backend. Once a chunk of work is done, the repository should be published to github, and a pull request generated. Code should not solely exist on development machines for more than a few days.

To help keep branches small and short lived, we can employ feature switches. The permission system already supports the '"feature_switch": True"' property. This will keep the feature turned off even for admins. If the task at hand can't be hidden behind a feature switch like that, discussions can be had on how to proceed. We can also at that point accept a know long lived branch.

It's not out of expectation that there might be longer running branches. This is OK. In this case local commits should be squashed in ways that make sense, and pushed to github. A pull request can wait until the entire chunk of work is done.

An example of branches and squashed commits:

backend

• 2022-09 Product profiles projects
  • Generate App
  • Models and serializers
  • Views
  • Testing

common

• 2022-09 Product Profiles
  • Setup project models

frontend

• 2202-09 Product Profiles
  • List view
  • Detail view

backend

• 2022-09 Prodct Profile Lineitems
  • Add lineitem models and serializers

common

• 2022-09 Product Profile Lineitems
  • Add lineitems module
  • Expose related lienitems on project model
  • filter project views by lineitem brand
  • Test lineitem views

frontend

• 2022-09 Product Profile Lineitems
  • and line item view for product profile projects
  • add lineitem creation dialog
  • add global tabs filtered by company/view

While the above feature might take 2-3 weeks, none of these branches in particular should take more than 3-4 days to complete and push.

Branch Chaining

In order to keep branch life down, we can chain branches.

As an example, if you want to work on feature_b, but it's based on code thats waiting in a pull request for feature_a, we can chain the branches. I'll be including command line examples here, but the workflow is accomplishable with the Github desktop app.

Branch featur_b from feature_a. Checkout feature_a, then create a new branch from that.

git checkout feature_a
git checkout -b feature_b

If there any changes that need to be made to feature_a before merging, you can add commits for feature_a, and then rebase feature_b against it.

git checkout feature_b
git rebase feature_a

Once feature_a has been reviewed and merged, you can rebase feature_b onto the main branch.

git checkout master
git pull origin master
git checkout feature_b
git rebase --onto master feature_a feature_b

If there's any commits that need to be made that would affect both feature_a and feature_b, make sure to make the commit on feature_a and then rebase feature_b against it. Otherwise you might end up with weird conflicts.

Code Reviews and merging

Given that we're asking for short lived branches, timely code reviews are neccessery. Whoever is in charge of merging is expected to be available for code reviews and merging branches at least daily. Best times are likely to be start of day on the west coast and end of day on the east coast. Of course, as pull requests are generated, and a message on teams can get immediate reviews depending on availability.