Remote: Open to remote, hybrid, and in person

Willing to relocate: Yes

Technologies: C, C++, Fortran, Java, Message Passing Interface (MPI), OpenMP, Python (Matplotlib, Numpy, Pandas, Scipy), SQL (especially SQLite)

Résumé/CV: Available upon request

Email: https://www.andrewtrettel.com/hnjobs.png (to prevent spam, my email address is in the linked image)

GitHub: https://github.com/atrettel

Website: https://www.andrewtrettel.com/

Hi, I'm Andrew Trettel. I'm a scientist with a PhD in mechanical engineering looking for any potential opportunities outside of academia and research labs.

I am open to many different roles, including being a software developer or data scientist. I have over a decade of experience in scientific research, especially on the numerical side. I have years of experience in writing software for and running large simulations on high-performance computing (HPC) systems. I have also developed software for non-scientific purposes, like creating user interfaces for desktop applications and writing command-line tools. I have extensive experience using commercial and noncommerical computational fluid dynamics (CFD) codes. I have years of experience working with large datasets, including the tasks of calculating statistics and developing hypotheses/models/theories from data.

I've worn many hats over the years and love learning new and interesting topics.

In the short term, I have seen a lot of managers and other higher-ups talk about how we do not need to worry about low-level details anymore. In their minds, we are now all designers and architects, so we do not think about the small implementation details that ultimately do matter for performance and reliability.

People who know what they are talking about worry about all of the details from the big picture down to the small scales. We can still operate using abstractions like designers and architects, but we must know enough to choose the right abstractions that account for the concrete details properly. I've discussed this point earlier this year [1] using the tree swing diagram [2].

[1] https://news.ycombinator.com/item?id=46422597

[2] https://en.wikipedia.org/wiki/Tree_swing_cartoon

[1] https://en.wikipedia.org/wiki/Oil_drop_experiment#Millikan's...

A .deb file has many advantages over curl piped into a shell. You can check the contents before installation, you can potentially verify the authenticity of the .deb file, and dpkg makes it possible to uninstall the package later since it keeps track of what it installed in an organized manner.

I won't say that I would feel safer with a .deb file. That depends on the source, what the package does, and other factors. Security is about tradeoffs. I personally find the tradeoffs associated with a .deb file better than the tradeoffs of curl piped into a shell, but I myself do not install .deb files in the first place since I get almost everything that I need from package repositories.

It is also possible to have a signed file that you can use to check the authenticity of a downloaded file directly without having to use checksums. Rust [1] does it that way for its other installation methods.

[1] https://forge.rust-lang.org/infra/other-installation-methods...

SSL/TLS/HTTPS is more about encrypting the traffic and ensuring that there was no tampering with the file between you and the server. The steps that I describe are more about ensuring that there was no tampering between you and the original source. Those are two separate problems. If you just rely on HTTPS, somebody can replace the file on the server with a modified version, and you would not know.

[1] https://curl.se/docs/sslcerts.html

Curl piped into a shell command provides no means to verify that the download is uncorrupted and unmodified before running it. For example, whenever I download software manually I check the downloaded file against the verified checksums to ensure that I have an unmodified version. Ideally I check this with gpg --verify on the signed checksum file (against the source's public key). This is a standard procedure for many organizations [1]. If you just download something and immediately run it without this step, you could potentially run a hacked version of the installation script.

[1] https://www.debian.org/CD/verify

[1] https://en.wikipedia.org/wiki/Wernher_von_Braun#Surrender_to...

[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC6306777/

[1] https://folklore.org/Negative_2000_Lines_Of_Code.html

To figure that out, I remember searching for articles on how to implement inverted indices. Once I had a list of candidate strategies and data structures, I used Wikipedia supplemented by some textbooks like Skiena's [2] and occasionally some (somewhat outdated) information from NIST [3]. I found Wikipedia quite detailed for all of the data structures for this problem, so it was pretty easy to compare the tradeoffs between different design choices here. I originally wanted to implement the inverted index as a hash table but decided to use a trie because it makes wildcard search easier to implement.

After I developed most of the backend, I looked for books on "information retrieval" in general. I found a history book (Bourne and Hahn 2003) on the development of these kind of search systems [4]. I read some portions of this book, and that helped confirm many of the design choices that I made. I actually was just doing what people traditionally did when they first built these systems in the 1960s and 1970s, albeit with more modern tools and much more information on hand.

The harder part of this project for me was writing the interpreter. I actually found YouTube videos on how to write recursive descent parsers to be the most helpful there, particular this one [5]. Textbooks were too theoretical and not concrete enough, though Crafting Interpreters was sometimes helpful [6].

[1] https://en.wikipedia.org/wiki/Inverted_index

[2] https://doi.org/10.1007/978-3-030-54256-6

[3] https://xlinux.nist.gov/dads/

[4] https://doi.org/10.7551/mitpress/3543.001.0001

[5] https://www.youtube.com/watch?v=SToUyjAsaFk

[6] https://craftinginterpreters.com/