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…
It’s OK for your open source library to be a bit shitty (2015)
121–130 of 364 posts
Re: It’s OK for your open source library to be a bit shitty (2015)
#122Earlier 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?
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)
#123Earlier 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.
Re: It’s OK for your open source library to be a bit shitty (2015)
#124But 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.
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)
#125Earlier 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…
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)
#126Earlier 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.
Re: It’s OK for your open source library to be a bit shitty (2015)
#127Essentially; 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)
#128I'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.
Re: It’s OK for your open source library to be a bit shitty (2015)
#129As 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…
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)
#130PHP: 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.