4 ms·

A quote really jumped out at me: > VPs of Engineering from frontend backgrounds are relatively rare, and it’s partly because the most pressing technical challe

A quote really jumped out at me: > VPs of Engineering from frontend backgrounds are relatively rare, and it’s partly because the most pressing technical challenges a startup faces are often around scaling, reliability, and backend architecture. If we had been dealing with nonstop incidents, constant struggles with scaling, and major architectural challenges with our query and storage engine, someone with deeper backend and operational experience likely would have been chosen for the job, not me. Because of Ben, Ian, and other incredibly talented ICs on our team, and some of the solid design decisions the founding team made that bought us a lot of technical runway, these concerns were not top of mind for our leaders. Goals like executing well against our product strategy and leveling up our user experience were instead the concerns of the day, and there I could be more helpful. I’ve worked at companies in the past where frontend is looked down upon because all of our leaders are backend/infra people. What I’ve noticed is that the code quality from those backend devs is quite awful. I wonder if there exists an inverse relationship between leadership representation and engineering talent?

harrygeez 3y ago
> What I’ve noticed is that the code quality from those backend devs is quite awful Without knowing which metrics you use to measure the code quality, my hunch says you are focusing on the wrong thing. I am a frontend engineer turned tech lead. I think we developers choose our focuses based on our personal inclinations and what we value, and usually what I would notice is people who choose frontend work have different inclinations from backend developers. What is awful code? Is it not formatted consistently or prettily? The variables are not named descriptively? The code is not split or structured nicely? I find that frontend developers tend to judge code on superficial values. In an organization especially an engineering focused one, people get acknowledgements by solving problems. Very often, teams can function well enough without their main frontend guy but would struggle without one let alone a few strong infra or backend engineer. That's just the reality.
- DrammBA 3y ago
  I'm a 5 yoe frontend developer and I agree completely with you, backend/infra can be so much more complex than frontend. In my current company I participate on many hiring interviews for our team, and the backend interviews are incredibly savage compared to what's being discussed on a regular frontend interview. Even if I tried I can't bring the frontend interviews to that level of intensity because frontend simply doesn't have enough depth. It's a miracle I get paid a similar salary to them.
- wgottschalk 3y ago
  There's a few things that stood out to me from that codebase: 1. No unit tests. Integration tests broken weekly when external data source would change. 2. Hand rolled ORM resulting in inconsistent separation of concerns. Some controllers would use the ORM classes directly. Some would add layers of indirection. Some would make database calls directly in the indirection layers. 3. Database data model would "compress" dimensions to be clever. ex: the id field is a concatenation of a user supplied string + timestamp + some hard coded string prefix. In addition, there's multiple columns which represent similar concepts like "tenant", "customer", "team". 4. Several ongoing migrations created necessary but hard to understand backwards compatibility logic. Code breaks in strange ways when trying to add features because you have to remember there's 2^n different code paths. 5. No async code. Everything was a blocking call to the database resulting in unnecessarily slow api responses. 6. No indexes in the database to improve db perf The managers didn't see this stuff. They just know features can take a while to get out the door so they respond by asking for more head count. Leadership sees that more backend devs are needed and hire more backend focused managers to try and manage the fact that there are scaling and perf issues.
  - ukFxqnLa2sBSBf6 3y ago
    Isn’t it good for tests to fail when things change? Are you saying that the data source is not abstracted properly like with a repository pattern?
  - zelphirkalt 3y ago
    Does not seem like typical mistakes backend developers would make. Perhaps it is rather, that they moved on into leadership, since they found that to be their more effective roles, rather than their output as backend developers? Kind of like admitting, that perhaps it was not meant for them? With these kinds of practices, I could imagine that.
wpietri 3y ago
> I’ve worked at companies in the past where frontend is looked down upon because all of our leaders are backend/infra people. I think there's a lot going on here, but one of them is definitely gender. Front-end development is often feminine-coded and seen as lesser. E.g.: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-css https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c... I also think in tech-land we tend to associate leadership with male-coded traits. So it's not shocking at all to me that leadership and front-end backgrounds are often seen as somehow incompatible. And I think that same sort of gender dynamic is relevant to the code, too. For me, part of what makes for good code is that it's good for others, good for collaboration. But if you're going to be a macho big-swinging-dick alpha nerd tech bro, then that can involve performing genius via solo cowboy coding. There the goal isn't to work closely with a team to make something together, it's to be a visibly amazing IC with upper management written all over him.
- jtmarmon 3y ago
  This article is hilariously bad. The argument goes: I like CSS more than Tailwind -> Why don't people like CSS more? -> Maybe because 'CSS, which makes things look ‘pretty’, is considered feminine' You're entitled to like CSS more, and I could even agree making things look pretty is feminine coded, but it obviously doesn't explain people's preference for Tailwind because Tailwind also exists to make things look pretty. --- I've worked with plenty of female engineering leaders, and most of them have a backend background. The reason for this imbalance has nothing to do with gender, but entirely to do with criticality. Given that frontends tend to read/write from the backend, the domain model is usually owned by the backend in most apps, meaning that capability design and expansion is gated by the backend. Not to mention that screwing up your backend architecture is in 95% of cases a much much deeper problem than screwing up your frontend. A data migration is basically always harder than redesigning the UI for some app.
  - wpietri 3y ago
    That is not in fact the argument. If that's all you're getting from it, I suggest you try again. As to your other views, I think you have several errors. The biggest is declaring "it has nothing to do with gender" in a very gendered society, one with a long history of bias, and thinking having one (weak) alternative explanation is sufficient to explain executive hiring patterns.
