Today I want to talk about project planning and when it can occur. Typically, you want to do all your project planning that you can at the start of a project. Some things will always come up, but its best to always have as much planned as possible. For example, if you get sixty percent of the work identified and planned before staring a project, the remaining forty percent doesn’t just disappear.

Do you ever look at a commit message and think “this is just awful”? I’m sure you have, especially when doing a code review. git commit -m "stuff" might work for personal projects or when you’re frustrated, but you should work towards a standard way of doing your commit messages. Different places have various standards, but one open source standard I’ve adopted is conventional commits . It’s taken several months to get into the habit of using conventional commits, but now that I’ve gotten used to it, I can’t imagine not using this commit style.

Today’s post is going to be a short one, I just renewed my AWS Solutions Architect - Associate certification and gained the AWS AI Practitioner certification and thought I would share some tips that helped me through both. Read the questions thoroughly: there’s usually 1-2 keywords that will make one answer stand out. Read the answers thoroughly: I’ve found that the pattern is usually 1 off the wall answer, 2 that are similar, and one that seems plausible, but still kind of out there.

Recently, I had the opportunity to read The Five Dysfunctions of a Team: A Leadership Fable (on O’Reilly ) and wanted to provide my thoughts on it. The book follows the story of Kathryn, who took the position of CEO at a dying startup tech company. The company can’t ship software effectively and is having internal problems with its C-Suite leadership team. The team itself is highly dysfunctional and cannot come to a single decision in multiple hours of meetings.

“I was nearly sure last night. He’s becoming real.” “But we’re all real!” At least, you are, and I suppose I am." “But he’s becoming more real. Extremely real. Nearly as real as Death, and you don’t get much realler…” I read that line in Mort by Terry Pratchett, a comical coming of age story, and it stuck with me. If we’re good engineers, we’re always on the move so to speak.

At work we use Jira heavily, and while it’s a very powerful project management tool, some days it can feel like it’s too restrictive. For my side projects, I keep using GitHub Projects and the difference is staggering between the two softwares. I find that I keep going back to GitHub Projects when I get frustrated with Jira. I find myself going to set up a new project to test views, statuses, and other properties when I find I can’t do what I want in Jira.

I’ve recently started programming more in Python, and wanted to document how the process of getting more experience in a new language is. One of the first things I’ve done is go being skimming books on Python. I’m currently reading through Think Python , and have picked many interesting tidbits of info on Python. While some may think it’s a waste of time to start at the beginning of a language, its not.

Over the past two years or so, I’ve been working on a new way of measuring work. This has evolved from a simple task list of things I need to get done for the sprint and other tasks, like reminding myself to ask someone a question or put in for time off. This concept has evolved into a daily note that houses three main areas to put tasks: Goals, Meetings, and Bonus Items.

As all good programmers do when learning something new, I’m starting this blog with Hello World! In this first article I hope to accomplish the following: Why did I decide to start this blog? What do I want out of this? What to expect How did I make it? Why make a blog? The idea of a blog has been in the back of my mind for a while now. Looking back at the last year of notes, I’ve found various ideas and pages tagged as “blog post” ranging from technology to project management.