So lately I found a new pattern to increase my productivity. I work on APIs pretty extensively, and have adopted using Bruno to test with and store my test calls in my repo with the api. Since Bruno calls are basic text files, I found I can do the following: use a swagger page to collect curls for all the calls I make for setup and testing feed those calls into copilot, telling it to use them to set up the pre and post script runs then tell copilot what specifically to test for and have it create a bruno file for that call (or update one that has the bare bones for the call I’m making) additionally, I will tell copilot to update the docs section with how to manually run the test in case QA wants to review manually I’ve found that this process greatly speeds up how I test and has completely replaced integration tests in some instances.

This weeks post will be a bit of quick one, not too much going on. One thing of interest I’ve noted about myself is even successes in hard games (like SilkSong) aren’t as rewarding anymore. I play a few hours, got to and defeated Moorwing, and I haven’t even thought about it again. It was just “meh”. After that I picked up my secret project (which may stop being secret soon) and honestly I found that much more rewarding, even if AI was doing some of the heavy lifting.

What makes a team more productive? There are many aspects to increasing productivity, but I believe one of the most important ones is keeping the team focused on one thing. Teams that can keep single project flow have much more success in moving that project along. You hear it time and again about single piece flow and how that maximizes productivity, but how does that look practically? Business usually can’t afford to work on just one thing, so teams don’t get afforded that luxury either.

Been a long couple of weeks on a tight deadline project, and I’m just now having time to begin thinking about moving to the projects I was supposed to be working on. This work has been pretty exclusively in C#, with some minor reviews of JavaScript. This swapping languages, coupled with a new want to write more in Go, has me wanting to writing about languages and changing them frequently.

Obsidian released bases this week and honestly, I don’t know how I feel about it yet. If you’ve read my previous articles, you know I’m a huge Obsidian fan and use multiple vaults for various journals, posts, etc. I thought I would take this week to talk about bases and my initial thoughts. The Good The bases plugin provides native support for filtering and aggregating data on your files. It allows you to filter based on file names, folders, tags, and custom properties (there are more filter options as well).

I recently read the article Writing Code is not Software Engineering , which I highly recommend reading. I thought I would take this weeks article to share my personal experiences with it. First and foremost, context is king. If you don’t know why you’re writing something, you’re going to get the how wrong because you never had a good target in the first place. The language and methods don’t really matter.

The two work types that I see are odds more often than not are the business projects and the internal projects. Why can’t we easily integrate these two types of projects into a single roadmap? What I think is the problem is product and engineering see two very different views of the code. Most people think code is a stable, structured thing, like steel in a skyscraper. But that’s where everyone is wrong.

No post for this week, taking a break. I’m re-reading The Phoneix Project. Highly suggest if you’ve never read it before. I need a week off to gather my thoughts, I’ll return next week, probably with a book review!

I’ve recently started a new front end project. It’s been years since I have done any sort of front end work, so besides getting into the more recent frameworks, I’ve been exploring IDEs. I had used VS Code for a long time, but since I have all products package for Jetbrains, I thought I would give WebStorm a try. Overall I’m very happy. It uses the same format as all other Jetbrains products, so opening it is as familiar as GoLand, PyCharm, or Rider.

This weeks topic is another obvious one, but I thought it would be good to talk about as I’ve reaped the benefits of it in the past few days. Today I’m going into why little things add up over time. There’s a myriad of small things you can do that can make pay dividends in the future. From a simple email system to taking the extra time to set up extra configuration, the 30 minute tasks add up over time.