Josh Charpentier

I was talking recently with my manager in a mid-year review, and we both came to the conclusion that one of my biggest strengths is my communication. I've been reflecting on that because I realize I now feel extremely comfortable talking to most people, but that's not how I always felt. So why am I so comfortable and good at communicating now? I think it really comes down to two things, the first of which is something I learned from a close friend: talk to people like they're people. I can't say when, but I remember noticing how comfortably my friend went into conversations, and I later realized the reason for that comfort was that he wasn't seeing the person he was talking to as different from himself. It sounds simple when it's written down, but I think we carry a lot of assumptions about who we are speaking to. We may be afraid that someone is out to get something out of us, or ask something of us, or judge us. I think the last one is what I always used to anticipate. As time's gone on though, I've realized that as you open up space to be judged by presenting yourself as more authentic, you invite authenticity and humanness from whoever you're talking to, and all that tension that may otherwise exist evaporates. I think the other crucial key to being a good communicator, at least in the workplace, is being clear about every detail in both the questions you ask and the assistance you provide. I cannot count the number of times I've spoken with people who are vastly smarter than me, but when I ask them a question, their response leads to even more questions. Or the people who ask a question and get an answer totally unrelated to what they were asking about because they didn't spell out what they wanted. I tend to take the following approach when helping others: 1. Explain at an abstract level the behavior they are asking about. 2. Help them reach a point of understanding the abstract description. 3. Equate the abstract to a more practical level, drawing analogies back to the abstract. I think getting too technical is a fast way to end up causing more confusion than help, but that technical piece is still needed, so make sure the person understands the abstract first. Similarly, I think the best thing you can do when asking a question is first describe what you think the answer is, so your misunderstandings can be fully understood and people can see exactly where you are going wrong. My manager claimed that communication, in his eyes, was more important than any other quality. A good communicator is easy to get along with and easy to work with. Much can come from good communication.

I started reading The Grapes of Wrath a few days ago. Early on, Steinbeck describes a man being pushed off the land his home is built on. The one doing the evicting insists it isn't really him doing it. It's the Bank. And the Bank, he says, is unstoppable. It always wants more, no single person who works for it is truly responsible for what it does, and there is no one to blame. He calls it a monster: something men made but no longer control, something that seems to exist above humanity as a thing entirely its own. The man losing his land asks how the other can do this for three dollars a day, knowing he's uprooting families who now can't feed themselves. The answer is that he can't afford to think about who he's hurting. He can only think about what keeps his own family fed, whatever the cost to anyone else. The whole time I was reading, I kept thinking about the last decade of social media, and now AI. And I kept thinking about the developers. I get the sense that sometimes developers feel that they contribute to something without ever thinking that it is their own. They work on projects and contribute their ideas, but the product still isn’t theirs. When something goes wrong at scale, there's rarely one person to point to. Responsibility can spread so thin that it eventually evaporates. Everyone did their small part and no one will take ownership of it all. No one built the monster. But responsibility is not destined to evaporate. This calls back to a lesson learned from The Pragmatic Programmer: take responsibility for your code. Whether you write it or AI writes it, individual contributors are responsible for their work. Steve Jobs once described contributions in the tech space as sediment: each of us contributes a thin layer to a mountain no one will ever fully see. He meant it as a reflection on how quickly our work is buried and forgotten. But I think this metaphor has another meaning. If you laid down a layer, you helped contribute to where the surface now sits. You are responsible.

