Opening the Codebase Up to Everyone | Hacker News Reader

Opening the Codebase Up to Everyone

ghiculescu.substack.com

37 pointsghiculescu16 comments

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.

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.

> 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?

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?

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.

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.”

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.

At Thread we encouraged non-engineers to contribute to the codebase and it was a broadly great experience: https://danpalmer.me/2018-01-04-teaching-non-engineers-how-t...

One downside, many tools end up interacting with "active engineers", and while hundreds of dollars per month of SaaS costs per engineer is reasonable, paying that much for a non-engineer to fix a typo or tweak a config value once a month isn't great.

To me that is exactly a failure of usefulness that makes those tools less valuable and counts towards avoiding them. It's probably very difficult to quantify what is lost vs what is gained by buying in to things like that, but "difficult to quantify" doesn't mean there's nothing there. It's not even the fixed typo that's the valuable lost thing, it's the frictionless discovery or creation of a whole new useful developer or ops admin.

Also the value of allowing people to take pride in and care about their work, which is your product. What's that worth? Hard to measure but I will confidently say it's a lot.

I found this section interesting:

>[Non-programmer programmers becoming/being SMEs] is great for a while; finally someone can fix all the annoying known issues in that space that have been lingering for a while.

Followed a whole sentence later with:

>If something is only getting done because someone that "isn’t a dev resource” wants to work on it, then that’s a sign that it shouldn’t be getting done.

Yes it's qualified that it's "a sign" but if you have annoying known issues that are customer facing (even if only internal customers) sitting open in perpetuity you're probably under resourcing those areas. If you're doing that it's likely that those areas could disappear and the company would be better off or should be charged at a higher rate to external customers so they are properly maintained.

As a whole having the codebase be accessible is just open source writ small: a small number of people will be interested enough to take part and they'll often not be fully aware of the code culture when they submit a PR leading to more work for the maintainer. But they were also interested or annoyed enough to clear the hurdle of submitting one and maybe that's a sign something should be getting done in that area.

I like this metaphor. I think we’d get a lot of value out of structuring our internal processes more like an open source project.

In the first anecdote the author recounted, I suspect the reason that opening up the codebase to Adam was so effective is that Adam had a mathematical background.

It's not true that anyone who has studied mathematics at a high level is effective in tech, but the ones who make it into tech (in whatever role, not just as programmers) tend to have this same characteristic. They are thinking in terms of problems to solve, and if a problem needs automation, they will figure out automation.

I am always willing to give people with mathematical backgrounds a chance, regardless of experience or current skills.

I think similar principles might apply to the lawyer who started reading/writing unit tests and maybe to the other cases as well.

Can someone, anyone, explain to me how this passes SOX scrutiny?

I have issues with business/product team even commenting on PRs because auditors have said that access to GitHub=Access to Codebase.

There are a select few people I would consider granting access to code within our product teams, but without "segregation of duties" clearly defined, I don't think it would fly.

If you can solve a Sudoku puzzle you can program a computer. Secretaries were programming emacs in lisp in the 1970's. Normal people.

To some extent the IT industry is predicated on people being too unmotivated (for whatever reasons) to learn to program. (Something I've never understood. Programming is the best video game?)

Now that the computers can talk...

Learning to program does not equate to learning to architect and evolve over many years a non-trivial system, operate it, document it, train others on it, scale it, etc. - “unmotivated” is a bit reductive. In the same way I might enjoy some DIY here and there but don’t want to and shouldn’t be trusted to build new houses, the same goes for non-trivial systems - sometimes you really do just need professionals.

That’s not to say you can’t give areas with guardrails to non-software-engineering-professionals if you can teach them git.

> “unmotivated” is a bit reductive

Well, sure, it's under-specified, I said "unmotivated (for whatever reasons)", eh?

I agree with you. When it comes to programming computers it's one of the few areas where I am unabashedly elitist ( https://sforman.srht.site/AnyoneCanCode.html "For most people learning anything more complicated than Excel is counter-productive." )

My point is that it's not that hard to learn to program, not that it's easy to program well (it's not. I've been at it for over a quarter of a century and I'm still barely capable.)

My additional point is that the barrier to entry (other than apathy or disinterest) is the complexity (just to make a website you need to know three or four computer languages!?)

My third point is that that complexity is about to vanish in a haze of linear algebra and massive data (the computers can talk now.)

Reply on news.ycombinator.com