13.8 Kaggle and open source

What this is and why it exists

Everything else in your portfolio is work you did alone, on problems you chose, to standards you set. Public evidence of working with other people's code is what separates "learned alone" from "can work on a team", and employment is mostly the second. A finished competition, one merged contribution and something small you maintain: three artefacts, none of which require you to be exceptional, all of which require you to start — and the barrier is administrative courage rather than skill.

The vocabulary

• Leaderboard — the public ranking of a competition's entries.
• Public notebook — a solution somebody published for others to read.
• Pull request — a proposed change to somebody else's repository.
• Contribution guide — the file saying how a project wants changes proposed.
• Good first issue — a label marking work suitable for a newcomer.
• Maintaining — being the person who answers when somebody has a problem.

The mental model

Work one competition through to a real position, and the position matters far less than having finished.

What you learn is not modelling. It is iteration under a hard measure: the leaderboard does not care about your reasoning, so every idea is tested rather than argued, and the gap between what you expected to help and what did is the education. You also learn validation the hard way — the difference between your local score and the leaderboard score is the most instructive number in the exercise, and it teaches leakage and split design more convincingly than any warning.

Two rules make it worth the time. Finish: submit, iterate, and stay to the end, because most of the learning is in the last stretch where the obvious ideas are exhausted. And build your own validation before looking at anybody's solution, since the whole lesson is in whether your local estimate predicted the public one.

Reading public solutions is where most of the competition's value actually sits, and it is under-used. After the competition, read the top solutions and — more usefully — the write-ups explaining what people tried and abandoned. You will find techniques you had not met, feature ideas nobody would invent unprompted, and validation schemes better than yours. An afternoon reading solutions to a competition you worked teaches more than the weeks of working it, because you now understand the problem well enough for the solutions to mean something. Reading them without having tried teaches much less.

Note also the honest limit: competition technique is not production technique. Enormous ensembles that win by a fraction are not deployable, and knowing that difference — and saying so — is itself a signal of judgement.

A first contribution to a library is the artefact that most changes how you are read, and the barrier really is administrative rather than technical.

Legitimate first contributions, in order of accessibility: fixing documentation that is wrong or missing, which every project needs and nobody wants to do; a good bug report, which is genuinely a contribution — a minimal reproduction, the versions, the expected and actual behaviour, and what you already tried; adding a test for an untested path; fixing something labelled for newcomers; and only then a small behaviour change.

Documentation fixes and good bug reports are real contributions. People wait until they feel ready to fix something significant, and that day does not arrive, while the small useful thing was available all along.

What the exercise teaches is what employment mostly consists of: reading unfamiliar code well enough to change one part safely, working to somebody else's conventions rather than your own, writing a change small enough to review, responding to review comments without defensiveness, and being patient with a maintainer's timescale. None of that is on display anywhere else in your portfolio.

The procedure: read the contribution guide before anything, because projects have specific expectations and ignoring them is the commonest reason a first attempt goes nowhere. Open an issue and ask before writing a large change. Keep it small — a large first contribution is hard to review and frequently declined for that alone. Run the tests. Write a description saying what and why. And expect it to take longer than you think, and expect review comments, because both are normal rather than a judgement.

Maintaining something small of your own shows a different capability from building one.

Building is a burst of attention on your own terms. Maintaining is somebody else opening an issue about a case you did not consider, on a platform you do not have, and your responding — reproducing it, deciding whether to fix it, saying no kindly when it is out of scope, keeping the thing working as its dependencies change.

Responding to somebody else's issue is the part that counts, and it is what an employer is really asking about, because it demonstrates that you can look after something rather than only start it.

It need not be large. A small tool that does one thing, a wrapper you found yourself rewriting, a dataset with a proper card and loading code, a scaffold for the pipeline you always build. What makes it count is a README somebody can follow, a licence, working installation instructions, and a response when somebody writes. A repository with three stars and two answered issues says more than one with a hundred stars and an unanswered inbox.

Then the trap, which is the reason this topic ends the module. Waiting until you feel ready is the failure mode, and it does not resolve on its own — the field is large enough that you will never feel ready, and the people contributing are not more certain than you, they started earlier.

So set a date rather than a standard. This month: one documentation fix or one well-written bug report. Next month: finish a competition, however you place. The month after: publish something small with a README and a licence. Each of those takes an evening or two, none requires you to be exceptional, and together they are the evidence nothing else in your portfolio can supply.

What you should now be able to explain or do

Work a competition to a finish and say what iteration under a hard measure teaches. Build your own validation first and read the local-versus-public gap. Read public solutions after competing, and say why that order matters and where competition technique stops being production technique. Choose a legitimate first contribution, including documentation and a good bug report. Follow the contribution procedure and expect review and delay as normal. Maintain something small with a README, a licence and answered issues. Set a date rather than a standard.

Check yourself