I think if you applied the Postel's law conventionally to this function, you wouldn't end up with either variant discussed in the article but with an entirely different one.
The function in this case would accept a possibly empty list and always return a list item. You would achieve that by essentially weakening the type system, for example by returning a zero initialized value or some placeholder value (NaN, nil, Infinity, "", 0, undefined, Object, interface{}, {} etc.)
Essentially you would disguise an inconsistency, which leads to what the Wikipedia article discusses under "Criticism". In my own words: a "bug is a feature"-system of patched-overness.
I much prefer the 'fail-fast' mantra (example: Erlang community).
If I remember correctly there was a statement in this book like (paraphrasing): always search the bug upstream.
Combining this debugging principle with the above: If your program fails earlier then you end up searching less because the failure condition is already pushed upstream.
If you push the variance downstream you possibly end up with a proliferation of error handling, workarounds and types.
I recommend this book, “Debugging”, by David Agans: https://amazon.co.uk/Debugging-Indispensable-Software-Hardware-Problems/dp/0814474578
I enjoyed reading it, even as a veteran software engineer - it should be required reading for all new programmers IMNVHO.
I have a set of rules that I follow when debugging. They are mostly common sense but knowing that you have a written strategy to follow helps avoid panic.
One of the rules is "Get a fresh view". There is no shame in getting someone else to take a look for you. If you have exhausted the other 8 rules then you'll know it's time to ask for help.
1) Describe in detail what it is doing.
2) Describe in detail what it should be doing.
3) Re-read the docs to make sure you haven't misinterpreted them.
4) Start investigating what its components are and find which ones are behaving the way they should and which ones are not. Trace the flow of data through the application. Use logging/printing to see where the data is/isnt what you expect. Narrow down the space of possible components where the problem is.
For more on this skill, read this book: https://www.amazon.co.uk/Debugging-Indispensable-Software-Hardware-Problems/dp/0814474578
To more usefully answer this question, we'd need to know what sortof things the company does.
The only two things that are generalizable are source control, debugging, and technical/project communication skills.
If you are doing web development, it really helps to have a solid mental model of SQL. Django and Rails kinda let you pretend you don't need to know about it. But, even if you have only 100s of users, you quickly run into meaningful performance problems ^(or at least I did at my 2nd job...) that are easily-avoidable if you have SQL in mind when you're writing things.
These videos from a stanford course are solid. Skip XML but don't skip Relational Algebra. You'll never use Relational Algebra directly but it will make everything else fit into your memory so much better.
Programming is a skill. It can be used for many jobs, including software engineering, data science, business analyst, etc. Many people come to university having already taught themselves the basics of programming. This presents a problem for folks designing a CS curriculum: Programming is a skill necessary for understanding and completing many of the assignments in a CS program. However, if you spent the first half of CS101 on teaching the basics of programming, it would bore 30-60% of the class. So what schools will often do is have a separate class to teach programming that folks without that skill can take before they then take CS101.
Should you just wait to take that class? You could, but in university, about 40%-90% of what you learn in a class in university is actually self-taught. In CS classes, it is 65-90%. In the specific intro-programming class I TA'd over my university's January term, it was 90%. So my recommendation is to go download this free book and work through it.
Does a CS degree make you a better programmer? Yes. ^(well, if you take advantage of the resources of the program.)
1) You get practice with different styles of programming.
2) You learn concepts that help you design your code in ways that make it more clear, robust, and maintainable.
3) You learn concepts about system design that you then apply by writing programs. This doesn't improve your programming skill strictly, but does make you a better engineer, statistician, or designer who works with code.
However, there are a set of Software Engineering skills that CS programs can often be bad at teaching (though they occasionally make valiant sometimes even successful efforts), specifically around project management, communication, and the details of debugging. For debugging, I recommend that whenever you learn a new language, acquaint yourself early with tools for automated testing and interactive debugging. In python, check out pdb and py.test. More generally, this book is fantastic. These tools are also helpful for learning. For project management and communication.... well I'm actually thinking up some questions to as on this very forum...