Live data from Hacker News

It’s OK for your open source library to be a bit shitty (2015)

drmaciver.com

121–130 of 364 posts

Re: It’s OK for your open source library to be a bit shitty (2015)

#121
post #106

Earlier quoted context omitted.

off-topic: I still don't understand the use case that left-pad solved. I'm not into js at all but why do you need a dependency to add space to text? I'm asking honestly, I just don't get what the use for this was.

Literally what it says: https://github.com/left-pad/left-pad/blob/master/index.js Now if you ask "but why?", ultra-small packages like this are popular in JS because of the lack of a standard lib. Lots of devs prefer to install a dependency for each one-liner utility rather than write them themselves. The only added value of those packages is that they're usually unit-tested against weird edge-cases that you might mi…

The smaller the library, the better.

Re: It’s OK for your open source library to be a bit shitty (2015)

#122

Earlier quoted context omitted.

No, there is no obligation. But there’s a thing called courtesy. And as humans there are certain social norms. If someone spams me, I will ignore or retaliate by reporting as spam. If someone sends a low effort question, I might politely tell them to rtfm. If someone makes an effort to articulate a problem, even if I disagree, I’ll try to give them a reasoned response. And if I genuinely have no interest in any inter…

So you agree that there is no obligation, then assert a set of social obligations that should be respected. Do you see the contradiction here?

You are simply being pedantic.

He said there's no "absolute" obligation, but there are some by virtue of us living in a society.

Re: It’s OK for your open source library to be a bit shitty (2015)

#123

Earlier quoted context omitted.

Literally what it says: https://github.com/left-pad/left-pad/blob/master/index.js Now if you ask "but why?", ultra-small packages like this are popular in JS because of the lack of a standard lib. Lots of devs prefer to install a dependency for each one-liner utility rather than write them themselves. The only added value of those packages is that they're usually unit-tested against weird edge-cases that you might mi…

The smaller the library, the better.

The less there are dependencies, the better.

Re: It’s OK for your open source library to be a bit shitty (2015)

#124
post #56

But when potential employers come looking at your work they'll say "hey this code is shitty! It's not a work of art with 100% code coverage tests and perfect in every way. We can't possibly give you a job. Every line of code in our corporate repo is Mona Lisa quality, we can't let rubbishy developers like you in."

Since there are comments refuting you, I'll provide an anecdote the other way. My coworkers absolutely do this to every single potential interviewee. On multiple occasions I've had to talk them out of not wanting to even interview based on one random file in a random repo by the interviewee. Because of this, when I start applying I hide all my repos that I'm not mostly proud of.

Haha, admirable but I love employers like that. When they proactively remove themselves from the process without intervention from me we've made selection so much more efficient.

I wouldn't want to work there and they would have saved me so much trouble.

Bad GitHub code means nothing. Good original GitHub code means something. And the less these orgs realize that the easier it is to get engineers that are otherwise unappreciated.

Re: It’s OK for your open source library to be a bit shitty (2015)

#125

Earlier quoted context omitted.

I’ve evaluated GitHub profiles and contributions in the past. As long as there’s a body of work with reasonable complexity and no big red flags like a nasty argument or a bug-riddled PR, I consider it a positive signal that they can code. I specifically look at their opened issues and PR’s, rather than their commits, as a way to gauge their ability to code in a team setting. I won’t try to guess how good they are at…

I'm pretty cynical about how any code evaluation is done. Amongst the many many ways code evaluations fail, the worst and most typical IMO is that the evaluator has an air of superiority, who marks down things they don't understand, and thinks their own coding is that of an artistic genius, approaches the tasks with zero science or rigor and is unable to articulate anything hard to back up their vague assertions comi…

I like giving a cursory glance at candidates github profiles mostly to see what they're interested in, if they participate in open source, things like that. The particular "quality" of code is imho relatively irrelevant.

Besides normal open source contributions and semi-maintained side projects my own github for example is full of one off scripts and weekend project repos that are interesting for an average of NIn most domains I've worked in other parts of the CV and public presence are far more informative about a candidate, shoehorning pseudo-scientific metrics about code or test quality on candidate's github profiles seems counterproductive. People have other things to do in their life than maintaining recruitment-friendly github profiles, expecting one is not much different to the odd practice of unpaid take home exercises imho.

Re: It’s OK for your open source library to be a bit shitty (2015)

#126

Earlier quoted context omitted.

I have a pretty simple project with 2.4k stars, and have met nothing but good people eager to help, and bending over backwards to help me help them. My project's "niche" may have something to do with it.

Application domain may have something to do with it, language also. As a maintainer of Javascript and Ruby libraries, the difference in entitlement and cluelessness is remarkable.

The Ruby community has always struck me as friendly and welcoming.

Re: It’s OK for your open source library to be a bit shitty (2015)

#127
I agree with this to the extent that "open source your library" means "publish it on Github". Adding it into a package management system, be it one for a language or one for a Linux distro, is implying some level of stability and functionality. This is especially true if you choose a desirable namespace for your project on a system that doesn't differentiate by username.

Essentially; do publish all work you possibly can, simply be clear about what the software does or does not do.

I am very guilty of not doing this myself. I throw together some bit of code that is useful to me, and dump it on github with no explanation of what it does or how to use it.

As a bad example, I'd encourage everyone like me to put in a bit of effort to explain what your code does, so that when someone stumbles across it they have a way to give it a try and see it doing something.

Re: It’s OK for your open source library to be a bit shitty (2015)

#128
post #44

I've used and been the maintainer of a "shitty" open source window manager off and on for the last 10 years. I love the project. People at my last few companies joke about it. But it's so fun. Who cares if it's shitty. Ride bikes and write code.

Some of my favorite memories of open source involvement have been contributing to that "shitty" project. Thanks for helping to keep it going!

Re: It’s OK for your open source library to be a bit shitty (2015)

#129
post #5

As the author of shitty open source libraries I agree, but a bit of a disclaimer in the readme should be expected.

> a bit of a disclaimer in the readme should be expected Every project already has these. They're in the license files. > This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This disclaimer is clear, self-explanatory, legally binding and a standard feature of all licenses. So why do people a…

> So why do people assume they can use random code from random developers they never met without even looking at the source code?

Because that's open source, and has worked well for a lot of things.

Re: It’s OK for your open source library to be a bit shitty (2015)

#130
So, we like to have some clickbait on the front row? Ok. I have a few more.

PHP: it is OK to be a bit shitty. Javascript: It is OK for your type system to be a bit shitty. Javascript: It is OK for your semantic consistency to be a bit shitty. Java: it is OK for you syntax to be a bit shitty. Java: it is OK for your value semantic to be a bit shitty. MongoDB: it is OK for your design decisions to be a bit shitty. node_modules: it is OK to be totally shitty.

I could go on and on.

Post reply on HN