5 ms·

It's very simple; no juniors at the beginning! They can make things work, but they don't have the experience to avoid tech debt even in the short term. I have

It's very simple; no juniors at the beginning! They can make things work, but they don't have the experience to avoid tech debt even in the short term. I have seen this as a CTO, unfortunately I came too late and the company broke. The terrible management played a bigger part, but the code base was so terrible and the tech debt so big they couldn't ship even very simple features in a timely manner. Testing and release was insanely slow.

deleted 6y ago
[deleted]
Viliam1234 6y ago
Is the problem actually the presence of juniors, or rather the fact that in "agile" all developers are treated as replaceable, so the juniors randomly get assigned strategically important tasks where they can do long-term damage? I imagine that after a month, when the senior developer(s) laid down the foundations, it should be possible to find work for the juniors (not all at the same time, but adding them gradually). They just cannot be assigned tickets at random.
x0x0 6y ago
I can't emphasize this strongly enough: no juniors. Probably for the first 3+ years. They're a disaster, and it's taken my company a year -- with another year or more to go -- to recover. It's not even necessarily their fault; they just need piles of time and mentorship and direction that you can't afford to give yet. Worse, you'll quite possibly end up firing them when you eventually start reigning them in and they don't like being told how to build things. Trust me, it's been an extremely painful experience.
- cs-szazz 6y ago
  "Worse, you'll quite possibly end up firing them when you eventually start reigning them in and they don't like being told how to build things." Had this exact thing happen at my company. It's tough when you have to start doing this, but even tougher if you don't. There are times I certainly think we'd have the same output with half the people if we'd kept the bar higher.
boffinism 6y ago
Counter-anecdote: one very successful SaaS startup I know launched with one unsupervised junior dev building everything, because they had no budget for more. He knew so little about coding he didn't even know what tech debt was when I spoke to him, a year in. But he got the v1 to market, which got them investment, and allowed them to hire in experience round him, and start paying off a mountain of tech debt. It was painful, but it worked. And, crucially, they could not have even got started if they'd not done it that way.
- kissgyorgy 6y ago
  I don't think it's a "counter-anecdote". It worked DESPITE of the junior, not because of him. The startup I'm currently working for has the same story. A junior wrote most of the code, but we got hired at the first round. It will take months to solve the spaghetti, but it might work, but I'm very experienced handling even huge and terrible code bases (300-500 thousand of lines of legacy code).
  - boffinism 6y ago
    Actually it did work 'because of' the junior dev. They couldn't afford a senior dev, so the only viable path to success was to hire a junior. If the point of the original anecdote was 'don't hire a junior for your startup' the point of mine is 'sometimes do'.
    - xupybd 6y ago
      I've seen this a few times. Terrible code but successful company. The companies could not have afforded better programmers. Instead of seed funding they funded with debt, technical debt. The hardest part is explaining to the owners why it's so expensive to fix everything. They don't understand how it was so cheap to build yet so expensive to maintain.
  - Roritharr 6y ago
    I ONLY know this story. In the past 15 years I've only seen "started out underfunded and as a mess" and ""never went live because of overengineering", nothing really in-between, but I'm in Europe where Seed Fundings are pretty small.
hertzrat 6y ago
I think it depends a lot on the juniors. I’ve seen some really terrible code written by experienced people who just didn’t hone their craft, and some juniors who figured out some good practices very early on
- kissgyorgy 6y ago
  Yeah, I met juniors who improved at an insane rate, and they became awesome developers, but it's very rare.
- ProZsolt 6y ago
  Years in the business != seniority
trentnix 6y ago
While hiring senior developers doesn't necessarily inoculate you from the same fate, your point about the lack of experience is real. Some lessons can only be learned via the ass-kickings that come with experience.
giomasce 6y ago
Honest question: how are "junior" and "senior" defined here?
- kissgyorgy 6y ago
  Here is how I think about this usually: - Junior: somebody who is happy that they found a working solution. Most code what they write doesn't even work or they don't know yet how to approach problems. - Normal / mid-level: developers who can easily find working solutions to problems, but not always the best or easy to understand. Should be able to handle edge cases and errors properly. - Senior: How to solve problems is not even a question for them, they can come up with multiple ways solving the same problem, but their chosen solution will be flexible, easy to understand (even for Juniors) and maintainable in the long term. When they make a technical debt, it is a conscious decision and not a fatal mistake.
