4 ms·

Generally I think the message of the post with respect to democratizing access is fine, but I find this part rankling: > "Experts" in high growth tech will tel

by jxf 3y ago

Generally I think the message of the post with respect to democratizing access is fine, but I find this part rankling: > "Experts" in high growth tech will tell you that you should only ever made senior/experienced hires, so that you can just focus on scale. I've not heard experts in healthy organizations say this. If you want to build a durable institution, you need people of every skill level to create a pipeline of talent.

KnobbleMcKnees 3y ago
This comes from the same person who said >This policy has created a lot of extra work, headaches, and overhead for more senior programers that have to support it. By my best estimate, less than 2% of our code is written by non-programmer programmers. Despite all this, I’m very glad we did it. Does the author hold some resentment for senior engineers or something? I wonder if other areas of the org were opened up to this behaviour whether the response would be the same. How about having the accountants doing some experiment design or have data analysts balancing the books? It's an interesting idea and social experiment but somewhere in their organisation, someone is bearing the brunt of it (engineers by the sound of it), and that's a cultural deficiency caused by bad leadership. I would like to have heard more about how that deficiency might be solved but the post seems hell bent on driving home a narrow, feel good, "anyone can do it!" message rather than exploring the idea meaningfully.
- majesticglue 3y ago
  > Does the author hold some resentment for senior engineers or something? Sounds like it. I worked at a company where some of my team leads were business persons (and had no coding experience) who just happened to start working on backend (before i started working there) and setup a codebase. It probably was beneficial at the time because they knew what to build and what type of value it could bring... But of course, when the team started expanding, people realized the database had one of the absolute awful data modeling that was completely unworkable. No one can work on it because of all the complicated SQL queries (we are talking full page SQL queries) required to make any kind of changes. They wanted a new version of the app, but no one wanted to touch that mess but they were literally stuck because they had valuable data formatted in this conglomerate mess. For example, the app would take like 5 seconds to load, and make 5-10 different api calls for what should be single api calls to the backend. Fortunately it was an internal app so performance wasn't as big an issue, but many people were using it. So there were so many bugs and requests of this app but no one can address them whatsoever, not even the person who built the app. And yes, it was THAT bad. They wanted us to rebuild that same app, but not rework the backend because of how long it might take, and even 1-2 years later, the app looked better but...the bugs to address are still nearly impossible without a reworked backend. They may have gotten users...but I'm pretty sure they wasted more money on trying to maintain the thing than how much it benefitted the company. Gotta love business people loving the "anyone can do it!". And code maintenance in the backburner like usual. As long as the app attracts "users", that's all that matters right?
- ghiculescu 3y ago
  I hold no resentment! I think there’s an assumption that there’s an unavoidable brunt of work for others that this policy creates. The reality is that there is a small amount of extra work created, but it’s not significant. I’m curious how you’d suggest structuring this to avoid cultural deficiencies?
mistrial9 3y ago
Paul Graham specifically excluded engineers over 40 years old, systematically from the YCombinator filters. I believe this is quietly known since it is directly illegal to discriminate by age, on paper.
ghiculescu 3y ago
Talk to almost any VC and this is one of the main things they’ll tell you. “You have to hire experienced operators who’ve done it before - at every level of the business.”
- jxf 3y ago
  VCs are not experts in high growth technology firms. They are experts in securitization and capital management. These are different things from building healthy, productive organizations that people want to work at.

by jxf 3y ago

KnobbleMcKnees 3y ago

This comes from the same person who said >This policy has created a lot of extra work, headaches, and overhead for more senior programers that have to support it. By my best estimate, less than 2% of our code is written by non-programmer programmers. Despite all this, I’m very glad we did it. Does the author hold some resentment for senior engineers or something? I wonder if other areas of the org were opened up to this behaviour whether the response would be the same. How about having the accountants doing some experiment design or have data analysts balancing the books? It's an interesting idea and social experiment but somewhere in their organisation, someone is bearing the brunt of it (engineers by the sound of it), and that's a cultural deficiency caused by bad leadership. I would like to have heard more about how that deficiency might be solved but the post seems hell bent on driving home a narrow, feel good, "anyone can do it!" message rather than exploring the idea meaningfully.

majesticglue 3y ago
> Does the author hold some resentment for senior engineers or something? Sounds like it. I worked at a company where some of my team leads were business persons (and had no coding experience) who just happened to start working on backend (before i started working there) and setup a codebase. It probably was beneficial at the time because they knew what to build and what type of value it could bring... But of course, when the team started expanding, people realized the database had one of the absolute awful data modeling that was completely unworkable. No one can work on it because of all the complicated SQL queries (we are talking full page SQL queries) required to make any kind of changes. They wanted a new version of the app, but no one wanted to touch that mess but they were literally stuck because they had valuable data formatted in this conglomerate mess. For example, the app would take like 5 seconds to load, and make 5-10 different api calls for what should be single api calls to the backend. Fortunately it was an internal app so performance wasn't as big an issue, but many people were using it. So there were so many bugs and requests of this app but no one can address them whatsoever, not even the person who built the app. And yes, it was THAT bad. They wanted us to rebuild that same app, but not rework the backend because of how long it might take, and even 1-2 years later, the app looked better but...the bugs to address are still nearly impossible without a reworked backend. They may have gotten users...but I'm pretty sure they wasted more money on trying to maintain the thing than how much it benefitted the company. Gotta love business people loving the "anyone can do it!". And code maintenance in the backburner like usual. As long as the app attracts "users", that's all that matters right?
ghiculescu 3y ago
I hold no resentment! I think there’s an assumption that there’s an unavoidable brunt of work for others that this policy creates. The reality is that there is a small amount of extra work created, but it’s not significant. I’m curious how you’d suggest structuring this to avoid cultural deficiencies?

mistrial9 3y ago

Paul Graham specifically excluded engineers over 40 years old, systematically from the YCombinator filters. I believe this is quietly known since it is directly illegal to discriminate by age, on paper.

ghiculescu 3y ago

Talk to almost any VC and this is one of the main things they’ll tell you. “You have to hire experienced operators who’ve done it before - at every level of the business.”

jxf 3y ago
VCs are not experts in high growth technology firms. They are experts in securitization and capital management. These are different things from building healthy, productive organizations that people want to work at.