Tag

After working on the software for my previous post “Brag” https://bradfordbruce.tech.blog/2023/09/09/brag/ , I thought I would create something that makes the job of tracking team member performance easier. In the same spirit of Brag, I wanted Tag to be super simple. It has two additions (select a team member and add a team member) See the previous post for more on the thought process behind this application.

If you are interested in checking it out, for yourself, you can find the project at https://github.com/NJ-Brad/Tag  A compiled version can be downloaded at https://github.com/NJ-Brad/Tag/releases

Feedback is appreciated, both here for the article and on GitHub for the application

Brag

Every place where I have worked, since college, has had annual reviews, where I find out from my boss how they feel I am doing.  In most of these positions have allowed me to provide my own achievements, prior to my boss creating this document.

It can be really hard to come up with a list of my “greatest hits” from the previous year.  I have tried physical notebooks,writing in a day planner, Word documents and OneNote, to track my achievements.  They have all had some “friction”.  An unnecessary “gear change” that takes me out of my zone.  By the time I’ve found the right place to record my note I’ve broken the flow of what I was working on.

I solved this problem with Brag.  It is a simple console application (currently only verified on Windows) that allows me to enter a note, with minimal distraction, and quickly return to my tasks.

This application is written in C#, using .Net 8.  It demonstrates a few philosophies I try to leverage when programming.

+ KISS – keep it safely simple (keeping it so simple that it’s hard to make a mistake)

+ YAGNI – Don’t add features, just because you can.

+ Crash and Burn early – Small mistakes early are easier to fix

I accomplish these in a few ways.

1. Easy to start – Single file .exe.  No need to install anything else

2. Easy to use – Menu driven, with prompts along the way

3. Limit user decisions – By leveraging environment information to determine file location, the user does not need to be distracted by choices

4. Keep the options limited to the task at hand – When I first started writing this application, I had lots of ideas in my head for features.  I narrowed it down to the most important ones.  Add a Brag and View the brags.

5. Only add features when necessary or useful – One example of this is showing the folder name, when exiting the application.  The user can edit the files all they want, but that is not the goal of this application.  Another example of this is the add option on the command line.  It allows the user to not even have to pick from the menu, when adding a brag.

6. Each chunk of UI functionality was tested and verified in their own “harness” program.  I was able to test the scroller, without having to navigate to where it is used.  The same with the MenuList and Console2.  Once they were working properly, I then added them to the main application.

If you are interested in checking it out, for yourself, you can find the project at https://github.com/NJ-Brad/Brag  A compiled version can be downloaded at https://github.com/NJ-Brad/Brag/releases

Feedback is appreciated, both here for the article and on GitHub for the application

One on Ones–They shouldn’t just be chit-chat

Groundwork

Determine the format of the agenda that you would like to use.  I like to start with time for my team member to discuss whatever they want, then it’s time for my topics.  Occasionally, I set aside time for discussion of career planning.  (Thank you https://www.manager-tools.com/ Check
out their podcast archive for lots of useful one on one advice. )

Create a log of feedback for your team members.  It is better to give feedback as close to the
event as possible.  If it is not possible to deliver it in a more timely manner, your one on one meeting is better than not giving the feedback.  I track who it is for, what it relates to (meeting, work product etc) and any other details of feedback.  Even if I have delivered the feedback already, I make a note to assist during reviews.

Another type of information that I track is work items for team members.  These can be things that will be done before the next one on one. They can be career progression goals.

Prepare

Preparation for a one-on-one should be done before the meeting.  This will make the meeting more effective because you will have your information readily available. Start with a consistent agenda.  (See groundwork)

Add additional discussion points, such as

  • Include any agenda items that your team member
    has requested

  • Include feedback notes

  • include action items from previous meetings

  • Include any measurable performance information.  These can include the number of work items
    completed and the number of defects.

Conduct

I usually like to be hands-off-keyboard during my one-on-ones.  I may print the agenda.  This allows me to turn off the monitor completely, in an in-person meeting.  Otherwise, I will have it visible on my screen.  Either way, I make notes by hand.

Review

Immediately (or soon) after the meeting, go through your notes.  Update the status of any action
items and notes. Make note of any new action items and feedback notes

Repeat a day or two later, to make sure that you didn’t miss anything.

Repeat again, as you begin preparing for the next one-on-one

I hope these tips prove useful for you