UFODivebomb

joined 2 years ago
[–] UFODivebomb@programming.dev 2 points 1 year ago

Thanks! Ive wondered about this too. Now to add to my bastardized sway + gnome setup: https://github.com/coreyoconnor/sway-gnome/blob/main/default.nix

[–] UFODivebomb@programming.dev 30 points 1 year ago (1 children)

Reminds me of the glorious thread on the steam community page. Somebody was suspicious of all the sudden positive reviews.

[–] UFODivebomb@programming.dev 1 points 1 year ago

Haha i think you got it right

[–] UFODivebomb@programming.dev 2 points 1 year ago (1 children)

My hands are huge

[–] UFODivebomb@programming.dev 7 points 1 year ago

My favorite is that you can't see if content is actually off screen sometimes. No scrolbar to indicate and often those clean lines just look like the end of the content. Horrible

[–] UFODivebomb@programming.dev 1 points 1 year ago

Cool! Have fun! I wouldn't worry about a lot of code quality opinions then. Especially if somebody is looking at prototypes and thinking they are not prototypes haha

[–] UFODivebomb@programming.dev 4 points 1 year ago

My advice comes from being a developer, and tech lead, who has brought a lot of code from scientists to production.

The best path for a company is often: do not use the code the scientist wrote and instead have a different team rewrite the system for production. I've seen plenty of projects fail, hard, because some scientist thought their research code is production level. There is a large gap between research code and production. Anybody who claims otherwise is naive.

This is entirely fine! Even better than attempting to build production quality code from the start. Really! Research is solving a decision problem. That answer is important; less so the code.

However, science is science. Being able to reproduce the results the research produced is essential. So there is the standard requirement of documenting the procedure used (which includes the code!) sufficiently to be reproduced. The best part is the reproduction not only confirms the science but produces a production system at the same time! Awws yea. Science!

I've seen several projects fail when scientists attempt to be production developers without proper training and skills. This is bad for the team, product, and company.

(Tho typically those "scientists" fail to at building reproducible systems. So are they actually scientists? I've encountered plenty of phds in name only. )

So, what are your goals? To build production systems? Then those skills will have to be learned. That likely includes OO. Version control. Structural and behavioral patterns.

Not necessary to learn if that isn't your goal! Just keep in mind that if a resilient production system is the goal, well, research code is like the first pancake in a batch. Verify, taste, but don't serve it to customers.

[–] UFODivebomb@programming.dev 1 points 1 year ago (2 children)

Great potatoes... This is not very good advice. Ok for prototypes that are intended to be discarded shortly after writing. Nothing more.

[–] UFODivebomb@programming.dev 3 points 1 year ago (1 children)

How often does a cop look at those and decide not to pull them over because of the trouble?

[–] UFODivebomb@programming.dev 11 points 2 years ago

The bill actually needs to get to his desk first...

[–] UFODivebomb@programming.dev 23 points 2 years ago

We've selectively sampled like 5 metrics and carefully confused population averages with the median and can confidently say: yachts are more affordable. QED you're wrong.

/s

[–] UFODivebomb@programming.dev 10 points 2 years ago

We've created an economy where that is not sustainable.

This fact is bad imo, but it's where we are.

view more: ‹ prev next ›