YT YouTube2Text

YouTube2Text → Transcripts → My Daily Software Engineering Workflow (ft. Logitech MX Keypad)

My Daily Software Engineering Workflow (ft. Logitech MX Keypad) — Transcript

by Caleb Curry · 3,955 words · 568 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00I have been a software developer for my
0:01entire adult life and recently I've been
0:04building my own software and one thing
0:06that I constantly feel is that I'm not
0:07building things fast enough or I'm
0:09taking too long on slow tasks. But
0:11throughout this entire process I've
0:13found that it's often inefficiencies in
0:15my workflow and not so much that I'm a
0:17slow developer. So there's a good chance
0:18you're spending most of your time on
0:20routine or mundane tasks or repeating
0:22things constantly that you could
0:24automate or get rid of entirely. And
0:26when you start to keep your eyes open
0:27for these things you start to notice
0:29where you're spending your time and then
0:30you start to realize how much time is
0:31actually wasted just in the process of
0:34software development. So what I do is I
0:36always try to solve certain problems
0:38permanently. How can we fix our workflow
0:41or create something that will prevent me
0:43from wasting time ever again in the
0:44future? This can make sense in code. So
0:47for example, if you're constantly
0:48writing the same code, creating a
0:49component that you can reuse, this is
0:51just basic code design. But what then a
0:53lot of developers fail to do is take
0:55those same principles and apply them to
0:57their actual day-to-day workflows. So
0:59what I want to do in this video is talk
1:00about some of my software engineering
1:01workflows. By the end of this video
1:03you'll see how I save a lot of time and
1:04stay focused so that I can spend as much
1:06time as possible on building valuable
1:08software. Let's start off with something
1:10simple that you can start doing today
1:12and that is cataloging all of your
1:14thoughts or effectively a brain dump of
1:16any information you're storing up here.
1:18Get that down on paper, ideally
1:20organized in some way. The goal is to be
1:23able to have software development
1:24sessions without a bunch of random
1:27thoughts picking at your brain. You want
1:28to focus on just the work you're working
1:30on, driving that to completion. So I
1:32will have a place for whatever I have to
1:34do, whether that's features, bugs,
1:36client requests, ideas, or different
1:38integrations that I need to consider.
1:40And I can put all of that information in
1:42one location and then I can have an AI
1:43agent actually sift through everything
1:45and organize it for me. Now a lot of the
1:47things we're going to talk about here do
1:48not require AI. This is just an extra
1:51thing that you could do to go above and
1:52beyond rather than just having random
1:54notes splashed on a page, you can have
1:56an agent go through that and turn it
1:58into actionable items that you can then
2:00keep track of much easier, making sure
2:01nothing gets missed. I'm going to show
2:02you exactly what this process looks
2:04like. To make it easier, I use voice,
2:06basically just chat and say everything
2:08that's on my mind or anything that I
2:10need to get done. This can then be fed
2:12to a file or to an AI agent to do
2:13process immediately. For this episode, I
2:15partnered with Logitech and they sent me
2:17their MX Keypad, which can make
2:18automating this process super simple.
2:20So, what is a Logitech MX Keypad? It's a
2:22programmable LCD button pad with
2:24multiple pages where you can customize
2:26all of the buttons to do pretty much
2:28whatever you want. So, any action
2:30[snorts] you find yourself doing over
2:31and over again, you can program into a
2:32button and then just tap it whenever you
2:34need to use it. I have one key on here
2:36programmed to start Claude Code and
2:38transcribe what I'm saying, and then
2:40that gets fed to a skill which is
2:41designed to go through any of the
2:43information I give it. So, we can start
2:45voice. Today, I need to pay some bills,
2:48I need to go on a walk, and I need to
2:51edit this video. I also have like three
2:53bugs in the backlog.
2:55This is just a very basic example. You
2:57can have the skill describe GitHub
2:59issues or markdown files any way that
3:01you want to organize your information.
3:03I've used this approach to help with
3:04content planning and feature planning,
3:06basically describing everything that I
3:08want to happen and then having AI
3:11distribute that into logical groupings,
3:14which is the best way that I think. So,
3:16instead of just having a wall of
3:18information, I have all of my ideas
3:20nicely grouped. So, then I can basically
3:22plan out very large things by organizing
3:25just a bunch of little pieces. So, for
3:27example, we have this voice here. This
3:30launches Claude Code,
3:32has a delay and then hit space. Very
3:34simple to set up. This can have multiple
3:36pages for all kinds of different custom
3:38buttons, as well as profiles for certain
3:40apps or custom profiles for certain
3:42workflows, so you can create any
3:44customization you need. And then if it's
3:45an application profile, it'll
3:47automatically switch to that profile
3:49when we open that app. So, for example,
3:51button to open VS Code, and then my
3:52keypad completely changes to show all of
3:54the Visual Studio Code icons. There is
3:57also a marketplace, so you can go in
3:58here and find plugins for important apps
4:01that you use,
4:03whether that's Teams, Cloud Code,
4:05Chrome, IntelliJ, Visual Studio Code,
4:07OBS Studio, and many more. What I did
4:10next went a little bit deeper, but I
4:11actually used their SDK to create a
4:13custom record button, and this would put
4:15all the recorded messages into an inbox,
4:17and then whenever I'm ready, I can just
4:18process that entire inbox rather than
4:21having to transcribe directly into
4:23Claude or whatever AI agent you're
4:24using. It's really not all that much
4:26different. This is just going to open up
4:27Copilot and then paste in a prompt that
4:30we're going to continually use. So,
4:32process every pending voice capture. So,
4:34here's an example of this running. It's
4:36recording, and it shows the time of how
4:38long I've been recording. I can ask it
4:40to process any messages. I could say,
4:42"Hey, I need you to look at my GitHub
4:44repo and check for any issues or new
4:46PRs." And then when I'm done, I can stop
4:49recording. So, this is just a bit more
4:50of a custom process that I was able to
4:52build out with the SDK. Last thing I
4:54wanted to mention is that with the MX
4:55Keypad, you do get 3 months free of
4:57GitHub Copilot Pro Plus. Which is a
5:00pretty good deal, so you can get that
5:01from your account here. All of the
5:03workflows and ideas in this video I'm
5:04going to talk to you about, you can
5:06follow on your own. The keypad just
5:07helps because it's often something that
5:09we're going to do over and over again.
5:11So, automating it is just going to make
5:13it that much easier. I'd encourage you
5:14to give it a try. I'll leave a link in
5:15the description. And then throughout the
5:16rest of the video, I'll show you any
5:18interesting ways that you can use the
5:19keypad. So, as we mentioned, the first
5:21goal was to get everything out of your
5:22head written down somewhere. Anything
5:24technical related to creating code, I
5:27would create as an issue. Likely just in
5:29GitHub would be fine. You could also
5:31just use markdown files or Notion or any
5:33of the other issue tracking softwares.
5:35Because the goal is when we want to
5:37actually develop, we do not want to be
5:39thinking about what do we want to build?
5:41What are we focused on? We just want to
5:43grab issues and start working on them.
5:44So, that way we can just effortlessly
5:46power through the creation of features
5:49and fixing bugs and not get distracted
5:51with choices that are not relevant for
5:53that specific issue. So, that's the
5:56first thing we want to do. Once we have
5:57those issues created, we can start
5:59building. Now, I code really in two
6:01modes. One being by hand within an
6:04editor and then the other one being with
6:06agents. Typically with agents, I'm going
6:08to be running multiple at a time because
6:11if you're just running an agent and then
6:12you're waiting for multiple minutes or
6:14an hour or whatever it might be, that's
6:15a lot of time wasted. So, let me first
6:17talk about how I would run multiple
6:19agents. So, when I'm working with
6:20agents, I like to work with up to four
6:23at a time. I usually don't go more than
6:24that because I just lose track of
6:26things. And this also gives me enough to
6:27focus that I usually don't have much
6:29down time. Like I'm always jumping
6:31between the different agents. So, what
6:33I'll do is I'll run four of these at a
6:34time and do this within iTerm.
6:38And [snorts] these will all run within a
6:39Docker container so you can see it
6:41installing everything. And this allows
6:42me to run dangerously. So, it bypasses
6:45all permissions, but it's sandboxed so
6:47it doesn't have access to certain things
6:50outside of the container. It just has
6:52access to the code and then anything I
6:54give it through Cloud Code. Once
6:56everything's done, you'll have the four
6:57windows here and you can run four
6:59different tasks in parallel. Now,
7:01obviously you could do the same idea
7:02with sub agents running from a single
7:04terminal or you could just have a single
7:06terminal window, but I kind of prefer
7:08this for visibility and just being able
7:10to jump through different tasks like
7:12this. You could also split four tall
7:14ones if you think this crunches the
7:16windows a little too much. So, obviously
7:18if you've never really worked with
7:19agents, jumping to four at a time is a
7:21little extreme. So, you might just want
7:22to start with one or two. A good start
7:24would be to use two, one for kind of
7:26asking questions and doing additional
7:28research, and then one for actual
7:29implementation. So, you can basically
7:32jump between those two topics or ideas.
7:35This will burn through usage extremely
7:37quick if you're doing some serious work.
7:39So, it's probably not going to be super
7:41useful on just the pro plan. When I was
7:43actively building on four windows, I was
7:45doing the $200 a month plan. But, I
7:47minimum probably the 100 a month if
7:48you're going to do any serious
7:50development. And then, basically, you
7:51could assign issues to each one of these
7:55and have them start to work through
7:57those. And then, as they're going, you
7:59might lose track of what's going on. So,
8:01there is the ability to rename, and
8:04that'll look at what you're talking
8:05about, what you're trying to do, and
8:07give an appropriate name to this window.
8:09So, for example, I asked it a question
8:11about weather, and now here in the
8:14message, you'll see weather look up
8:15request. So, that's where you can see
8:17what issues you're working on across
8:19these different windows. Now, some
8:20people will use different approaches to
8:23having agents work together at the same
8:25time on the same code base with
8:27different branches or trees or whatever
8:28it might be. My approach is usually just
8:30to have them work on separate things, so
8:32there's not a whole lot of stomping over
8:33each other. That's worked for me, but
8:36there are more formal approaches to
8:37this. And then, I programmed it to name
8:40all of them at once, so I can always
8:42stay up to date with what's going on.
8:43So, you can see we have weather look up
8:45request, clarify rename request, bug fix
8:47clarification, and design session. That
8:49just helps me keep track of what's going
8:51on. And then, obviously, I'm not going
8:52to do everything from within the
8:53terminal, so I can open up VS Code like
8:55so. Or, I could check out the specific
8:58GitHub issues that we need to work
9:00through, so I can automatically open
9:02those as well. Some useful shortcuts
9:04that I use within Visual Studio Code,
9:06toggling word wrap. So, if it's going
9:07off the page, making it difficult to
9:09read, turn that on. If I'm working
9:11within a markdown file, I can easily
9:12open the markdown preview, which is nice
9:15when working with markdown files to
9:16actually see how those edits show up.
9:18Can also open the markdown preview to
9:20the side, so you don't have to replace
9:22what you're working on. So, in this
9:23situation, you can see it's cropped off
9:25the side of the page, so I can just turn
9:26on word wrap, and now I can edit this
9:28easily. If I'm working within a file, I
9:30can format.
9:32You might also have format on save, so
9:34then you have to worry about it. But,
9:35you may prefer to format on demand. I
9:37also have the ability to search a repo
9:40for a specific term across all the files
9:44rather than within a single page or
9:45having to open this and type it in
9:47manually.
9:49So, that can help you find where a
9:50certain term or function might be used.
9:53Obviously, you could also go into some
9:54of these other options as well, but I
9:56tend to use the search quite a bit as
9:57it's pretty versatile. And then I might
9:58be doing all of this editing and
10:00whatever over here in VS Code, but to
10:02actually run the server, I can just
10:05launch that and it'll create a new
10:06terminal window
10:10and launch it on my specified port. So,
10:12those are some of my setups for actual
10:14development. The goal there is to be
10:16able to build as efficiently as
10:17possible, but with agents especially, we
10:20want to actually make it a little bit
10:21more difficult to get code out to
10:24production. I remember reading books
10:26about Agile and development processes,
10:29and a lot of it was, "Hey, let's make it
10:30very easy to ship code. We can do
10:32nightlies, get code out there very
10:34easily." But, with agents, if you don't
10:36have the right structure, you can
10:38actually burn yourself if you're
10:39shipping code too easily. Not saying it
10:41has to be slow, you can still do it
10:43frequently. We just want to have a bunch
10:44of gates that you need to go through to
10:47meet quality expectations, as many of
10:49those being automated as possible. I've
10:51talked about this in great detail in
10:52other videos, but there's really two
10:54main things you need to consider. The
10:55first being anything that can be
10:57scripted, so any kind of type checking
11:00or linting of any kind, any tests, and
11:04then anything that could be interpreted.
11:06So, this is something we can have an
11:07agent actually do any kind of code
11:08review or challenge any of our
11:10implementations, whatever it might be
11:11that we need it to do. And this can
11:13focus on just doing everything that is
11:15not specific to linting. So, obviously,
11:18you could tie this into CI/CD, but you
11:19might want to run it on demand. So, I
11:22have all of my linting
11:24in a check all.
11:27And you can see everything that it's
11:28doing here.
11:30So, that is the deterministic stuff, and
11:33then we also have the non-deterministic
11:34stuff being able to invoke an agent to
11:37actually read through the code and
11:38interpret. So, it could be a skill, it
11:40could invoke an agent, or you could just
11:43have a prompt snapshot that you
11:45continually invoke. So, do any
11:48deterministic and non-deterministic
11:50checks before you push any code
11:52so that you don't end up pushing
11:54something broken. This gets into code
11:56design and stuff as well. So, for
11:58example, when it comes to testing, if
11:59you can isolate as much logic as
12:01possible to test, that's going to make
12:03your code better. So, whenever I'm
12:04building something, I want to create
12:05pure functions that isolate all the
12:07logic, and then the display portion is
12:10much thinner, and we extract all that
12:12functionality into functions that we can
12:14test. That's where unit tests can become
12:15very valuable, making sure that our
12:17logic is working, and then if we have an
12:19issue with the way it's showing up, we
12:21know it's just a display issue and not a
12:22logic issue. And then obviously, do
12:24whatever research you need for CI/CD,
12:26continuous integration, continuous
12:28deployment. You can have checking be
12:30done before this code ever goes live by
12:33creating a pipeline that the code
12:35actually has to go through before it
12:37ever gets deployed. That's obviously
12:38super valuable, but sometimes you just
12:40want to do that on the fly as needed
12:42while you're building. So, you don't
12:44always want to have to rely on CI/CD.
12:47Sometimes you just want to run those
12:48commands locally, and I encourage you to
12:49do that as much as possible to make sure
12:51your code is good. And then I have
12:52shortcuts for pretty much anything I
12:53need to be using, including logs,
12:57deployments, so I can see any issues
13:00with deployments,
13:01the actual GitHub repo, so I can find
13:03any issues or pull requests.
13:06We have the Visual Studio Code project.
13:09We have the actual app login page.
13:12We have the Discord for all of my
13:15customers. We have two Obsidian
13:17shortcuts for the desktop and mobile
13:20app, so I can access any of my specs or
13:22documentation.
13:24And then we have Stripe for any
13:26payments. So, let's talk about how you
13:28can work through building software. So,
13:30I think the big thing that people don't
13:32realize is how much work goes into
13:34building good software. Even with agents
13:36being able to do a lot of work, it takes
13:38a lot of time. And I would recommend to
13:41keep your first version as thin as
13:44humanly possible so that you can finish
13:46it in a month, maybe 3 months,
13:49maybe six, but the farther you go out,
13:51the higher chance of it never getting
13:54completed. I remember reading this book
13:56when I was first starting with software
13:57development. It was about this software
14:00team that was working on getting some
14:02software out. I really didn't learn much
14:04from the book except how disastrous
14:07building software was from the inside of
14:09a company. And it made me realize how
14:10important it is to keep your software
14:12super simple to start. Even for some of
14:14my software, I thought I was starting
14:15simple and then I had scope creep where
14:17I continually added new things and new
14:20features. And then it ended up taking me
14:22like 6 months to really get a good
14:24version out there.
14:26And multiple times in that, there were
14:27opportunities for me to just stop doing
14:28it entirely. And with that, instead of
14:30thinking of software as something you
14:31complete, think of it as a continual
14:33process, a flow of information instead
14:36of a sprint where you do everything and
14:38then you're done. And if you're not
14:40emotional about it, it helps a lot. I
14:41think one of the challenges for me is I
14:43was working on the software basically
14:45full-time, gave up a bunch of other
14:46stuff. So, I started to put a lot of
14:48pressure on myself to build this
14:50software because I was putting so much
14:51effort into it and relying on it to be
14:53successful. While that did allow me to
14:55give a lot of time to the software, it
14:56put a lot of stress on me and probably
14:59made me make worse decisions. I probably
15:01could have gotten similarly good results
15:03without giving up so much in the
15:04process. So, if you can do anything to
15:06not be emotional about it, I think
15:07that's going to be helpful. And just
15:09getting into a consistent workflow,
15:11creating issues as cards, and then going
15:13through the issues, solving any features
15:14or bugs that way. That's just an
15:16approach. There's probably other
15:17approaches, but just having some way to
15:20organize the work and work through it is
15:22going to get you very far. Yes, you
15:23could have some good sprints and some
15:25productive weeks, but if you're not
15:26consistently building, then you're just
15:28not going to get as far as you could
15:30compared to if you had a really good
15:32structure where you were continually
15:33building something each week. For a
15:35while there, I was basically giving
15:36weekly feature updates on what things I
15:39was adding and things I was fixing. This
15:41added a lot of extra time, so I really
15:43wouldn't recommend that unless you
15:44already have the product out. If you're
15:46still just working on software
15:48that's not released to anybody, I would
15:50just get it out as quickly as possible.
15:52Nobody actually cares about your changes
15:54if nobody's using the software. So, get
15:55the software out and then you can worry
15:57about more formal feature change
16:00announcements. So, think of it like
16:01this, very emotionless, put requests and
16:05features and bugs into cards. Grab cards
16:08and implement whatever the card is
16:10saying to do. Push code into production
16:12if it works. If it doesn't, go back and
16:14fix it. If it does, push it, and then
16:17any new bugs you encounter, put it in
16:18the cards. Very simple process if you
16:20think about it like that, you're just
16:22building one card at a time and
16:24eventually you're going to have some
16:25software. I think people get super
16:26overwhelmed with like building massive
16:29software suites,
16:30and that's actually probably gotten
16:31worse with agents because now you have
16:33to build so many new features to compete
16:35with all the software out there, but I
16:36still think simplicity wins, so keep
16:38your product very focused and have
16:40continual progress on it over time. The
16:42actual build process is pretty simple.
16:44You capture the data, what you need to
16:46do. This is basically the brain dump
16:47section I was talking about where you
16:49just share everything you got to work
16:50on, logging that somewhere, likely in
16:53cards or in Notion or in some MD files,
16:55build the stuff, and then verify that
16:58the stuff actually works. Get some early
17:00users because they're going to be the
17:01best testers possible and actually show
17:04you how the software could be used. As
17:05you do all three of these, find any
17:07workflow issues that are slowing you
17:09down and figure out how you can solve
17:11that problem permanently. One common
17:13example that comes to my mind is getting
17:15things launched to actually start
17:17developing. So, for example, if I wanted
17:18to work on the mobile app, I would have
17:20to open the repo and figure out exactly
17:22what commands to get the server launched
17:24and all of that stuff takes a lot of
17:26time.
17:27And even if you put it in the readme,
17:29which you should do, that's very
17:30helpful, it's easy to forget and jump
17:32around setting up your Docker containers
17:34and all this stuff. So, any of that that
17:36you can automate is going to save you a
17:37lot of time and reduce the friction to
17:39actually developing, which is usually
17:41the biggest thing stopping you from
17:43progress. These are just some of the
17:44things that were top of mind for me as
17:46I've been building over the last several
17:48months. I'm sure there's so much more I
17:49could talk about, so if there's anything
17:51specific you'd like me to talk about,
17:52let me know in the comments section
17:54below. As always, I'll have important
17:55links for you down in the description
17:57below. If you like this content, please
17:59be sure to like, subscribe, and hit that
18:00notification bell, and I will see you in
18:02the next lesson.

About this transcript

This page contains the full transcript of My Daily Software Engineering Workflow (ft. Logitech MX Keypad) by Caleb Curry, generated from the public captions YouTube serves with the video. The transcript has 3,955 words across 568 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.