71–80 of 95 posts
for me, in a nutshell, software is the comprehension of the problem(s) at hand expressed in code.
I'm a so called "scientific" programmer. Yeah, one of those. ;-) A real software developer joined my team of researchers. By agreement, his job is not to be a code jockey for us, but to work on his own software related research projects. Still, I've asked him to watch what I'm doing and suggest ways to improve my skills. Meanwhile, he gets a guinea pig to try out ideas for what works in a research setting.
That’s a cool team setup! As a fellow computational scientist without much formal CS/SwEng background, do you mind sharing any insights you’ve found valuable so far?
When I find myself feeling like an imposter with X technology, I build a small project with X.
This pattern has helped me build the confidence that if I don’t know X, I know I can figure it out.
Nothing.
I'm 10 years into a stagnate career. Just going to wait it out another 20.
I'm managing my resources with Terraform - I'm about to start managing all my personal GH repos this way too! I think GitOps and DevOps are cool and a great way to level up as a programmer.
And I'm doing a master's in CS through UT Austin, focusing on machine learning. Implementing old and new architectures in PyTorch.
Last, I'm building an "embeddings as a service" app, which is mainly just normal full-stack stuff but hopefully will present some complexities as we go.
I looked at my home architecture (home lab) and grew from 4TB to 1/4 PB in about two years, with a concentration on self-hosting and digital sustainability. I should reach a petabyte within 5 years. Ultimately I had a poor grasp of what scaling compute effectively looks like, but I feel much more useful when working with cloud resources due to better foundational understanding in that time. It all started with me put…
What kind of data?
I'm a so called "scientific" programmer. Yeah, one of those. ;-) A real software developer joined my team of researchers. By agreement, his job is not to be a code jockey for us, but to work on his own software related research projects. Still, I've asked him to watch what I'm doing and suggest ways to improve my skills. Meanwhile, he gets a guinea pig to try out ideas for what works in a research setting.
That’s a cool team setup! As a fellow computational scientist without much formal CS/SwEng background, do you mind sharing any insights you’ve found valuable so far?
It's OK to start out with dirty code. Within a tight team, it's OK to make breaking changes if you warn people and help them fix their stuff. We have just begun to adopt a discipline where nothing leaves our group if it's not in decent shape, and this is going to include testing. In fact, I just took an online course on unit testing, and have applied it to a small library for the first time.
You can see that we're really starting at the ground floor.
At the present time we don't expect our code to be directly incorporated into the production code base, and in fact we use a different language. We're in an experimental group, so we're interacting with physical equipment, and our software guy has asked us to start including simulators so he can work on stuff from home. This is good discipline anyway because it lets us run our unit tests without all of the hardware connected.
I've noticed that the developers love layers of complexity and abstractions. Us normies, not so much. Keep things simple if possible. I've been moving to a more functional style, not due to thread safety but just the ages-old warning against using global variables. A big unwieldy parameter list is preferable to fetching parameters from globals.
We comment our code. I'm skeptical that comment-free code documents itself. At the very least. Scientists tend to be OK at explaining themselves in text, but doing so in code involves a learning curve.
I recently discovered how good mimalloc is, how helpful tracy integration is, and that static reflection is actually somewhat possible in modern C++ thanks to refl-cpp.
And a lot of other, domain related things.
For me, pushing the limits, and just building things definitely contributes a lot to becoming a better programmer.
Earlier quoted context omitted.
Interested in giving me some feedback? Git repo’s in my bio.
Your repo is basically empty ?!
I reversed engineered the tools they used to build out the beautiful content at plausible.io last year, and now I’m turning it into free tool for frontend developers as a passion project.
Despite all of the FUD about how it would impair learning, it lets you skip through boilerplate you already know how to do, shows you some ideas you wouldn't think of, and can work as an on-demand code reviewer.