Recently I've changed my story at some social profiles again - to this:
Specializing in: Control systems, software development for measurement data analysis, IT security, troubleshooting and reverse engineering systems with physical (hydraulic) and software (control) components.
I am running a small engineering consultancy together with my husband. We are both physicists, and we focus on designing, programming, and troubleshooting control systems for heating / solar systems, especially heat pump systems with a combination of uncommon heat sources and custom control. For more than 10 years I have implemented, reviewed, and troubleshooted public key infrastructures, and I still do this for some long-term clients.
I am blogging about this and about related science and engineering topics at https://elkement.blog.
In contrast to this blog, this site here is more of an extended profile / About Me page. It is my hand-crafted whoami machine.
I think about my exploration of layers of software. tl;dr: I am gradually moving down / back to the lower levels of software, the ones closer to hardware, electronics, control, field bus systems etc.
I've started out learning about micro-controllers in electronics class as a physics student. Then I programmed sensors and actuators for measuring the low-temperature electrical properties of superconductors as a staff scientist at the university (in Turbo Pascal). Yet I jumped up to the top of the software stack and switched to Microsoft scripting languages: VBA, VBScript, ASP when I went 'from research to IT'. Even the first version of my numerical simulation for our heat pump system was an Excel spreadsheet, then a VBA application using spreadsheets.
It seems I needed to trade 'IT' again officially for 'renewable energies' to be motivated to move down the stack again. When I was a non-traditional 'post-graduate' student in in energy engineering I was always been the 'Excel programmer' in group projects. Buth then I went down rabbit holes: Learning SQL Server and Transact-SQL for analyzing our measurement data. Re-writing the simulation software, now based on Visual Basic .NET, for the first time using a true object-oriented design. To get ready for this, I had re-written this website from scratch in .NET before. My so-called Data Kraken uses a combination of Powershell and SQL scripts today.
I finally learned to utilize all my processors in my simulation, and I fixed lots of performance issues. I read Joel on Software cover to cover to re-live the period I 'was in IT' and to catch up on fundamentals. He pointed me to Structure and Interpretation of Computer Programs which I consider the single best ever lecture / course I've ever 'attended'. It is both so deep and philosophical, and at the same time so useful: My simulations became faster by a large factor.
And all the time, I did reverse engineering and debugging. I think I have done this ever since, but always at the level I understood software at the time. Of all the tasks I had as an IT Security / Public Key Infrastructure consultant, troubleshooting weird issues with X.509 certificates was maybe the best one: Digging deep into network traces, reading up on RFCs. Every time I was theoretically only a user of software and services, I ended up debugging in detail - like using Wireshark to track down a weird compatibility issue between my e-mail client and a mail server, when just trying to sign my invocies via a digital signature solution using SMTP.
Then I finally learned C and C++, and I read about Assembly and the art of reverse engineering and malware analysis - to really appreciate the final chapters of SICP, about the self-referential wonders of compilers and interpreters.
Trying to visualize the stack and what happens to the registers, I picked up a very old book - the one I used decades ago in my electronics class - and I jumped into the chapter about micro-controllers. And then it hit me: Those fundamentals, they have not changed much. Yes, different processors have different instruction sets and you might have 8bit, 16bit, or 32bit. But the explanation about the stack, and how to return from a function - this has always been an eternal truth since that electronics book and SICP had been released.
All falls into place: Understanding C is really the pre-requisite for understanding field bus communications, and that is what control units use. Debugging skills are essential when dealing with abandoned engineering software from the stone age.
So I finally found the most logical connection between physics and IT, the place to be as a physicist in IT or in engineering or whatever.
Onword to Python!