The "perceived benefits" of being able to see more things at once might really be an illusion if they're just a firehose of distractions.
Less so when the things in question are "an error log next to the bug I'm filing about it", or "program output and the program I'm iterating on" or "the total state of production while I'm deploying code" or "chat with team members while I'm reacting to an incident and don't have the mental bandwidth for extra context switching". A really powerful tiling WM with desktops that can be independently switched between a couple of monitors is pretty much a superpower in these situations.
TFA seems overconfident and mistaken in its assumptions.
This. I use a big widescreen monitor so that I can see the code I’m writing, the modules related to it, the running application, documentation, etc. all at once.
If I’m writing fiction, a small screen is all I need most of the time. But for a big programming project, it really helps to have all the relevant bits on the screen at once.
The reMarkable is a very impressive piece of hardware with unfortunately bad software and a business model that looks to be deteriorating (see recent moves to subscription services, etc.).
In physical/tactile terms, it's a really impressive writing experience, but I've found the utility of that so constrained by the absence of indexing and navigation features that I don't use it for much besides occasional drawings. It turns out that navigating a physical notebook works in ways that flipping through electronic pages can't keep up with without a lot of work on the interface.
As an e-reader, recent updates to the rendering have made it usable, though there are still sometimes hassles with display and getting documents onto the device. It's theoretically great to be able to annotate PDFs, but in practice not being able to easily navigate the annotations later makes it substantially worse than writing notes in the margins of a paper book.
I'm sure a lot of this can be improved with 3rd-party hacks, but it isn't designed as a platform and it feels only grudgingly open to modification, which seems like a huge missed opportunity. (Not to mention being yet another product built on open code that doesn't return the favor.) Being able to SSH to the device and poke around the filesystem is cool, but it mostly feels like a glimpse into how much more utility the whole thing could offer.
I'll use mine as long as it works, but I'm unlikely to buy another one and I can't in good faith recommend it for most users. I do know several folks who are happy with the narrow range of things it's good at, which is why I bought it in the first place. Personally, I'm placing my hopes for a more useful-to-me e-ink future on devices like the PineNote.
Why would you say that? Most devs I know dont loath their jobs and I know many who actually love it. Never heard dentists, accountants or schoolteachers sound as passionate about their craft as I have devs.
Just curious, but how many dentists do you know personally? I work in a field adjacent to dentistry and interact with many dentists daily.
It’s shocking to me how many of them are deeply passionate about dentistry and teeth/gums/etc. This may be a situation where I tend to mostly work with successful happy dentists, but the same bias may exist w/ you and developers.
Development is fun, but a lot of work involves non fun stuff, such as unreasonable deadlines, code reviews, grinding algorithms, being to learn a new language in a few hours.
I'd say it still is a lot of fun as long as you optimize for the fun bits and not the highest salaries.
And even when you write code the interesting bits are the minority of what you take care of. Writing tests, making sure that errors are handled correctly and CRUD take a significant portion of time and they are simply not interesting if you've been doing this for a while.
> I also noticed that while they do appear to use pylint to enforce good standards, almost all source files have at least one check disabled...
I haven't touched any of the CircuitPython hardware libraries in... Well, something close to two years by now, I think. A lot has probably changed. Still, when I was last involved, placating pylint was consistently a hassle.
As I recall it squawks about things like identifiers that don't conform to snake_case. All well and good as a general stylistic suggestion, but not especially helpful when that's what the thing is called.
There may be some bad ideas lurking in places where those checks are disabled, but in general I blame no one for disabling one or more of its checks in service of greater readability or better code layout.
> In one of this paper's experiments, for instance, a computer split a pot of money between itself and a human participant; this person was led to believe the computer was also a human participant. Sometimes the pot was split unevenly, and the human participant was given a chance to take vengeance by reducing the computer's pot without enriching his own. Researchers discovered that participants classified as having higher TIV scores were "strongly associated with behavioral revenge" in this scenario.
In retrospect, dictator game allocation scenarios presented to a pile of undergraduates by way of a screen were probably nonsensical back when I was helping my social science grad student friends implement them as crappy Perl CGI in like 2003. I'm disinclined to expect much better from this one.
We recently conducted an extensive evaluation of CI options[0], concluding at the time that GitLab could meet our needs but didn't make a whole lot of practical sense unless we also migrated to it for code review. Other considerations (Gerrit user experience and sustainability, onboarding costs, a de facto migration of many projects from our Gerrit instance to GitHub, etc.) led us to re-evaluate whether a migration for code review would make sense, and that's what the decision linked here addresses.
I am on the team that maintains our existing CI system[1] (Zuul, Jenkins, JJB), though I mostly work on other things. While this system is certainly quite powerful, I would not personally describe it as easy. We have a lot of work in front of us in migrating it to GitLab, but so far I've found the experience there quite a bit more pleasant than grepping through JJB definitions and the like.
At any rate, if you're interested in how all of this pans out, we will as ever be doing the work in a very public fashion.
To clarify, is your GitLab-based job system done with configuration-as-code and does it share definitions of jobs across repos?
The solution we come up with in using Gerrit/Jenkins was to have a common test invocation (in our case `make test`) that glossed over all the details of a projects build process, and was expected to output test and coverage in specific formats Jenkins could consume (junit/xunit and cobertura). We have jobs that run `make test` no matter if the code is C, Go, Python, Javascript, etc.
This also had the beneficial side effect of lowering the barrier to entry for someone working on any random project - make papers over all those toolchain differences.
Less so when the things in question are "an error log next to the bug I'm filing about it", or "program output and the program I'm iterating on" or "the total state of production while I'm deploying code" or "chat with team members while I'm reacting to an incident and don't have the mental bandwidth for extra context switching". A really powerful tiling WM with desktops that can be independently switched between a couple of monitors is pretty much a superpower in these situations.
TFA seems overconfident and mistaken in its assumptions.