Being in a position where I'm learning more about various topics unrelated to much of my day-to-day work, I find myself reflecting a lot on the importance of both industry experience and additional out-of-work effort. Firstly, I should note that I am in a lucky position: I have the time and am able to consistently grow my knowledge base outside of work. I have noticed that there is so much I've learned from my first year of working full-time, which has just concluded. Seeing the day-to-day challenges that teams face and juggling various opinions, deadlines, and responsibilities is not something I would have learned from a book or online resource. I would certainly have less empathy for the pain points that can arise in these areas. In contrast, the growth I gain from speaking with coworkers who have been working for many more years than myself is, once again, something I can only really experience in a work environment. And if all I'd learned was what I learned while on the clock, my knowledge base STILL would be FAR greater now than it was a year ago. Even so, my knowledge would in many ways be company-scoped. I might never learn about alternatives to our approach simply because we didn't choose them, and my understanding of other practices and technologies would stay limited. Enter: out-of-work learning. For the past few months I've been heavily focused on C++, strengthening my grasp of data structures and algorithms, and learning system design. What I've gained in each of these areas is enormous, and almost all of it came from outside of work, or at the very least built greatly on what I picked up on the job. I have learned a great deal from both, and will continue to do so. I am proud of all that I've learned in a relatively short span of time.

It's been about a month now since I've started really grinding away at trying to become a better engineer outside of work. I've been learning C++ and working on rebuilding the shell (thank you CodeCrafters for a great project), working on DSA problems on NeetCode, and learning about system design from Hello Interview. Looking back I'm stunned by how much more I know now than I did even just one month ago. C++: My understanding of C++ is growing quickly, learning how to write code equivalent to the languages I am more familiar with. It takes time but, slowly I am getting a better understanding for things like pointers and addresses, C helper methods which can't take "strings", std::move() to manually hand pieces of memory around, etc. DSA: As for DSA, I've been really trying to better understand two pointers, sliding window, and linked list problems, all of which I feel much more comfortable with now. I still struggle with medium problems, but even just the comfortability with coding and thinking about how to solve a problem has increased significantly. System Design: Lastly, I've learned everything I know about system design in the past month, having never touched it before. Learning about various web protocols, caching, sharding, APIs, and more all to degrees that really interest me. Thinking about problems in a more tradeoff-centric, abstract way has been really refreshing and enjoyable to learn about. All this to say, it's impressive what can be done within just one month. I can only hope my knowledge will continue to grow going forward.

I recently finished reading The Pragmatic Programmer by Andy Hunt and Dave Thomas and despite the vast amount of good advice, one phrase stuck out to me: "no broken windows". My understanding is that there was a study done which showed that a building with one unrepaired window soon had multiple unrepaired windows, and other signs of neglect. The idea being that once people saw that no one cared enough to fix the first window, there was less of a desire to maintain the rest of the building, because, again, no one cared about the window. Hunt and Thomas extend this idea this idea to software engineer, suggesting that as software engineers, we should not let neglect slip into our codebases. I've often found myself seeing something and thinking "someone else will get to this" or "this is an issue, but not large enough to warrant addressing". Lately, since I've read this book, I've stopped thinking like that. I remind myself, "no broken windows". Fix the issue now, or at least address the issue in an upcoming PR. It's been my experience that unclean codebases can tend to run rampant when not enough care is put into maintaining them. That care needs to be put in constantly, and truthfully, it requires active decision making and thinking that not everyone wants to engage in. I think in the long run though, the whole team will be glad if they can look at a well maintained and easy to understand codebase. Fix any broken windows.

In general, there seems to be some passive aggressive/ironic conversation around using Obsidian, of which I'd heard little about. After giving various note taking apps a try I decided to try Obsidian as well, and it is really transforming how I learn. I find that I used to be much more passive in my intake of information, whether that be through watching videos or reading books. The fear was that I'd write notes but never again look back at them. Luckily for me, someone created an Obsidian plugin to turn notes into built-in Anki flashcards with ease. This has been a life changer. I have hundreds of flashcards now and each day I have a set of flashcards to look through and practice for spaced repetition. I am feeling the benefits of this more than any past attempts to really get into algorithmic thinking. I should also note that Obsidian's easy linking between notes is an incredibly useful feature. Lastly, I think much of the meme-focused conversation around Obsidian is that the vibe-coding tech bro will link it to their local AI system and have it make all these useless notes. Honestly, I can't attest to AI integration as I haven't attempted it. The same can be said of many other plugins that are made for Obsidian. I really feel like people should give it a try as a note taking app, and if they feel limited, a plugin probably has your back. Add plugins iteratively as to not be overwhelmed.

