Over the last month or so, I’ve been using Claude Code for assisting with development tasks¹. One of the things that has confused me the most about the LLM-assisted programming ecosystem is the Model Context Protocol (MCP) landscape. In theory, MCP is a way to provide the LLM with data from an external system through a structured protocol. However, it sucks. It turns out that it is more efficient to have the AI just write code to analyse and manipulate the data from the external system directly. Rather than piping the data from the external system into the LLM’s context window and letting the LLM muddle through it, the LLM-written code can just do the necessary data processing. Computers have been good at running instructions on large datasets for a very long time and AI is not going to be a substitute for that.

A few weeks ago, Typst came back on my radar because of Sylvan Franklin’s videos on the topic came into my YouTube feed. In particular, Rewriting my resume in Typst in which he rewrites his resume from \(\LaTeX\) to Typst piqued my interest. I have maintained my resume in \(\LaTeX\) since I started at Mines in 2016, and so I figured this would be an opportunity for me to learn something new.

In this article, I am going to discuss how to build a career in the software industry. We will explore career tracks, and discuss the attributes needed to become a senior software engineer. Then I will provide my view of how LLMs will affect the software engineering industry and job market.

I recently read I Know When You’re Vibe Coding by Alex Kondov in which he described certain characteristic “smells” of vibe-coded software. For example, he points to LLMs proclivity to pave their own path and go against established patterns within a project.

The article resonated with me, but I realized that it resonated with me at a deeper level than just explaining my interactions with LLM-written software. I realized that I’ve seen these “smells” before in pre-LLM software (especially that written by students).

It’s always awkward to come out, but the lead-up is always the worst part. Once it’s done, it’s done and I move on with my life. I have been out to my family and most of my friends for a few years now, but as one of my friends described it, I’m about as out as the sun on a cloudy day. Well, I guess it’s time for the sun to shine a bit more.

A few months ago, I was asked to give the keynote address at the BlasterHacks hackathon hosted at Mines by their ACM chapter. I wasn’t quite sure what would be interesting to talk about for the keynote, so I asked some friends. Byron suggested that I either talk about hackathon advice or career advice. Since I was giving a hackathon keynote, I decided to focus my presentation on hackathon advice. I went to six hackathons while I was a student at Mines, and won prizes at all but one of them so I felt I had something interesting to say about the topic.

Donald Trump has made two vice presidential picks. In 2016 he chose Mike Pence, and in 2024 he chose JD Vance. Each of these picks was brilliant in its own right.

2016: Mike Pence

During the 2016 Republican primary, Trump faced significant resistance from within the Republican party for having a morally objectionable character, for not being a principled conservative, and for not having enough requisite understanding of politics to successfully run an administration. However, Trump emerged from a hotly contested primary ahead of Ted Cruz and Marco Rubio, two highly respected figures within the Republican establishment.

I have decided that I will not stand again in this year’s Matrix Governing Board elections. I recently joined Can/Am Technologies as a tech lead and I do not feel like I can dedicate a sufficient amount of time to be a good board member. Thus, I have decided to step aside and let others have a chance to take on the challenge of governance.

Today I am happy to announce that I have joined Can/Am Technologies as a Senior Implementation Tech Lead.

Can/Am makes a point of sale product for local governments called Teller. I worked for Can/Am in the past as a software developer and I am excited to return after nearly a decade in a new capacity. I will be leading the engineering team responsible for building integrations with third-party vendors. I’m excited about the opportunity this position will afford me to leverage my experience teaching and mentoring students at Mines in a new challenge of leading and mentoring a technical team.

In this article we are going to be investigating how the code you write gets to your users. This article is intended for consumption by computer science and software engineering students to provide insights into technologies and processes you might encounter in industry. This will be focused specifically on software delivery in web-based SaaS offerings rather than more traditional software delivery methods such as those seen in embedded systems. Every software project has different process for building, testing, and deploying to users and I’m not going to discuss every possible technology which might be used for each of these steps. Rather, I’m going to be describing what kinds of software might be used. I’ll describe how these systems affect the day-to-day work of software engineers, and I’ll also provide some thoughts on how you might integrate some of these ideas into your own personal projects.