Live data from Hacker News

Want to Recruit Better Engineers? Open Source Your Code

angel.co

1–10 of 146 posts

Re: Want to Recruit Better Engineers? Open Source Your Code

#3
I was listening to a friend's music podcast tonight and they were talking about how industry will seize on any shred of creativity so that they can use it to sell cars, and this contributes to people getting defensive about the things they like becoming popular. There is a latent fear that just over the horizon, some marketing asshole is waiting to get their hands on something that is meaningful to you, in order to abuse that connection so they can buy themselves a boat.

This post feels like it's edging way too close to that. If you want to attract "talent" by putting repos on Github or Gitlab, that's great. But if you are hiding bad engineering practices and/or a shitty work environment and putting up a facade which is carefully crafted as a recruiting tool (and not truly a reflection of what it's like to work on a project inside your company), you are making a huge mistake that will backfire and it will come back to haunt you.

That's not to say that we don't know that open source is a tool companies use to get more for less (everybody knows that). But if you keep a carefully-controlled open source repository around to show potential hires when there is a bonfire in the engineering team's side of the open-office floorplan because your actual engineering practices are abysmal, you should know the "talent" you want to hire is no spring chicken, and they will know almost immediately that you have been duplicitous in your hiring, and word will spread. And then you'll have existential hiring problems.

Re: Want to Recruit Better Engineers? Open Source Your Code

#5
Anecdotally, I look at the public repos of any company advertising a job I'm interested in before I apply, so open source certainly attracts some class of developers.

The problem is the assumption that people who do that are "better" in some way. I've known some brilliant engineers who don't care at all for open source code; they wrote great code that no one besides the customer would ever see or use. That doesn't make them bad engineers.

Re: Want to Recruit Better Engineers? Open Source Your Code

#6
There is a line you can draw in the sand here. I usually define it in terms of the Product; I don't believe companies should feel compelled, or even desire to, open source code which directly relates to the product they're trying to sell. The number of companies which actually do this are few and far between (Red Hat, Gitlab, others of course).

However, companies should desire to open source code which supports their product. Libraries they've written internally to do important things. Services. Infrastructure tooling. These are all great things to open source. There are many reasons why this is a great idea, beyond just recruiting and marketing.

1. Every company has shit code. Most of this is centered around your business domain (aka product) because that's what changes so often. Its alright to find a balance between "we're hiding skeletons in the closet" and "don't make a snap judgement based on a few Github repos, we have mentorship and you'll learn a lot about the context and intentions a lot of this stuff arose from."

2. It forces your developers to think beyond just their team. Now, suddenly, anyone can see this. Woah. I mean, its pretty likely only a couple dozen people will, but I guarantee you'll get really high quality READMEs, you'll get documentation, clean APIs... all of this benefits your internal team tremendously. Why doesn't this happen as often "by default" with strictly internal projects? Developers know the internal requirements, and they're usually not a strict as their perceived public requirements many open source projects live by. Crazy. True.

3. It forces your developers to think beyond just your product. This is HUGE. I cannot stress how important this is. "Evolved" companies develop everything with the little voice in the back of their head that it could just be thrown away tomorrow. Because, whether you like it or not, pivots happen. Maybe small, maybe big. If all of your code is intricately intertwined with your latest Uber for Canaries idea, you'll find reusing it during one of these pivots to be very difficult. But if its open source, there's this invisible force telling you that it can't be like that. It forces you to find the right APIs to work with both your product and Generic Use Cases. This takes longer. You should find a balance. But its worth it.

Re: Want to Recruit Better Engineers? Open Source Your Code

#7
post #3

I was listening to a friend's music podcast tonight and they were talking about how industry will seize on any shred of creativity so that they can use it to sell cars, and this contributes to people getting defensive about the things they like becoming popular. There is a latent fear that just over the horizon, some marketing asshole is waiting to get their hands on something that is meaningful to you, in order to a…

Boats are awesome but you will always want a bigger one.

Re: Want to Recruit Better Engineers? Open Source Your Code

#8
post #6

There is a line you can draw in the sand here. I usually define it in terms of the Product; I don't believe companies should feel compelled, or even desire to, open source code which directly relates to the product they're trying to sell. The number of companies which actually do this are few and far between (Red Hat, Gitlab, others of course). However, companies should desire to open source code which supports their…

[deleted]

Re: Want to Recruit Better Engineers? Open Source Your Code

#9
post #6

There is a line you can draw in the sand here. I usually define it in terms of the Product; I don't believe companies should feel compelled, or even desire to, open source code which directly relates to the product they're trying to sell. The number of companies which actually do this are few and far between (Red Hat, Gitlab, others of course). However, companies should desire to open source code which supports their…

I challenge the notion that product is so precious that there's a benefit to it remaining closed source. If there is a line, I'd draw it at business process, not product.

I'm a former Artsyer. There, a good bit of core product code t is actually open source, including the entire website and iOS app. As it turns out, the real value in most businesses is the data, business relationships, the domain knowledge, and the processes. People can't use your code to steal your business, even if they want to.

It does, indeed, have some impact on code quality, although I wouldn't say there was major difference. Much of the closed source code was pretty critical in its need for correctness.

Another benefit is that as you blog or do conference talks, you can point to real life code, rather than contriving examples. So there's somewhat of a virtuous cycle of positive exposure.

I can also say that the CTO is genuinely enthusiastic about his engineers building their personal brands. Sure, they might eventually leave (like me), but on the whole, it gives people growth opportunities outside the company while working there, and definitely helps with recruiting.

Post reply on HN