I put a lot of work into doing the last 10% for a project recently, and I'm not convinced yet that I'll be getting anything out of it, other than my own satisfaction. After my colleagues and I got our paper (on real-time depth estimation with an event camera and a laser projector [0]) accepted at a workshop, we could have just dumped the convoluted, messy research code on GitHub and be done with it. For other people to figure it out, if they really cared.
But I sat down and completely rewrote all the scaffolding around the presented algorithm, to make for a smooth and fast demo. Wrote up documentation for the implementation, gave it a command line interface, set up a script to reproduce the measurements in the paper with a single execution (downloading the required data and comparing several methods). Broadcast in all channels available to me (institution press release, LinkedIn posts, GitHub awesome list linkings). And I actually brought the demo to the workshop, which wasn't required at all, I could have just presented it as a poster.
The feedback of the people seeing the polished demo was fantastic, but now I'm sitting here with my 5 GitHub stars on the repo, after I put like 2.5 extra months of work into it. Maybe it led to more people noticing it, and finding it useful. Maybe not.
Getting stuff out there to be noticed is difficult, a lot of work, and going the the last 10% does not guarantee any more success.
I work in the cloud consulting department at BigTech. We have a very straightforward open source approval process where we can open source any code (MIT-0) that we write for a client as long as we scrub the business processes and anything proprietary to the customer.
It does take some work (not two months) to sanitize the project, write documentation, put the boilerplate open source documentation and go through the approval process.
I’ve released 8 projects to GitHub using this process over 3 years and collectively may have gotten 15 stars in total. But the way I see it, it’s a great portfolio and the only chance in my career that I could actually show production code from work I’ve done professionally along with my resume.
Also, how many times have we changed jobs and had to solve the same problem from scratch because we couldn’t legally or ethically use code from a previous company? This solves that problem too.
Your work represents you. Even if no one stars it, you now have a portfolio of work you can be proud of that you can point to when you’re interviewing instead of yet another to do app.
I don't know. I don't think people actually care. Maybe I'm a cynic, maybe I'm jaded. I've sat through a handful of interviews after submitting a resume with links to my GitHub profile, links to my (former) co-founded startup, the parents we received for our work, the projects I painstakingly polished before open sourcing, etc... At the end of all of that, I can recall exactly 1 person who even casually mentioned this stuff. He ended up being a manager and he would sometimes bring it up as a point of conversation with others on our team but it never found traction. My conclusion is simply that exceedingly few people (in the wild) give a shit about this stuff. Probably other like-minded folks.
I totally agree with you. Nobody gives a fuck. I sweated 6 months on my CS Masters thesis. After the day of the presentation, I walked up to my Professor's office. As per the rules, you are supposed to hand a printed copy of your thesis to your thesis advisor. So I handed over the printed thesis proudly. Then we chatted, I said my goodbyes & left. In those days we had no github internet etc. All the C++ code for my thesis was on a 5 1/4 floppy. When I reached home I found the floppy. I was like, God I've forgotten to give him my code! So I picked up the floppy and trudged back to the university. Then I walk up to my advisor's office again & knock on the door. He is ofcourse surprised to see me. I say - Sorry I forgot to give you my code. Here is the floppy. I'll put it next to my thesis. Where is my thesis ?
He doesn't say anything. I look around to see if my thesis is on his bookshelf, but no, it isn't there. Then I turn around & I find my thesis. It is in his trashcan. I was so stunned & shocked. My advisor says sheepishly - look its just a Master's thesis. Its not like you have discovered a new theorem or something. These results are well known in the literature.
I just put my floppy in that trashcan and walked out. Its been more than 2 decades now but I still remember that incident like it was yesterday. Literally, nobody gives a fuck.
That's a pretty gutting experience; I'm sorry for you. But especially with the internet, the are people who value Masters work. I sent an email thanking someone for their thesis, and mentioning that I had added it as a citation on Wikipedia, but I didn't get a response. Maybe there is a vicious spiral of apathy towards undergraduate and early postgraduate work.
> I was so stunned & shocked. My advisor says sheepishly - look its just a Master's thesis. Its not like you have discovered a new theorem or something. These results are well known in the literature.
The gesture is unfortunate and I understand that you were shocked. I'm curious if your view of it changed with experience however?
I mean, unless you actually discover something great - which very rarely happen, is frankly exceptional and would probably lead to a paper on top of the actual thesis - a master thesis is mostly something you do for yourself. The point of doing it is what you learn durint the exercise. It's not really intended for being read outside of your jury. An advisor might keep a few good ones to give as reference to future students but that's pretty much it.
Hopefully, your advisor actually gave a shit when he was advising you. That's where he could have been valuable.
I worked on my master's thesis quite a bit, even worked on submitting a publication (it was in control systems and was only rejected because they wanted more empirical results). The stuff was extremely groundbreaking - we were able to get 2 orders of magnitude of better performance compared to existing solutions.
Fast forward to a few weeks back, when I was talking with a process team at a multi-billion dollar biotech company (yes, it's a huge) somewhat casually, when that idea cropped back up. Their response was basically "meh, we really don't need that much higher performance".
I'm sure if I were to start up around this, I would be able to get enough funding from the recent AI rounds from VCs. But I wouldn't have customers willing to buy this in the first place! I would be like the proverbial solution looking for a problem to solve.
I always look, and I'm always happy to see something meaty enough to actually talk about in an interview.
Somewhat to my surprise, I've found that at least 90% of candidates who include a GitHub username, when I go look at their repositories, either have nothing but unmodified forks of existing open-source projects or obvious "go through the tutorial for technology X" projects. I can totally get how, after seeing that kind of thing ten times in a row, people might give up looking.
But I still always look, both at the person's public repositories and at their contribution history in other public repos.
Precisely this. I often check GitHub profiles if a candidate provides them, but I have the same experience. It's often times completely empty, or just a half-finished tutorial. Once it looked like a really active developer (like commits on almost all days), but that was from a repo with generated commits to make the GitHub contribution history look nice... not actual work.
Tip: If you're applying and want people to look at your repo. Mention this in either your cover letter or on top of your resume. If it's empty, better to leave the link out altogether.
I’ve open source something from every project I’ve done at work since I’ve started my current job. Again - after going through the open source approval process.
So I’m thinking about with each major bullet point of what I did in STAR format, I’ll have a footnote to the open source code that came from it
Yeah come on just throw it on the CV if you are proud of it. Expecting the interviewer to actually click through your GitHub account and figure out what you did is additional work for them.
I am at a point in my career that aside from my current company, I haven’t done a traditional submit my resume and interview in years. Even this job kind of fell into my lap without me seeking it out.
My prior two jobs came from knowing someone who knew someone looking for my particular combination of experience and meeting them.
I’m not saying I’m a special snowflake. But I’ve previously been hired for more strategy/architect type positions where the CxO or director wanted someone who was vetted.
12 years ago I was interviewing for a job and I was surprised that it didn't include any coding bits, only a few light technical questions on the first interview.
When I asked for this I was told they had looked at my GH account and that it was clear that I had the skills they needed. That was nice.
Something similar happened on the job after that.
But in the last two gigs I had to do a coding exercise and I was a bit disappointed that my GH didn't seem to have an effect.
The difference? In the last two jobs the companies were big organisations, with a clear interviewing process, and the technical interview was on hands of almost random engineers that could even not be part of the team I was joining.
When I have been involved in the process, I always look for public open source code. So far I have never had a candidate with an active GH account.
Personally, I have been happier working with the people that cared about these things.
Can you explain why people should care? I get a guy who is not well adapted socially, who thinks he is the best thing to ever walk through the door and I know he’s going to be a short-lived nightmare for his sup and potentially for HR. A GitHub portfolio doesn’t change the fact that it’s already a broken deal.
On the other hand, I get a guy who I can see is optimistic, friendly, humble, hungry etc and know I’m going to be happy to give him his raise every 6 months. He will be a good employee which is only really 10-20% about his skill. If he gets through our technical interview then why would I even bother looking at his repos? A homemade stupid flashy website tells me he has a rudimentary understanding of computers, he’ll figure out the rest if he doesn’t know it. Are these applicants going through my history or my companies history, painstakingly preparing questions about something tangentially related to their position? I hope not, there is simply too much movement to expect anyone to care that much.
> Can you explain why people should care? I get a guy who is not well adapted socially, who thinks he is the best thing to ever walk through the door and I know he’s going to be a short-lived nightmare for his sup and potentially for HR.
You shouldn’t care in most cases. I wouldn’t care. I hadn’t had any open source contributions since 1994 when I submitted code to the ftp info Mac archive until 2020. The only reason I have any now is because I get paid for it.
> On the other hand, I get a guy who I can see is optimistic, friendly, humble, hungry etc and know I’m going to be happy to give him his raise every 6 months. He will be a good employee which is only really 10-20% about his skill.
Are you going to do a strategic hire who only has 20% of the skill you are looking for? Are you going to hire him as a team lead? Someone leading a major new initiative without having proven industry skills?
> A homemade stupid flashy website tells me he has a rudimentary understanding of computers,
And that’s why I don’t do coding outside of work. Every piece of code I have on GitHub is running at a company somewhere and they paid my employer to use it. I more than likely spent hours on calls gathering requirements, vetting the design, teaching them how to use it, etc.
I've had some really good experiences as a candidate, since my GitHub has a couple repos that are actually used by people and have some stars. I've even had an interviewer tell me he had used one of them before, that was nice.
As for hiring for my team, the results are unfortunately much less useful. The vast majority of GH repos are completely useless, half finished tutorials or some long abandoned project.
Sometimes I have found some really interesting work though, and this always earns the candidate an interview from me.
But I agree that I'm in the minority, most other senior developers or managers don't care about it at all. And I've never had a recruiter mention it.
I think you're probalby right. There's no way to know that a github repo represents the actual work of the applicant. References from former employers/clients are going to be the main thing I would care about.
As someone on the hiring side, Github projects only matter when they show impact via serious industry adoption (this is not sufficient, leftPad won't get you hired).
The problem is that a Github repo is too much time an effort to evaluate on technical merits. And even if the work is good, how fast can you do it? Some people turn out good work at 1/3 the rate their peers, I don't want to hire them. Between other parts of the evaluation I can give the repo 30-60 minutes max, just not enough time.
If I were looking at a Github portfolio, I would be more concerned about reading their documentation. I want to know about their communication skills and why they think their code matters. What problem were they trying to solve? Even if it was to scratch an itch that they had and only three people including themselves ever use it. What was their motivation for doing it?
I find the signal from this is still too low for it to be worth looking into. Quality of documentation has a lot to do with:
1. Correctness
2. Matching the content to the intended audience
I find that in general I have no time to check correctness, nor is it obvious who the intended audience is. A blurb and basic setup instructions is fine if the intended audience is the author. A tool intended for a particular set of power users may not require motivation. The author may well know how to write more accessible documentation and chose not to for a sensible reason.
I kind of yada yada yadad over what I actually do.
My last two jobs before my current one and probably my next one aren’t really based on traditional submit my resume and interview. It’s based on networking and now mentioning “check out my GitHub profile” when you get a chance.
From my time on the hiring side, I was looking for passion. Side projects, githubs, etc all showed passion and. It wasn't the github project itself, it was the passion. That's what made the hires.
So keep doing it and talking about if it's your passion. Don't do it if it's forced. It's the passion that stands out and humans can tell if someone is really passionate about something or not.
Fwiw, 90% of the time when I visit a cool package I don’t interact with the creator at all.
If you do want nice notes, solicit them in the readmes. “If you see this, send me a note at foo@bar and tell me your thoughts!”
I rarely email a random person my random thoughts unless I have a smart question or bug report. Maybe only once have I sent a thank you this is so interesting email. Don’t want to bug people.
On the opposite end, two of the jobs I’ve had in the last ten years noted that they saw my emacs config (one interviewer admitted to borrowing from it) and I’m pretty sure it had a positive impact on my prospects.
For every person starring the repo there will be an unknown number who found it useful but aren't using GH stars or forks.
Consider that if you hadn't gone the extra mile, your work would with 99% probability never be useful again (I say without having seen it). Now it may be a shoulder for someone to stand on to make even greater things than they would otherwise be able to. This could be in several years, when your own attention is in a completely different space.
I'm one of those unknown readers with no stars (why would I add to the inflation of tokens of already little worth?) and forks (why would I clutter up my forks with projects I can't meaningfully contribute to?) - but I am a prolific bookmarker of interesting projects! Those often end up pasted into IRC or Matrix channels where there is interest in later years, potentially multiplying the impact of my initial visit 10x or even 100x, inspiring future contributors or new projects.
It might not be in vain, but it can often be a poor balancing of priorities. The last 10% can easily require as much work as the first 90% - perfection is expensive.
If your reason to perfect something is internal (high personal standards and taking pride in your work) then great - take the opportunity cost in stride and finish something you'll be satisfied with. But if it's external (eg. making it just that bit more impressive to others) I'd say usually your time would be better spent moving on to the next thing.
I'm not entirely in agreement here. While there was undoubtedly some internal motivation at work (as publishing subpar code just doesn't sit right), I believe a significant portion of it was external, and I don't see that as a negative. During the polishing phase, I had two primary goals: first, to lower the entry barriers for people who wanted to try it out, and second, to expand its capabilities as much as possible (e.g., enabling it to run on a laptop rather than a high-powered desktop, without any frame drops). I view this less as an attempt to impress others, and more as an effort to enhance utility and thus broaden the potential user base.
I do see the tradeoff between spending more time discussing the project vs perfecting its technical aspects though. This can be tough for us techy folks who don't really like evangelism. In this respect, I believe academics and technical founders face quite similar challenges.
On another note, the feedback in the replies here has been incredibly uplifting, and I want to express my sincere gratitude for that.
Just wanted to say, you have benefitted a lot from the last 10%.
In the future, when you're bootstrapping a project and building scaffolding, you know what the 100% looks like and feels like, which means you're going to do a much higher quality job on the first 80-90%.
The first 80-90% of your future projects will be smoother, faster, and more likely to bring you success.
Sports analogy: by practicing your swings 100 times instead of "until I got my first on-base", you're investing in your future RBI and OBP, which is more valuable than any individual hit today.
That last 10% generally has long payoff. The rewards of that paper feel immediate, but the code on GitHub will be useful to people for years. (The paper also has a long payoff. It also a short, which GitHub didn’t here.)
> Getting stuff out there to be noticed is difficult, a lot of work, and going the the last 10% does not guarantee any more success.
This is true. It’s still a bet. It could have wildly high expected value and still turn up a 0. But doing nothing guarantees you won’t have more success.
You did that 10%, making your research easier to reproduce and your technology easier to use. I am going to bet that in 15 years, when you've long since moved onto other exciting things and forgotten the details of the state-of-the-art circa 2023, you'll come back to your earlier work, be it for nostalgia or comparison, and be one of those who will benefit from that extra documentation and polish :)
Sure, they're just silly internet points. Yet, after heading back from the conference, they're the only immediate, tangible pat on the back that's left. It'll be a while before the first round of article citations start rolling in. So, seeing HN readers drop by the repo and leave the tiniest note by starring it did bring a few smiles to my face.
Sadly GitHub stars do have meaning to people who make decisions about which code library to add to their current project. And to people who review libraries that tackle a specific sort of problem, whose articles then get read by people who need to make decisions, etc. Such people may also use other metrics - recent activity, number of contributors, etc - to refine their judgments, but I've seen too many examples of "must have at least 1000 stars" used as the main justification for a decision. It's sad that the world is the way it is, but I doubt it will change anytime soon.
If there's one change I'd like to make to GitHub, it would be to make the value of a starring decay over time. But I'm sure even that could be gamed.
> Getting stuff out there to be noticed is difficult, a lot of work, and going the the last 10% does not guarantee any more success.
If your benchmark is number of stars on Github, then yes, things might get depressing when "JS toy framework number 45" easily gathers hundreds of stars.
But, personally, I have half a dozen reasonably polished projects on less trendy topics. While not huge, I know they were useful to other people. Some are packaged in linux distributions, others I've got requests for improvements, or were used as cross-reference for concurrent implementations, or were forked and continued a life of their own.
It's not huge, but by spending ~30% more time on things like documentation, tests, proper build system, a post here or on Reddit, I've enabled these projects to be more than an unapproachable pile of code.
And if it saves even one person the effort of implementing these projects, that's a result well worth the ~30% more effort for polishing the project in my book.
Lastly, users/interested people are often not developers. Personally, I have two websites related to a video game (one displaying some stats, the other being a loot box simulator). Both projects sit a 0 star on Github, but the access logs tell a different story, there has been thousands of (non-bot) visits since both went live, being useful to quite a few players of this particular game.
It's hard to measure impact, but it's extremely easy to underestimate it.
> The feedback of the people seeing the polished demo was fantastic, but now I'm sitting here with my 5 GitHub stars on the repo, after I put like 2.5 extra months of work into it. Maybe it led to more people noticing it, and finding it useful. Maybe not.
Those 2.5 extra months could save orders of magnitude more (for users) if it does find success. The problem is those 2.5 months often don't translate into higher likelihood of success.
Well a comment is worth perhaps only an epsilon. But since you can always write another comment, the project will never be at 100% - only in the limit.
If you're a researcher from academia applying for a job in my team, the quality of your GitHub repo makes a huge difference in how you are perceived before we even talk to you.
If you believe in your work and would like to see someone build upon the results, having clearly reproducible results also makes all the difference. Most of the time, you won't even know that people are trying out your code/model/whatever, and friction in the onboarding often means that they will move onto something easier.
If you bound the last 10% and avoid scope creep, I am all for investing the time.
I wrote about my motivations in a different comment. To be honest, I didn't harbor any particular expectations. Maybe a flicker of hope for a bit of feedback or interaction from someone who'd given it a go, be it results, queries, or issues.
Maybe I should have kept my expectations in check, considering not many labs will have the setup ready to go, let alone have the inclination to dabble with it. But that was a step I didn't consciously take.
There's an uncanny silence from the world when you've thrown so much of yourself into a project, and you're the only one to care about it. It really shouldn't catch you off guard if you're thinking about it rationally, especially if you're not regularly communicating about the project for more people to notice it. But it still doesn't feel great.
You use the academic term "we" when it should be "you" or "you can". This immediately signals to the reader that unless they are a researcher the product is not for them.
But I sat down and completely rewrote all the scaffolding around the presented algorithm, to make for a smooth and fast demo. Wrote up documentation for the implementation, gave it a command line interface, set up a script to reproduce the measurements in the paper with a single execution (downloading the required data and comparing several methods). Broadcast in all channels available to me (institution press release, LinkedIn posts, GitHub awesome list linkings). And I actually brought the demo to the workshop, which wasn't required at all, I could have just presented it as a poster.
The feedback of the people seeing the polished demo was fantastic, but now I'm sitting here with my 5 GitHub stars on the repo, after I put like 2.5 extra months of work into it. Maybe it led to more people noticing it, and finding it useful. Maybe not.
Getting stuff out there to be noticed is difficult, a lot of work, and going the the last 10% does not guarantee any more success.
[0]: https://fraunhoferhhi.github.io/X-maps/