Glorified Plumbing

I’ve been taking a bit of a break from things. I’ve taken a few months off from blogging and a week off from work. While I was working, I’d been taking a break from coding for one project to design work in preparation for a presentation on another. Taking a break is great, I’m back feeling more relaxed, and ready to start again. The question is “What do I do next?”

Life was very structured in the previous few companies I’ve worked for. In my last job, I headed up a major subcomponent of the system: the firmware’s ability to receive and deploy updates to itself and a couple of connected microcontrollers. The source control, project management tools, wiki, and SharePoint were very well established. We had product managers, project managers, and engineering managers. That is quite a bit of technical responsibility but it is well supported by the team and the infrastucture.

Where I am now, we are still early enough in the company’s life to need almost all of the structure to be created. I’ve been involved with this company since late February. I was given a couple of prototype boards and sent an email containing the schematic. I knew the requirements based on a lengthy phone call and the sales pitch I’d seen a few months earlier. The immediate need was hardware bring-up code and an early proof of concept. A reasonable short-term gig.

Normally, during onboarding, I get access to the internal wiki, shared drive, project management system, and code repository. I’ll be assigned a task, and off we go.

This time, onboarding has been a bit backward. I’m Firmware Engineer #1, first in the door. There was

• no repository
• no shared drive
• no project management tools
• no wiki

Did I mention, effectively, no budget?

Okay, so I have stepped into ready-made systems for most of my career. The companies had typically been up and running their engineering teams for at least a year. There were three times when I moved into five-man start-ups that were only a few months old. By then, something like Office365 or Google Drive had been adopted, and some version control was in place. Project management was pretty ad hoc, with a Gantt chart somewhere, but at least it was there.

This time around, I’ve moved into a bare-floored space with whitewashed concrete walls (metaphorically, as there is not yet a physical office). The first things needed are a workbench, toolbox, and storage shelves, and a Filofax.

The workbench and toolkit?

• My existing laptop
• IDE – VS Code + Arduino IDE
• Saleae 16 Pro (logic analyzer)
• 2 Channel Rigol oscilloscope
• Protocol Analyzers
• Bench Supply

Now the storage solutions?

• GitHub
  • Code
• OneDrive
  • Documents
  • Schematics

And wall calendar/desk planner?

• TBD (to be decided)

I’m not going to discuss the choice of the IDE; that’s just a boring, safe default. However, I want to talk about storage solutions and how they play into or work against task planning. The code repository system I elected to use actually has some level of task management built-in, but the minimal document control setup needs some support. Neither provides an overall project management solution.

After setting up my workspace and identifying the essential hardware and software, it’s time to consider how my choice of digital tools influences project management and task planning. In today’s development landscape, selecting the right storage solutions and version control system isn’t just about keeping files organized; it’s about facilitating efficient collaboration and ensuring that planning aligns with execution.

Who doesn’t opt for GitHub for their repo these days? Well, it’s either SVN for die-hard fans or Perforce for big corporations. Git and GitHub are accessible to hobbyists and popular in younger, smaller companies. It was easy for me to start a private repo on my account and add the only other user. When the time comes, we will get a business account, and I’ll change the ownership of the repo. In the meantime, we have a place to share code, perform reviews, and track bugs and requests.

Git is great with plain text, LaTeX, and markdown documents. You can track text changes as simply as you track code changes. This is particularly true in Markdown if you place each sentence on a new line, with a double newline marking paragraph breaks. A recently managed an entire book project using GitHub and Pandoc. I know how elegant and efficient this method can be. MD and LaTeX are not as intuitive as the WYSIWYG (what you see is what you get) feel of a word processor.

MS Word is comparatively simple to use; however, it yields files that are so complex that you just want to treat them like binary files. Large binary files and Git are not the best of friends. MS Word provides for document reviews; they are managed within the document rather than in a source control system. As a result, we are using a shared folder on OneDrive to share documentation, but we have to be careful about merging changes. I have previously enjoyed using Google Docs or Jira to maintain documents. They allow for collaborative editing and make sharing easy.

As for task planning, I’ve been using Jira by Confluence for so long now that I’m out of touch with other project management systems. I did start flirting with GitHub Projects, but that is a learning curve I’ve only just started on. I’ve been relying on my open Git branches to show where my work in progress is, and immediate milestones are listed in a plan of record, held as a markdown file. Now for the breakdown in communications.

As I said at the beginning, I’m not sure where to resume now that I’m back from a break. Not having a backlog and sprint to hand, I am trying to remember what I was last doing. I know it was documentation, but where is that work? Is it my local Documents folder or up on OneDrive already? Was it a customer presentation or the technology roadmap? Conversely, I can step right back into the coding, and I can figure out where I was up to.

• There’s a history of commits
• There are two open branches
• There are no pending pull requests

See, a natural way to track progress within a project, or at least in the code repository associated with it.

On the documentation side? Crickets. I don’t even get to walk into a team stand-up and someone ask “Hey Alex, when will the XYZ be ready?” I’m lost.

Maybe you’re like the old me; you might put a Post-It note on your monitor (physical or digital) or have a notebook. Perhaps you would’ve started NewCo with a project management system before the repo. I was only meant to do code initially, not run the department, so setting up the repo first made sense. What do you use to track the progress of a team composed of “Me, myself, and I”? Is it too early to spend time on adding the complexities of project management, or is that something inherently needed for a project?

Right now, I wish I’d left better breadcrumbs before my break. At least a sticky note or scribbling on my whiteboard would have worked. The few of us in the company each handle several roles concurrently. This will naturally cause us to butterfly from task to task more so than in a typical engineering team. We need a formal way to track our to-do list and monitor our status.

I know from past lives that a simple kanban or agile board can do wonders. As a lead engineer, I would happily define and break a feature into tasks and subtasks. Assigning priority, estimating time, and tracking progress is second nature. I never did time as a project manager, so I will need to use the tools in an “out the box” or “ready to wear” mode. I could figure out how to set up my preferred flows, custom forms, and report pages, but that is a workload I don’t need.

So, do you have a favorite low-cost (time and money) solution for tracking a project? One that makes sense for a project whose scope will keep a couple of engineers busy for a year or so. One that will help show a roadmap and a game plan that’s easy to digest and, most importantly, easy to maintain?