I think that one very underrated skillset is the ability to implement a data structure or algorithm on top of an existing platform. For example, can you implement reservoir sampling and a state machine on top of SQL? If you can, there's a good chance your Hadoop analytics cluster can be replaced with a single DB instance and a work-queue system. Can you implement a graph algorithm on top of MapReduce? That's how Google's Pregel system got started. Can you implement a diff algorithm on top of the DOM? React. Three-way merge on S3? DropBox. Binpacking over Linux containers? Borg/Omega/Kubernetes.
Spot on. This sort of out-of-the-box thinking is definitely one of the most important things in the career of an engineer.
- unavailable (in a permissive license in) the platform you're currently using.
- available with an unsatisfying implementation.
If you're lucky, your employer will allow you to contribute to open source during your working hours so other developers won't need to re-implement it.
Now, if the question is about whether I needed to come up with a totally novel data structure at the office, the answer is no in my case.
For example, rather than import some all-things-to-all-people, infinitely scalable graph theory package, sometimes it's better to just spend 45 minutes writing a simple vertex-to-vertex map (to provide a piece of functionality that you know won't change).
Heck, sometimes it's even substantially quicker to roll your own data structure than go searching for a mature library that claims to provide it (and evaluate whether it's really properly maintained or won't otherwise impose technical debt on your project). What's key is knowing when to make that judgement call, of course.