2023 In Code From Wakatime

A few years ago, after seeing someone mention it on Mastodon, I started using Wakatime to track my time coding. It’s a service that offers a plugin for basically any editor you could imagine, and it tracks metrics about what you do. What OS and editor you use, what projects you work on, what types of files you spend time on, etc. The metrics are honestly pretty neat, and I love using it.

Part of my initial affinity was because it allows me to track my time by project, and this was actually insanely useful for me when I was working a job where I had to account for how much time I spent working on projects for each customer. Obviously this doesn’t cover everything I did for that customer since it was only time that I was actively working in an editor. It didn’t include time spent looking things up, working on and testing my deployment, etc., but it gave me a decent basis for the time spend writing code. That in turn made it easier to track everything else.

The other aspect I enjoyed is simply that I’m a geek who loves to see stats on things. I’m the type of dork who would finish a game of League of Legends and spend forever digging through all of the end game stats… and would actively have them in mind when playing the next game. So it’s simply interesting for me to see things like how much time I’ve spent coding since I started using the service, how much time I’ve spent on professional versus personal projects, how much time I’ve spent in different editors, etc. I want to say this was the first time Wakatime has done an end of year recap, though I could just be failing to remember it in years prior. Regardless, here are my highlights for 2023.

Overall, I spent 917 hours coding out of my total 1,627 total hours with Wakatime (at the time of this writing.) On Wakatime, that put me in the top 3% of developers. However, it’s important to keep in mind that’s just out of people using Wakatime. I’m lucky enough to work in a job where having metrics pushed to Wakatime like this isn’t a big deal… so I can use it while I’m working. Plenty of developers are absolutely not in that situation, so even if they wanted to track this time, it’s not an option. I would actually guess that my daily average of just over three and a half hours is probably on the low side compared to most “developers” since I don’t do development full-time at work; I split my time between a few different areas, and one of them just happens to be coding.

Of that time, I spent 837 hours coding on a Mac and 80 hours coding in Linux… which tells me that my time spent working on personal projects has really suffered. My MacBook Pro is my work machine while I use Linux on my personal laptop. So if I’m coding on the side, it’s on Linux. This is something that I think happened for a few reasons. I’ve had a lot of changes in my personal life this year that mean I’ve not had as much free time as I previously did. 2023 also saw a lot of changes in what I did with my free time, including working on this website and building (and managing) another site. I still have a bunch of ideas for personal projects that I’d like to get back to working on in 2024, though.

The editor numbers were really interesting to me just because I’m a snob about them. Regardless of my opinion of an editor, though, I’m a fan of using the right tool for the job even more. As a result, VS Code took the top spot with 543 hours just because it gets so much love from so many communities and has excellent tooling… even if I hate how bloated and clunky it is as a web app parading as a native app. Neovim is what I reach for on smaller projects, and I honestly want to get more familiar with using the built-in debugging tools most languages offer directly so that I’m not stuck with VS Code just so I can debug easily. Sublime Text is my preferred GUI editor, but the lack of features compared to VS Code is pretty stark. While there are a decent number of packages for it, they don’t get the same kind of love that VS Code ones do. Many are dated, and I think it’s only a matter of time before breaking changes eventually start to occur. IntelliJ is something I just started using this year for working with Groovy. Even VS Code doesn’t really have much in the way of Groovy support as far as I could determine, and IntelliJ makes working with Groovy, especially different versions of Groovy, a breeze. It’s also great for handling things like importing .jar files to a project and, subsequently, compiling my own .jar files. Yes, I could manage all of that from the command line, and no, I don’t want to do that. Vanilla Vim isn’t really something I use these days. I just have it set up with Wakatime on my personal VPS to track when I’m making tweaks to one of my websites or to a simple project running as a cron job on that machine.

I worked with far more file types than are seen here, but I didn’t want a screenshot that was multiple pages long. After TypeScript, everything falls off pretty hard, so I figured this caught this interesting stuff. Python is my de facto language for both my day job and a lot of my personal projects. As a result, I’m not at all surprised to see it at the top of the list. C# is something I worked with a decent bit in my previous role, but I haven’t done much with it since I left that position. I’d honestly like to circle back on it sooner rather than later for one of my personal projects. If that ends up being something that happens, I could see there being a blog post on it here at some point in the future; for the time being, I haven’t touched the language in a few months, though I recently bought a new book to refine my understanding of it with the idea of starting up a new side project.

Groovy is a language I got back into using this year after a little time away, and is what prompted me to start using IntelliJ as an editor. I’m sadly stuck working with a very old version of Groovy; I’d really like to spend some time using Groovy 4 (and eventually 5 once it releases.) Markdown is pretty ubiquitous for things like README files, so that always makes an appearance. PowerShell I worked with some in my last job, again, but I would honestly struggle to write anything more than a basic script in PowerShell right now. I think that’s a good thing because, while you can do things like create proper classes and do OOP with PowerShell, even the tooling from Microsoft doesn’t have any support for it, making it a fairly miserable experience. It’s clearly something Microsoft wants people to use as a sysadmin tool for building scripts rather than a developer tool for building applications. Puppet is the infrastructure as code tool we use at work, and while the DSL can take a little bit of time to get used to, I’m honestly rather fond of it. You can create a lot of customizations for it with Ruby, and after creating a simple “secret manager” library for the server side, it’s something I’d be interested in doing more of. Ansible tends to be the go-to tool these days, but Puppet’s architecture works perfectly for our use case with agents phoning in to a central server (whereas direct SSH access from a central server doesn’t), so I don’t see us moving away from it any time soon.

Bash is kind of all over the place for me, spanning from fairly large scripts I’ve written for other people in the organization to deploy various applications and services to quick helper scripts I write for myself to manage Kubernetes. JSON and YAML are always going to be around for configuration, and HTML is something I don’t do a ton of since I avoid frontend wherever possible; I just don’t enjoy it.

TypeScript is the last one that I only used for one project, but I was really interested in learning it. Since I’ve never been a frontend person, I’ve always had a bit of a dislike of JavaScript, and I’ve never been motivated to use it for a backend. However, I had a need for a GitHub Action to copy an archive of a repo to SharePoint Online when a change was made to the main branch. After looking through the marketplace, I saw a few things that were close but didn’t quite do what I needed. I initially created my own Action in Python using Docker, but while it worked I didn’t love the fact that it took about 40 seconds to spin up and complete. It wasn’t a horrible amount of time considering a whole container needed to initialize in the background, but I knew I could do better. I ended up forcing myself to learn some TypeScript and created a native JavaScript Action. It was a bit of a learning curve, but I honestly didn’t end up hating TypeScript nearly as much as I hate JavaScript. I also don’t love it, however, and I’m not motivated to use it outside of cases where it can make being forced to deal with JavaScript a little less painful.

Overall, I think I had a decent year of coding in 2023. I’ll be curious to compare these results with 2024 just depending on how my role fluctuates at work and whether or not I’m able to get back into the swing of regularly carving out time to work on personal projects. I really need to read that C# book sooner rather than later… though my reading numbers haven’t been great lately.