marcosdumay 3y ago
> What I’ve noticed is that the code quality from those backend devs is quite awful. In my experience, people that look at areas they don't know and think "I don't know of any problems there, it should be easy" have a very high likelihood of being bad at the things they know too.

harrygeez 3y ago

> What I’ve noticed is that the code quality from those backend devs is quite awful Without knowing which metrics you use to measure the code quality, my hunch says you are focusing on the wrong thing. I am a frontend engineer turned tech lead. I think we developers choose our focuses based on our personal inclinations and what we value, and usually what I would notice is people who choose frontend work have different inclinations from backend developers. What is awful code? Is it not formatted consistently or prettily? The variables are not named descriptively? The code is not split or structured nicely? I find that frontend developers tend to judge code on superficial values. In an organization especially an engineering focused one, people get acknowledgements by solving problems. Very often, teams can function well enough without their main frontend guy but would struggle without one let alone a few strong infra or backend engineer. That's just the reality.

DrammBA 3y ago
I'm a 5 yoe frontend developer and I agree completely with you, backend/infra can be so much more complex than frontend. In my current company I participate on many hiring interviews for our team, and the backend interviews are incredibly savage compared to what's being discussed on a regular frontend interview. Even if I tried I can't bring the frontend interviews to that level of intensity because frontend simply doesn't have enough depth. It's a miracle I get paid a similar salary to them.
wgottschalk 3y ago
There's a few things that stood out to me from that codebase: 1. No unit tests. Integration tests broken weekly when external data source would change. 2. Hand rolled ORM resulting in inconsistent separation of concerns. Some controllers would use the ORM classes directly. Some would add layers of indirection. Some would make database calls directly in the indirection layers. 3. Database data model would "compress" dimensions to be clever. ex: the id field is a concatenation of a user supplied string + timestamp + some hard coded string prefix. In addition, there's multiple columns which represent similar concepts like "tenant", "customer", "team". 4. Several ongoing migrations created necessary but hard to understand backwards compatibility logic. Code breaks in strange ways when trying to add features because you have to remember there's 2^n different code paths. 5. No async code. Everything was a blocking call to the database resulting in unnecessarily slow api responses. 6. No indexes in the database to improve db perf The managers didn't see this stuff. They just know features can take a while to get out the door so they respond by asking for more head count. Leadership sees that more backend devs are needed and hire more backend focused managers to try and manage the fact that there are scaling and perf issues.
- ukFxqnLa2sBSBf6 3y ago
  Isn’t it good for tests to fail when things change? Are you saying that the data source is not abstracted properly like with a repository pattern?
- zelphirkalt 3y ago
  Does not seem like typical mistakes backend developers would make. Perhaps it is rather, that they moved on into leadership, since they found that to be their more effective roles, rather than their output as backend developers? Kind of like admitting, that perhaps it was not meant for them? With these kinds of practices, I could imagine that.

wpietri 3y ago

> I’ve worked at companies in the past where frontend is looked down upon because all of our leaders are backend/infra people. I think there's a lot going on here, but one of them is definitely gender. Front-end development is often feminine-coded and seen as lesser. E.g.: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-css https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c... I also think in tech-land we tend to associate leadership with male-coded traits. So it's not shocking at all to me that leadership and front-end backgrounds are often seen as somehow incompatible. And I think that same sort of gender dynamic is relevant to the code, too. For me, part of what makes for good code is that it's good for others, good for collaboration. But if you're going to be a macho big-swinging-dick alpha nerd tech bro, then that can involve performing genius via solo cowboy coding. There the goal isn't to work closely with a team to make something together, it's to be a visibly amazing IC with upper management written all over him.

jtmarmon 3y ago
This article is hilariously bad. The argument goes: I like CSS more than Tailwind -> Why don't people like CSS more? -> Maybe because 'CSS, which makes things look ‘pretty’, is considered feminine' You're entitled to like CSS more, and I could even agree making things look pretty is feminine coded, but it obviously doesn't explain people's preference for Tailwind because Tailwind also exists to make things look pretty. --- I've worked with plenty of female engineering leaders, and most of them have a backend background. The reason for this imbalance has nothing to do with gender, but entirely to do with criticality. Given that frontends tend to read/write from the backend, the domain model is usually owned by the backend in most apps, meaning that capability design and expansion is gated by the backend. Not to mention that screwing up your backend architecture is in 95% of cases a much much deeper problem than screwing up your frontend. A data migration is basically always harder than redesigning the UI for some app.
- wpietri 3y ago
  That is not in fact the argument. If that's all you're getting from it, I suggest you try again. As to your other views, I think you have several errors. The biggest is declaring "it has nothing to do with gender" in a very gendered society, one with a long history of bias, and thinking having one (weak) alternative explanation is sufficient to explain executive hiring patterns.

marcosdumay 3y ago

> What I’ve noticed is that the code quality from those backend devs is quite awful. In my experience, people that look at areas they don't know and think "I don't know of any problems there, it should be easy" have a very high likelihood of being bad at the things they know too.