Resume

Endnotes

1 I recommend to read my article on problems first. Problems that are extremely large in the context of their scope, number of requirements or interleaving of requirement. I think back to building a lab data system from machine to storage to application to metrics for the Cathode Lab in Tesla, or building up pouch cell analysis from scratch. problems like this are also analytic in nature, meaning that only time spent or sweat drawn won't solve them, but skill, focus, and precision will. I am extremely talented at these kinds of problems, with the caveat that I sometimes fall into the trap of adding scope to feed my need for it.

2 There are two types, known unknowns and unknown unknowns. Being aware about how either affects your problem space is paramount to being a great engineer (and human). Known unknowns are those you know that you don't know. What I recall is learning material science from first principles at Tesla, since I went to school for Chemical Engineering from UC Davis, which has become my main work and career interest. Or how I knew that building a data sytems is not just full-stack development (something I knew well from my time at Libretexts) , and that understanding how docker/k8s or airflow works etc. is needed (tools I now wield like weapons).

Unknown Unknowns are just what you think, and only in hindsight can we realise they gravitated us towards certain requirements or issues. A great mentor of mine once said that

Growth is experience times analysis.

This tells us that you can shrink the universe of these invisible constraints by reflecting on your solutions or results. You can reflect even during a sprint. To implement better and better solutions, I would ask my self:

What is the problem I am trying to solve? Is this actually a problem-has it been solved before? Do the requirements go on ad nauseam-rendering this problem meaningless? My approach to unknowns is how I did so much at Tesla.

3 This is the one-two punch of my career. Computer science is a truly amazing thing, one we don't appreciate enough. By way of operating system and compiler we can engage with anything we can imagine, without worrying about physical resources nor socio-economic limits.

I learnt much of computer science through the use of textbooks (the older the better: The Dragon Book, SICP, The Dinosaur book, Computer systems, etc.) or on the job at LibreTexts and Tesla. In fact most of my career has been decomposition of problems into functions that then compile to a solution. I am grateful to so many technical mentors in this domain, who ensured I wrote beautful code and understood things from first principles. As another mentor told me:

First principles effectively means adhereing to correctness to a field.

I took this to mean that if you can develop patterns from the most beautiful solution, and think critically and precisely about how any sub-structure of that pattern structure can match to another problem, you do not need to be taught the answer, you can derive it. I am excellent at computer science, because I am excellent at first principles.

The major limit to computer science, and why I avoid making it 100% of my time, is that there is no physical product at the end. Your reward for writing better software is sometimes just more abstraction.

Material science, and more explicitly informatics or material-computer science, solves this by challenging you to come up with better materials or pathways using computational rigour. Although not studying material science, its draw (working in a lab, processing a material with my hands, fabricating cells to test them) was seductive enough that I pattern my career around this field. I respect computer science as technical art, and a function of material science.

A final thing to note is I use science as the suffix, but I do treat myself as an engineer. In the sense that I define a problem space, and specifty requirements, interating on those for versioned products. I am serious about engineering, and serious about science something few are in the non-academic sector.

4 Burnout is a myth in the way we currently understand it. It is not that the more you work you will hit a wall, for which you will need a period of rest. If you are truly aligned with the purpose of you work and that work (or type of work) is a subset of your vision, you will not burnout. Burnout is a lagging indicator. I, working three years at Tesla, being promoted four times, and now staff at Periodic Labs, have only become more energised and passionate about what I do. I do what I do because it is exciting.

5 The best way to contact me is by email, the header of my website should have it. You can also find my linkedin, though I won't link it. If you know my name you can find it. I wish you the best, and remember that It's all possible, truly it is.