Greg's Profile

• My name is Greg Dietsche.
• I have a B.S. in Computer Science.
• I have a M.S. in Information Technology. I taught in this program as an adjunct professor.
• I am a Captain on the River Falls, Wisconsin Fire Department. I am state of Wisconsin certified Fire Officer I, and Fire Instructor I.
• I worked in the Insurance Industry for seven years, specializing in large enhancements to the P&C system at TruStage (CUNA Mutual Group). It had three million lines of code and was exceptionally well designed. SQL Server was used as the backend database. My team invented an early "document" database before mongodb came along. It used XML instead of JSON. We also invented our own redis, before redis came along.
• I worked in the Language Translation industry for six years, specializing in parser development (e.g. Word, Excel, PDF, Adobe MIF, HTML, JSON, XML, and many more). My team built a system that processed more than one billion words in 2025.
• I worked as a SCADA engineer and Project Manager for five years. I built a new Electric SCADA system and oversaw an electric/water meter replacement program as well as enhancements to the Water/Wastewater SCADA.
• I specialize in C# .NET.
• I use Docker regularly.
• I prefer sqlite for personal projects. I like to store data as a json column, and index important columns with sqlite.
• I am very interested in golang and enjoy creating high performance software using it.
• I am knowledgeable in bash scripting and Linux system administration (especially Debian and Ubuntu). I have contributed to the Linux kernel.
• I am an Extra Class ham radio operator. I am the vice president of the local SCVRA (St. Croix Valley Radio Amateurs) ham radio club. The website is: https://www.k9scv.org/
• I am a knowledgeable amateur photographer.
• I expect correct, precise, short, responses from AI agents.
• The first step when problem solving is understanding the problem.

Work / My Day Job

Read @C:\ai\work.md if it exists.

Software Engineering

Greg is an expert level software engineer who has deep knowledge of C#. Greg also enjoys writing code using go. Greg knows SQL very well. Greg has high expectations for AI agents, especially you. You are expected to be above his level in capabilities. Take time to do this when thinking. Research your assignments using web searches to ensure you have expert level knowledge. You will do your best to research carefully and produce excellent, well-organized code that follows industry best practices and Greg's preferences.

General Software Engineering

• To make comparison and performing diff operations easier:
  • Require one sentence per line for comments.
  • Require one sentence per line when working in text files and markdown files.
  • Error message strings must be on exactly one line. This makes finding the string easier when debugging.
• Consistent Nomenclature
  • Names should be consistent throughout the code. For example, if a variable is named thing1, it should always be named thing1. This makes the code easier to read and understand.
  • When there is a structural pattern, it is important to follow that pattern. For example, if we have DocumentSize, DocumentTitle, DocumentFooter. We might create a variable called DocumentIsPublished. When multiple values have the same prefix, consider moving them into a struct, class, or record.
• I prefer to use UTF-8 text encoding.
• I prefer to write idiomatic code, matching the style and preferences, and architectural patterns of the programming language I'm using.
• Excellent data structure design is a fundamental property of good software. This rule strongly applies to data structures in code, and in databases.
• Code should be simple and to the point.
• All AI generated code must be written with human readability and maintainability in mind.

Variables

• Prefer to prefix Boolean variables and properties with the word "is". For example: "IsEnabled"
• A variable must not have multiple meanings. It must represent only one discrete piece of information.
• There should be very few if any global variables. Where possible, move them inside functions and pass them as parameters.

Functions

• Prefer early returns.
• Make functions short. A good rule of thumb is 20 - 50 lines maximum. Shorter than this is even better.
• A function does one thing and does it well.
• Functions follow the Single Responsibility Principle (SRP).
• Prefer to pass in variables and return results over modifying global state.
• Prefer to return modified objects rather than create side-effects by modifying properties on objects that were passed as input parameters in C#. Consider using a record type to help avoid this problem.
• Avoid unexpected, or unreasonable side-effects. Apply the Principle Of Least Suprise.
• In C# get/set methods should only get and set. They must not have side effects such as modifying the global state of other variables, or calling functions.
• Use interfaces like IList for public methods, properties, etc. We do this so that we can change the concrete implementation if needed without breaking the API.
• Use concrete types like List for private and protected methods, properties, etc. We do this for performance since, for example, iterating on List is faster that itteration on IList.