Ever since the term "vibe coding" or "AI-assisted coding" became a real thing, I've noticed two polarizing camps emerge. The first claims that if you vibe code, you're less of an engineer because you don't actually know what you're building. The other believes that if you aren't vibe coding, you are less of an engineer due to your inability to keep up on emerging tech. I've seen very little in the way of a middle ground. In reality, I've found there is a vast middle ground where most of us should be operating. You can use AI to your advantage while still maintaining the knowledge needed to understand what's happening at the code level. Those who I've witnessed seem to make the most of the middle ground are those that not only can understand the generated code, but also know the codebase so well that they can easily pick apart lies from a given AI model. For instance, some model may claim to have the best approach to a solution, and as someone with minimal codebase understanding, you may believe it, whether it's correct or not. This is where the problem seems to stem from: the potential to end up with some faulty product and not know why. I believe the more unfamiliar you are with a given codebase the more you should look to avoid putting your code in the hands of a model before you understand it entirely.

Sometimes I have doubts about how I am attempting to grow my knowledge and position myself better for the future. There is, after all, so much to learn when it comes to computer science. Each subsect of the industry has infinitely more to learn, and it can sometimes be tough to feel that I am doing enough. The added layer of this being *drum roll*: AI. Will some of what I'm learning be fruitless if we delegate certain tasks to AI in the next few years? Why learn C++ and how to create video game art, for instance, if AI will be doing those things before too long? Everyone, even you reading this, likely has an immediate answer when I pose those questions, but the truth is none of us know how the future is going to play out. While it would be foolish to ignore all the opinions and predictions, they cannot be taken as law either. At the end of the day, I need to focus on the tools I have at my disposal and how I can utilize those tools while also staying focused on my goal. Yes, AI exists, and it won't stop me from learning things that may or may not be useful in 5-10 years. But is usefulness the only reason to learn something? I would argue that the mere act of learning is at least equally important. Pushing oneself to grow and adapt to new and changing landscape will only ever be a good thing. In the meantime, I've found I will utilize AI to help me learn. Here are some of the ways I'm already doing this: - Detailing project folder structure + what each file will do according to best practices - Spelling out project requirements based on an idea + back and forth feedback - Creating individual file templates (commented up boilerplate including methods for me to implement manually; comments may include topics to research too) - Deliverable art requirements based on the scope of the project and more. This is all to say, I can't predict the future, I need to stay focused, and remain confident that investing in myself with the tools available will get me to where I want to go.

Recently, Anthropic announced that they would be giving their latest model, Mythos, to a select number of companies rather than the general public due to its prowess in finding dangerous security vulnerabilities. Something that I found interesting surrounding the discussion of Mythos and its implications, was the idea that more modern languages are sometimes being encouraged in opposition to languages that allow memory manipulation and other low level capabilities like C and C++. I wonder what the implications of this would be in certain industries. As far as I am aware, the reason so many video game developers rely on C++ is because it allows for greater efficiency thanks to, in part, the ability to manage memory manually. It seems like the strength of a language like C++ is also evidently its weakness. I wonder if AI models will find that these lower level languages are much more easily exploited than modern languages. Only time will tell. Furthermore, it's tough to tell if many companies really are trying to steer away from these lower level languages or if this was an overstated occurrence. My inclination is that, in reality, the number of companies making the decision to avoid certain languages due to security vulnerabilities is very few, both because of the different needs for these lower level languages as well as the feasibility of switching at this point. On a team that primarily programs in C++, converting a codebase to a more modern language not only would take months if not years, but also would rely on the ability of many to potentially have to learn a new language as they convert code over. I've seen this on a smaller scale in the workplace and it seems like it's doable but may limit the ability of the team to make informed decisions. On the flip side, it could be argued that the investment of adapting a new language is less and less as AI models do more and more of the actual coding. Food for thought.