I’m a software engineer now. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.
General learnings and observations:
Writing things down is really key. I watched and learned from Daniel Gavidia how he plans out the list of PRs he’ll have to make before shipping them. This seems incredibly motivating. It also has the added benefit of creating an artifact that can be easily shared with the team for feedback, to make sure you’re on the right track.
Starting tomorrow, I’d like to sleep by 11pm and wake up at 7am.
I think that the fastest way to learn is to just write commits and push PRs. I haven’t been doing much of this over the last few months. I also notice that my velocity of technical learning has not been as fast as it was during bootcamp. It was a core tenet of Fractal bootcamp that we were required to push 3-5 PRs every single day. Can you tell by my commit history when I learned the most?
What supported this prolific output? In order of importance: 1) Daily structure 2) setting, and 3) team.
I think (1) and (2) are about the same ingredient: predictability. I would get up every day and arrive at the office at the same time. I would eat lunch at the same time. I would leave at the same time. I could plan and optimize within those bounds. The problem is that when my schedule is shifting around, it’s hard to expend energy and attention figuring out the extra logistics of my day in addition to the focus and emotional energy it takes to unblock myself and focus on my work.
My team in the bootcamp was other software engineering students equally committed to working hard and learning, as well as two instructors who were there to unblock me. While I’m working, I can replicate this by working side by side with other engineers on my teams and being proactive about my communication with senior engineers.
Noticed that Ty tends to be very successful in how he does LLM-assisted engineering and debugging by sometimes providing less context to the LLM - saying things like “ok, wait, i don’t get it” or “no silly, we have to do this!” or “could you please explain how to do XYZ.” Providing informational context like codebase snippets is good. But LLMs are bad at questioning your assumptions, so maybe open-ended questions are more productive because they prevent the LLM from being painted into a corner.
Right now I’m able to write and deploy services to our k8s cluster. I feel like I’m able to get by mostly with the help of Claude, and I understand in terms of our system architecture how to write and deploy new k8s services. How can I sit down and learn k8s in depth so that I can more effectively see what’s possible from infrastructure?
I need to have smarter, more capable answers to technical questions. “Oh yeah, we can do that, here’s how.” How do I do this?
Technical learnings and observations
Tips for coding with LLMs:
Repomix - pack your code repos
URL to Markdown - transform documentation into markdown that can be copy-pasted
I should write test files to test endpoints rather than using curl commands from my terminal, because those are more easily usable by other engineers building in the repo
The Model Context Protocol (MCP) is a framework to allow AI systems to interact in a structured way with data sources. An MCP server allows generalized tooling to be exposed to an MCP host. An MCP host might be Claude Desktop or a code editor that wants to integrate with an external data source. The host will have a client that is programmed to interact with the MCP server in a particular way.
(need to shore this knowledge up - I should build an MCP client and server)
On logs - there should be an easy way to debug your services by controlling logs. I have services deployed to a k8s cluster. Logging with pino is enabled. I was getting a 401 unauthorized error. The 401 unauthorized error should be returned to the user but also raised in the console. (Does this happen natively if you don’t force console.error? Maybe wrapping in a try-catch block just automatically surfaces the error in the console.)
Describing myself
In the interest of getting better at telling my story, I’m working on how I describe myself in the most impressive way. I’ll open-source this process. Here’s a current draft:
“Parth is an engineer trying to help AI eat the world. He’s done product and research engineering to build voice agents, computer use agents, AI search and consumer products at Profound, Sandbar, HDR, and ESAI.”
This feels like more of a VC-friendly pitch, because I think I want something more complex than AI eating the world - more like, I want AI to join with the world, and for humans to join with it. I want to usher in the cyborg future, and I want to help us integrate well. I want a cyborg economy.
“Parth is an engineer working to usher in our magnificent cyborg future. He’s done product and research engineering to build voice agents, computer use agents, AI search and consumer products at Profound, Sandbar, HDR, and ESAI.”
more snippets to incorporate
“experimenting at the edge of AI”
“productizing”
“3X Betaworks companies”
“SPC, Khosla Ventures”
“helps AI companies eat the world”
doesn’t incorporate: my prev healthcare experience, product management experience, FindOurView, founding, 0 → 1 as much? maybe it could in the future.
every story is incomplete, it’s just - is it the right story for this moment, for this purpose, for this audience?
(If you’re not interested in getting these updates, but you’re interested in staying subscribed to the rest of my Substack where I write about more than just tech, you can unsubscribe from the specific section “[yelling computer].”)
Very thought provoking post.
"open-ended questions are more productive because they prevent the LLM from being painted into a corner". I find this very insightful and I am going to explore this aspect more in my posts. this aligns with my thoughts on how to be a super engineer in the age of GenAI
"write test files to test endpoints" -- why is this effective? because doing so creates a reusable and active artifact. Warning: by shifting ones mindset to a reusable pattern will forever change you, for better. it forces you to think deeply about interfaces (in this instance, "Test driven Development" mindset). There is also "Behavior Driven Development", "Design Driven Development".
MCP - I learned something new. amazing yet predictable. when you have a plurality of something, such as many LLMs, or many data sources, or many services or any kind, you need a language or protocol to talk to them - once again think of this as a pattern. HTML was invented for a similar reason. SQL for databases. the list goes on.
Epiphany: The act of coding should be ones daily flywheel. the one does it, the more one wants to do. that fantastic feeling of solving problems by coding becomes the fuel for the flywheel. and GenAI should be your coding buddy (pair programming). There is no such thing as using it too much. because that's the only way to will learn how to use it well. its a crutch in as much as GPS is one for navigation. doesn't GPS enable navigating more complex routes? and calculators did not kill future mathematicians. I will explore this more in one of my posts.