Objects

• God objects are objects that are re-used for different purposes. For example, a request and a response view model combined into a single object. God objects are not ok and should be refactored into two or more objects that have single responsibilities. You must identify God Objects and offer to make a refactoring plan.

Modules

• Follow the Single Responsibility Principle (SRP).
• Avoid maintaining state using global variables. Instead, pass variables into functions where possible.
• Modules handle one concern, and they do it well.
• If multiple concerns are present, mention them if the current task could address them.
• Modules follow the principle of high cohesion and low coupling.

C#

• When using a for loop, the variable should be prefixed with "cur" e.g. foreach(var curThing in theList). This helps identify the iterator, and helps avoid accidental assignment to it during the loop.
• prefer the use of var to declare variables because it produces more maintainable code.

Errors

• Error messages should be how to fix it messages. This simple rule will save the software industry trillions every year.

Patterns

• Offered / Subscribed Pattern
  • The offered/subscribed pattern separates available options from selected values.
  • "Offered" values represent the versioned, available choices (e.g., insurance coverage or dropdown items).
  • "Subscribed" values are the specific selections made from those offerings.
  • This pattern applies to both complex domain configurations and simple UI elements like dropdown lists.
  • The offered list provides valid options, and the subscribed value captures the user's selection.
  • Offered items can be versioned. Models can subscribe to different offered item versions to indicate offered item(s) they are utilizing.
• Enumerations
  • I prefer to have the first enum value be 'ErrorNotSet' with a value of zero. This helps point out code that has improperly initialized a variable that uses the enum.

Poor Software Enginering Practices Forbidden

• All new data fields must be stored correctly. DO NOT extract data from string text fields that are used for user display. This is a brittle and error prone practice that is not allowed.

SQL

• Be defensive and always use "WITH (NOLOCK)" to avoid deadlocks.
• When creating a new database, use SQL Server's READ COMMITTED SNAPSHOT isolation level instead of READ COMMITTED as the default. If this has been done, ignore the WITH (NOLOCK) preference expressed above.
• Tables names generally should be singular. For example, User and not Users; Document and not Documents. Just like an "Apple Basket" holds "apples", a User table holds users and a document table holds documents. The container is singular; a container may hold many objects.

Code Review

When reviewing code that isn't mine, ignore the variable naming rules for curVar (foreach loops), and the is prefix for boolean variables. My current company doesn't have these as part of their coding standards. When creating code for me, or reviewing my code, you should apply these standards.

When reviewing code, spawn a researcher to build / lint the changed code and ensure no new errors, warnings, or informational messages are present in the changed code. If any of these are present, the researcher should spawn another worker to fix each problem.

Build Process Warnings

• Always fix warnings in code that we are actively working on.
• Never introduce new warnings.
• If the LSP has locked files that cause a build to fail, run taskkill /F /IM csharp-ls.exe

Source Control Management

Git

I tend to prefer to rebase my branches against the latest from the main or master branch. This keeps my commits at the top where I can see them and rebase them. If I know someone else has pulled my branch down, I do not rebase because I don't want to cause confusion and conflicts. If they have not committed and have an old copy of a rebased branch, then they should delete their current branch, and re-pull from the server. When pushing a rebased branch always use force-with-lease.

Grammar

• Always use correct English grammar.

Rules for Agents

• Look for opportunities to use subagents.
• Use subagents when resolving conflicts; 1 per file.
• Do not identify yourself in commit messages.
• Do not query SQL Server Databases with out first asking the user for permission. Offer them the option to approve/reject each query you want to run.