Bethany Janos 
Brittany Ellich 
Eggyhead 
Jonathan Tamsut Brittany Ellich (00:02) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I am your host, Brittany, and I am joined by…
Bethany (00:10) Hey, I’m Bethany.
Brittany Ellich (00:13) We met while working on a team at GitHub and realized that we were all obsessed with getting better at what we do. So we decided to start this podcast to share what we’ve learned. We’ll be talking about everything from leveling up your technical skills to navigating your professional development, all with the goal of creating a community where engineers can learn and connect. Today on Overcommitted, we are joined by Bassem Dghaidi senior software engineer at GitHub, building the next generation of GitHub actions and content creator at glitch.stream.
He’s not only one of our colleagues from our actions days, but we thoroughly, that we thoroughly enjoyed working with. He’s also a self-described de-influencer who isn’t afraid to challenge tech hype and push back on conventional wisdom. Bassem welcome.
Bassem (00:58) Thank you for having me.
Brittany Ellich (01:01) All right, to kick us off, this is something that we ask everybody, what is one thing you’re currently building or obsessed with learning right now?
Bassem (01:09) ⁓ It’s a lot of different things to be honest. I’ve been working very thoroughly on my system design course. So I’ve been doing a lot of different deep dives into distinct areas of the distributed systems. And then you think that you know a lot about a certain topic until you really have to start teaching it. And then you realize, I know very little actually. ⁓ So yeah, I’m doing a lot of deep dives into databases, database management systems, how the internals of databases, how do we optimize them? How do we scale?
but also event streaming, Kafka, consensus algorithms, actual distributed system stuff, a deep discussion of causality and determinism. That was one fun video that I created recently and I’m still, have yet to finish it for that particular course. So it’s a lot of fun stuff.
Brittany Ellich (01:58) That sounds really interesting and I actually can’t wait to take that because I feel like I will learn a lot from that even being like an experienced engineer because that’s always an area where you can learn a lot more from. So that sounds cool. Yes.
Bassem (02:09) There’s always nuance and details,
yeah, for sure.
Brittany Ellich (02:13) ⁓ I understand you originally started at GitHub as a solution architect, correct? Then went back to a software engineer. Is there anything that you learned or gained from that experience?
Bassem (02:24) Yeah, my entire career honestly has been fluctuating between different types of roles in the industry. I started writing code when I was 12 and I’ve been a developer since and I built a lot of experience freelancing, but also working in different types of companies, startups, ⁓ medium scale SMBs and also bigger enterprises. ⁓ And yeah, when I joined GitHub, a recruiter reached out and they’re like, and I was working as a solution architect prior in a consulting firm here in the Netherlands. ⁓
So it was just a continuation of that particular function. And the way I saw the role of the solution architect was, in my head at least, we were just working with distinct customers, and not necessarily at GitHub, but prior to that. And I was leading an entire team of software engineers, and we were literally building an entire bank in Bahrain.
And that was a fun thing. And then the recruiter reached out and they’re like, GitHub. I’m like, but I want to finish that project first. But also GitHub is not something you would say no to. So I was like, yeah, well, let’s see. We did the interviews. Everything went well. The team really liked me. And I joined GitHub. And it was one of the best decisions I’ve made for my career. As a solution architect within GitHub, it was pretty fun to work with a ton of our enterprise customers, not just on how to properly use Git, but how to scale a Git usage internally, how to navigate
get up actions and scale adoption within the organization. But also working on a lot of the friction points that they have and coming up with actual technical solutions for problems that they are facing with the use of the product or ⁓ using best practices from the industry also to refine their SDLC and how to optimize how they work ⁓ to be a bit more effective and just ship faster and better.
Brittany Ellich (04:12) Gotcha. That seems like it would be really helpful background knowledge for shipping code within GitHub too, to know like this is how customers actually use it. So.
Bassem (04:20) It definitely gives you perspective and it gives you a thing that a lot of software engineers miss out on, which is having this tunnel vision on how we do things and they start becoming a bit more focused on one way of doing things. But if you work in the industry and see how other companies ship as well, and maybe even advise them on how they can define things, you just get a much broader perspective ⁓ on how things are done. And I’ve always been a software engineer at heart, but I was never, I never shied away from exploring other functions because I’m a holistic learner.
and I do enjoy seeing the big picture and seeing things end to end, including the business functions and whatnot. And all of my opinions on software engineering are now shaped by that perspective that I’ve gained through fulfilling different roles ⁓ across my years of working in this industry.
Brittany Ellich (05:08) Gotcha. And then do you feel like you were like pushed towards any of those roles or are those things that you actively sought out and like, you know what, I’m going to try being a solution architect for a while and see if that helps me learn more or how did that work out?
Bassem (05:21) Opportunities were
presented and I chased them. I wouldn’t say that I necessarily sought after being a solution architect or something like that. The function was not even on my radar.
And the problematic part about our industry is the inconsistency of how we apply titles to functions. Titles don’t necessarily reflect what you do, and a software engineer somewhere is not the same as somewhere else, and a solution architect somewhere is not the same as somewhere else. ⁓ So no, I did not seek these particular roles, but I did seek the expansion of my knowledge and the expansion of my perspective. And I never escaped or ran away or tried to pigeonhole myself into a specific…
niche that I thought like this is it, this is my identity, all of my identity is associated to this, no, so I actually don’t mind exploring.
Brittany Ellich (06:12) Yeah, that makes a lot of sense. I feel that very deeply. I think my first senior engineer role, quote unquote, I was when I had like nine months of experience. So talk about imposter syndrome, but that was just a place where, you know, everybody was a senior engineer starting out and that was just the way they did their titles. So.
Bassem (06:30) Yeah, it’s a bit of a shame because it dilutes a bit, you know, the title in a way, and it creates a bit of confusion on what it means. And internally, you feel like, I didn’t really earn it yet. But at the same time, I feel like I’ve done enough to consider myself mid-career or even senior. So I understand it. But I also worry that standardizing this across the industry is not also productive. ⁓
So what matters for me more importantly than the title is how does the engineer or is that engineer capable of describing their actual impact and why they are at that level and whether they can justify with what they built, you know, the title that they’ve gotten.
Brittany Ellich (07:15) Yeah, yeah, I think that makes a lot of sense. And I think you are a self-taught drill developer, correct? Is that?
Bassem (07:21) Yeah.
I did actually go through a computer science program and I studied for one year before dropping out. Financial reasons and ⁓ taking on a ton of debt to get a degree was not on my radar. So I was like, yeah, I’ve been doing this already. I’ve been freelancing since I was 15 and writing code for other people. So why not just join and get my career started? And I was lucky enough that when I started my career, companies were a bit more receptive to folks who did not have a degree. And the idea of having that traditional path started to f-
was phased out a little bit. It was a big worry for me, honestly, but ⁓ things worked out and I rode the wave from 2007, eight and until 2024. And at some point in time, credentials don’t matter as much. And nobody’s gonna ask you about your GPA at school or even bother to ask you about your college degree and whatnot.
Brittany Ellich (08:14) Yeah, yeah, that’s valid. Do think that that’s still the case? Or like if somebody getting into the industry right now, like would they be better off with a degree? Or do think it still doesn’t matter?
Bassem (08:24) You’re always
better off with a degree, not necessarily because the education that you’re going to get there is you cannot get it any other way. I did study all of my computer science material, and I know a lot of topics much more in depth than a computer science graduate from today. I have a ton of experience in so many different domains. it’s not about the degree is a logistical element that you need to have. In a lot of countries, if you don’t have developed countries,
passport privilege like mine, for example, I come from Lebanon originally. You’re going to need your degree to justify that you are a high skilled migrant, for example. You’re going to need your degree to
get a lot of paperwork done. A lot of these immigration offices don’t really understand experience. And then justifying experience is much more difficult than credentialism, where you could just slap a paper and say, hey, I picked that box. So in that regard, I do recommend people to actually go through the traditional paths until we have enough rebels to disrupt the educational system the way it is. But that’s going to be a bit tougher than just getting a degree. ⁓
So if you want to work three times harder than everybody else to continue reestablishing yourself over and over again, don’t get a degree. ⁓ Not saying that you’re not going to have to work hard after you get it, but it’s going to make a lot of logistical things just much easier for you.
Bethany (09:45) Yeah, that definitely makes sense. It’s unfortunate this inequity with education and basically folks who can afford it being able to like get that solidity to check that box. So it is definitely a huge problem. I mean, American all over the world, of course. ⁓
Bassem (10:04) Yeah, it is a problem in my country as well, which is one of the reasons why I started a boot camp in 2018. It’s called SC Factory, and that boot camp was a bit different than other boot camps. It was taking fresh computer science and engineering graduates. These folks were able to actually get their degrees in some form or another, even from second, third, or fourth year universities. The problem that they had is they were not really equipped to enter the job
and even with their degrees, they were not really ready. And that boot camp was basically an acceleration of their careers. So basically crunching two years of experience in a 14 week program. And that gave them much, much more leverage to penetrate the market with. yeah, lack of equity and ⁓ equality is prevalent even in developing countries and a lot of regions across the globe. We need to do more on that front for sure.
Bethany (11:04) Absolutely. That’s so cool to learn about that bootcamp. That’s really awesome. ⁓
Bassem (11:09) Yeah, it was
very successful. Even one of my students is now my colleague at GitHub, which was really a big milestone, which is really funny ⁓ and really cool to see, to be honest. And a lot of the students did really well for themselves.
Bethany (11:25) That is so cool. wow. Nice. So I guess pivoting to some technical deep dives, ⁓ you’ve published some content on rebuilding Git from scratch in Go and diving into the .git folder. ⁓ I’m very curious what originally pulled you down that path, and ⁓ was there anything surprising about ⁓ making that content?
Bassem (11:54) One of my biggest regrets is the fact that I never really finished that series. Hopefully I’ll go back to it one day. But if you build content for YouTube, never promise a series until you actually finish it and you’re ready to publish it. Because once you start, ⁓ it becomes much more difficult to maintain the pace and momentum. And then you get distracted by other shiny new stuff. But the reason why I started that series is educational for me first. And I like to learn in public sometimes. So a lot of my live streamed series are literally just that.
learning in public and ⁓ we work at GitHub, right? And it’s a shame, not a shame, but it’s like for me, it’s like it makes sense to really understand Git at a deeper level than just being a regular consumer. And the best way to actually do that is not by reading about the internals because they’re always going to be abstract, but actually rebuilding it and rewriting it is a fantastic learning opportunity to really absorb the trade-offs, some of the decision-making and to demystify
the technology underneath, right? If you dive into, if you watch the video where I dove into the contents of the .git folder, you actually realize, ⁓ this is much simpler than I thought, but it’s actually really cool that this whole thing works and that it scales to the sizes that it does. And I’ve been working with lot of customers within GitHub and my function as a Solution Architect on scaling Git and working with large monorepos and whatnot. And we used to do a lot of optimization.
and think about repacking and how to clean up their history and how to do a lot of history rewriting and all of that stuff. And we’ve been using tools, but these tools have always been too abstract and like, what’s going on really underneath? So that was the motivation for starting that series. And I have no regrets on diving deeper into it. And it also helped me sharpen my go skills. ⁓ Although I really need to go back to it and finish it because… ⁓
there’s a lot more to do there. We got to the point where we built the internal database, we were able to do our first commit, we were building the Merkle trees, but we never got beyond that point. And I think the cooler stuff starts when you really need to start thinking about rebasing, merging, and ⁓ all of the concurrent type functions and activities for good, yeah.
Bethany (14:14) That definitely makes sense. is one of those tools that it’s very, I mean, I know if you have no experience looking at it, it’s very overwhelming, but it’s one of those things that combines a very massive, elegant system behind a few simple commands. And it’s just really incredible that you can go as shallow or as deep as you need to. But when you get in those situations where you need to scale it, it’s so important to understand the system behind all those commands. ⁓
Was there any one Git command or concept that ⁓ you found was commonly misunderstood among developers?
Bassem (14:55) It’s not a discovery, but I think a lot of developers really struggle to conceptualize Git Treebase. For some reason, it’s a bit of a struggle for them to understand. I kind of get it. ⁓ I think the representation of the Git trees in the people’s minds as an abstract data type, it’s a bit hard to conceptualize in how the commits relate to the tree and how… People don’t have a visual map of the tree in their heads.
And I think some of the visualizations that were published around this topic aren’t really that helpful in the sense that…
it’s very difficult to understand where like where’s the beginning and how commits are chained together and what happens if you break the pattern tree and the parent relationship between different commits and whatnot, which makes rebasing what are we basing what onto what and the semantics of it make it a little bit more complicated than it actually is. And that confuses a lot of people. So I think.
It’s not, as a concept, it’s not very difficult to wrap your head around. I think the semantics of the CLI make it a bit harder for people to grasp. And the lack of knowledge of the internals of Git also makes it a bit harder to grasp. But effectively, it’s a very simple thing.
Bethany (16:13) That makes a lot of sense. I am one of those developers that avoids rebasing at all costs. So maybe I need to watch your video and try to understand rebasing better. ⁓
Bassem (16:25) It definitely helps once you understand
how the commits are chained together and how you can restructure the parent relationship between the commits and how they are actually stored on disk internally and what a rebase actually does and maybe even creating that function yourself. We never got to it in the video series. Hopefully we will someday. ⁓ But it’s much simpler than you think, yeah.
Bethany (16:51) That makes sense. ⁓ So pivoting a little to microservices, everybody’s favorite, ⁓ favorite controversial word. ⁓ You made a video ⁓ called microservices, more problems than solutions? ⁓ Question mark. ⁓ And ⁓ you take a position in that video.
So I’m curious if you have any, what your typical recommendations are for when a company should approach microservices or when it is a viable solution. ⁓ And if there’s any gotchas that folks commonly walk into with microservices and have, has your opinion changed over time?
Bassem (17:39) ⁓ Funny. My opinion has not changed over time. I still hold that position that microservices are more problem than solutions for the following reasons. Microservices are ⁓ not a software architecture pattern as much as they are a remapping of an organizational structure onto ⁓
systems and these microservices aim to solve organizational inefficiencies and they aim to solve the problem of concurrent shipping or building features across a team of engineers within an organization or a company.
And a lot of engineers mistake the idea of microservice and they think it’s a solution to scale technically, might not necessarily be so. It’s a solution to scale organizations to be able to ship more effectively. And I think that misunderstanding leads a lot of engineers down the wrong path. And it leads them down the path of…
trying to implement microservices way earlier and before their organization matures or gets to the point where a lot of engineers need to building simultaneously features together and then they start stepping on each other’s toes. That’s when microservices comes in and shines and that it allows the…
definition of certain domain boundaries and it allows us to lock certain domains within what we call conceptually services and it allows teams to own particular domains as opposed to just, you know, vaguely own modules maybe or a bunch of files within a monolith that everybody needs to come in and shove stuff into and whatnot.
Microservices also aims to solve the bottlenecking of ⁓ internal traffic in between different modules. And I think the…
the concept of allowing microservices to define very specific contracts for how they want the integration to be and how we want different microservices to integrate with each other is something also very positive. And it allows us to really lock that domain very well and make it easier to consume, but also easier to extend and easier to maintain and continue evolving.
And one problem that microservices solve is the fact that what do do with ⁓ legacy stuff? How do we deprecate certain endpoints and APIs and whatnot? And I think microservices can, if implemented properly, can also solve this particular problem. So a lot of smaller teams, they start implementing microservices whenever you have a group of two or three individuals working, maybe even a group of 10 engineers. And then in my opinion, the overhead of managing all
of these microservices outweighs any benefit that they’re gonna get from that implementation. They are better off building a monolith and building different modules and even defining specific interfaces for these modules. And they are better off building in a monorepo where they ship everything on ⁓ regular intervals as opposed to dealing with the burdens of microservices.
And I’ve seen teams and I’ve led teams that decided to implement microservices prematurely.
and we paid a hefty price because everything crawled to a halt. And the more importantly than the microservices themselves, the platform that is supposed to support the runtime of these microservices and the life cycle of each service just wasn’t there. And if you don’t have that, good luck shipping microservices at the pace you would like to ship it. Everything becomes a struggle multiplied by the number of services you have. And that’s not necessarily an effective way to build software or ship anything.
Bethany (21:37) really love that concept of basically microservices is an evolution of Conway’s Law and being able to divide that organizational communication and split into domains. ⁓ I think there is something to be said about when you break into microservices, you can scale.
components individually, though you have to be at very large scale to actually encounter that problem, it feels. So it doesn’t seem like a problem that most companies would encounter until like very, very far along ⁓ in their, yeah.
Bassem (22:18) Absolutely. I’ve been talking about this very, very openly and very… ⁓
broadly. I’ve been on another podcast recently and I’ve talked at length about all of these. And I think scaling prematurely or at least building for the highest level of scale before we actually attain ⁓ some numbers that tell us where we’re going in the direction and building for the ambition of company owners is not necessarily the right approach when it comes to engineering practices. We need to build for the next ⁓
next level of scale, which is the next order of magnitude, in the sense that
Once we have 100 users, we can start building for the next 1000. Once we have 1000 users, we can start building for the next 100,000. Once we get that, maybe we can start thinking about the next million or 10 million and whatnot. But a lot of companies start with building for the 10 million because they have high hopes that their product is going to get there. This type of success just doesn’t happen overnight. Very, very difficult. Even if you have the golden standard for startups and SaaS metrics, which is the hockey stick ⁓ exponential growth in terms of your user base, they’re still going
to be that beginning where growth is going to be very, very slow before you get that tipping point and then you start scaling exponentially. And all of that time can be invested shipping faster, better, and not necessarily worrying about scale at that point in time and focusing much more on product market fit.
Bethany (23:49) 100%. Yeah, I feel like most developers have a traumatic experience with a team that invested in microservices a little too early. My first job, I remember it was a chat application that pops a chat modal in the bottom corner. We had over 20 microservices to support just that. The sign that it went too far was when we implemented a service just to do math.
Bassem (24:18) you
Bethany (24:18) So good times good times it doesn’t exist anymore so that might be a signal of that. So you’re launching a like speaking of microservices in these problems that are encountered ⁓ you’re launching a practical system design course which targets engineers with three plus years of experience.
Bassem (24:23) That’s the answer.
Bethany (24:41) I’m curious what your reasoning for targeting that specific point in an engineer’s career was and what’s the gap that you’re seeing that you really want to fill there.
Bassem (24:51) I think that is, that group or that demographic of engineers that have spent maybe two or three years in the industry is the peak of the Dunning-Kruger effect where engineers think that, oh, now I know everything about this domain. And now I think I can make a lot of great decisions. And they know enough to create the path that’s going to lead them to failure. That’s how it is. And I think, for me at least, learning from other people’s experience was tremendous.
tremendously helpful to understand the gaps in my what I know and to also realize what I don’t know. We don’t know what we don’t know, right? So we need somebody to show us what is out there as well. And that is my hope with this particular course is to show and enlighten a lot of these engineers on what they don’t know yet and a lot of the pitfalls in the reasoning and the experience that they gained so far, which is great experience. It’s a lot of it’s a lot of work. It depends on how you spend those three or four years.
But there’s still a lot to know and there’s still a lot to see in how to implement different patterns. What makes me different, for example, than my other junior engineers who work with me is not the fact that I know more about the programming languages or the syntax or the, know.
design patterns or the architectural abstract. I know the impact of implementing these abstractions and what happens on the ground, even if the actual landed experience is not going to be exactly the same as what I’ve seen in the past, but I can draw on my past experience to steer us away from certain familiar patterns. Now you would say, but you’re relying basically on heuristics and it’s not really a methodology.
Very rarely there is a lot of methodical approach to building software. And heuristics is often all we got because we are every single time we’re building bespoke systems and these systems are complex and they behave in non-deterministic ways. So all we got is literally pattern recognition and our ability to try to sort of.
guide these systems to behave in a way we want them to. And all of these insights, I want to share it with, you know, folks who have spent that amount of time in the industry. Although the course is not just designed for this category. I’ve had my waiting list open for a while and I’ve had people who have spent 10 plus years in the industry sign up because they still believe they can gain and benefit from that knowledge and experience. And honestly, in my deep dive is that I’ve been publishing also on YouTube for my members. We go really deep. Like one of the episodes was about load balancing.
and I took as a case study the global load balancer implementation that we have at GitHub, right? And that is…
A very interesting case study because that GLB is designed from multiple components, some of which are implemented at the layer four of the stack and some of which is implemented at layer seven and the way we do, for example, rotation of the servers ⁓ in the GLB and how we keep everything running while we do a lot of these server rotations and upgrades and whatnot and how we do the routing and the shaping of traffic. All of these are fantastic things and interesting to know of and learn from.
And if an engineer who has spent three years thinks, this is not very relevant for me right now, great. Skim it. Go through the content. Move on to something else that’s more relevant. Somebody who’s spent 10 plus years was probably implementing something similar in their companies would benefit a lot from watching and seeing this knowledge. I think there’s a current gap in the market because a lot of the courses are designed to prepare folks for interviews. So a lot of the system design material, like
For example, Hello Interview, they do a fantastic job with their breakdowns and they offer a lot of guidance and information and they go really deep into the fundamentals as well.
but they lack the practical aspect of it. So some of the exercises that I’m building for this course are hands-on experience with distributed system problems. One example of that is ⁓ in the topic of causality and determinism, we actually go through an actual raft consensus algorithm implementation and then we discuss it. And at the same time, some of the exercises are going to be focused on how to actually run that with a bunch of servers, how they can communicate with each other, what happens when one of the nodes
down, how do we do leader election, and then some exercises to play with that to solidify the concept. ⁓ And I’m trying to provide also a bit the platform to play with some of the distributed system problems that we see every day and we try to work around. It’s a lot of work. Hopefully I’ll get it done at some point.
Brittany Ellich (29:31) It sounds like it. It’s cool though that you’re releasing some, sounds like as you go to your members. I might have to subscribe and go check those out because I’m excited about it.
Bassem (29:40) I would love it. I would love some feedback as well if you have it.
Brittany Ellich (29:43) Yeah, I think one of the things that has always drawn me towards your content is the fact that you go so deep and technical and like you’re not just saying like trying to make content for the sake of making content. It feels like you’re actually making something that’s really useful. And like I’ve learned a ton from your get internals videos. Yeah.
Bassem (30:01) Appreciate it. Thank you. That’s great
to hear. It’s harder for sure, and it has lesser of an audience. So I have a lot to say about my time spent creating content. ⁓
The type of content I started creating was the type of I was interested in myself, the type of videos I want to see myself. The problem is that the folks who might be interested in that level of depth don’t necessarily watch videos because their time is much more valuable and there’s very few hours during the day. So spending it on an hour and a half understanding the Git internals really has to matter for you so that you can invest that particular period of time. So yeah, that’s why sometimes my viewership is less
than other types of material, which is fine as long as a group of people is benefiting. I would love to keep on creating that type of content because I enjoy that learning as well myself. yeah, it’s fun and it’s hard at the same time.
Brittany Ellich (31:00) Does that philosophy play into your de-influencer status that you’ve mentioned before? I love the term de-influencer so much.
Bassem (31:06) I was
so bitter about a lot of the stuff that happens in the community. I I grew my following from zero to probably 100K across all platforms, TikTok, LinkedIn, and YouTube and whatnot. ⁓ And I see…
I hate social networks, let’s put it that way. I hate the way they’re designed, I hate the algorithms, I hate brain rot, I hate how the setup is. And if you’re gonna capture anybody’s attention, you’re gonna have to compete with a lot of content.
that is much easier to consume, a lot of entertainment-based content, and it’s much more difficult to put educational content out there in a form that is easily digestible, to process, but at the same time fun. And I hate influencers, like in tech specifically. Like I understand entertainment for the sake of entertainment, but when you do edutainment,
And at the same time, your opinions and takes on something are not necessarily at the level where they should be or at the depth that they should be. And then when we start sensationalizing the wrong things in the industry, I really, really hate that. And I try to sometimes break a lot of these misconceptions in my takes and in my opinions. And I also try to shake the tree a little bit because I feel like in a lot of times we fall into the dogma of doing certain things and we start creating these cults that are based on identities and we start doing
identity-driven development added to the list of all of the other types of development that we do. ⁓ You know, where I’ve been seeing it all over the place and the association with associations with different programming languages and different paradigms is weird to me in my opinion. I get why people do it, but.
We can talk a lot about that as well. ⁓ But that’s why I like to label myself as a de-influencer. I don’t take on brand deals. I don’t promote products. I don’t promote tools, even though it’s necessary if I’m going to ever make this business sustainable. I hate the fact that it is this way. ⁓
But yeah, I’m gonna always share my controversial takes and my experience the way I see it and from my vantage point. And I always tell people who watch my content, never take anything I say for granted. It’s not a rule. It’s not something you have to abide by. Use and critical thinking. And when I share with you something, take it as an opinion, think about it, process it, digest it, critique it. And if it actually applies to you, use it and
keep on evolving from it as well.
Brittany Ellich (33:57) Yeah, I think that makes me think a little bit about ⁓ Will Larson has this really interesting article about ⁓ writers ⁓ who operate. And I feel like that’s sort of similar in the tech influencer space where there’s a point where you’re making so much content that you’re not operating anymore. You’re not a software engineer anymore. also just generating content. And so that kind of takes you away from the space. But it seems like you’ve got a pretty good balance of like,
You operate, you’re a software engineer regularly doing work. mean, I work with you. know that you’re regularly doing a ton of work and you’re making all this content at the same time. That’s like actually good and technical and like deep. ⁓ and I feel like that’s probably a hard balance. Yeah.
Bassem (34:37) It’s not sustainable.
And that’s why a lot of people don’t do it. A lot of people go full time on content because it’s not sustainable to do it besides anything else. I used to work for seven days a week. I got burned out because of it. That’s why I haven’t published anything. It’s been a few months. But I’m trying to get back on track. But it’s a lot. It’s a lot. And also trying to have balance stakes after a 9, 10 hour workday where you’re dealing with all sorts of stuff we deal with is also very hard not to be a bit bitter about how certain things are and certain things in our industry for sure.
Brittany Ellich (35:11) Yeah, I get that. You also had a podcast for a while and interviewed a ton of great folks in the software industry. Simon Willison, Cameron Ahmed, Edward Thompson, a bunch of others. Are there any conversations from that that you like remember or stick with you that have like genuinely changed how you think about something?
Bassem (35:34) Absolutely. ⁓ Cameron, specifically Cameron Ahmad for folks who don’t know and a lot of people don’t know. Like he’s the guy who created roadmap.sh. The roadmap where you go and check out like what you need to learn, the concepts you need to learn to become a software engineer, DevOps engineer, whatnot. Like it’s one of the most popular websites for beginners and very few know who’s behind it.
Cameron is so humble and he’s so humble about his beginnings, his experience, his technical knowledge. It’s, how do you say it? It’s inspiring in that regard. And he doesn’t necessarily consider himself one of the elite software engineers and yet he has created something that a ton of software engineers use, love, and benefit from on a day-to-day basis. And he has grown Roadmap.sh to become way more.
than what it just is, a roadmap. Now he’s enabling it with more focused courses and content that allows you to actually dig into the concepts that are part of that roadmap. And he’s always been open for feedback about his platform, which is something I respect a lot. So Cameron is very pragmatic and he’s not shy of his beginnings. And he is very patient with outcomes and he keeps on shipping awesome stuff until this day. And he quickly moves to fill gaps.
like, there’s an area I can actually add value in. He immediately uses his platform to start creating in that space. And that is very inspiring to see. Another example is Simon Willison, ⁓ the co-founder of Django. That was a fantastic conversation. And Simon is so prolific. He’s amazing. He is such a very well-spoken person as well, very eloquent.
And he shares his ideas very clean, he’s very lucid when he shares his thoughts. And ⁓ he’s insanely humble like that. Guy’s contributions are amazing. He continues to be an amazing contributor now in the data, LLM and AI space. His Today I Learned blog is amazing and you always learn new things from it. And yet again.
He’s so down to earth, fantastic guy. So I think these two people, among many others, and I interviewed a lot of great folks as well, ⁓ are just examples of how the people I want to see more in tech and the people I want to see be the inspiration for others and be the examples of others instead of the folks who do rage-baity, click-baity, controversial-taiky, whatever. ⁓
content out there. And I understand social media is driven by controversy and engagement. I hate that. And we need to see more people like Simon, like Cameron, be more vocal and be thought leaders.
Brittany Ellich (38:34) Yeah, I agree with that. follow Simon’s blog and I think one of my favorite things about it is he writes so much. Like you said, he is so prolific and he has a thing on there that’s like, you can pay me to send you less things where he like curates the things that he writes every month so that he can like send it all at once instead of ⁓ his RSS feed is crazy. ⁓ That’s great. And having a podcast, I feel like it’s just such a great way to like network remotely. ⁓ I’ve met so many people through this podcast.
Bassem (38:51) Insane.
Brittany Ellich (39:03) that and gotten to have such great conversations that I feel like I haven’t been able to otherwise. So shout out to podcasts. Excellent. Well, with that, we are coming up on time. So we’re going to wrap up with our fun segment. So every week we pick a different thing sort of catered towards the folks that ⁓ that we’re talking with. And so this week I came up with a terminal setup roast. We can do a round robin.
Bassem (39:08) Agreed, 100%.
Brittany Ellich (39:32) of our current terminal setups ⁓ and let you roast them. Or if you think that something’s great, then let me know. So we’ll talk about what tools we’re using, ⁓ what’s good, what could be improved, what could make them better. And then you can also talk about your own setup, any tools that you really like using, ⁓ anything that you could, any tools that you would change or whatever comes to mind. ⁓
So I’ll start, I’m gonna throw a photo of it in, instead of sharing my screen because it’s just easier. I’m gonna throw a photo of it in the shared doc that we have. I use Iterm2. ⁓ And I’ll post these all online too. ⁓ It is in dark mode at the very least.
Bassem (40:11) Thank you.
you
Yeah, I mean.
Brittany Ellich (40:23) That’s about
all I’ve got actually. That’s the only thing. I don’t use any specific tools other than that. And you can see too, my last login was November 25th, so I don’t use my terminal terribly often. ⁓ it is open to. ⁓
Bassem (40:33) This is insane. This is like my mom’s
terminal. This is the terminal my mom would use. You get 1.4, like, not using the light mode, so…
Brittany Ellich (40:42) you. And I downloaded
a new thing. It’s not like I’m using the default on my Mac.
Bassem (40:46) Yeah, that’s
true. I-term 2 is pretty good. mean, like, Elite Standard or Elite Status, as if you use Ghosty, for example. But I-term 2 is close. It’s not that far. But you need to… Is that Bash?
Brittany Ellich (40:59) Thank
you.
Bassem (41:02) That’s so funny. I used to get roasted for using fish for the longest time, if you know the fish shell.
A lot of people hate it. I used to love it. Like I had even a video about it and people just roasted the hell out of it because they don’t like fish for some reason. I like fish. It’s nice. ⁓ And I swapped or switched to ZSH ⁓ quite a while ago. And I think it’s pretty cool. I mean, my terminal, yeah, it’s a bit different. I use a lot of tool. I spent time refining it because I also, it’s not about the pride, know, it’s about
⁓ the capability of the terminal and being a bit more productive in that space. Let me share my screenshot of mine. It’s super, super simplistic and I like it to be that way.
just gonna put it in the dock. Yeah, there it is. It’s literally absolutely, it doesn’t even have borders. And ⁓ I use ZSH on it, but I also use a bunch of plugins for that in particular.
Brittany Ellich (42:03) Ooh. Mm-hmm.
Bassem (42:14) And I use a Power P10K theme for that. And I use the Z plugin, as well as the ZSH auto suggestions, which I think are really my defaults for everything. And I turn to.
Brittany Ellich (42:30) awesome.
I got credit for that, so that’s great. ⁓ Yeah, I’m writing all these down so that we can include them in the comments too if anybody wants ⁓ to check them out. ⁓ Bethany, do want to share your setup as the Vim user? Hopefully yours is slightly better.
Bethany (42:34) You
I would love to. No, I’ve also spent a lot of time on my setup. I used to use iTerm2, but they started doing a lot of like… kind of weird things. It was going beyond what I would want ⁓ in a shell, so like they were adding AI and web browsing and I was like, I don’t need all this, it’s so heavy. And so I swapped to Ghosty and I am not looking back. It’s amazing. I love it.
very minimal config, which is what I love. ⁓ And so I use cat poutine themes everywhere. That is the elite theme. I will die on that hill. ⁓ And one thing I really enjoy using is this tool called Chez Moi. It’s written in Go. ⁓ And what it is is it basically lets you… ⁓
templatize your configs so you can populate them to different machines. So I use this for all my Macs and then ⁓ also because I could have used Codespaces, I also use it for my Codespaces config. And all of that is in my ⁓ .config repo. So if anyone is curious how that works. ⁓ But for Codespaces, T-MACS is a must because it will preserve your session. I’ve been logged out of Codespaces far too many times to ⁓
to let it go by chance, so I always use T-Mux on there. And then, as Brittany mentioned, I am a Vim user. I’ve been using Vim since basically college. It’s just, I get overwhelmed with IDEs and all these buttons that I don’t know what they do, so I prefer configuring things myself. that’s been my happy spot. And ⁓ yeah, I have a lot of plugins there. So…
Just because I’m using NeoVim doesn’t mean I’m doing everything the hard way. I still have menus to scroll my files and I’m like, grepping through my repo and things like that. it’s, I’m really proud of the workflow I’ve developed, which eventually my talk that I gave at Go4Con will be put up and I can share that with folks to show what exactly I use in NeoVim, but I will spare you all that talk.
Bassem (45:08) I would love to see your, like, where’s scope pilot in your new Vim setup? You have a chat window and I would love to see that part.
Bethany (45:13) Yeah.
Absolutely. ⁓ So this is actually fairly new and I didn’t include it in the talk because the Copilot CLI was in beta or was only for staff users, I think, at the time. So I was really wanting to show it off, but I was like, no, I can’t. can’t. They haven’t announced it yet. ⁓ But Folk, ⁓ who does a lot of New of plugins, he made a plugin called Sidekick.
which lets you take whatever your favorite CLI ⁓ code or LLM thing is and add it to any of them. So I use that. It works very well. Also, GitHub does have a official Copilot plugin. It’s only for completions, but it does work pretty nicely for those completions. But with the folks plugin,
It also has next edit suggestions, which is wild. The first time it popped up, it was a jump scare. like, what is happening? But it was really cool. I was like, I didn’t even know that it could do this. So ⁓ Neo Vim is just so powerful. I used to only use bare bones Vim for quite some time, but I am always blown away with how much progress Neo Vim has made on Vim.
Bassem (46:35) Absolutely. One of the reasons why I never fully switched is literally copilot, to be honest. And right now, the copilot agent flows and in VS code is, no, I cannot. I would leave everything else and not skip on that one.
Bethany (46:52) Totally, No, the VS code is the quintessential. ⁓ I mean, I have to say that, but it’s true. It is like the quintessential agent mode experience. But ⁓ NuOvm has come quite close to it. There’s still some gaps, but I do like the CLI flow for agentic use. I get overwhelmed when things just start making changes on my behalf, so.
I prefer to let the agent do it in the CLI and then review it after, like I’m reviewing a pull request and my brain is a little more happy with that, but ⁓ VS Code does good things.
Bassem (47:28) Bethany wins.
Bethany (47:30) Yay!
Brittany Ellich (47:31) Yes, absolutely.
I feel like there’s a spectrum of developers who only want to be in an IDE and developers who only want to be in a CLI. Bethany and I are on opposite ends of that spectrum. Absolutely.
Bassem (47:44) But see, this is also like, it flows back into our conversation a bit ⁓ earlier about elitism, right? Like you could also be a highly effective engineer with a terminal like that. Like it’s fine, it’s cool, it’s fun. I enjoy the configuration aspect of it itself. But again, the benefits are not exponentially higher or bigger.
Brittany Ellich (48:06) Yeah, yeah, I agree with that.
Bethany (48:07) Yeah, it would
be tough to convince somebody to just drop everything and move to neovim if they’re not used to it at all. Similar to if someone is used to it, it would be not recommended to shove jet brains in their face and be like, use this. So I think it’s wherever you’re most effective. But I’ve been roasted so much for using neovim by people. it’s like, I mean, it’s fine. It works for me. I’m not saying you have to use it.
Brittany Ellich (48:40) People, there’s always something to roast somebody out on the internet. That’s just, that’s just what it is. ⁓
Bassem (48:46) Yeah, tell me about it. Like some people
don’t like the fact that I’m bald. Like, okay, great. What can I do about it? I’m sorry. My jeans, I cannot modify them. I cannot edit them. You don’t like the fact that I’m bald. Just don’t watch my content. That’s fine. Yeah. Yeah.
Brittany Ellich (48:59) That’s wild. That’s a crazy reason to not like somebody online. ⁓
Well, thank you so much. Fasten, this has been awesome. ⁓ If folks want to find you online, where do you recommend they go?
Bassem (49:12) funny story. ⁓ So first of all, if you can write my family name, you can Google my name, you can find me there. If you can’t write my family name, glitch.stream. But I thought it was smart to come up with a brand name that, and I had a typo in the glitch because it doesn’t have a T in it. And that was on purpose. This is the bane of my existence. Don’t be too smart when you’re trying to come up with your brand. Just…
you know, set something up. So glitch.stream, but remove the T from glitch and you will find me.
Brittany Ellich (49:44) Perfect, we’ll link it in the show notes too, just in case anybody struggles with it. ⁓ Great, well thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you’re supposed to do on the podcast app of your choice. Check us out on Blue Sky, join us on Discord for our ongoing book club, Writing for Developers, and share with your friends. Until next week, thank you so much, goodbye.