haykot.dev
Weekly Notes Programming Git

March 26, 2022

Deep Work, PR Review, and Git Hashes

Deep Work, PR Review, and Git Hashes

This week I’m starting a new practice to capture my weekly thoughts and notes and write them up in a weekly blog post. We’ll see how it goes!

Deep Work and Productivity

This week I finished reading through Deep Work and the previous week I had finished Atomic Habit. Both of these books were apart of a larger path I’ve been on to find more focus and productivity in the work that I do during that day and outside of it. While Atomic Habits wasn’t nearly as useful as Deep Work, I think they both provided some good footing for improving your work-life and are worth the read. My main takeaways are

  1. Schedule time for focused work
  2. Don’t define habits, define a lifestyle and relay back to the actions you want to take. I don’t want to eat healthy food, I want to be a healthy person.
  3. Pick small habits for easy wins and let the compounding effect bring your bigger wins.
  4. Reduce time spent idling. If you’re want to be on your phone on twitter, make a decision to do that. Reducing your brains idle time and flowing from small activity to small activity has a negative impact on your ability to focus.

All in all they’re worth the read - hopefully I see some positive impacts in the near future.

PR Reviews

At work this week it’s been a whirlwind of PR reviews. I’ve been working with my team to create a better review process to ensure code is consistent across projects and teams. This is especially important, I’ve found, with languages like C# where Visual Studio can hide a lot of complexity and lead to inconsistent environments and failed builds. I’ve probably done 4 or 5 PR reviews this week and am struggling to identify why it’s becoming such a difficult process.

Ultimately the problem comes down to the fact that a PR review is too late for some many code quality changes. A lot of the problems in our team can be boiled down to a few categories

  1. Inconsistent formatting
  2. Poor function/variable naming and/or not enough documentation or context around complicated code.
  3. Unstructured code

While 1 is easily implemented as a CI check and I’m sure there’s some automated solutions around #2, #3 really is a bigger culture issue than it is a code issue. To have an effective PR Review process, I’m starting to think there’s a few things that need to come first.

  1. Automated Testing and CI builds for “nit-picks” - no code review should be commenting about formatting or whitespace. That’s a waste of developer time
  2. Your team needs a style guide. Even if it’s just a copy-paste of an existing guide, you need some documentation around what the expectation is for code quality. Effective naming from that start can eliminate a whole host of ambiguity that increases time code is stuck in PR reviews.
  3. A team culture of design. Maybe less applicable in teams that are working on a single product, but my team is shipping small applications on a fairly regular basis. As such, it would be extremely beneficial to have a Standard Operating Procedure of design that we could all use to ensure our code looks at least similar. The more we can do to reduce developer time to “Get Context” they better experience PR Reviews are for everyone.

Git Hashes and Docker Builds

After nearly 6 months of work, I finally got a working beta of Mealie out the door for the v1 rewrite. As apart of the rewrite I’m trying to adopt a more Agile mindset and ship small more incremental changes - especially within the context of the beta. I don’t want to have to bump a version number every time something tiny changes. The solution here is to package a build ID with the docker container so I can easily differentiate images that have the same tag. How do I do this though?

Build Args was an easy solution to this problem. Surpassingly easy. First, when running docker build you need to provide the argument so it can be read from the dockerfile.

--build-arg COMMIT=$(git rev-parse HEAD)

This snippet will capture the latest git commit hash and apply it as the argument COMMIT. Then all you need to do is capture it in the dockerfile and it’s available in the env of your container.

ARG COMMIT
ENV GIT_COMMIT_HASH=$COMMIT

Now you can use that to display the Build ID in your UI or where-ever you need it.