Nicolas: Welcome to another episode of The F**king Death. I'm Nicholas and we are again walking in the beautiful Prater in Vienna, this time with sunshine.
Philipp: And I'm Yes, the sun is finally back. Yes. What a week it's been.
Nicolas: Exactly. episode a bit of problem because we had audio issues in the end. so you missed my love talk about Postgres and Alexia. ⁓ this was my positive of week, but will just present it as the positive topic of this week. And that's how we get started. ⁓ and I talked a bit about microservices and Philipp mentioned so everyone should just use Elixir. If don't know Elixir, it's a functional programming language on the Erlang virtual machine. The Erlang virtual machine was invented in the 70s and it's pretty amazing if you think about it today because processors can talk to each other And Alexia is, so to say, syntactic sugar around Anyway, the reason I wanted to pick this as a positive topic of the week, There's this background shop library, which called Oban, which is to work with in Alexia. And they just a Python package as well. And what happens you now can communicate with the Alexia application. through Postgres to Python background shops. Postgres is the message service basically in between. so this helps you when you, for example, have some packages that are not available in Alexia to then queue things in Python and then communicate back, which is quite nice. It's actually something that I might need for my own side project right now.
Philipp: So the job runtime connects to the same database and it also can handle different followers
Nicolas: Yes, exactly. ⁓ and this happens through Postgres Notify system. So you can have these queuing system through And so last week you asked me like, Hey, ⁓ Nicholas, didn't you me to not use this? And that's correct. So there was half a year ago, a good blog about how the Postgres notification system. is actually broken because it has a bottleneck because has a global lock but this was the good news then after all in january they fixed this in posqriss and now they longer have this global locking and you can use posqriss as your queuing messaging system which is quite cool
Philipp: That's cool. ⁓ thing that's missing from Postgres is a way to handle ⁓ blobs ⁓ Like F3 service. No, no. But it's the only micro-service, like the other thing you need to build ⁓ more robust right? You need some kind of queuing, need some kind of messaging, you need some kind of blob handling and some database.
Nicolas: Whoops. do you have to listen to Marzico? I don't I mean, you can store blobs in Postgres. Nothing prevents you from storing a lot of data there. just might get troublesome. And it's also actually Postgres at a certain size of a few kilobytes stores this somewhere different ⁓ per column anyway. There's a name for it, I'm sorry, ⁓ that I don't know it now. But what is actually missing from Postgres is sharding. That's one of the problems that you run into if you have databases that are above ⁓ the of SSD. Let's say terabytes is the maximum you can easily get at cloud providers. And fortunately, I think in the last one and a half years, companies started building stuff on it. So I think currently we have three solutions there that are working actually. That's the cool thing. So the first one was announced, I believe, for PlanetScale, software, I And they hide the abstractions mostly for you. The second is from SuperBase. And I think they call it multigress. I think it's source even. Please let me if I'm wrong. And the last one that saw last week, this is my positive of this week, is PGDog. I think all of these solutions, work the same. PgDock is a load balancer. it do sharding for you and replication. and a correction pooler. it everything built in. just a proxy. And if I understood correctly, it's a Rust project that passes your SQL and tries to figure out like what should go where. And it can do even sharding on demand and resharding on demand without ⁓ that is pretty pretty cool and we're finally at the stage because many companies have lots of terabytes of data and charting is not easy I speak from experience
Philipp: Thank you, speaking from experience. Yeah, because you just mentioned PGDog thing, I also have like a positive thing that I saw on Hacking News this week. Miniu, which is the open source S3 server that lots of people use in their Docker setups, ⁓ has discontinued, I think in November last year, and has outstanding CVEs and like, but is unmaintained anymore. But yeah, there's like a block post now from someone who's ⁓ doing fork ⁓ and features fixed, the build is running again. ⁓ So Miniu lives on.
Nicolas: nice this is good ⁓ for every side project i'm doing where i need to store data i'm always annoyed to set up everything with or r2 or whatever and maybe this is a good solution for me
Philipp: I was thinking about this because of this agent box stuff that I was building, which initially I built completely on Cloudflare primitives, but now that I've open sourced this and people actually want to deploy this, obviously this is not a good stack because you can only deploy it on Cloudflare. So I was thinking of dockerizing it and keeping dependencies simple to make this kind of reasonable.
Nicolas: one more topic then You need to explain me about the ⁓ whole CloudFlare Next.js rewrite. before that, There was pragmatic podcast about S3. It's really astonishing what the S3 team did And also how can ⁓ invent this algorithm, how ensure that the distributed storage is working well. ⁓ It's a recommendation before want to ask you about the whole next year. Like I'm no longer in this front end ⁓ part, I also always need ask you. So what happened with the whole Cloudflare next year's rewrite?
Philipp: Vercell and have been kind of an interesting relationship for a long time. ⁓ And this week kind of a new drama broke out when announced that they have built a replacement of Next.Chest that runs on Veed. And ⁓ they are claiming that it's like... a lot faster because of it. Builds are faster because Veed is just more optimized and more modern basically. And the astonishing thing is that they've been doing, this thing in one week AI assisted tools. And I think they mentioned that it costs them $1,000 in tokens.
Nicolas: Which is cheap in this case, yeah? Yeah. So, why did they do this?
Philipp: to see for. So we're sad as a lot flares main motivation of course is to get more people to use the cloud platform and next just has this Stigma of being not very portable and very like built into the versatile platform even though there are lots of projects recently that kind of open it up to more places and there's like Really a lot of work underway to fix this But yeah, I wanted to have something for their customers that they could use that's basically API compatible ⁓ and doesn't have any of the ties to Versaille. instead of it from the bundle level, they were basically taking Veed as kind of the dependency and then just build the whole kind of React framework on top of it. And because the ⁓ test suite is so thorough we know that agents are working well if you give them ⁓ a good test they were able to move pretty fast with this. And they make claims that it's like 90 % of the API surface is covered, which of course does not mean 90 % of the tests are running. So there has been this little bit of drama around how good this thing is. It was obviously very early. At the end of the day, it's a project that people worked on for one week and released. It's impressive that it's a week, but even if they build it for like a few months, there's like no way it could be as stable as Next.js, of course. yeah, the drama basically was then amplified by there being a bunch of CVEs ⁓ the first day. And ⁓ that's how things are going.
Nicolas: We need the category front and drama of the week, think from you. think ⁓ would be your category then. ⁓
Philipp: could try. The thing is, I'm only an observer now. know. Yeah.
Nicolas: But still it's enough. Because I only the titles and you at least read the first paragraph maybe.
Philipp: That's true. I have not tried it out. It looks promising, honestly. I think APIs and developer experience of Next.js is really cool, but also I personally like Veed a lot it's a very good handler. So yeah, the thing really works out, be really interesting to look at it. But obviously with the Cabot, this is like working this for a week. ⁓ think comparing it to Next.js in terms of stability, not good even though they used agent to build it no matter how good you are with agent it's
Nicolas: Yeah, makes sense. was one thing because you mentioned the test suit. was a post from TL Draw, like this open drawing library. now I'm titles. think they made their test suit
Philipp: I only saw the title of this tool, yes, but I think The idea that ⁓ once you very good test harness, agents are really good at recreating them. So they are kind of mode for people it without making the test private. I don't really know what to think about this yet. I think maybe it's just a temporary fix. I don't know. We'll see how it plays out for sure. And if others follow suit.
Nicolas: Exactly for this case, it's ⁓ legitimate way one language to but now in my opinion,
Philipp: Yeah, especially for things that have very, very, thorough test suite. Like we saw this when Cursor was by coding a browser that actually could render pages. Just because the spec is so thorough and it goes over like all of the details and in a very like high level way. But yeah, it's still a vibe coded browser from what I understand. And it wasn't even compiling when they released it. was like the architecture wasn't making any sense. But yeah, there was this good post by Chris Latner about the C compiler that I think. Who built it? Was it the codex team that built it? Entropic. Or Entropic actually, even. Yeah. One of the AI lives built a C compiler from scratch, basically also using some of these huge test suites. And Chris Latner, who is known for inventing LLVM, inventing Swift. Yeah. You know, he, knows something about compilers. Yes. Has kind of looked over it and said it's, yeah, surely it's not as optimized as a real C compiler, but it being like AI generated is really crazy. And it's just the beginning. think one of the things is gonna get better. think like the current, you haven't.
Nicolas: You sound like this typical CEO. This model will be better in six months. we see here today is not the future. Anyway, wanted this to be an AI-free episode. I mean, yes, talked a bit about AI coding tools, but ⁓ not that much. wanted to talk about career development. It's a bit of larger topic though. Let's see how we split Do you any thoughts otherwise I would stop?
Philipp: ⁓ I guess maybe just high level overview for people who aren't used to working in companies of how like these typical career leaders look like for engineers.
Nicolas: mean, every company also has a very different naming ⁓
Philipp: and Some companies use numbers which also not really comparable, usually software engineers, come from some kind of background, get into first The ⁓ companies call it the entry level, right? It's expected from people in this to able to write code. I think that's the prerequisite to learning a software engineering job, ⁓ but everything like soft care is more like the kind high level overview of that is like build on top. And that's what builds like the IC career path for software engineers. It has a management path, but I think we'll go one more the IC path here. So what usually happens is you have like some kind of entry level at companies and some kind of mid level. Senior level is I think where the majority of people are. And a lot of companies, I speak, I can speak here for a matter because I worked there. It's also a terminal level. So you could, It's expected from a new hire to eventually become medium level and senior level. But from a senior level, you can just stay senior indefinitely because you are providing value. can basically manage your own project and bring kind of impact to the company this way.
Nicolas: Yeah, I think that's totally fair that you have this terminate level here because you don't want to force people above senior. too much and also it makes the calibration weird over time. Like too many people are then having too many high roles,
Philipp: Yeah, then after the senior parts, it really becomes more about amplifying your impact across the organizations. And people have invented terms like staff or principal. Sometimes it's principal before staff, whatever. It's row is after senior, where it's more about your impact and less about your ability to
Nicolas: code. Yes, but this actually comes with problems. two things that I identified, three things that I identified. The first thing is you need to always operate to be promoted. You need to operate on the next level. And this is super weird. Let's say you are a senior engineer and what you do is basically you try to ship stuff. That's your job. get to staff level. You need to have this impact of you mentor other people, you have influence on maybe the product direction or the architecture and so on. But this requires you time to perform this. So you have two choices, right? You either work more or you cut out what you do as a senior role. And this is then a hard time to figure out the priorities sometimes because you are constantly need to deliver. You are this workhorse somehow of the team. And then you also need to above and beyond of what you're doing. It's sometimes hard to do because you to sometimes remove the work that you're currently doing. Not figured out how to do this properly all the time. And also there's this other thing like I'm currently a staff engineer, I have the feeling that responsibility that the department works well, right? And then sometimes my best use of my time could be that I jump into the senior engineering role where I just code. Because maybe we are lacking engineers right now or we need to get project over the finish line. And then you suddenly no longer have this staff level impact in this moment, which makes it hard for your promotion case. So sometimes, unfortunately, what is best for company is always best for your promotion. Another thing that I ⁓ mentioned in of my talks recently. So we say that this entry-level engineering positions, they usually just try to and be impactful within the team And after senior and staff, more about influence. How you can influence people ⁓ to get things you mentor them and so on. So let's assume someone workforce. They are an excellent influencer. are we call it the glue. ⁓ they ⁓ with everyone very well and are not the strongest coder which is fine someone else is stronger coder and then it happens that stronger coder gets promoted because they are senior then right and the other one not promoted the other one ⁓ would shine really well at a staff engineering when they don't need to code that much. That's weird thing.
Philipp: Yeah, I think what you're touching here is that the incentives for individuals and incentives for the companies here are not very well aligned. yeah, in my experience, I have never been promoted at the company. All my promotions were because of like switching positions. So from my perspective, it's definitely easier to a higher role at a different company ⁓ than to get promoted in the companies I work at. Which is also something that shouldn't be there because it's much more expensive for companies to hire on board and all of that than to promote people.
Nicolas: and more risky. episode where we discussed how hard it is to have these signals in the behavioral interview. So staff level is quite tricky to hire.
Philipp: Yeah. It's hard to fix, right? I think it's the same problem why companies have such a trouble creating new products. They have to kind of bear the weight of their existing stuff. Yeah. And they have to, you know, when they want to promote, they have to make like a framework so that it's fair to everyone in the company. cannot just promote people because you have a feeling that they will be better. You have to make it objective because otherwise it's not fair to the other people. And that's why we are in this position, I feel like. What advice would give people who want to make the promotion from senior to staff? Maybe also from other ones, from junior to mid and from mid to senior. I'm mentioning senior to staff because that's what we both have been most recently undergoing.
Nicolas: never got ⁓ to senior film. ⁓ We never got a promotion because we're the first job, like, okay, let's say it's the second job actually, but it's this job where we have been at PSP DevGit. were working there for half a year or a year and we got our business card from our ⁓ and the card was titled Senior Engineer and we both looked at them and asked like, ⁓ we are senior engineers? And he said like, yes. So this was our informal promotion back then.
Philipp: Business guys.
Nicolas: I it's totally fine if you just want to keep senior, to be honest. And for the senior promotion, I think it's quite clear. It's about quality of your work, how you get things done. As well? How you communicate, yes. ⁓
Philipp: how communicate. For being a senior engineer, you just have to make sure the team knows what you're up to. You be really proactive in how you organize stuff. Don't go rogue and work on something. Be the person that speaks up and says, hey, I have this thing to discuss. I want to move things forward. Basically, you should not be the bottleneck of the product.
Nicolas: Yeah, it should be, when I was a manager and had senior engineers, my idea was I give them the project and I can pretty much for 90 % be sure that this gets delivered on time. And the 10 % is just a typical risk you have for these projects. So that was my imagination of a solid senior engineer. And for staff level, it's more like, they will hopefully come to me with ideas how to... fix things in the organization or in the product or architecture and it will just maybe start working on it with a prototype already and then try to get the others working with them which is sometimes super hard for
Philipp: Yeah, there's a really good book as well about the staff engineering path. I forgot the name. Yeah, I think that's one. That's a, there's multiple books about it, but it also mentions these kind of different archetypes of staff engineers, which is something interesting to talk about.
Nicolas: Rensh.com Yep. Again, we can do this maybe in another episode. idea is that you are maybe stronger in one archetype than the other, but you need to perform in all pretty well. So I was in the senior position back then and I felt a bit stuck to be honest. And then my manager came along and was an excellent manager and he said like, you need to go to staff. ⁓ Otherwise you will not be happy. and was totally case. So I was constantly working on shipping and everyone was happy. And this is a super tough spot to be in because everyone knew, okay, just Nikolaus the project and it will be done. It's nice that you this reputation, but it's also bad because everyone will come to you to get projects done. So you are overloaded with this kind of work and you can't easily go beyond that. And he tried to do is then like sneak in ⁓ half a Friday afternoon or whole Friday, maybe sometimes to work on something that you think the organization needs to do and then show that off. And I was, to be honest, a bit lucky in my time. I was just pulled in into a super critical that had to something that had company wide impact. And this got me the promotion in end. yeah, because of my reputation to get stuff done. Not just luck. Of course it was lucky that they thought about me. so build up a reputation that you get things done and then you get also in this company-wide project that are important and help you with the promotion. And now that I'm promoted,
Philipp: How did you get pulled in? So maybe not just luck.
Nicolas: I'm looking into the next level and this is even harder because the department-wide impact is not enough. You need to have ⁓ larger impact now. And this really becomes hard because your own personal goals, they are no ⁓ aligned with what your team or department wants, in my opinion.
Philipp: have seen similar cases. There's other properties as well that staff engineers observe, which for example, they can handle ambiguous projects really well. ⁓ you throw them something like we want to go in this direction and they are working in a that they can explore different options, figure out what's the best solution, get like people on the team to like collaborate and stuff. Then there's like the impact angle, there's the influence angle, how much can you kind of rally up the company to do stuff. It also really helps with like promotions. It's really many ways to kind of show that you're doing more than a senior engineer. the thing is still if we are a senior engineer, you have to still be a good senior engineer. Yes. Because you cannot be promoted if you're not a good senior engineer, but you also need to perform at the next level and demonstrate that you could do this.
Nicolas: I also mentioned, at the staff level you also still need to perform somehow at a senior level. This is sometimes hard because you also still need to push out code depending a bit on the team of course, but it's the expectation that if a lack of engineers, you just jump in but if you are constantly in this architecture type of thinking, it's quite hard to switch.
Philipp: Okay, so to wrap this up, Nicholas, maybe a few sentences, what is some advice you would give people that are, let's say, not at the senior path yet to kind of hit the next level?
Nicolas: get good and be proactive, a lot, to get at a good quality ⁓ of the you get the Merge Request out and you get an approval immediately for most of your This is my expectation from senior and then the longer you do this, the more credibility get and then you get the projects assigned. And also this is one thing. tell your manager what you want. This is super crucial. Of course they don't know. They have so many people to manage. They don't know what everyone wants to work on. So this is advice for them. Tell the manager you want a project and want to grow in a certain area. And then when the project lines up, they can think about you. That's crucial. And for every staff engineer, help your intermediate engineers or senior engineers exactly the same. Think about them when you get assigned a project that someone else should take over to help them with the promotion as well.
Philipp: Yeah, cool. I don't think I have anything to add. Only maybe one thing, that it's hard and it's work and you have to put in the work.
Nicolas: Yeah, and one more thing, my personal advice is don't care about these titles. sounds weird we talked so much about now, ⁓ actually I never about any of these promotions. So my communication my manager was always, I don't care about the promotion, but me know if I already operated this level, And if they tell me I operate at the next level, I'm fine. Because the promotion will come eventually. with that mindset and it's more important that you grow than you have a fancy title with your name. Yeah, so we are again at end of our route. I to wrap this up with something that I observed this So Philipp and I this podcast now, I think it's fifth episode, right? ⁓ wow, yeah. And we also said, ⁓ at I said, let's care about the numbers people who listen in to this. And obviously the first episode was the one that was listened the most to and the episodes afterwards were a bit less. But this week a comedy stand-up show with a friend of ours and I told her about the podcast and she asked like, what, you're doing a podcast now? And I said like, yes, but it's only a few people who are listening in there. And she's like, how many people are listening in? And I told her the number. And she was like, hey, this is pretty cool. This is half of this whole room that you're currently in. So half of the people who came to this comedy show are weekly listening into this podcast. And amazing to think about.
Philipp: Yeah, I like to imagine these are all AI agents, don't they? So if you are really human and listen to this, please prove me wrong. Otherwise, of course, thank you so much. And yeah, see you next week.
Nicolas: See you, bye.
Philipp: And I'm Yes, the sun is finally back. Yes. What a week it's been.
Nicolas: Exactly. episode a bit of problem because we had audio issues in the end. so you missed my love talk about Postgres and Alexia. ⁓ this was my positive of week, but will just present it as the positive topic of this week. And that's how we get started. ⁓ and I talked a bit about microservices and Philipp mentioned so everyone should just use Elixir. If don't know Elixir, it's a functional programming language on the Erlang virtual machine. The Erlang virtual machine was invented in the 70s and it's pretty amazing if you think about it today because processors can talk to each other And Alexia is, so to say, syntactic sugar around Anyway, the reason I wanted to pick this as a positive topic of the week, There's this background shop library, which called Oban, which is to work with in Alexia. And they just a Python package as well. And what happens you now can communicate with the Alexia application. through Postgres to Python background shops. Postgres is the message service basically in between. so this helps you when you, for example, have some packages that are not available in Alexia to then queue things in Python and then communicate back, which is quite nice. It's actually something that I might need for my own side project right now.
Philipp: So the job runtime connects to the same database and it also can handle different followers
Nicolas: Yes, exactly. ⁓ and this happens through Postgres Notify system. So you can have these queuing system through And so last week you asked me like, Hey, ⁓ Nicholas, didn't you me to not use this? And that's correct. So there was half a year ago, a good blog about how the Postgres notification system. is actually broken because it has a bottleneck because has a global lock but this was the good news then after all in january they fixed this in posqriss and now they longer have this global locking and you can use posqriss as your queuing messaging system which is quite cool
Philipp: That's cool. ⁓ thing that's missing from Postgres is a way to handle ⁓ blobs ⁓ Like F3 service. No, no. But it's the only micro-service, like the other thing you need to build ⁓ more robust right? You need some kind of queuing, need some kind of messaging, you need some kind of blob handling and some database.
Nicolas: Whoops. do you have to listen to Marzico? I don't I mean, you can store blobs in Postgres. Nothing prevents you from storing a lot of data there. just might get troublesome. And it's also actually Postgres at a certain size of a few kilobytes stores this somewhere different ⁓ per column anyway. There's a name for it, I'm sorry, ⁓ that I don't know it now. But what is actually missing from Postgres is sharding. That's one of the problems that you run into if you have databases that are above ⁓ the of SSD. Let's say terabytes is the maximum you can easily get at cloud providers. And fortunately, I think in the last one and a half years, companies started building stuff on it. So I think currently we have three solutions there that are working actually. That's the cool thing. So the first one was announced, I believe, for PlanetScale, software, I And they hide the abstractions mostly for you. The second is from SuperBase. And I think they call it multigress. I think it's source even. Please let me if I'm wrong. And the last one that saw last week, this is my positive of this week, is PGDog. I think all of these solutions, work the same. PgDock is a load balancer. it do sharding for you and replication. and a correction pooler. it everything built in. just a proxy. And if I understood correctly, it's a Rust project that passes your SQL and tries to figure out like what should go where. And it can do even sharding on demand and resharding on demand without ⁓ that is pretty pretty cool and we're finally at the stage because many companies have lots of terabytes of data and charting is not easy I speak from experience
Philipp: Thank you, speaking from experience. Yeah, because you just mentioned PGDog thing, I also have like a positive thing that I saw on Hacking News this week. Miniu, which is the open source S3 server that lots of people use in their Docker setups, ⁓ has discontinued, I think in November last year, and has outstanding CVEs and like, but is unmaintained anymore. But yeah, there's like a block post now from someone who's ⁓ doing fork ⁓ and features fixed, the build is running again. ⁓ So Miniu lives on.
Nicolas: nice this is good ⁓ for every side project i'm doing where i need to store data i'm always annoyed to set up everything with or r2 or whatever and maybe this is a good solution for me
Philipp: I was thinking about this because of this agent box stuff that I was building, which initially I built completely on Cloudflare primitives, but now that I've open sourced this and people actually want to deploy this, obviously this is not a good stack because you can only deploy it on Cloudflare. So I was thinking of dockerizing it and keeping dependencies simple to make this kind of reasonable.
Nicolas: one more topic then You need to explain me about the ⁓ whole CloudFlare Next.js rewrite. before that, There was pragmatic podcast about S3. It's really astonishing what the S3 team did And also how can ⁓ invent this algorithm, how ensure that the distributed storage is working well. ⁓ It's a recommendation before want to ask you about the whole next year. Like I'm no longer in this front end ⁓ part, I also always need ask you. So what happened with the whole Cloudflare next year's rewrite?
Philipp: Vercell and have been kind of an interesting relationship for a long time. ⁓ And this week kind of a new drama broke out when announced that they have built a replacement of Next.Chest that runs on Veed. And ⁓ they are claiming that it's like... a lot faster because of it. Builds are faster because Veed is just more optimized and more modern basically. And the astonishing thing is that they've been doing, this thing in one week AI assisted tools. And I think they mentioned that it costs them $1,000 in tokens.
Nicolas: Which is cheap in this case, yeah? Yeah. So, why did they do this?
Philipp: to see for. So we're sad as a lot flares main motivation of course is to get more people to use the cloud platform and next just has this Stigma of being not very portable and very like built into the versatile platform even though there are lots of projects recently that kind of open it up to more places and there's like Really a lot of work underway to fix this But yeah, I wanted to have something for their customers that they could use that's basically API compatible ⁓ and doesn't have any of the ties to Versaille. instead of it from the bundle level, they were basically taking Veed as kind of the dependency and then just build the whole kind of React framework on top of it. And because the ⁓ test suite is so thorough we know that agents are working well if you give them ⁓ a good test they were able to move pretty fast with this. And they make claims that it's like 90 % of the API surface is covered, which of course does not mean 90 % of the tests are running. So there has been this little bit of drama around how good this thing is. It was obviously very early. At the end of the day, it's a project that people worked on for one week and released. It's impressive that it's a week, but even if they build it for like a few months, there's like no way it could be as stable as Next.js, of course. yeah, the drama basically was then amplified by there being a bunch of CVEs ⁓ the first day. And ⁓ that's how things are going.
Nicolas: We need the category front and drama of the week, think from you. think ⁓ would be your category then. ⁓
Philipp: could try. The thing is, I'm only an observer now. know. Yeah.
Nicolas: But still it's enough. Because I only the titles and you at least read the first paragraph maybe.
Philipp: That's true. I have not tried it out. It looks promising, honestly. I think APIs and developer experience of Next.js is really cool, but also I personally like Veed a lot it's a very good handler. So yeah, the thing really works out, be really interesting to look at it. But obviously with the Cabot, this is like working this for a week. ⁓ think comparing it to Next.js in terms of stability, not good even though they used agent to build it no matter how good you are with agent it's
Nicolas: Yeah, makes sense. was one thing because you mentioned the test suit. was a post from TL Draw, like this open drawing library. now I'm titles. think they made their test suit
Philipp: I only saw the title of this tool, yes, but I think The idea that ⁓ once you very good test harness, agents are really good at recreating them. So they are kind of mode for people it without making the test private. I don't really know what to think about this yet. I think maybe it's just a temporary fix. I don't know. We'll see how it plays out for sure. And if others follow suit.
Nicolas: Exactly for this case, it's ⁓ legitimate way one language to but now in my opinion,
Philipp: Yeah, especially for things that have very, very, thorough test suite. Like we saw this when Cursor was by coding a browser that actually could render pages. Just because the spec is so thorough and it goes over like all of the details and in a very like high level way. But yeah, it's still a vibe coded browser from what I understand. And it wasn't even compiling when they released it. was like the architecture wasn't making any sense. But yeah, there was this good post by Chris Latner about the C compiler that I think. Who built it? Was it the codex team that built it? Entropic. Or Entropic actually, even. Yeah. One of the AI lives built a C compiler from scratch, basically also using some of these huge test suites. And Chris Latner, who is known for inventing LLVM, inventing Swift. Yeah. You know, he, knows something about compilers. Yes. Has kind of looked over it and said it's, yeah, surely it's not as optimized as a real C compiler, but it being like AI generated is really crazy. And it's just the beginning. think one of the things is gonna get better. think like the current, you haven't.
Nicolas: You sound like this typical CEO. This model will be better in six months. we see here today is not the future. Anyway, wanted this to be an AI-free episode. I mean, yes, talked a bit about AI coding tools, but ⁓ not that much. wanted to talk about career development. It's a bit of larger topic though. Let's see how we split Do you any thoughts otherwise I would stop?
Philipp: ⁓ I guess maybe just high level overview for people who aren't used to working in companies of how like these typical career leaders look like for engineers.
Nicolas: mean, every company also has a very different naming ⁓
Philipp: and Some companies use numbers which also not really comparable, usually software engineers, come from some kind of background, get into first The ⁓ companies call it the entry level, right? It's expected from people in this to able to write code. I think that's the prerequisite to learning a software engineering job, ⁓ but everything like soft care is more like the kind high level overview of that is like build on top. And that's what builds like the IC career path for software engineers. It has a management path, but I think we'll go one more the IC path here. So what usually happens is you have like some kind of entry level at companies and some kind of mid level. Senior level is I think where the majority of people are. And a lot of companies, I speak, I can speak here for a matter because I worked there. It's also a terminal level. So you could, It's expected from a new hire to eventually become medium level and senior level. But from a senior level, you can just stay senior indefinitely because you are providing value. can basically manage your own project and bring kind of impact to the company this way.
Nicolas: Yeah, I think that's totally fair that you have this terminate level here because you don't want to force people above senior. too much and also it makes the calibration weird over time. Like too many people are then having too many high roles,
Philipp: Yeah, then after the senior parts, it really becomes more about amplifying your impact across the organizations. And people have invented terms like staff or principal. Sometimes it's principal before staff, whatever. It's row is after senior, where it's more about your impact and less about your ability to
Nicolas: code. Yes, but this actually comes with problems. two things that I identified, three things that I identified. The first thing is you need to always operate to be promoted. You need to operate on the next level. And this is super weird. Let's say you are a senior engineer and what you do is basically you try to ship stuff. That's your job. get to staff level. You need to have this impact of you mentor other people, you have influence on maybe the product direction or the architecture and so on. But this requires you time to perform this. So you have two choices, right? You either work more or you cut out what you do as a senior role. And this is then a hard time to figure out the priorities sometimes because you are constantly need to deliver. You are this workhorse somehow of the team. And then you also need to above and beyond of what you're doing. It's sometimes hard to do because you to sometimes remove the work that you're currently doing. Not figured out how to do this properly all the time. And also there's this other thing like I'm currently a staff engineer, I have the feeling that responsibility that the department works well, right? And then sometimes my best use of my time could be that I jump into the senior engineering role where I just code. Because maybe we are lacking engineers right now or we need to get project over the finish line. And then you suddenly no longer have this staff level impact in this moment, which makes it hard for your promotion case. So sometimes, unfortunately, what is best for company is always best for your promotion. Another thing that I ⁓ mentioned in of my talks recently. So we say that this entry-level engineering positions, they usually just try to and be impactful within the team And after senior and staff, more about influence. How you can influence people ⁓ to get things you mentor them and so on. So let's assume someone workforce. They are an excellent influencer. are we call it the glue. ⁓ they ⁓ with everyone very well and are not the strongest coder which is fine someone else is stronger coder and then it happens that stronger coder gets promoted because they are senior then right and the other one not promoted the other one ⁓ would shine really well at a staff engineering when they don't need to code that much. That's weird thing.
Philipp: Yeah, I think what you're touching here is that the incentives for individuals and incentives for the companies here are not very well aligned. yeah, in my experience, I have never been promoted at the company. All my promotions were because of like switching positions. So from my perspective, it's definitely easier to a higher role at a different company ⁓ than to get promoted in the companies I work at. Which is also something that shouldn't be there because it's much more expensive for companies to hire on board and all of that than to promote people.
Nicolas: and more risky. episode where we discussed how hard it is to have these signals in the behavioral interview. So staff level is quite tricky to hire.
Philipp: Yeah. It's hard to fix, right? I think it's the same problem why companies have such a trouble creating new products. They have to kind of bear the weight of their existing stuff. Yeah. And they have to, you know, when they want to promote, they have to make like a framework so that it's fair to everyone in the company. cannot just promote people because you have a feeling that they will be better. You have to make it objective because otherwise it's not fair to the other people. And that's why we are in this position, I feel like. What advice would give people who want to make the promotion from senior to staff? Maybe also from other ones, from junior to mid and from mid to senior. I'm mentioning senior to staff because that's what we both have been most recently undergoing.
Nicolas: never got ⁓ to senior film. ⁓ We never got a promotion because we're the first job, like, okay, let's say it's the second job actually, but it's this job where we have been at PSP DevGit. were working there for half a year or a year and we got our business card from our ⁓ and the card was titled Senior Engineer and we both looked at them and asked like, ⁓ we are senior engineers? And he said like, yes. So this was our informal promotion back then.
Philipp: Business guys.
Nicolas: I it's totally fine if you just want to keep senior, to be honest. And for the senior promotion, I think it's quite clear. It's about quality of your work, how you get things done. As well? How you communicate, yes. ⁓
Philipp: how communicate. For being a senior engineer, you just have to make sure the team knows what you're up to. You be really proactive in how you organize stuff. Don't go rogue and work on something. Be the person that speaks up and says, hey, I have this thing to discuss. I want to move things forward. Basically, you should not be the bottleneck of the product.
Nicolas: Yeah, it should be, when I was a manager and had senior engineers, my idea was I give them the project and I can pretty much for 90 % be sure that this gets delivered on time. And the 10 % is just a typical risk you have for these projects. So that was my imagination of a solid senior engineer. And for staff level, it's more like, they will hopefully come to me with ideas how to... fix things in the organization or in the product or architecture and it will just maybe start working on it with a prototype already and then try to get the others working with them which is sometimes super hard for
Philipp: Yeah, there's a really good book as well about the staff engineering path. I forgot the name. Yeah, I think that's one. That's a, there's multiple books about it, but it also mentions these kind of different archetypes of staff engineers, which is something interesting to talk about.
Nicolas: Rensh.com Yep. Again, we can do this maybe in another episode. idea is that you are maybe stronger in one archetype than the other, but you need to perform in all pretty well. So I was in the senior position back then and I felt a bit stuck to be honest. And then my manager came along and was an excellent manager and he said like, you need to go to staff. ⁓ Otherwise you will not be happy. and was totally case. So I was constantly working on shipping and everyone was happy. And this is a super tough spot to be in because everyone knew, okay, just Nikolaus the project and it will be done. It's nice that you this reputation, but it's also bad because everyone will come to you to get projects done. So you are overloaded with this kind of work and you can't easily go beyond that. And he tried to do is then like sneak in ⁓ half a Friday afternoon or whole Friday, maybe sometimes to work on something that you think the organization needs to do and then show that off. And I was, to be honest, a bit lucky in my time. I was just pulled in into a super critical that had to something that had company wide impact. And this got me the promotion in end. yeah, because of my reputation to get stuff done. Not just luck. Of course it was lucky that they thought about me. so build up a reputation that you get things done and then you get also in this company-wide project that are important and help you with the promotion. And now that I'm promoted,
Philipp: How did you get pulled in? So maybe not just luck.
Nicolas: I'm looking into the next level and this is even harder because the department-wide impact is not enough. You need to have ⁓ larger impact now. And this really becomes hard because your own personal goals, they are no ⁓ aligned with what your team or department wants, in my opinion.
Philipp: have seen similar cases. There's other properties as well that staff engineers observe, which for example, they can handle ambiguous projects really well. ⁓ you throw them something like we want to go in this direction and they are working in a that they can explore different options, figure out what's the best solution, get like people on the team to like collaborate and stuff. Then there's like the impact angle, there's the influence angle, how much can you kind of rally up the company to do stuff. It also really helps with like promotions. It's really many ways to kind of show that you're doing more than a senior engineer. the thing is still if we are a senior engineer, you have to still be a good senior engineer. Yes. Because you cannot be promoted if you're not a good senior engineer, but you also need to perform at the next level and demonstrate that you could do this.
Nicolas: I also mentioned, at the staff level you also still need to perform somehow at a senior level. This is sometimes hard because you also still need to push out code depending a bit on the team of course, but it's the expectation that if a lack of engineers, you just jump in but if you are constantly in this architecture type of thinking, it's quite hard to switch.
Philipp: Okay, so to wrap this up, Nicholas, maybe a few sentences, what is some advice you would give people that are, let's say, not at the senior path yet to kind of hit the next level?
Nicolas: get good and be proactive, a lot, to get at a good quality ⁓ of the you get the Merge Request out and you get an approval immediately for most of your This is my expectation from senior and then the longer you do this, the more credibility get and then you get the projects assigned. And also this is one thing. tell your manager what you want. This is super crucial. Of course they don't know. They have so many people to manage. They don't know what everyone wants to work on. So this is advice for them. Tell the manager you want a project and want to grow in a certain area. And then when the project lines up, they can think about you. That's crucial. And for every staff engineer, help your intermediate engineers or senior engineers exactly the same. Think about them when you get assigned a project that someone else should take over to help them with the promotion as well.
Philipp: Yeah, cool. I don't think I have anything to add. Only maybe one thing, that it's hard and it's work and you have to put in the work.
Nicolas: Yeah, and one more thing, my personal advice is don't care about these titles. sounds weird we talked so much about now, ⁓ actually I never about any of these promotions. So my communication my manager was always, I don't care about the promotion, but me know if I already operated this level, And if they tell me I operate at the next level, I'm fine. Because the promotion will come eventually. with that mindset and it's more important that you grow than you have a fancy title with your name. Yeah, so we are again at end of our route. I to wrap this up with something that I observed this So Philipp and I this podcast now, I think it's fifth episode, right? ⁓ wow, yeah. And we also said, ⁓ at I said, let's care about the numbers people who listen in to this. And obviously the first episode was the one that was listened the most to and the episodes afterwards were a bit less. But this week a comedy stand-up show with a friend of ours and I told her about the podcast and she asked like, what, you're doing a podcast now? And I said like, yes, but it's only a few people who are listening in there. And she's like, how many people are listening in? And I told her the number. And she was like, hey, this is pretty cool. This is half of this whole room that you're currently in. So half of the people who came to this comedy show are weekly listening into this podcast. And amazing to think about.
Philipp: Yeah, I like to imagine these are all AI agents, don't they? So if you are really human and listen to this, please prove me wrong. Otherwise, of course, thank you so much. And yeah, see you next week.
Nicolas: See you, bye.