Griffinsauce 6y ago
I've seen a startup struggle with so much waste from a bunch of senior engineers massively overengineering an app to the point of developing something akin to their own front end framework... before being anywhere in sight of profitability or even PMF. The pain lasted for years after, even when a successful business model started to come into view. With the exact outcome that you describe. Senior v. Junior is not the problem here. Developing according to your stage and future is. Build things that can be thrown away next week when your product shifts. (ie. low coupling, simple, avoid abstraction adventures). _Maybe_ "senior" devs are more likely to understand that. I'd argue it's rather devs with any multi-year experience at an early stage startup, regardless of skill level.
- kissgyorgy 6y ago
  Someone who unnecessarily overengineers an app is not a senior engineer by my definition. They are just somebody who working in the field for a long time.
erdo 6y ago
I really agree with this. Junior developers just can't write clear, simple code. They accidentally over-complicate everything, in the most unhelpful way possible. If you have a senior developer that does that, I would consider them a mid-level developer at best. I've seen this play out in 2 large companies I've contracted for so far. At the start of a new project, recruitment look for developers with the lowest daily rate they can find and end up with a team of recent grads / people switching careers within the company etc. That's all fine as long as you add a good measure of developers with >5 yrs relevant experience to the mix. But as these people are twice as expensive, they often start without them. A few years later the product "almost" works. But it's full of bugs, it takes months instead of days to make minor changes, and it still requires an enormous team of people who are all irreplaceable (they possess the "secret" knowledge about the product that usually would be embodied in clear code intentions, past jira tickets, commit history, basic documentation etc.) Meanwhile a new competitor in the market has developed a much better product. This situation can last for years (because some companies are a bottomless money pit, despite being tight with it) Eventually some expensive people get hired to put the "finishing touches" on the product and they start the long slog to fix it up (or just quit in horror after a few weeks) So far: 1) retired the entire project after years of development 2) company got bought out and the product scrapped after several years of investing money on it 3) is in progress (company has enough money to fund the situation for years, but time will tell if we manage to untangle the mess before it kills the project)

deleted 6y ago

[deleted]

Viliam1234 6y ago

Is the problem actually the presence of juniors, or rather the fact that in "agile" all developers are treated as replaceable, so the juniors randomly get assigned strategically important tasks where they can do long-term damage? I imagine that after a month, when the senior developer(s) laid down the foundations, it should be possible to find work for the juniors (not all at the same time, but adding them gradually). They just cannot be assigned tickets at random.

x0x0 6y ago

I can't emphasize this strongly enough: no juniors. Probably for the first 3+ years. They're a disaster, and it's taken my company a year -- with another year or more to go -- to recover. It's not even necessarily their fault; they just need piles of time and mentorship and direction that you can't afford to give yet. Worse, you'll quite possibly end up firing them when you eventually start reigning them in and they don't like being told how to build things. Trust me, it's been an extremely painful experience.

cs-szazz 6y ago
"Worse, you'll quite possibly end up firing them when you eventually start reigning them in and they don't like being told how to build things." Had this exact thing happen at my company. It's tough when you have to start doing this, but even tougher if you don't. There are times I certainly think we'd have the same output with half the people if we'd kept the bar higher.

boffinism 6y ago

Counter-anecdote: one very successful SaaS startup I know launched with one unsupervised junior dev building everything, because they had no budget for more. He knew so little about coding he didn't even know what tech debt was when I spoke to him, a year in. But he got the v1 to market, which got them investment, and allowed them to hire in experience round him, and start paying off a mountain of tech debt. It was painful, but it worked. And, crucially, they could not have even got started if they'd not done it that way.

