Tech heads are re-discovering what "community" actually means, after overusing and abusing the term for the last two decades when they actually meant to say "audience" or "network".
For sure, we need to collectively recognise how much real work takes place in this mode.
I once collaborated with a colleague to design and implement a data sync framework. For six weeks we chatted about it during our lunch break, while walking from the office to a Japanese takeaway and back again. We'd propose ideas and find weaknesses and flaws in them, and would spend our evenings thinking hard to come up with solutions to get around these issues.
Our boss saw none of this, but it easily consumed about three weeks of person-hours (i.e. around 120 hours).
One day, walking back from lunch, neither of us could find any problems with our proposed solution. We walked into the office straight into a meeting room, spend 30 minutes drawing diagrams on a whiteboard, then returned to our desks and coded up a working proof-of-concept in a couple of hours.
From our boss's perspective, we had implemented a new technology in an afternoon. He's the kind of non-technical person who equates productivity with typing code into a computer. But I think more places need to equate productivity with sitting on a sofa staring into space, or going for long walks, or whatever it happens to be that works for the developer in question.
Just read an article about employers increasingly monitoring their WFH employees with software installed on their computers. This is the "sitting at a desk and typing" measure of productivity. How do they propose monitoring the "solving problems by thinking hard" measure of productivity?
Nice, I remember playing with Dasher many moons ago; visited David MacKay (RIP) back in 1996. In 2009 I developed my own text input system called D-Board. There's a brief video of a prototype here: https://www.youtube.com/watch?v=Do0fUWME0Mw
In fact, with the help of Paul Geerts, I submitted an earlier version of d-Board to SONY in 2006 or thereabouts while working in game development. It ran on the PS3 and used a similar interface to that shown in the video. The search menu in the PlayStation Store on PS4 later adopted this interface (although it's been replaced by an OSK these days), perhaps because somebody saw the prototype and decided they'd use it there.
I suggest you read "Bullshit Jobs: A Theory", by David Graeber.
He explains that apprentice -> journeyman -> master no longer holds; we all get stuck at journeyman, working in the service of others for our entire career.
Great stuff, and awesome to see this coming from Google (and in Rust instead of Go). Interesting historical note: The author of Sublime Text left Google to work on it by himself when he couldn't get it approved as a 20% project.
It is not "coming" from Google despite it is under Google GitHub organization. There is a disclaimer[1] at the bottom of the repo README, stating that "This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.". It's my understanding that it's Raph code and Google has nothing to do with it other than having to own the code.
* Push conflicted branches so developers in a distributed team can work together to resolve conflicts.
* A git-powered version of Rake, which runs only those tests that need to be run based on the git history since the last run.
* A tool to identify what code changes caused a particular test to fail, based on the above.
* Language syntax detection for smarter diffs, improving the display when blocks of code are moved around or indented/outdented.
* Language linters built in, to detect when a change is introducing a syntax error. Same for coding style.
I'd also move the "Close Pull Request" button a little farther away from the "Comment" button, and make it possible to add comments to a diff when you've hidden whitespace differences (with `&w=1`... I'd also make it a bit more obvious that you could do that).
Well, it is kind-of possible for Ruby/Rails. I half-built such a system once. Here's what you do:
* Gather coverage information when running tests or compiling assets.
* Use that to generate Rakefiles for running tests / compiling assets that have dependencies on the source files they would touch.
* Run the tests once, recording information about the git status of each dependency.
* When the git status of a file changes (i.e. you've just fetched some changes), mark the dependency as dirty
Even better, it you're gathering coverage data and know the test status for each commit, then not only can you show the commit that broke the build, you can show the particular part of the diff that broke the build.
