news_to_me

Maybe you wanted to say "certain people"? Working from home is definitely more difficult for some people's work style than others, plus a ton of other factors like how well one's home is suited to working in, how much skill a person has working in that environment, etc.

Time theft is a bummer, especially on the team-level where you just want to get things done. I wonder what causes it? Off the top of my head I can think of:

- People are naturally lazy (I really disagree with this, but it feels like the default "robber baron" answer)

- People are having trouble adjusting to different and various work environments (probably a good amount of this)

- The nature of how we work in America is fundamentally unnatural for many people, and the lack of supervision allows people to assume a better work/life balance

#3 is maybe just my experience in the workplace, but it feels pretty true — I wonder how widespread that experience is.

In any case, I'm glad the pandemic forced many people to reevaluate what "going to work" looks like, and hopefully we settle on something closer to how we'd each like to work.

Good luck on the next ten :)

I ended up doing a lot more math than I expected to understand the fundamentals of projection, basically teaching myself linear algebra, but that was pretty fun in itself.

My goal was to build a minimum-viable software rasterizer for embedded situations (STM32-F7). I still haven't gotten around to getting lighting to work efficiently, or to leverage SIMD, but I intend to whenever I get back to the project.

The source is here if you're curious: https://git.sr.ht/~zjm/Moon3D. There's also some screenshots/progress updates on my Twitter: https://twitter.com/zackmichener

[0]: https://www.pearson.com/us/higher-education/product/Foley-Co...

[1]: https://www.youtube.com/watch?v=01YSK5gIEYQ&list=PL_w_qWAQZt...

If we could be sure the computer wouldn't get stuck (which is just a bug), then progress bars and spinners would be fine. If the task is as granular as you suggest, progress bars would be a great visual indicator, much better than text.

But since computers do get stuck, additional indicators should help with that. A spinner is supposed to show that a process isn't stuck, but those are fallible too. A textual representation ("bytes currently downloaded") sounds like a great addition to a progress bar. I've seen this a lot on linux distro installers, where you can click "details" below the progress bar to see the console output.

- A progress bar should not measure multiple tasks, unless each task is of the same type (e.g. converting a batch of files, _not_ system booting)

- A progress bar should not measure "time left" unless it is literally tied to the value of a timer (i.e. _not_ "time left to download big file")

- A progress bar does not show "busy state" — a spinner does that. A progress bar can stop if e.g. it measures bytes of a file downloaded and the network connection drops; a spinner will still spin.

- A progress bar should include a label to explicitly state what it is measuring (otherwise users will assume it means "time left")

People like to see progress bars because they want to know "progress is being made", but a progress bar is not always appropriate, depending on the situation. Instead, consider using:

- Spinners show activity is happening. Use when there isn't a single metric to report, or the "bounds" of the metric aren't known.

- A checklist can show different tasks completed in sequence. Can be combined with a spinner on the "current" task

- A segmented progress bar can replace a checklist when each task could be represented by a progress bar

Just my opinions, I guess, and obviously we don't live in the world where the above is applied, but it feels good to have it sorted in my own head. Curious what others think of this scheme.

Abusing progress bars are not a good response to this, though. I would rather trust progress bars for what they are meant to show rather than as an indication of true activity. After all, you still can't tell whether the progress bar kept moving, but the process is stuck in a loop.

A progress bar should measure exactly one dimension, where a total is known, and a label should show what the dimension is. Usually progress bars implicitly measure "time left", but the total isn't known in that case, so progress bars are inapproprate.

For most "loading" scenarios, a spinner is a more appropriate element.

Until recently I was using Think C, which was great, but recently I've switched to Think Pascal. It's true what you read on the old forums, Think Pascal had more love put into it. The editor is better, the errors more helpful, and little things like remembering which files you had open in a project make a big difference.

Shout out to the Mac 512k Blog[0], which has some great content as well.

(Edit) Also for anyone else looking for helpful online resources (beyond tutorial books and Inside Macintosh, which are essential), preserve.mactech.com has tons of great old articles.

[0]: https://macgui.com/news/showcat.php?id=8

Good luck, Dropbox!

It's a bit of a bummer that it only really supports landscape mode, though — I strongly prefer portrait mode when working on the iPad. What was the design decision to only (primarily) support one mode?

True, but it was also your job as a developer to not be holding onto those pointers when the memory manager ran.

What's interesting about Reddit is, to what extent is a subreddit its own community vs part of the Reddit community? Probably better for evil people to set up their own forums, or preferably to not be evil at all.

> Satellite images comparing the area before and after the explosion show the complete destruction of Beirut's port. The grain silos that were next to the site of the explosion are still partially upright, although it's believed that up to 85 percent of the country's grain stocks have been lost. (Lebanon imports 80 percent of its food supply, and Beirut normally handles 60 percent of the country's total imports.)

https://arstechnica.com/science/2020/08/what-we-know-about-t...

My solution was pretty janky, but it's an interesting problem space to explore.

I just think as general advice for young programmers, “work 60+ hour weeks” is very much the wrong message. Stay healthy and let your passion drive your work.