kissgyorgy 6y ago
I don't think it's a "counter-anecdote". It worked DESPITE of the junior, not because of him. The startup I'm currently working for has the same story. A junior wrote most of the code, but we got hired at the first round. It will take months to solve the spaghetti, but it might work, but I'm very experienced handling even huge and terrible code bases (300-500 thousand of lines of legacy code).
- boffinism 6y ago
  Actually it did work 'because of' the junior dev. They couldn't afford a senior dev, so the only viable path to success was to hire a junior. If the point of the original anecdote was 'don't hire a junior for your startup' the point of mine is 'sometimes do'.
  - xupybd 6y ago
    I've seen this a few times. Terrible code but successful company. The companies could not have afforded better programmers. Instead of seed funding they funded with debt, technical debt. The hardest part is explaining to the owners why it's so expensive to fix everything. They don't understand how it was so cheap to build yet so expensive to maintain.
- Roritharr 6y ago
  I ONLY know this story. In the past 15 years I've only seen "started out underfunded and as a mess" and ""never went live because of overengineering", nothing really in-between, but I'm in Europe where Seed Fundings are pretty small.

hertzrat 6y ago

I think it depends a lot on the juniors. I’ve seen some really terrible code written by experienced people who just didn’t hone their craft, and some juniors who figured out some good practices very early on

kissgyorgy 6y ago
Yeah, I met juniors who improved at an insane rate, and they became awesome developers, but it's very rare.
ProZsolt 6y ago
Years in the business != seniority

trentnix 6y ago

While hiring senior developers doesn't necessarily inoculate you from the same fate, your point about the lack of experience is real. Some lessons can only be learned via the ass-kickings that come with experience.

giomasce 6y ago

Honest question: how are "junior" and "senior" defined here?

kissgyorgy 6y ago
Here is how I think about this usually: - Junior: somebody who is happy that they found a working solution. Most code what they write doesn't even work or they don't know yet how to approach problems. - Normal / mid-level: developers who can easily find working solutions to problems, but not always the best or easy to understand. Should be able to handle edge cases and errors properly. - Senior: How to solve problems is not even a question for them, they can come up with multiple ways solving the same problem, but their chosen solution will be flexible, easy to understand (even for Juniors) and maintainable in the long term. When they make a technical debt, it is a conscious decision and not a fatal mistake.

Griffinsauce 6y ago

I've seen a startup struggle with so much waste from a bunch of senior engineers massively overengineering an app to the point of developing something akin to their own front end framework... before being anywhere in sight of profitability or even PMF. The pain lasted for years after, even when a successful business model started to come into view. With the exact outcome that you describe. Senior v. Junior is not the problem here. Developing according to your stage and future is. Build things that can be thrown away next week when your product shifts. (ie. low coupling, simple, avoid abstraction adventures). _Maybe_ "senior" devs are more likely to understand that. I'd argue it's rather devs with any multi-year experience at an early stage startup, regardless of skill level.

kissgyorgy 6y ago
Someone who unnecessarily overengineers an app is not a senior engineer by my definition. They are just somebody who working in the field for a long time.

erdo 6y ago

I really agree with this. Junior developers just can't write clear, simple code. They accidentally over-complicate everything, in the most unhelpful way possible. If you have a senior developer that does that, I would consider them a mid-level developer at best. I've seen this play out in 2 large companies I've contracted for so far. At the start of a new project, recruitment look for developers with the lowest daily rate they can find and end up with a team of recent grads / people switching careers within the company etc. That's all fine as long as you add a good measure of developers with >5 yrs relevant experience to the mix. But as these people are twice as expensive, they often start without them. A few years later the product "almost" works. But it's full of bugs, it takes months instead of days to make minor changes, and it still requires an enormous team of people who are all irreplaceable (they possess the "secret" knowledge about the product that usually would be embodied in clear code intentions, past jira tickets, commit history, basic documentation etc.) Meanwhile a new competitor in the market has developed a much better product. This situation can last for years (because some companies are a bottomless money pit, despite being tight with it) Eventually some expensive people get hired to put the "finishing touches" on the product and they start the long slog to fix it up (or just quit in horror after a few weeks) So far: 1) retired the entire project after years of development 2) company got bought out and the product scrapped after several years of investing money on it 3) is in progress (company has enough money to fund the situation for years, but time will tell if we manage to untangle the mess before it kills the project)