Not a founder but have 20+ years experience in code and 7 before that in design and build of data center blade tech back when that was still kind of new; been in engineering a while
And yeah... have seen all the jargons come and go. DOS, Novell, Windows NT, xml, soap, next, BSD had a moment, chef and yada yada...the vague hand wavy semantics to 2010s web saas will not be spared
The most common shared cross continent language for whats going on is math... stats of state of memory registers
The jargons conjured up on the fly to do office work 30+ years ago all fade away; how many startups went all in on COBOL during the RoR era?
So yeah; hard pressed to recommend tethering juniors to useless jargon as we have most of my career.
Just because you are a founder, does not mean you "are" the company. To build culture as a company, you need people to "grow up" within said company. To be sustainable for a long term, it's more important to have a team that is familiar with your company, the way you do things and the issues you encounter along the way. Someone "growing up" in your company will be way more valuable long term. Sure, you might say a senior dev will be able to grow much the same way but
1. He will cost more upfront
2. He might have (justifiably) have higher standards of his own and leave you for a better offer
3. He will be less flexible in trying out new things
Those are generalizations but in my experience, once the 5-Year mark passes, a junior is pretty much always a better colleague than a senior.
This is not to say that you should not hire seniors but you need a good mix of trainers and trainees. Training employees can also make a senior much more effective at his own job.
It's a tough time to make those decisions. I really don't know what juniors will do. Continuity is a real cost, but a long term one. So, early on definitely doesn't make sense, especially when you are laying a foundation. But afterwards, you have to have some form of continuity to maintain the product and the cheapest and best way would be to bring on young talent.
Hi fellow founder here, just sharing some thoughts. Agree that with AI more eng work can now be handled by a senior dev but a good junior dev using AI is also more capable than ever. I think with a good process in place, you can ramp up a junior dev sooner rather than later. And as good as AI is, there's still a human bottleneck, so I'd assess the quantity of work you have vs. the technical complexity
I just meant that even a senior dev can only manage a finite number of tasks at a time, even if AI is doing the work. So if everyone's plates are full, then maybe some of the work can be offloaded to junior devs. However, if you feel like the work is not suitable for junior devs, then maybe you need more senior devs.That being said, I wouldn't look at it as simply as senior dev = 3x junior dev. Of course, it depends on the work you have, your hiring talent pool, etc.
I'd wager a Junior engineer has the same capability to become versed in AI technology software delivery workflows is just as capable of learning and maybe more capable of thinking with the mindset of all the new LLM tooling than someone who, though capable, may not be amenable to learning yet another set of tools.
Hire them, you're gut is questioning your rational brain for good reason.
The future of OpenAI and Anthropic is contingent on a lot of factors which can (and maybe will) just vanish overnight. If China "invades" Taiwan, or if the data center buildouts completely stall, AI is going to be in a very precarious spot.
It sounds like you want to hire people to just be your fingers, and not build a team of people who care about what they’re trying to do, and who find and solve problems you aren't aware of. LLMs are not good at solving meta problems like this, teams are.
If you’re the type of person or company that would hire an outsourced team overseas without hesitation, then LLMs would probably be fine for you.
> So far, I'm really struggling to see the value add of a junior engineer given how good the models have become. A senior with Max plan beats three junior hires (very rough estimate).
A single staff-level engineer with 4 concurrent agents on a Max plan replaces 4 seniors and 12 junior hires.
It's okay to say that we want don't need to hire any human programmers anymore since they are the bottleneck. But the strong disadvantage is that these agents need humans to tell them what to do.
If you think otherwise, look no further than the Huggingface hack and what happens when they run completely autonomously. Not only that is a waste of tokens, it can cause you to be legally liable for damages if something terrible happens.
Not a founder but have 20+ years experience in code and 7 before that in design and build of data center blade tech back when that was still kind of new; been in engineering a while
And yeah... have seen all the jargons come and go. DOS, Novell, Windows NT, xml, soap, next, BSD had a moment, chef and yada yada...the vague hand wavy semantics to 2010s web saas will not be spared
The most common shared cross continent language for whats going on is math... stats of state of memory registers
The jargons conjured up on the fly to do office work 30+ years ago all fade away; how many startups went all in on COBOL during the RoR era?
So yeah; hard pressed to recommend tethering juniors to useless jargon as we have most of my career.
Just because you are a founder, does not mean you "are" the company. To build culture as a company, you need people to "grow up" within said company. To be sustainable for a long term, it's more important to have a team that is familiar with your company, the way you do things and the issues you encounter along the way. Someone "growing up" in your company will be way more valuable long term. Sure, you might say a senior dev will be able to grow much the same way but 1. He will cost more upfront 2. He might have (justifiably) have higher standards of his own and leave you for a better offer 3. He will be less flexible in trying out new things
Those are generalizations but in my experience, once the 5-Year mark passes, a junior is pretty much always a better colleague than a senior.
This is not to say that you should not hire seniors but you need a good mix of trainers and trainees. Training employees can also make a senior much more effective at his own job.
It's a tough time to make those decisions. I really don't know what juniors will do. Continuity is a real cost, but a long term one. So, early on definitely doesn't make sense, especially when you are laying a foundation. But afterwards, you have to have some form of continuity to maintain the product and the cheapest and best way would be to bring on young talent.
Hi fellow founder here, just sharing some thoughts. Agree that with AI more eng work can now be handled by a senior dev but a good junior dev using AI is also more capable than ever. I think with a good process in place, you can ramp up a junior dev sooner rather than later. And as good as AI is, there's still a human bottleneck, so I'd assess the quantity of work you have vs. the technical complexity
Thanks for sharing. Do you have a few examples of these human bottlenecks where a junior engineer is apt?
I just meant that even a senior dev can only manage a finite number of tasks at a time, even if AI is doing the work. So if everyone's plates are full, then maybe some of the work can be offloaded to junior devs. However, if you feel like the work is not suitable for junior devs, then maybe you need more senior devs.That being said, I wouldn't look at it as simply as senior dev = 3x junior dev. Of course, it depends on the work you have, your hiring talent pool, etc.
I'd wager a Junior engineer has the same capability to become versed in AI technology software delivery workflows is just as capable of learning and maybe more capable of thinking with the mindset of all the new LLM tooling than someone who, though capable, may not be amenable to learning yet another set of tools.
Hire them, you're gut is questioning your rational brain for good reason.
The future of OpenAI and Anthropic is contingent on a lot of factors which can (and maybe will) just vanish overnight. If China "invades" Taiwan, or if the data center buildouts completely stall, AI is going to be in a very precarious spot.
It sounds like you want to hire people to just be your fingers, and not build a team of people who care about what they’re trying to do, and who find and solve problems you aren't aware of. LLMs are not good at solving meta problems like this, teams are.
If you’re the type of person or company that would hire an outsourced team overseas without hesitation, then LLMs would probably be fine for you.
hire them. that's my thought.
> So far, I'm really struggling to see the value add of a junior engineer given how good the models have become. A senior with Max plan beats three junior hires (very rough estimate).
A single staff-level engineer with 4 concurrent agents on a Max plan replaces 4 seniors and 12 junior hires.
It's okay to say that we want don't need to hire any human programmers anymore since they are the bottleneck. But the strong disadvantage is that these agents need humans to tell them what to do.
If you think otherwise, look no further than the Huggingface hack and what happens when they run completely autonomously. Not only that is a waste of tokens, it can cause you to be legally liable for damages if something terrible happens.