ERRATA - It's difficult to separate my desire for purity in doing as much in plain-text as possible, with the practicality that GitHub (and others) have features you're not going to want to miss, but can't yet get in plain text. This video represents a compromise. - I'm SO SURE I'm wrong about Odysseus/Ulysses that I'm going to put this here right now: en.wikipedia.org/wiki/Odysseus - I couldn't resist adding the effect at 3:00. That's Saike's glorious "Abyss Reverb" for Reaper.fm, the same as I used for my recent Ambient album: th-cam.com/video/nkdRLtubbII/w-d-xo.html - 11:50 I did not say the phrase "style guide enforcement" very clearly, apologies. I've manually fixed the subtitle. - Linus did not create Git because existing version control systems wouldn't scale. He did it because the proprietary BitKeeper service he was using decided to revoke its free licence offerings.
@@TheSast I assume that it'll confuse a few people who might say "the sound is broken at 3:00" so I put this in to fix that before it happens! I hope it's fun!
@@AexisRai I was struggling hearing this one too, so I looked it up in the script (yay opensource) > notes: You could also, for example, set up style guide enforcement, blocking the PR if the phrase "on premise" has been found.
@@aviinl1 Thanks. Am I correct in reading that as some kind of joke? I don't do enough of this kind of thing to know why you'd block "on premise" but it sounds like somebody advertising themselves in your PRs.
ikr. Thats what I noticed too. Sometimes its just so much easier to "do less". Just ship a product out and get it done with. Then you can modify it as you go. Its software. Its easy to change shit. People are afraid of having to refactor whole codebases for no reason. We should work on tools to make sure its easier to upgrade software. Not to make software faster to make.
I genuinely believe it is a subconscious thing in most managers' head that they really are barely doing anything productive, so they force their presence on the actual labourers. All my respect for the good managers of course, but so many of them are horrid.
The comp sci department in my college uses git for everything. Every old test/assignment, syllabus change and bibliography is there for all to see. As a student i love the ease of access to materials and the ammount of old stuff to study from
Oh boy, a company putting their ToS and stuff to GIT so everyone could see what was changed instead of getting an e-mail of big wall of text without actually knowing what was changed due to not everyone having absolutely perfect memory let alone actually reading more than one ToS ever, if that
Well spotted, I removed an entire 4-minute section from my original draft and replaced it with that teaser. This deleted section now forms the basis of a new video, the draft title of which is "THE UNREASONABLE EFFECTIVENESS OF LINUX WORKSTATIONS" ;-)
@@NoBoilerplate nice! the Milan Kundera reference makes me think you’ll spend the first chapter exploring whether it’s even worth saving any data at all 🤭
@@NoBoilerplate really looking forward to it. I resonate a lot with your approach and the storage issue is something I am just about to get started on, so I'm looking forward to your take on it!
It would be really cool to see lawmakers use git in this fashion. All law would be in plaintext in a repository for everyone to see. Government would create a pull request, parliament would comment on it and then vote on whether it will be merged. The justifications for that law proposal or change would be plainly visible in the commit messages and you could see a complete history of them. Any time you wanted to see why a certain law exists, you could just run git blame on it and read. You could possibly even have regular citizens commenting on the pull requests what they think of the new proposal.
@@NoBoilerplate Unironically this would make the US Senate / House divide on sister bills so much easier. It literally would just be merging two branches, no need to make a complete rewrite and try and sync things up.
Do you one better while we're at it: Anarchism - as in "no authority you didn''t consent to"". Nothing more democratic than every person governing themselves.
@@marsjune6716 That's not democratic, democracy is the will of the many outweighing the will of the few, for very good reason. For example, a world where my neighbours don't consent to education and healthcare is a bad world for me, not just because I want them to be healthy and educated in an abstract way. It's bad for me on a practical level. In the words of John Green, "We have discovered as a species that it is useful to have an educated population. You do not need to be a student or have a child who is a student to benefit from public education. Every second of every day of your life, you benefit from public education. So let me explain why I like to pay taxes for schools, even though I don't personally have a kid in school: *It's because I don't like living in a country with a bunch of stupid people*"
@@NoBoilerplate That's not really how anarchism works. It doesn't imply the lack of education or healthcare, rather in this context it believes in agreement on how these things are achieved, rather than wasting resources into coercing everyone into a pre-made routine that just isn't useful for the place it's used. I don't hope to explain it to you in comments however, you're much better off reading about it elsewhere.
Stand up meetings are good for two things in my experience so far: 1. check if anyone is blocked. 2. check for duplication of effort. i.e. make sure two people aren't doing two overlapping things.
1. Just post it in the group chat 2. Just look at the kanban board What's the point of keeping all of these written channels of communication if people can't ever use them properly because they always need someone to tell them on a videocall when there is a problem?
@@josevargas686 the true value of the meeting is *shared attention*. It is a coordinated moment when the whole team pays attention to the same thing. This is expensive, but outperforms any asynchronous communication method in resolving blockers. No matter who needs to get involved in unblocking, they are there to immediately speak to their ability to do so. If you make this process async, it can sometimes take an hour or more to sort out what would have been solved in a few minutes, as people respond to things whenever they are available. It's expensive and unpleasant, so keep it super short, but it can deliver a ton of value in a very short time.
I've enjoyed the ones that last for 90 minutes where most of the talking is the PM ranting illustrated by his throwing things at people. It was very Agile.
Recently my team had to migrate to a diffrent "workspace" in databricks and we were unable to migrate models, workflows, and experiments. I want you to know that becasue of this video I will be pushing for saving things like these in as simple, transparent & popular format, within a git repo.
Exactly the kind of problem I wrote this video to try to address. I've worked in industry (including government) for 15 years, and have lost count of the number of times this has happened!
Would love to hear more about the stand up meeting you described. I find they often just turn into a status update meeting and everyone is just waiting their turn to talk before mentally checking out
There's nothing to it, really: - walk the board backwards - strict time limit per ticket (30s or 60s works for me) - finish up with blockers - go back to work
@@NathanHedglin I'm relaxed about the medium, many distributed teams need to do async standups, and this is one of the areas I don't care about slack's impermanence - the status updates are only useful today, so perfect!
@@NoBoilerplate About the second point, the "strict time limit per ticked"; what do you say about the ticket other than "X is working on it"? If the task was already clear and agreed, and it doesn't have a problem that you are hoping someone might have the solution, then why does everyone need to know about it?
There's lots of ways of doing it. Requiring that there be a specific reason in order to be allowed to schedule one. Making people stand on one leg while talking. (Obviously, people who can't stand due to disability should probably be given an alternate option. Status meetings serve absolutely no purpose. If you're just reporting status, that can be done without everybody being there at the same time and decent project management system, or a text file, can do that just fine.
Every time I watch one of your videos I get convinced of something, but this was the best one. Less is better. In the world of productivity tools, the minimal setup, the simplest workflow is always the best. Its hard to acknowledge that, we all love the new shiny thing. But it is the truth.
Thank you! Yes as I get more experienced, I'm less impressed by the shiny new things, and more impressed with the proven things that stick around. Hot take: VS Code is nice, but I'll still be using vim when the world moves on to the next hot editor! (cold take: I, of course, use vscode for a bunch of things, liveshare especially is incredible!)
@@Rudxain one of the most important skills of a good programmer is a healthy resistance to using new toys. (The most important rule is to foster humility)
I work for a unicorn software company, and this vid describes our workflow to a tee. Instead of growing via series funding and then IPO like most successful startups, they focused on efficient workflow & management to remain profitable without relying on investors, and this is pretty much what they came up with. It works great, but it requires long-term vision, which can be hard to find in a world running on short-term profits. Edit: also, as a bugfixer, I cannot even imagine having to work without git and especially git blame.
The quote at 3:06, "The difference between science and screwing around is writing it down," although most famously said by Adam Savage actually originated from Alexander "Alec" Jason a firearms specialist for the show. Adam talks about it here. th-cam.com/video/2WFFhicVeXI/w-d-xo.html He starts explaining the quote's origin at 8:35. It's Adam Savage so naturally he goes on a tangent before finishing the story but it officially starts at 8:35. Also, there are differing versions of the quote but from all the sources I could find they all start with "the *only* difference...". The version of the quote said by Adam Savage on MythBusters is "Remember kids, the only difference between screwing around and science is writing it down." However, in the video linked above Adam quotes Alexander Jason with saying "The only difference between science and screwing around is writing it down." Obviously the later is prone to inaccuracies, as he is recalling it from memory. Adam saying the prior version of the quote can be found here. th-cam.com/video/BSUMBBFjxrY/w-d-xo.html edit: spelling & minor revisions
@@JhonIdrovo-the-human I try to get the source of quotes and data as best I can, you'd be amazed at how many 'sources' are just urban legend! When I make inevitable mistakes, my pinned ERRATA comment keeps me honest. You can't edit videos after publishing, sadly.
He just basically copied Bitkeeper, driving it to irrelevance in the face of free and open source competition. Don't get me wrong, I appreciate that I don't have to pay for a brilliant distributed version control system, but he didn't invent anything, just reimplemented a great idea as free software.
We're living the result of "everyone uses a different format, what we need is a new format!" XD But yeah, plaintext markdown, restructured text, etc. Totally agree. Great take.
@@marschma heh, I do have a soft spot for LaTeX, but the most I do with it these days is embed a few equasions in my obsidian markdown files with it's built-in suport for in-line mathjax, eg: $$ \frac{1}{5.4} $$ FUN FACT: DID YOU KNOW that the creator of TeX ALSO popularised big-O notation? Donald Knuth has had a huge impact on our industry! en.wikipedia.org/wiki/Donald_Knuth (my video on Obsidian.md is here if interested: th-cam.com/video/DbsAQSIKQXk/w-d-xo.html)
@@marschma It's probably overkill as most people don't need more than italics, bold and different fontsizes. Latex and the like can be incredibly helpful for various technical fields though. Certainly nicer to read than the stuff that was in books from the '70s and '80s when typsetting was being computerized in a rather crude way.
Plain text -- no images -- has held me back in the past. I'd be fine with anything with images though. Honestly, HTML 2-3 were actually kind-of good, but people started whining about details which worked out just fine in practice. Separately, some page composition software severely overused tables for layout and, similar to the earlier response to Don Knuth's complaint about the overuse of GOTO, this led to a jihad fanatically eliminating all use of tables for layout. I remember the time mobile browsers could restructure desktop web pages and still have everything in the right order. That was tail end of the era of HTML tables. Now, browsers are Wrong if they put a single character anywhere but where The Page Designer intended. Sorry for the rant. Old frustrations coming up. I did get on all right with markdown for a while, but last I heard it was not standardized. (Not surprising when its author explicitly didn't want it to be machine-parsed.) I don't remember any markdown implementation supporting bold italic, which is not a serious fault but seems rather retrogressive to someone like me who enjoyed the look of bold italic from books printed before I was born all the way up to the 00s.
I use my old Raspberry Pi as a provate git repo host on my LAN. Among many other repos, it includes a repo in which I keep my dream journal, which is a plain text file that is formatted with the date followed by paragraphs, with each entry separated by new lines. I'm definitely a fan.
That sounds great! Tip: open that git repo as a new 'vault' with Obsidian.md, thank me later. (my video on Obsidian is here btw th-cam.com/video/DbsAQSIKQXk/w-d-xo.html)
I took a video game programming course in college, and when we were given a group project, I started by taking a few days to learn some git (because I had heard that it was great but had never actually used it), and then about a third of the rest of the time I spent on the project was dedicated to trying _and failing_ to teach git to my teammates. 😩
Git the CLI has a lot of sharp edges, for sure. You'd be surprised what people will be happy to learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!) I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface. It won't work for some people, I acknowledge. But it WILL work for far more than you might think!
Moving to plain text, enforcing PRs, and making teams work through merge conflicts was a learning experience for everyone at a previous job of mine. However, it also exposed who the good teams were, and which teams were poor performers but were hiding behind issues in proprietary tool sets. Some middle management was very unhappy, as rhey couldn't coast and get their bonuses.
@@NoBoilerplate Years ago I was with a company who used a file based archive system. I could be a bit confusing but it worked well. However, a couple developers REFUSED to learn it. A config manager had to check out their code for them and then commit it to the archives. Such a pain.
@@NoBoilerplate I agree that this is mainly the problem, it's just unfortunately a massive problem. Corporations are filled with people who refuse to learn anything.
When I just saw the video title, I was quite confused, because in my brain "plain text" means "no markup whatsoever" first, and only then "not a binary format"... Kind of like if you use fenced code blocks in said Markdown with language "plain" - it won't highlight anything. But I do agree, using git for "just texts" is so convenient. I'm using Obsidian for note keeping, and one of the folders is auto-converted into a static website using MkDocs. Try to do that using Google Docs or local docx files as documents!
This video is unreasonably persuasive for something I randomly stumbled upon, and I’m tempted to forward it to every project manager I’ve ever met. Looking forward to more content like this!
Even though I don't agree with you completely that storing all documentation a diverse and distributed team needs in git is a good idea (I'm currently getting accustomed to jira/confluence after working with no docs) the message in all your videos, and this in particular, is great, sound and sane. Make things that work. Especcially through time. I think this method of organisation I've stumbled upon by accident while looking through your gh is a must for a team starting out. Thank you for your work and contribution. It's so great seeing other creators adopt your style of presentation. Makes me hope we can have focused no-nonsense content
Torvolds did not create Git because existing version control systems wouldn't scale. He did it because the proprietary BitKeeper service he was using decided to revoke its free license offerings. It was then the lack of comparable _open source_ equivalents that spurred him to create his own. The FOSS community had been warning him of the possibility for ages, but he didn't pay any attention to them, until it actually bit him on the azz.
What's also interesting to me is that we had a sort of Cambrian explosion of distributed version control systems around that time. Before git came along we already had mercurial, darcs, monotone, bazaar, and so many others I've long since forgotten. I was a big fan of mercurial and continued to use it after git was already taking off until all of my colleagues insisted on using git and forced me to switch. But Linus didn't like the workflow or features of these for the kernel so when bitkeeper bit him in the ass, as you pointed out, he decided to make his own. It's funny to me that all of those other general purpose dvcs' didn't work for Linus and the kernel but git does seem to work ok for general purposes.
This video highlights exactly the main problems I've had with low-code solutions: 1) poor version control, and 2) no fast and powerful text replacement tools. The amount of time I could have saved if I just had regex based search and replace...
the world outside programming could be SO enhanced by the techniques we employ day-to-day, but people tell me "normal people won't understand". Rubbish! You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
It's kindof obscene that regex is not a standard concern for all low-code solutions. They're mostly trying to imitate either a spreadsheet, fancy word processor, or a database. All of these tools would 100% have an intuitive find+replace feature. So why on earth don't low code companies, who are trying to get people familiar with these tools to use their proprietary thing instead, think to implement search as one of the first things they do??
I love the idea of regex, but when I used to use them all the time, I got them wrong often, in the stupidest ways. Sometimes, after years of using a certain feature correctly, I'd forget it existed. Some peoples' brains just don't do accuracy. I still use regexps, just less often, with more care, and in an environment easier to debug than the command line. An editor with undo is fine, so long as undo works on all the files. Very occasionally, I'll use a more verbose language instead, even if it's slower.
I've tried many task management systems. I'd never stick to any of them. All of them had too much friction when it came to adding tasks, modifying, rearranging, or viewing them. I would overtime slowly drift from them. Org-mode, for me, has finally presented a system that I've been able to stick to. Performing all the actions I need to is so effortless that I never feel discouraged to engage with it. It's seriously allowed me to organise my life in a way that I never was previously. The fact that it's all written in plain text means that I can edit and format any project in a way that feels natural to that workflow, rather than having to stick to the opinionated constraints of a graphical application.
I adore org-mode and ran my life on it for 2 years, writing the first few seasons of Lost Terminal [1] in it. Due to the lack of satisfactory mobile options (the best is orgzly with syncthing, and that's very poor) I switched to Obsidian.md and have never looked back, it's WONDERFUL. If you don't need mobile editing, you can stick with org-mode. If you do, then my video on Obsidian, is here: th-cam.com/video/DbsAQSIKQXk/w-d-xo.html [1] th-cam.com/video/p3bDE9kszMc/w-d-xo.html
@@NoBoilerplate I'm actually rocking a strange amalgamation of org mode and obsidian. Org mode for task management and obsidian for everything else. Be-org is an okay mobile app for org mode task management. I definitely wouldn't use it for notes though. Obsidian has become my primary method of storing long-term information. The Obsidian mobile app is far better than I could've imagined. It's as feature-full as the desktop client.
@@NoBoilerplate I can live on mobile without my fancy org-roam graphs, and I was able to get Logseq to play nice-ish with Dailies, so I can just document anything i see or think about on the go and then turn it into something more once I'm home.
10:10 I'm happy how we work in our small company. Everybody knows the goal, everybody is available any time, when somebody has a problem, they immediately tell it to someone, if someone has an idea (normally the boss), they just tell it, if someone needs something from somebody else, they also just tell them.
I have found that most teams producing bad software are, in fact, the same in one important way: The team diminishes and dismisses what their users say their priorities for the product are and instead the team decides to focus on what the team members want to work on.
I'm a player of the game Sea of Thieves. The game has gone downhill, largely because the company is listening to players too much. There's definitely a happy medium to be had.
9:50 If you’re waiting 24 hours to get unblocked, those 24 hours (or probably 8 work hours) are most likely wasted (unless you were able to jump to another task and do it equally effectively). Don’t wait an entire day for some holy meeting, instead *talk* to your teammates to get unblocked much sooner. Waiting for the stand-up might make sense if you became blocked shortly before the meeting, but it’s a bad idea otherwise.
I am an geospatial engineer still in school. I got onto git mainly because of very convinient way of storing my .config files for different programs (iam a ricing adict) and because of easy and automatic hosting of webpages (learning web cartography). Now it helped me to get a job, because i could showcase my projects very easily (link in CV pdf) and the interviewver was pleasantly suprised by me knowing how to work with git and github (its not a norm in our field - only in the developement side of things). Now I am shifting more and more of my organisation and general knowledge keeping to git. I want to shift my obsidian stuff to git and other things (would appriciate video on that topic). Anyways using git and knowing it was only helpfull for me.
I'm delighted to hear this, it bolsters my opinion (expressed in this video) that git is a tool that can enhance any field! BTW I don't know if this will eve be useful for you, but GitHub can visually diff STL files: github.blog/2013-09-17-3d-file-diffs/
I wasn't aware of this GitHub feature. It's little bit different however I deal with 3d data, but more in the programatic processing side, rather than creation. If we go little bit abstract, I think that the git workflow of adding staging and pushing changes should could be added to any digital work environments.
@@janhorak5363 It's an exciting avenue that I don't think has been properly explored: I've not been able to find a list of all the file types that GitHub can diff, but I wonder what else is possible! Images at least are previewable, and I've seen some github actions that visually diff them, which is cool.
Well I havent explored it much, but most common 3d graphics file format glTF has a JSON like structure which links to textures and other stuff, so in theory diffing the text part should be possible. @@NoBoilerplate
This keeps popping back into my head ever since I watched it. I'm now forcing myself to store all notes and code snippets and whatever else in a Github Wiki. So far it's working well, thank you!
Fantastic! Here's a tip that might revolutionise your life: Clone that gh wiki (link at the bottom of the wiki page) and then open it as an Obsidian.md [1] vault. The link formats are the same, and you get the best markdown editor on the PLANET! [1] th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
I'm a co-op for a large company. I've spent significantly more time in meetings than I have doing any work at all. I have not been impressed with their agile work style at all.
9:58 "I didn't say the PM or DM or scrum master or whoever facilitates [a standup meeting]. That person doesn't exist in my team. These are not roles, they are hats." You've brilliantly and concisely put into words what I've always felt. Individual team members can handle moving their own tasks on the Kanban board, closing their own assigned Issues, or what have you. The project board for discussions will evolve naturally as work is completed (when using proper project management tools like GitHub), and one team member can be saddled with the brief responsibility of making sure conversation stays on topic during a standup. If more software development teams (or even better, their upper management) had this mentality, I think things would be a lot more efficient! Thanks for another excellent video Tris.
I've seen a few people commenting that it would be hard to teach people how to use git who are not familiar it, and your response is that you've been able to teach people with a pretty short demonstration. I'd be interested in seeing your approach to teaching people git as a video on here. Great video, btw!
I could do that, but it's so different per person, you have to meet them where they are, relate to their experience. That's hard to generalise into a video. My advice would be "listen to what the other person is telling you and help them solve their problems"
One super useful (also for non-programmers) feature that imo could have been mentioned / praised better is version control: I can not imagine writing large docs (e.g. long university assignments and papers, essays, motivational letters, literacy) without it anymore. - automatic backup to "the cloud" aka you remote git repo - clearly see changes since last meaningful version of the text (automatically marked in the editor) - never mind deleting entire paragraphs before rewriting them anymore (if i want to have it back just use look into the history) -> not only my final text is documented; the whole history of its creation is
To be fair, Google Docs and Microsoft Office do have something resembling history or version control. It's just... not very robust, at least as far as I've bothered to learn it. The fact that documents get moved, copied, published, etc, makes it much weaker than a real version control. You can totally do comments and suggest changes etc, but it's all second-class to the document's current state.
@@LibertyMonk ugh it's so bad, as you say, it's all second-class to the current state. Life is change, change should be modelled as the first-class unit, not as an after-thought!
YES thank you! I fought so hard to get a workflow like this used for documentation in my previous company, but people are so used to excel / ms projects / emails that they can't see how it can be simpler...
I actually really love email, but I assume the problem maor might have been talking about is using unstructured email (and follow-ups) to run a team, instead of having a central location where you can see everything at once?
Sooooo I actually think the git based product management concept is pretty good, but it’s going to be really fun trying to convince Karen from HR to use it.
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!) I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR.
@@NoBoilerplate I'd be interested in a video (or article) on Git(Hub) training for non-developers. I usually use the command line myself (with a few aliases), but haven't yet found a GUI tools that I like for personal use, and I struggle with how to simplify it, especially for non-devs.
@@ModEmbedded It's certainly possible, though not too similar to what I do on this channel. I had great success talking to my non-technical colleagues 1:1, and meeting them where they are with their experience, instead of expecting them to come to me, and showing them how to click through GitHub and do simple PRs all in the web interface. They universally loved it, and could see applications they never dreamed possible in their own work domains (because the existing tools are all too simple).
That was awesome. Thank you. I have been pushing for simpler tools. I consult to some of the largest and most regulated businesses in the world. And they are stuck complying with regulation in the same broken ways. I have managed to convince a few customers and they are LOVING it. Simple, "outside the box" thinking, engineer led solutions. Even their management are slowly learning the benefits of leadership in this manner. Excellent work as always, Tris.
I'm stuck with Confluence at my job, but sometimes I do this by including a tool's documentation in the repository and creating a "pointer" document in Confluence. Documentation should always live with whatever it documents. Separating them guarantees that the documentation will go out of sync; you might have the strictest processes for documentation and you will still fail to keep it up-to-date.
Your videos are always so well articulated, but maybe this is my favorite. It really hits home for me, as I try to be as plain-text as I can. While I am working in an environement where everything is wall-gardened, everything is opinianated, simplistic yet overly-specific, "easy-to-use" yet sometimes unintuitive, and above all not scalable... which only leads to frustration. What I would do to be able to edit a file in vim or emacs rather than fiddling with the GUI.
I do the same. I manage my project in the same Gitlab instance of my code. The greatest benefit is everything is connected, integrated and simple to manage than 40 apps
You started so good with text-based approach where having just txt/md files would be enough but then you moved Github issues and all the stuff built on top of git which is not even stored in the repo and inaccessible without Github (mb except wiki). Wiki can be replaced with simple doc/ directory in the root repo. And there is nothing wrong with writing HTML for something that is more complicated in structure than Markdown offers. HTML is not going away from us in any near future. In contrast to Markdown which can be replaced by any other markup language once Microsoft (the owner of Github) will decide to do that. Keep in mind that Github Markdown is already way beyond Standard Markdown and you might be already locked on GH's implementation of it. Also some Github actions can be easily replaced with git hooks and shell scripts. So there are still ways to improve to cut off more fancy stuff even more.
We agree on most of these things, absolutely. It's difficult to separate my purity argument for doing as much in plain-text as possible, with my practicality argument that GitHub (and other web hosts) have some features you're not going to want to miss. So, in this video, I propose a compromise. Yes, Issues, Projects and even PRs are outside of git, but because they are tied so closely to your repo, I still recommend them, as a concession to practicality. I still prefer GitHub projects to JIRA because it's the same tool, bound up closely to the repository, where the work is actually happening. My assumption is that you'll never change your git host, so these add-on tools (that are broadly similar in all GitHub competitors) are ALSO never going away. The Pact remains!
Git is not the end, while being the standard. There are VCS that do embrace storing everything together a-la github in the same manner as storing file changes. One of potentials is Fossil, but I'm sure there are more older and newer additions.
Markdown is more of a specification or convention on how to format text than a format in itself. It's simply more human readable than html and it's trivial to write a little parser for it. The rest of the proprietary stuff I agree, but I believe even if everything changes or ends the core data structure is preserved and easier to migrate than using some proprietary system.
I was a bit let down when the thesis of the video was "repo + web apps". All of product and project management can be handled in a shared and versioned directory hierarchy of text files. SyncThing is the 80/20 solution for this, not git.
I'm not so sure that all those github tools like projects, actions, issues and milestones actually abide by that plain text, never going away principle. Github isnt open source, and I dont know of any way to extract the data out of those 4 tools at all, let alone in a usable plain text format. Edit: apparently actions are actually plain text. +1 for actions.
It's difficult to separate my purity argument for doing as much in plain-text as possible, with my practicality argument that GitHub (and other web hosts) have some features you're not going to want to miss. So, in this video, I propose a compromise. Yes, Issues, Projects and even PRs are outside of git, but because they are tied so closely to your repo, I still recommend them, as a concession to practicality. I still prefer GitHub projects to JIRA because it's the same tool, bound up closely to the repository, where the work is actually happening. My assumption is that you'll never change your git host, so these add-on tools (that are broadly similar in all GitHub competitors) are ALSO never going away. The Pact remains! I'd love to learn more about git-native issues and projects, though my first thought is that if they're stored in markdown, you can build them in whatever editors you would like (as in the obsidian kanban screenshot at 7:19). The Unreasonable Effectiveness Of Plain Text
@@HazhMcMoor Actions are written in plain text scripts and config, saved inside your git repo, and they act on the plain text data in your repo. It's one of the superpowers you get when using plain text on git hosts (github is just one example), they all let you automate your workflows. Can't run too many scripts on a google doc 😀
I am relatively recent to your channel but so far, I love everything I've sat through. Thank you for sharing, and for all the work behind the scenes that makes it seem so convenient to your audience. Cheers!
(It's just me doing all this, you can safely say 'he"!) Here's my obsidian video: th-cam.com/video/DbsAQSIKQXk/w-d-xo.html I don't know how to tell you this, but... I think it's the most popular obsidian video on TH-cam?! I don't understand! :-)
I absolutely love and embrace this concept. Although github is the best for code-related stuff, the wording and tooling chain are sometime a bit too code-focused. I would very much like a git (or any better and backward-compatible source control system tbh) integration for non-code stuff.
The best tools in any branche of industry have a text based representation of the project at its core. Except for raw media or data that comes from measuring devices. They all store a parametric model of some sort and render/build it to produce the end result. Think of LaTeX, which still has a wide user base. And new generations of professionals that work with large living documents for publication still fall for the WYSIWYG trap and waste a lot of time applying simple changes. (LaTeX is old, but there are similar newer tools) So it is always: Editor->Model->Text->Versioning System->Build Tools->Publication.
I just stumbled across this, and it's brilliant. Very on-point and quite clear. I don't use Github to write or discuss with people, but it's a great idea. You're absolutely correct on the state of most collab software to be a messy, ever changing pit of wasted time. Not only that, but things like maintaining a current version of files for a project is hard to scale to many viewers. I saw this guy make a Github repo for his plugin preset files. It's amazing. Every few months I can go check the page and update my version without having to manually go through every preset or see which new ones were added, etc. I also appreciate the "use the tools you actually need" idea. Set things up for productivity and easy workflow rather than getting caught up in the minutia of tracking the progress. The fine line I suppose is how much to document on that progress. It's one thing to fix bugs or iron out things in the project itself, but I don't just wanna see "bug fixes and small changes" in my changelog either. Documenting stuff is fun or stressful depending on a lot of things, so having a simple methodology is a good thing. Subbed. Keep up the great work!
8:40 I started to hate these issues. When never managed to use them properly in the small company I'm working on. Insetad we sometimes create huge issues and add a list of hundreds of points into it. An issue like "Coding fixes", "Gameplay issues" or "Visual problems". Creating an issue is way too cumbersome for adding each little problem we found. Often it's just faster to tell the person who was responsible for it directly, or just to fix it oneself.
I loved irc. Plain text logs of conversations, grep and 2 seconds later I have something I talked about years ago pulled up. Try doing that with Discord.
Nice idea, but only for smaller teams consisting of programmers or other technically oriented people, willing to put all their documentation in the same place their code lies. I can't imagine, especially in corporate environment, how would you convince anyone who is not a developer to use terminal / GIT UI, learn what are branches, conflicts, merging, rebase etc. Programmers fuck all of those things up all the time, for non-technical people it would be like trying to learn black magic. As for "You can do this in your immediate team" part, eh... no. It still depends on the company policy. Sometimes you have to use Teams, sometimes Slack, sometimes Confluence alongside Jira. The bigger the company, the less flexibility you have on the matter. So again, smaller teams or solo projects? Yeah. Anything slighly bigger? Chances getting slimmer and slimmer.
Totally agree with you. This may be over-optimistic, but I think a big picture take away is that "in an ideal world, every team would operate like this," and obviously that's not the world we live in today. But with every generation of people, the average level of tech-savvy-ness gets higher and higher. Maybe at some point in the future it will be a lot more plausible to teach Git to every person on the workforce (or make it part of the onboarding process or education systems); and these changes to structure can be implemented in a wider scope. Just another way to look at it.
If there isn't a clear goal: how it'll work and what it'll do for devs + the bottom line + the company, the chance you'll convince exec/other teams/your own team to approve this massive shift in workflow is zero. The video sets up a foundation and focus that is required to start change in your company for your specific circumstances. As he said: no chasing the hype.
A lot of points you've made reverberate inside of my brain when I'm at work, thank you for putting this concept so eloquently. My team has no documentation outside of work instructions, which are absolutely inert. We have good network use though, I want to get my boss to embrace plain text documentation. It's also why love Obsidian so much. And Markdown in general.
Think outside the box: Don't think vscode and terminal git. Think Sparkleshare[1] and Obsidian[2]! If someone can learn JIRA, Figma, or Dropbox Paper, they can easily learn the github UI. I think there's a world here that can be explored! 1. www.sparkleshare.org 2. obsidian.md
This a programmers solution to a problem that involves many more than just programmers who are much less technical and have very different needs. Been leading tech orgs for 30 years now and the biggest challenge is often communication (and good leadership). But the solution is not plain text - at least not outside the pure tech teams. Instead several different worlds need to coexist with people well versed in several of them as translators.
You'd be surprised what people will be happy to learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!) I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface. It won't work for some people, I acknowledge. But it WILL work for far more than you might think!
8:52 markdown HAS NO STANDARD. There is NO compatibility between: - VS Code Markdown preview - Stack Overflow (they use standarized CommonMark) - Reddit (though they explicitly acknowledge modifications) - GitHub preview - Docutils Python library which can produce various output files based on Markdown input - any other tool that I have tried but don't remember Markdown's lack of standard is the very reason I resigned from this format for any pseudo-rich-text project (including generation of pages on my own website). It has no standard, therefore it is NEVER fully reproducible across different tools. If you want stability and reproduction, use CommonMark, Kramdown or a different format like RestructuredText which all have precise specification. Besides this, a really good video. Looking forward for more non-Rust content.
Thank you for your kind comments, I've started doing a blend of programming and non-programming technical topics, 50/50, and everyone's responded really well, I'm delighted! :-) However, regarding MD, I cannot replicate your assertions. Perhaps it was true in the past, but standardisation has happened since your research? Everything you've described either uses the Commonmark specification or is not markdown. The Commonmark website (commonmark.org/#when) says that all these use Commonmark: Discourse GitHub GitLab Reddit Qt Stack Overflow / Stack Exchange Swift VSCode uses Commonmark: code.visualstudio.com/Docs/languages/markdown Docutils uses ReStrucutredText, not markdown RST is not related to Markdown, it's a different system altogether. There is a well-used plugin for Docutils that enables Markdown support, and it uses Commonmark: github.com/executablebooks/MyST-Parser My favourite markdown editor and notes system that I build these videos with and store my whole second brain also supports Commonmark, have you seen my video on Obsidian? It's *incredible* th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
@@NoBoilerplate I dropped Markdown usage around 2 years ago but from what I remember I had trouble reproducing lists (or any similar nested block that uses spaces and/or indent) and not every tool agrees whether to use ``` or 4-space indent for code blocks. Then inline HTML (which is kind of againt Markdown idea) is another problem - yeah, it shoudn't be there but a lot of GitHub projects do put it inside md files and GitHub renders it too (while other tools do not). Also, my personal problem with Markdown is that nesting elements sometimes causes problems (like lists in lists or bold/italic). RST does it way better and that's why I use it for my website - additionally the ability to have custom keywords is great for extensibility. But RST is more complex and definitely not worth if you want just simple notes. Regarding Obsidian - just watched the video but haven't found anything extraordinary. Perhaps because I was already presented Obsidian by a coworker (especially the graph feature) and what can I say ... It's a really good note-making tool for non-programmers. Personally I use Notepad++ and unix GNU tools (especially grep) (all inside a repo) which replicate some of Obsidian capabilities. I rarely feel the need to link one note to the other - I tend to organize my knowledge in directory-hierarchical form. When I do need graphs, I write dot files and use graphviz to generate images (VS Code has a plugin for it) - such graphs are typically data not notes. Still, I would recommend Obsidian to non-programmers.
I would love to see a video from you about managing a calendar across a team. I am a firm believer in using tools that are popular, fast, and always available, but I’m not sure how to best handle a calendar. I work in a small company (less than 10 people) and my boss has this philosophy- if it isn’t in his iPhone iCloud calendar, it isn’t happening. As such I now have a calendar app that’s chock full of meetings and events that make it hard to get a glanceable look at my day. And if someone wants time off - put it in your calendar that everyone else is subscribed to. It feels like there has to be a better way - but I’m not sure what would be as seamlessly integrated with my boss’ iCal. I’m not a programmer in the slightest, but I really love your videos. Thank you for making them!
People regress back to general-purpose tools they already know how to use, and are general-purpose enough to kind of work for everything. Calendars, spreadsheets, post-its. HR systems that have an approval process for time off often have an ical link to subscribe to. Perhaps your boss could do that? Good luck there
Thank you! I'm convinced the benefits can extend to most digital teams, not just programmers! Here's something inspiring: github.blog/2013-09-17-3d-file-diffs/
@@NoBoilerplate Thanks, looks interesting. An other thought re plain text, maybe a tangent here: It is kind of curious that we use plain text to command AI to generate PICTURES ... I don't know why this feels significant but I think this is something to ponder.
@@Axel_Andersen Agreed, the first time I got chatgpt to solve a networking problem blew my mind. But do remember, it's only pretending to know what it's talking about - use your team of 1000 interns carefully! My video on this is here btw th-cam.com/video/glpR1MD1UoM/w-d-xo.html
More meetings does not increase productivity; meetings are the layer 8 equivalent of thread synchronization, and Amdahl's Law very much applies to multiprocessing at the human layer too. Meetings are the result of some other business process failing. Instead of institutionalizing yet another weekly meeting to fix what the failing process broke, change or replace the failing process. Thank you for coming to my TED Talk.
"These are Hats, not roles"... Amen! Thanks for making me believe that I am not alone in thinking that ScrumMaster is a not by definition a role... 🎉😊❤
This was extremely useful, thank you for your concise and informative videos. I first subscribed due to my interest in learning more about Rust, but now your channel has become goldmine to me for general purpose information on effective software development strategies. Keep up the great work.
This reminds me of my last internship. Major problems faced before and the decisions made for it was nit written anywhere. Like the ongoing migration frim SQL to NoSQL database and whst was does before making that decision was undocumented. A senior told me why it happened but left out a lot of details. I has to ask around a lot to know why things were the way they were.
My entire career can be summed up as "convincing people that they need to simplify, not add more and more plugins, tools, and toys to their workflow" UNIX Philosophy applied to systems and processes. Data portability. Common and uniform data formats. The keys to speed, efficiency, cost savings, and adding value to existing data is the same: Simplicity.
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!) I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface. It won't work for some people, I acknowledge. But it will work for far more than you might think!
@@NoBoilerplate I organize and lead an non profit group, that focus on creating tools on non violent communications and doing outreach on the streets for animal rights. I also do this to find, test and practice tools that are capable to create societal change for the better. My issue - I am not tech savy. And I tried all the tools. Also coming to the conclusion that markdown is the way to go - although I start to like org mode... But for now, I am working logseq and Tana for my personal pkms.. But I still have the issue, how share my work/skills/knowledge in the best, "open" and secure way. Notion still isn't it - and my work on Insta isn't it either... I would pay you, for giving an course/lecture for an multidisciplinary team on teaching how to use Git.....
Git with merge workflow is easy to explain to anybody. The hard part is to help non-technical colleagues to select a plain text editor that's actually good. And no, Notepad or Word are not reasonable options for writing plain text files. That said, I think rebase workflow is clearly superior to merge workflow if your team can handle it.
Obsidian doesn't have to last, the Open-Source community (led currently by Logseq) is quickly building open versions of this kind of app. As history has shown us, the Obsidian company will inevitably end or be bought and become bad at some point, and yet we will exceed their vision with open source. The reason I'm so relaxed about this, specifically in Obsidian's case, is that the data storage method of Markdown is EXTREMELY portable. I have already been delighted that my whole Obsidian Vault can be used unaltered (and even simultaneously!) in Logseq. The Logseq plugin ecosystem lags, Obsidians, but have you noticed how nearly all the Obsidian plugins are already open source? I'm optimistic, either Obsidian will become open source, or Logseq (or others) will become Obsidian :-) My video on Obsidian, if you've not seen it, is here: th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
I rarely find videos that I agree with every word of you have articulately summed up what I’ve been trying to say at work for years. You have made my day because I can send this link to my colleagues instead.
I'm delighted! With this channel, I hope to nudge the needle of the world in a small way. :-) Did you see my agile video? A similar video on that: th-cam.com/video/9K20e7jlQPA/w-d-xo.html
@@lawrencejob There's never been a better time to start a channel, I think the audience are tired of the same high-energy lolrandom meme-filled videos and grateful for some calmer content! If you'd like advice and/or a push, that's just the sort of thing I could coach you in a mentoring session!
Git is really nice and by far the most polished revision control tool out there. And (like most tools) is the most effective when you take your time to understand why it works the way it does and use it 'idiomatically'. All in all, Git is _the choice_ you should make when starting a typical project today. But will it always be this way? I think the most interesting competitor that's shaping up is Pijul. It takes some of the theory behind Darcs, but makes it scalable and efficient. It simplifies the workflow, effectively getting rid of any need to rebase and making merge conflicts happen only when truly necessary. Even though it is based in some formal ideas taken from pure math (category theory at that lol), it really seems to be easier to wrap your head around even for a non-technical person. Pijul is still an experimental tool. You can do real work with it (I've successfully used it in one little personal project already), but I'm not gonna argue everybody should switch to it as fast as possible. There are still rough edges and missing niceties we can be used to coming from git. Also, it's written in Rust.
Totally get what you're saying about markdown. I spend far too much time in Excel correcting formatting from something that colleagues pasted in from elsewhere. Inconsistent fonts and text sizes make spreadsheets a bitch to work with. Would love it if my spreadsheets could be locked down to a single font and text size. Formatting stuff in MS Office products is an absolute productivity killer.
As a student, I don't think this is feasible for me. I can't really expect group members to learn git, github, and what the hell a pull request is. I'm sold for all my personal project though
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!) I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR.
@@w花b The stakes are just too low for me to push that hard Changing how you work requires an amount motivation/excitement, and for small school projects, nobody really cares enough (I certainly don't)
Such a great and rational video on resiliency and self-reliance. I’m also sick of dealing with the whims of companies and their walled gardens (tempting as they are).
Well spotted, I removed an entire 4-minute section from my original draft and replaced it with that teaser. This deleted section now forms the basis of a new video, the draft title of which is "THE UNREASONABLE EFFECTIVENESS OF LINUX WORKSTATIONS" ;-)
I feel that all your emphasis of using all the github-specific features (issue tracker, actions, project view, teams, etc) defies most of your plaintext argument. Those are just another online software suite of management features, which are not portable, and not at all plaintext downloaded, offline files. Maybe I was expecting a method for managing tasks as a git repo itself (moving files of notes around, etc)
It's difficult to separate my desire for purity in doing as much in plain-text as possible, with the practicality that GitHub (and other web hosts) have some features you're not going to want to miss, but can't yet get in plain text. So, in this video, I propose a compromise. Yes, Issues, Projects and even PRs are outside of git, but because they are tied so closely to your repo, I still recommend them, as a concession to practicality. I still prefer GitHub projects to JIRA because it's the same tool, bound up closely to the repository, where the work is actually happening. My assumption is that you'll never change your git host, so these add-on tools (that are broadly similar in all GitHub competitors) are ALSO never going away. The Pact remains! I'd love to learn more about git-native issues and projects, though my first thought is that if they're stored in markdown, you can build them in whatever editors you would like (as in the obsidian kanban screenshot at 7:19). I'm putting my ideas together here: github.com/0atman/markrequests
There was a magnificent word processor for DOS called “Word Perfect 5.1” (invoked by typing in wp51) which had a mode to display (and edit) all the control characters that accumulate, when you start adding italics, underline, character fonts, etc. It was amazing, the file would become positively infested with italic-on, italic-off, italic-on, italic-off, just groups and groups of these switches accumulating between characters. What I learned is to eliminate all that I could use good old Microsoft Notepad. Copy the entire document with Ctrl-a, Ctrl-c then in Notepad execute Ctrl-v, Ctrl-a, Ctrl-x. That pastes the content (which rejects ALL format codes), selects it all again, then cuts from Notepad. Then you can replace back into Word Perfect (or Word, or any other word processor) clean of all formatting. I use only the .txt file type, I don’t have any use for markdown.
I'm sorry to hear you don't like the abundance of meetings. Maybe drop me an invite and let's synchronize on this, maybe we could organize a huddle and have a brainstorming session, or even a roundtable conference call (with mandatory cameras on)!
Where have you been all my life! I knew git is great, and I knew in the back of my head something was deeply wrong with my company's documentation hygiène but this just blew my mind entirely. Totally bringing it up Monday.
On topic of offline access and plaintext, showing all features of GitHub going a very different direction as you can't access any of that either offline or migrate to other git host easily.
It's difficult to separate my purity argument for doing as much in plain-text as possible, with my practicality argument that GitHub (and other web hosts) have some features you're not going to want to miss. So, in this video, I propose a compromise. Yes, Issues, Projects and even PRs are outside of git, but because they are tied so closely to your repo, I still recommend them, as a concession to practicality. I still prefer GitHub projects to JIRA because it's the same tool, bound up closely to the repository, where the work is actually happening. My assumption is that you'll never change your git host, so these add-on tools (that are broadly similar in all GitHub competitors) are ALSO never going away. The Pact remains! I'd love to learn more about git-native issues and projects, though my first thought is that if they're stored in markdown, you can build them in whatever editors you would like (as in the obsidian kanban screenshot at 7:19).
this is cool to watch. i'm a software dev, and i used to build my own tools to manage this problem, with all kinds of wonderful additions. But i kept making new ones, whenever updating the old ones was too much work. then i noticed that i am slowly 'devolving' into just being git. so now i just use Git.
Superb content as always - thank you for reminding us of the importance of grounding decision making in truth and documenting it in processes like ADR in easily accessible future-proof tech that's plain and simple.
The most beautiful thing about working via Git Repos is that personal local environment doesn't matter as long as it works with git I don't care which editor for files you're using, use what is best for you As long as it can meet the Git Standards of Style while pushed If you're finished with your work just push it up into the Repo and the Project Management can merge in their own time, while allowing multiple versions of one project to choose the best before merging into the permanent version
BTW, I found this cool little thing called PIJUL, think Git but built-in RUST Very simple & easy-to-scale & FOSS & focussed on patches instead of versioning (I can't post any links here cuz YT)
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!) I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface. It won't work for some people, I acknowledge. But it will work for far more than you might think!
“The Jira Effect” I felt that one hard. I used Notion for a long time for personal note taking and project management. Absolute horror after the 10th project. Everything was cluttered and we had legacy structures everywhere that never got updated. We still use a PM tool, but a more minimalistic one and I move personal note taking into Obsidian
I'm delighted for you, I make all my videos in the Advanced Slides plugin in obsidian, my whole second brain is stored in it, and my most popular video, somehow, is an intro to it! th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
I love git, but getting anyone but a Programmer to use it is just unrealistic. Github Desktop should have been finished / feature-complete along time ago, until then its a dream.
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!) I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface. It won't work for some people, I acknowledge. But it will work for far more than you might think!
I like the idea of keeping documentation and rules, etc. as text file/markdown, but how would one deal with graphics? A lot of technical descriptions in particular greatly benefit from having diagrams explaining the rough outline of things, but I do not know of a good way to embed graphics in a text document _in an editable way_. Any ideas?
How about drawio or mermaid? The interesting thing about drawio is that you can generate a png or svg which in itself embeds the xml that made it. So you have a myDiagram.drawio.png which you can embed into markdown AND edit with drawio. Then there is also Mermaid, which many Markdown Readers implement. It uses the code block to define diagram structure
As Toan said, mermaid is FANTASTIC, and natively supported on github and obsidian docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams normal images are fine too, they preview well, though they don't get visual diffs (yet! though there are third party actions that do this).
amusingly "ADR" also stands for "alternative dispute resolution", which formally is some other thing that has nothing to do with Nygard but sounds like it could conceivably be related
ERRATA
- It's difficult to separate my desire for purity in doing as much in plain-text as possible, with the practicality that GitHub (and others) have features you're not going to want to miss, but can't yet get in plain text. This video represents a compromise.
- I'm SO SURE I'm wrong about Odysseus/Ulysses that I'm going to put this here right now: en.wikipedia.org/wiki/Odysseus
- I couldn't resist adding the effect at 3:00. That's Saike's glorious "Abyss Reverb" for Reaper.fm, the same as I used for my recent Ambient album: th-cam.com/video/nkdRLtubbII/w-d-xo.html
- 11:50 I did not say the phrase "style guide enforcement" very clearly, apologies. I've manually fixed the subtitle.
- Linus did not create Git because existing version control systems wouldn't scale. He did it because the proprietary BitKeeper service he was using decided to revoke its free licence offerings.
Should the sound effect info go in the ERRATA?
@@TheSast I assume that it'll confuse a few people who might say "the sound is broken at 3:00" so I put this in to fix that before it happens! I hope it's fun!
11:50 you can offer _what_ enforcement? I can't understand this word.
@@AexisRai I was struggling hearing this one too, so I looked it up in the script (yay opensource)
> notes: You could also, for example, set up style guide enforcement, blocking the PR if the phrase "on premise" has been found.
@@aviinl1 Thanks. Am I correct in reading that as some kind of joke? I don't do enough of this kind of thing to know why you'd block "on premise" but it sounds like somebody advertising themselves in your PRs.
“You must have the discipline to do less” Me on the couch: I’m a boss
ikr. Thats what I noticed too.
Sometimes its just so much easier to "do less".
Just ship a product out and get it done with.
Then you can modify it as you go.
Its software. Its easy to change shit.
People are afraid of having to refactor whole codebases for no reason.
We should work on tools to make sure its easier to upgrade software. Not to make software faster to make.
Like a BAUS~
Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.
Teach me o master
Me rotting in bed for two weeks after surgery: I'm a multidimensional deity.
Oh my god, I just hate it when companies think more meetings will make the team more productive.
I'm sorry to trigger our group PTSD on this topic XD
I genuinely believe it is a subconscious thing in most managers' head that they really are barely doing anything productive, so they force their presence on the actual labourers.
All my respect for the good managers of course, but so many of them are horrid.
yeah, lets put this global mutex on the the entire company's process, sure that will make things fast... I revolved my eyes so much
@@monad_tcp that's a really good way to think of it. THEY'RE SO EXPENSIVE TOO
REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
The comp sci department in my college uses git for everything. Every old test/assignment, syllabus change and bibliography is there for all to see. As a student i love the ease of access to materials and the ammount of old stuff to study from
Imagine whole companies or governments that did this! The dream!
@@NoBoilerplate Yeah, when governments do this, and contracts (and EULAs and such) are done this way, that'll be a better world indeed.
Oh boy, a company putting their ToS and stuff to GIT so everyone could see what was changed instead of getting an e-mail of big wall of text without actually knowing what was changed due to not everyone having absolutely perfect memory let alone actually reading more than one ToS ever, if that
@@shaderunner7.0 oof, that'd be so good for transparency!
@@shaderunner7.0 Yeah, it'd be an amazing goodness, no?
“storage is cheap if you’re smart” looking forward to seeing that video
Well spotted, I removed an entire 4-minute section from my original draft and replaced it with that teaser.
This deleted section now forms the basis of a new video, the draft title of which is "THE UNREASONABLE EFFECTIVENESS OF LINUX WORKSTATIONS" ;-)
HYPE
@@NoBoilerplate nice! the Milan Kundera reference makes me think you’ll spend the first chapter exploring whether it’s even worth saving any data at all 🤭
@@NoBoilerplate really looking forward to it. I resonate a lot with your approach and the storage issue is something I am just about to get started on, so I'm looking forward to your take on it!
I just got 36tb of hard drives for 300 dollars, manufacture recertified enterprise drives are great
It would be really cool to see lawmakers use git in this fashion. All law would be in plaintext in a repository for everyone to see. Government would create a pull request, parliament would comment on it and then vote on whether it will be merged. The justifications for that law proposal or change would be plainly visible in the commit messages and you could see a complete history of them. Any time you wanted to see why a certain law exists, you could just run git blame on it and read. You could possibly even have regular citizens commenting on the pull requests what they think of the new proposal.
a utopia!
@@NoBoilerplate Unironically this would make the US Senate / House divide on sister bills so much easier. It literally would just be merging two branches, no need to make a complete rewrite and try and sync things up.
Do you one better while we're at it: Anarchism - as in "no authority you didn''t consent to"". Nothing more democratic than every person governing themselves.
@@marsjune6716 That's not democratic, democracy is the will of the many outweighing the will of the few, for very good reason.
For example, a world where my neighbours don't consent to education and healthcare is a bad world for me, not just because I want them to be healthy and educated in an abstract way. It's bad for me on a practical level. In the words of John Green,
"We have discovered as a species that it is useful to have an educated population. You do not need to be a student or have a child who is a student to benefit from public education. Every second of every day of your life, you benefit from public education.
So let me explain why I like to pay taxes for schools, even though I don't personally have a kid in school: *It's because I don't like living in a country with a bunch of stupid people*"
@@NoBoilerplate That's not really how anarchism works. It doesn't imply the lack of education or healthcare, rather in this context it believes in agreement on how these things are achieved, rather than wasting resources into coercing everyone into a pre-made routine that just isn't useful for the place it's used.
I don't hope to explain it to you in comments however, you're much better off reading about it elsewhere.
Stand up meetings are good for two things in my experience so far:
1. check if anyone is blocked.
2. check for duplication of effort. i.e. make sure two people aren't doing two overlapping things.
1. Just post it in the group chat
2. Just look at the kanban board
What's the point of keeping all of these written channels of communication if people can't ever use them properly because they always need someone to tell them on a videocall when there is a problem?
@@josevargas686 the true value of the meeting is *shared attention*. It is a coordinated moment when the whole team pays attention to the same thing. This is expensive, but outperforms any asynchronous communication method in resolving blockers. No matter who needs to get involved in unblocking, they are there to immediately speak to their ability to do so. If you make this process async, it can sometimes take an hour or more to sort out what would have been solved in a few minutes, as people respond to things whenever they are available.
It's expensive and unpleasant, so keep it super short, but it can deliver a ton of value in a very short time.
I've enjoyed the ones that last for 90 minutes where most of the talking is the PM ranting illustrated by his throwing things at people. It was very Agile.
3. Notice when mental health interventions may be indicated
@@stevecarter8810That is unironically the most important part about it lol
Recently my team had to migrate to a diffrent "workspace" in databricks and we were unable to migrate models, workflows, and experiments. I want you to know that becasue of this video I will be pushing for saving things like these in as simple, transparent & popular format, within a git repo.
Exactly the kind of problem I wrote this video to try to address. I've worked in industry (including government) for 15 years, and have lost count of the number of times this has happened!
Would love to hear more about the stand up meeting you described. I find they often just turn into a status update meeting and everyone is just waiting their turn to talk before mentally checking out
There's nothing to it, really:
- walk the board backwards
- strict time limit per ticket (30s or 60s works for me)
- finish up with blockers
- go back to work
@@NathanHedglin I'm relaxed about the medium, many distributed teams need to do async standups, and this is one of the areas I don't care about slack's impermanence - the status updates are only useful today, so perfect!
@@NoBoilerplate About the second point, the "strict time limit per ticked"; what do you say about the ticket other than "X is working on it"?
If the task was already clear and agreed, and it doesn't have a problem that you are hoping someone might have the solution, then why does everyone need to know about it?
There's lots of ways of doing it. Requiring that there be a specific reason in order to be allowed to schedule one. Making people stand on one leg while talking. (Obviously, people who can't stand due to disability should probably be given an alternate option.
Status meetings serve absolutely no purpose. If you're just reporting status, that can be done without everybody being there at the same time and decent project management system, or a text file, can do that just fine.
Every time I watch one of your videos I get convinced of something, but this was the best one. Less is better. In the world of productivity tools, the minimal setup, the simplest workflow is always the best. Its hard to acknowledge that, we all love the new shiny thing. But it is the truth.
"We all love the new shiny thing" reminds me of JS framework frenzies, lol
Thank you! Yes as I get more experienced, I'm less impressed by the shiny new things, and more impressed with the proven things that stick around.
Hot take: VS Code is nice, but I'll still be using vim when the world moves on to the next hot editor!
(cold take: I, of course, use vscode for a bunch of things, liveshare especially is incredible!)
@@Rudxain one of the most important skills of a good programmer is a healthy resistance to using new toys. (The most important rule is to foster humility)
“An idiot admires complexity, a genius admires simplicity” - Terry A Davis
I work for a unicorn software company, and this vid describes our workflow to a tee.
Instead of growing via series funding and then IPO like most successful startups, they focused on efficient workflow & management to remain profitable without relying on investors, and this is pretty much what they came up with.
It works great, but it requires long-term vision, which can be hard to find in a world running on short-term profits.
Edit: also, as a bugfixer, I cannot even imagine having to work without git and especially git blame.
wonderful to hear!
The quote at 3:06, "The difference between science and screwing around is writing it down," although most famously said by Adam Savage actually originated from Alexander "Alec" Jason a firearms specialist for the show. Adam talks about it here.
th-cam.com/video/2WFFhicVeXI/w-d-xo.html
He starts explaining the quote's origin at 8:35. It's Adam Savage so naturally he goes on a tangent before finishing the story but it officially starts at 8:35.
Also, there are differing versions of the quote but from all the sources I could find they all start with "the *only* difference...". The version of the quote said by Adam Savage on MythBusters is
"Remember kids, the only difference between screwing around and science is writing it down." However, in the video linked above Adam quotes Alexander Jason with saying "The only difference between science and screwing around is writing it down." Obviously the later is prone to inaccuracies, as he is recalling it from memory. Adam saying the prior version of the quote can be found here.
th-cam.com/video/BSUMBBFjxrY/w-d-xo.html
edit: spelling & minor revisions
oh very cool! Thank you for that video!
I love how this community is so on point with the scientific standards
@@JhonIdrovo-the-human I try to get the source of quotes and data as best I can, you'd be amazed at how many 'sources' are just urban legend!
When I make inevitable mistakes, my pinned ERRATA comment keeps me honest. You can't edit videos after publishing, sadly.
And the difference between writing it down and science is someone actually correcting what was written down once they have improved data.
I wonder if Linus had any idea he would have such an impact on the world.
Hell yeah! Dude has built some of the most important pieces of software till this day
Yeah, I like all of his TH-cam channels
He just basically copied Bitkeeper, driving it to irrelevance in the face of free and open source competition. Don't get me wrong, I appreciate that I don't have to pay for a brilliant distributed version control system, but he didn't invent anything, just reimplemented a great idea as free software.
@@victor1882 we’re talking about Linus Torwald not Linus tech tips
@@biggerben8276I think they were joking
I'm impressed you didn't mention RFC repos as a real-world example of plaintext organizations
We're living the result of "everyone uses a different format, what we need is a new format!" XD But yeah, plaintext markdown, restructured text, etc. Totally agree. Great take.
Thank you!
We should do all communication in latex.
Its more professional than markdown or plaintext
/s
@@marschma heh, I do have a soft spot for LaTeX, but the most I do with it these days is embed a few equasions in my obsidian markdown files with it's built-in suport for in-line mathjax, eg: $$ \frac{1}{5.4} $$
FUN FACT: DID YOU KNOW that the creator of TeX ALSO popularised big-O notation? Donald Knuth has had a huge impact on our industry! en.wikipedia.org/wiki/Donald_Knuth
(my video on Obsidian.md is here if interested: th-cam.com/video/DbsAQSIKQXk/w-d-xo.html)
@@marschma It's probably overkill as most people don't need more than italics, bold and different fontsizes. Latex and the like can be incredibly helpful for various technical fields though. Certainly nicer to read than the stuff that was in books from the '70s and '80s when typsetting was being computerized in a rather crude way.
Plain text -- no images -- has held me back in the past. I'd be fine with anything with images though. Honestly, HTML 2-3 were actually kind-of good, but people started whining about details which worked out just fine in practice. Separately, some page composition software severely overused tables for layout and, similar to the earlier response to Don Knuth's complaint about the overuse of GOTO, this led to a jihad fanatically eliminating all use of tables for layout. I remember the time mobile browsers could restructure desktop web pages and still have everything in the right order. That was tail end of the era of HTML tables. Now, browsers are Wrong if they put a single character anywhere but where The Page Designer intended.
Sorry for the rant. Old frustrations coming up. I did get on all right with markdown for a while, but last I heard it was not standardized. (Not surprising when its author explicitly didn't want it to be machine-parsed.) I don't remember any markdown implementation supporting bold italic, which is not a serious fault but seems rather retrogressive to someone like me who enjoyed the look of bold italic from books printed before I was born all the way up to the 00s.
I use my old Raspberry Pi as a provate git repo host on my LAN. Among many other repos, it includes a repo in which I keep my dream journal, which is a plain text file that is formatted with the date followed by paragraphs, with each entry separated by new lines. I'm definitely a fan.
That sounds great! Tip: open that git repo as a new 'vault' with Obsidian.md, thank me later.
(my video on Obsidian is here btw th-cam.com/video/DbsAQSIKQXk/w-d-xo.html)
I took a video game programming course in college, and when we were given a group project, I started by taking a few days to learn some git (because I had heard that it was great but had never actually used it), and then about a third of the rest of the time I spent on the project was dedicated to trying _and failing_ to teach git to my teammates. 😩
Git the CLI has a lot of sharp edges, for sure.
You'd be surprised what people will be happy to learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface.
It won't work for some people, I acknowledge. But it WILL work for far more than you might think!
So what was the problem? .git file in wrong folder?
Moving to plain text, enforcing PRs, and making teams work through merge conflicts was a learning experience for everyone at a previous job of mine. However, it also exposed who the good teams were, and which teams were poor performers but were hiding behind issues in proprietary tool sets. Some middle management was very unhappy, as rhey couldn't coast and get their bonuses.
EXACTLY! git and GitHub aren't difficult to learn, but it exposes people who don't WANT to learn. You don't need those people.
@@NoBoilerplate Years ago I was with a company who used a file based archive system. I could be a bit confusing but it worked well. However, a couple developers REFUSED to learn it. A config manager had to check out their code for them and then commit it to the archives. Such a pain.
@@NoBoilerplate I agree that this is mainly the problem, it's just unfortunately a massive problem. Corporations are filled with people who refuse to learn anything.
When I just saw the video title, I was quite confused, because in my brain "plain text" means "no markup whatsoever" first, and only then "not a binary format"... Kind of like if you use fenced code blocks in said Markdown with language "plain" - it won't highlight anything.
But I do agree, using git for "just texts" is so convenient. I'm using Obsidian for note keeping, and one of the folders is auto-converted into a static website using MkDocs. Try to do that using Google Docs or local docx files as documents!
This video is unreasonably persuasive for something I randomly stumbled upon, and I’m tempted to forward it to every project manager I’ve ever met. Looking forward to more content like this!
Thank you! Here's another video of mine in a similar vein, about agile: th-cam.com/video/9K20e7jlQPA/w-d-xo.html
I know from the title this is gonna be my next cause I'll annoy all my friends with for a week.
Even though I don't agree with you completely that storing all documentation a diverse and distributed team needs in git is a good idea (I'm currently getting accustomed to jira/confluence after working with no docs) the message in all your videos, and this in particular, is great, sound and sane.
Make things that work. Especcially through time.
I think this method of organisation I've stumbled upon by accident while looking through your gh is a must for a team starting out.
Thank you for your work and contribution. It's so great seeing other creators adopt your style of presentation. Makes me hope we can have focused no-nonsense content
Thank you so much for saying so 😊
Torvolds did not create Git because existing version control systems wouldn't scale. He did it because the proprietary BitKeeper service he was using decided to revoke its free license offerings. It was then the lack of comparable _open source_ equivalents that spurred him to create his own.
The FOSS community had been warning him of the possibility for ages, but he didn't pay any attention to them, until it actually bit him on the azz.
oh interesting! Thank you for the correction, I'll put it in the ERRATA :-)
What's also interesting to me is that we had a sort of Cambrian explosion of distributed version control systems around that time. Before git came along we already had mercurial, darcs, monotone, bazaar, and so many others I've long since forgotten.
I was a big fan of mercurial and continued to use it after git was already taking off until all of my colleagues insisted on using git and forced me to switch.
But Linus didn't like the workflow or features of these for the kernel so when bitkeeper bit him in the ass, as you pointed out, he decided to make his own.
It's funny to me that all of those other general purpose dvcs' didn't work for Linus and the kernel but git does seem to work ok for general purposes.
This video highlights exactly the main problems I've had with low-code solutions: 1) poor version control, and 2) no fast and powerful text replacement tools. The amount of time I could have saved if I just had regex based search and replace...
the world outside programming could be SO enhanced by the techniques we employ day-to-day, but people tell me "normal people won't understand". Rubbish!
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
It's kindof obscene that regex is not a standard concern for all low-code solutions. They're mostly trying to imitate either a spreadsheet, fancy word processor, or a database. All of these tools would 100% have an intuitive find+replace feature. So why on earth don't low code companies, who are trying to get people familiar with these tools to use their proprietary thing instead, think to implement search as one of the first things they do??
I love the idea of regex, but when I used to use them all the time, I got them wrong often, in the stupidest ways. Sometimes, after years of using a certain feature correctly, I'd forget it existed. Some peoples' brains just don't do accuracy. I still use regexps, just less often, with more care, and in an environment easier to debug than the command line. An editor with undo is fine, so long as undo works on all the files. Very occasionally, I'll use a more verbose language instead, even if it's slower.
I've tried many task management systems. I'd never stick to any of them. All of them had too much friction when it came to adding tasks, modifying, rearranging, or viewing them. I would overtime slowly drift from them. Org-mode, for me, has finally presented a system that I've been able to stick to. Performing all the actions I need to is so effortless that I never feel discouraged to engage with it. It's seriously allowed me to organise my life in a way that I never was previously. The fact that it's all written in plain text means that I can edit and format any project in a way that feels natural to that workflow, rather than having to stick to the opinionated constraints of a graphical application.
How’s that for friction? 😅
I adore org-mode and ran my life on it for 2 years, writing the first few seasons of Lost Terminal [1] in it.
Due to the lack of satisfactory mobile options (the best is orgzly with syncthing, and that's very poor) I switched to Obsidian.md and have never looked back, it's WONDERFUL.
If you don't need mobile editing, you can stick with org-mode. If you do, then my video on Obsidian, is here: th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
[1] th-cam.com/video/p3bDE9kszMc/w-d-xo.html
@@NoBoilerplate I'm actually rocking a strange amalgamation of org mode and obsidian. Org mode for task management and obsidian for everything else. Be-org is an okay mobile app for org mode task management. I definitely wouldn't use it for notes though. Obsidian has become my primary method of storing long-term information. The Obsidian mobile app is far better than I could've imagined. It's as feature-full as the desktop client.
@@NoBoilerplate I can live on mobile without my fancy org-roam graphs, and I was able to get Logseq to play nice-ish with Dailies, so I can just document anything i see or think about on the go and then turn it into something more once I'm home.
10:10 I'm happy how we work in our small company. Everybody knows the goal, everybody is available any time, when somebody has a problem, they immediately tell it to someone, if someone has an idea (normally the boss), they just tell it, if someone needs something from somebody else, they also just tell them.
Same here, it's amazing. No coasters on the job either, just competent people that work towards a common goal to their best ability.
I have found that most teams producing bad software are, in fact, the same in one important way: The team diminishes and dismisses what their users say their priorities for the product are and instead the team decides to focus on what the team members want to work on.
Absolutely, the core of doing agile right. Here's my take: th-cam.com/video/9K20e7jlQPA/w-d-xo.html
Can confirm
Precisely. Anything from bad video games to bad web app updates can be summarized like this.
I'm a player of the game Sea of Thieves. The game has gone downhill, largely because the company is listening to players too much. There's definitely a happy medium to be had.
@@HonestAuntyElle Ok, yes, that's true. Not every idea that the users have is right. Sometimes you have to protect your customers from themselves.
9:50 If you’re waiting 24 hours to get unblocked, those 24 hours (or probably 8 work hours) are most likely wasted (unless you were able to jump to another task and do it equally effectively). Don’t wait an entire day for some holy meeting, instead *talk* to your teammates to get unblocked much sooner. Waiting for the stand-up might make sense if you became blocked shortly before the meeting, but it’s a bad idea otherwise.
Of course, but the standup guarantees that the 24 hours is a maximum, even if a communications breakdown happens.
@@NoBoilerplate If someone fails to talk to teammates in private/over text, will they be brave enough to talk to the entire team in a meeting?
I am an geospatial engineer still in school. I got onto git mainly because of very convinient way of storing my .config files for different programs (iam a ricing adict) and because of easy and automatic hosting of webpages (learning web cartography). Now it helped me to get a job, because i could showcase my projects very easily (link in CV pdf) and the interviewver was pleasantly suprised by me knowing how to work with git and github (its not a norm in our field - only in the developement side of things). Now I am shifting more and more of my organisation and general knowledge keeping to git. I want to shift my obsidian stuff to git and other things (would appriciate video on that topic). Anyways using git and knowing it was only helpfull for me.
I'm delighted to hear this, it bolsters my opinion (expressed in this video) that git is a tool that can enhance any field! BTW I don't know if this will eve be useful for you, but GitHub can visually diff STL files: github.blog/2013-09-17-3d-file-diffs/
I wasn't aware of this GitHub feature. It's little bit different however I deal with 3d data, but more in the programatic processing side, rather than creation.
If we go little bit abstract, I think that the git workflow of adding staging and pushing changes should could be added to any digital work environments.
@@janhorak5363 It's an exciting avenue that I don't think has been properly explored:
I've not been able to find a list of all the file types that GitHub can diff, but I wonder what else is possible! Images at least are previewable, and I've seen some github actions that visually diff them, which is cool.
Well I havent explored it much, but most common 3d graphics file format glTF has a JSON like structure which links to textures and other stuff, so in theory diffing the text part should be possible. @@NoBoilerplate
This keeps popping back into my head ever since I watched it. I'm now forcing myself to store all notes and code snippets and whatever else in a Github Wiki.
So far it's working well, thank you!
Fantastic! Here's a tip that might revolutionise your life: Clone that gh wiki (link at the bottom of the wiki page) and then open it as an Obsidian.md [1] vault. The link formats are the same, and you get the best markdown editor on the PLANET!
[1] th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
I'm a co-op for a large company. I've spent significantly more time in meetings than I have doing any work at all. I have not been impressed with their agile work style at all.
Meetings are poison, here's my take: th-cam.com/video/9K20e7jlQPA/w-d-xo.html
9:58
"I didn't say the PM or DM or scrum master or whoever facilitates [a standup meeting]. That person doesn't exist in
my team. These are not roles, they are hats."
You've brilliantly and concisely put into words what I've always felt. Individual team members can handle moving their own tasks on the Kanban board, closing their own assigned Issues, or what have you. The project board for discussions will evolve naturally as work is completed (when using proper project management tools like GitHub), and one team member can be saddled with the brief responsibility of making sure conversation stays on topic during a standup. If more software development teams (or even better, their upper management) had this mentality, I think things would be a lot more efficient!
Thanks for another excellent video Tris.
Thank you! Did you see my teardown of capital-A "Agile" video? th-cam.com/video/9K20e7jlQPA/w-d-xo.html
@@NoBoilerplate I didn't but I'll definitely check it out. Thanks for the recommendation!
Been shipping for this idea for a decade now! You've laid out a much better argument than my "just use git ya nerd" 😂
hehe, you'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
I've seen a few people commenting that it would be hard to teach people how to use git who are not familiar it, and your response is that you've been able to teach people with a pretty short demonstration. I'd be interested in seeing your approach to teaching people git as a video on here.
Great video, btw!
I could do that, but it's so different per person, you have to meet them where they are, relate to their experience. That's hard to generalise into a video. My advice would be "listen to what the other person is telling you and help them solve their problems"
One super useful (also for non-programmers) feature that imo could have been mentioned / praised better is version control:
I can not imagine writing large docs (e.g. long university assignments and papers, essays, motivational letters, literacy) without it anymore.
- automatic backup to "the cloud" aka you remote git repo
- clearly see changes since last meaningful version of the text (automatically marked in the editor)
- never mind deleting entire paragraphs before rewriting them anymore (if i want to have it back just use look into the history)
-> not only my final text is documented; the whole history of its creation is
oh absolutely, I should have made more of that. I did say "with an audit trail that would satisfy a bank" but I should have done more!
To be fair, Google Docs and Microsoft Office do have something resembling history or version control. It's just... not very robust, at least as far as I've bothered to learn it. The fact that documents get moved, copied, published, etc, makes it much weaker than a real version control. You can totally do comments and suggest changes etc, but it's all second-class to the document's current state.
@@LibertyMonk ugh it's so bad, as you say, it's all second-class to the current state.
Life is change, change should be modelled as the first-class unit, not as an after-thought!
YES thank you!
I fought so hard to get a workflow like this used for documentation in my previous company, but people are so used to excel / ms projects / emails that they can't see how it can be simpler...
emails can be plain text, are asynchronous, and there is such a thing as git-send-email
I actually really love email, but I assume the problem maor might have been talking about is using unstructured email (and follow-ups) to run a team, instead of having a central location where you can see everything at once?
Sooooo I actually think the git based product management concept is pretty good, but it’s going to be really fun trying to convince Karen from HR to use it.
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR.
Could have been Jeremy from HR too you know
@@NoBoilerplate I'd be interested in a video (or article) on Git(Hub) training for non-developers. I usually use the command line myself (with a few aliases), but haven't yet found a GUI tools that I like for personal use, and I struggle with how to simplify it, especially for non-devs.
@@ModEmbedded It's certainly possible, though not too similar to what I do on this channel.
I had great success talking to my non-technical colleagues 1:1, and meeting them where they are with their experience, instead of expecting them to come to me, and showing them how to click through GitHub and do simple PRs all in the web interface. They universally loved it, and could see applications they never dreamed possible in their own work domains (because the existing tools are all too simple).
Karen from HR may learn to pull, commit and push. But dealing with conflicts is something I do not see a non-techie agreeing to learn ans do.
That was awesome.
Thank you.
I have been pushing for simpler tools. I consult to some of the largest and most regulated businesses in the world. And they are stuck complying with regulation in the same broken ways.
I have managed to convince a few customers and they are LOVING it. Simple, "outside the box" thinking, engineer led solutions. Even their management are slowly learning the benefits of leadership in this manner.
Excellent work as always, Tris.
Thank you so much. yes, EXACTLY. Engineer-led solutions!
I'm stuck with Confluence at my job, but sometimes I do this by including a tool's documentation in the repository and creating a "pointer" document in Confluence.
Documentation should always live with whatever it documents. Separating them guarantees that the documentation will go out of sync; you might have the strictest processes for documentation and you will still fail to keep it up-to-date.
Absolutely!
You are totally right. Also: "Happy families are all alike; every unhappy family is unhappy in its own way" (Some senile Russian grandpa)...
Your videos are always so well articulated, but maybe this is my favorite. It really hits home for me, as I try to be as plain-text as I can. While I am working in an environement where everything is wall-gardened, everything is opinianated, simplistic yet overly-specific, "easy-to-use" yet sometimes unintuitive, and above all not scalable... which only leads to frustration.
What I would do to be able to edit a file in vim or emacs rather than fiddling with the GUI.
it's unreasonably effective!
I do the same. I manage my project in the same Gitlab instance of my code. The greatest benefit is everything is connected, integrated and simple to manage than 40 apps
such a peaceful, simple life!
You started so good with text-based approach where having just txt/md files would be enough but then you moved Github issues and all the stuff built on top of git which is not even stored in the repo and inaccessible without Github (mb except wiki). Wiki can be replaced with simple doc/ directory in the root repo. And there is nothing wrong with writing HTML for something that is more complicated in structure than Markdown offers. HTML is not going away from us in any near future. In contrast to Markdown which can be replaced by any other markup language once Microsoft (the owner of Github) will decide to do that.
Keep in mind that Github Markdown is already way beyond Standard Markdown and you might be already locked on GH's implementation of it.
Also some Github actions can be easily replaced with git hooks and shell scripts.
So there are still ways to improve to cut off more fancy stuff even more.
We agree on most of these things, absolutely. It's difficult to separate my purity argument for doing as much in plain-text as possible, with my practicality argument that GitHub (and other web hosts) have some features you're not going to want to miss.
So, in this video, I propose a compromise. Yes, Issues, Projects and even PRs are outside of git, but because they are tied so closely to your repo, I still recommend them, as a concession to practicality.
I still prefer GitHub projects to JIRA because it's the same tool, bound up closely to the repository, where the work is actually happening. My assumption is that you'll never change your git host, so these add-on tools (that are broadly similar in all GitHub competitors) are ALSO never going away. The Pact remains!
Git is not the end, while being the standard. There are VCS that do embrace storing everything together a-la github in the same manner as storing file changes. One of potentials is Fossil, but I'm sure there are more older and newer additions.
Outside of the comment half, PRs are not that far away from the version-controlled core, as you can check out the branch yourself locally
Markdown is more of a specification or convention on how to format text than a format in itself. It's simply more human readable than html and it's trivial to write a little parser for it.
The rest of the proprietary stuff I agree, but I believe even if everything changes or ends the core data structure is preserved and easier to migrate than using some proprietary system.
I was a bit let down when the thesis of the video was "repo + web apps". All of product and project management can be handled in a shared and versioned directory hierarchy of text files. SyncThing is the 80/20 solution for this, not git.
Just in time to download before a short train journey, thank you! Looking forward to watching :)
Oh fun! Enjoy!
I'm also watching on the train! Maybe the rust and train overlap is larger than I thought.
that was dope. now i want the "storage is cheap if youre smart"-thing pls.
tldr: linux workstations, not mac laptops. Video drafting soon
I'm not so sure that all those github tools like projects, actions, issues and milestones actually abide by that plain text, never going away principle. Github isnt open source, and I dont know of any way to extract the data out of those 4 tools at all, let alone in a usable plain text format.
Edit: apparently actions are actually plain text. +1 for actions.
I think the point was it never going away due to popularity status
It's difficult to separate my purity argument for doing as much in plain-text as possible, with my practicality argument that GitHub (and other web hosts) have some features you're not going to want to miss.
So, in this video, I propose a compromise. Yes, Issues, Projects and even PRs are outside of git, but because they are tied so closely to your repo, I still recommend them, as a concession to practicality.
I still prefer GitHub projects to JIRA because it's the same tool, bound up closely to the repository, where the work is actually happening. My assumption is that you'll never change your git host, so these add-on tools (that are broadly similar in all GitHub competitors) are ALSO never going away. The Pact remains!
I'd love to learn more about git-native issues and projects, though my first thought is that if they're stored in markdown, you can build them in whatever editors you would like (as in the obsidian kanban screenshot at 7:19).
The Unreasonable Effectiveness Of Plain Text
Yes, my argument is a combination of purity and practicality (see my response)
Yeah the moment he talks about actions I started to wonder how plain text is this.
@@HazhMcMoor Actions are written in plain text scripts and config, saved inside your git repo, and they act on the plain text data in your repo.
It's one of the superpowers you get when using plain text on git hosts (github is just one example), they all let you automate your workflows. Can't run too many scripts on a google doc 😀
I am relatively recent to your channel but so far, I love everything I've sat through. Thank you for sharing, and for all the work behind the scenes that makes it seem so convenient to your audience. Cheers!
Thank you so much, I focus all my efforts on writing the best script I can, with simple visuals to support that :-)
“You sat through it!?”
I was wondering once you started talking about writing the ADR in markdown if you'd mention Obsidian, I'm glad you did!
they have a full video on Obsidian in case you haven't seen it yet
(It's just me doing all this, you can safely say 'he"!)
Here's my obsidian video: th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
I don't know how to tell you this, but... I think it's the most popular obsidian video on TH-cam?! I don't understand! :-)
Linus Torvalds SECOND greatest contribution to humanity was .... Linux
"the temptation is to use every feature"
never saw such a thing, 90% of jira or zen features in the places I worked in were simply ignored.
I absolutely love and embrace this concept.
Although github is the best for code-related stuff, the wording and tooling chain are sometime a bit too code-focused.
I would very much like a git (or any better and backward-compatible source control system tbh) integration for non-code stuff.
GPT suggested sourcetreeapp for this ❤🤖
obsidian?
I mean people use it to backup thrir wallpapers and dotfiles
The best tools in any branche of industry have a text based representation of the project at its core. Except for raw media or data that comes from measuring devices. They all store a parametric model of some sort and render/build it to produce the end result. Think of LaTeX, which still has a wide user base. And new generations of professionals that work with large living documents for publication still fall for the WYSIWYG trap and waste a lot of time applying simple changes. (LaTeX is old, but there are similar newer tools)
So it is always: Editor->Model->Text->Versioning System->Build Tools->Publication.
@@mennovanlavieren3885 LaTeX does not *still* have a userbase. It is the standard tool in academic and higher education circles (in my experience)
I just stumbled across this, and it's brilliant. Very on-point and quite clear. I don't use Github to write or discuss with people, but it's a great idea. You're absolutely correct on the state of most collab software to be a messy, ever changing pit of wasted time. Not only that, but things like maintaining a current version of files for a project is hard to scale to many viewers. I saw this guy make a Github repo for his plugin preset files. It's amazing. Every few months I can go check the page and update my version without having to manually go through every preset or see which new ones were added, etc.
I also appreciate the "use the tools you actually need" idea. Set things up for productivity and easy workflow rather than getting caught up in the minutia of tracking the progress. The fine line I suppose is how much to document on that progress. It's one thing to fix bugs or iron out things in the project itself, but I don't just wanna see "bug fixes and small changes" in my changelog either. Documenting stuff is fun or stressful depending on a lot of things, so having a simple methodology is a good thing.
Subbed. Keep up the great work!
Thank you!
8:40 I started to hate these issues. When never managed to use them properly in the small company I'm working on. Insetad we sometimes create huge issues and add a list of hundreds of points into it.
An issue like "Coding fixes", "Gameplay issues" or "Visual problems". Creating an issue is way too cumbersome for adding each little problem we found. Often it's just faster to tell the person who was responsible for it directly, or just to fix it oneself.
I loved irc. Plain text logs of conversations, grep and 2 seconds later I have something I talked about years ago pulled up. Try doing that with Discord.
Nice idea, but only for smaller teams consisting of programmers or other technically oriented people, willing to put all their documentation in the same place their code lies. I can't imagine, especially in corporate environment, how would you convince anyone who is not a developer to use terminal / GIT UI, learn what are branches, conflicts, merging, rebase etc. Programmers fuck all of those things up all the time, for non-technical people it would be like trying to learn black magic.
As for "You can do this in your immediate team" part, eh... no. It still depends on the company policy. Sometimes you have to use Teams, sometimes Slack, sometimes Confluence alongside Jira. The bigger the company, the less flexibility you have on the matter. So again, smaller teams or solo projects? Yeah. Anything slighly bigger? Chances getting slimmer and slimmer.
Totally agree with you. This may be over-optimistic, but I think a big picture take away is that "in an ideal world, every team would operate like this," and obviously that's not the world we live in today. But with every generation of people, the average level of tech-savvy-ness gets higher and higher. Maybe at some point in the future it will be a lot more plausible to teach Git to every person on the workforce (or make it part of the onboarding process or education systems); and these changes to structure can be implemented in a wider scope. Just another way to look at it.
If there isn't a clear goal: how it'll work and what it'll do for devs + the bottom line + the company, the chance you'll convince exec/other teams/your own team to approve this massive shift in workflow is zero. The video sets up a foundation and focus that is required to start change in your company for your specific circumstances. As he said: no chasing the hype.
A lot of points you've made reverberate inside of my brain when I'm at work, thank you for putting this concept so eloquently. My team has no documentation outside of work instructions, which are absolutely inert. We have good network use though, I want to get my boss to embrace plain text documentation. It's also why love Obsidian so much. And Markdown in general.
I do love plain text tools, but they're usually a **lot** more manual than other tools.
It's more like, the files/content are plain text....use whatever you want to edit it.
Think outside the box: Don't think vscode and terminal git. Think Sparkleshare[1] and Obsidian[2]!
If someone can learn JIRA, Figma, or Dropbox Paper, they can easily learn the github UI. I think there's a world here that can be explored!
1. www.sparkleshare.org
2. obsidian.md
This a programmers solution to a problem that involves many more than just programmers who
are much less technical and have very different needs. Been leading tech orgs for 30 years now and the biggest challenge is often communication (and good leadership). But the solution is not plain text - at least not outside the pure tech teams. Instead several different worlds need to coexist with people well versed in several of them as translators.
You'd be surprised what people will be happy to learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface.
It won't work for some people, I acknowledge. But it WILL work for far more than you might think!
This person relates to my suffering more than my family ever could
8:52 markdown HAS NO STANDARD. There is NO compatibility between:
- VS Code Markdown preview
- Stack Overflow (they use standarized CommonMark)
- Reddit (though they explicitly acknowledge modifications)
- GitHub preview
- Docutils Python library which can produce various output files based on Markdown input
- any other tool that I have tried but don't remember
Markdown's lack of standard is the very reason I resigned from this format for any pseudo-rich-text project (including generation of pages on my own website). It has no standard, therefore it is NEVER fully reproducible across different tools. If you want stability and reproduction, use CommonMark, Kramdown or a different format like RestructuredText which all have precise specification.
Besides this, a really good video. Looking forward for more non-Rust content.
Thank you for your kind comments, I've started doing a blend of programming and non-programming technical topics, 50/50, and everyone's responded really well, I'm delighted! :-)
However, regarding MD, I cannot replicate your assertions. Perhaps it was true in the past, but standardisation has happened since your research?
Everything you've described either uses the Commonmark specification or is not markdown.
The Commonmark website (commonmark.org/#when) says that all these use Commonmark:
Discourse
GitHub
GitLab
Reddit
Qt
Stack Overflow / Stack Exchange
Swift
VSCode uses Commonmark: code.visualstudio.com/Docs/languages/markdown
Docutils uses ReStrucutredText, not markdown
RST is not related to Markdown, it's a different system altogether. There is a well-used plugin for Docutils that enables Markdown support, and it uses Commonmark: github.com/executablebooks/MyST-Parser
My favourite markdown editor and notes system that I build these videos with and store my whole second brain also supports Commonmark, have you seen my video on Obsidian? It's *incredible* th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
@@NoBoilerplate I dropped Markdown usage around 2 years ago but from what I remember I had trouble reproducing lists (or any similar nested block that uses spaces and/or indent) and not every tool agrees whether to use ``` or 4-space indent for code blocks. Then inline HTML (which is kind of againt Markdown idea) is another problem - yeah, it shoudn't be there but a lot of GitHub projects do put it inside md files and GitHub renders it too (while other tools do not).
Also, my personal problem with Markdown is that nesting elements sometimes causes problems (like lists in lists or bold/italic). RST does it way better and that's why I use it for my website - additionally the ability to have custom keywords is great for extensibility. But RST is more complex and definitely not worth if you want just simple notes.
Regarding Obsidian - just watched the video but haven't found anything extraordinary. Perhaps because I was already presented Obsidian by a coworker (especially the graph feature) and what can I say ... It's a really good note-making tool for non-programmers. Personally I use Notepad++ and unix GNU tools (especially grep) (all inside a repo) which replicate some of Obsidian capabilities. I rarely feel the need to link one note to the other - I tend to organize my knowledge in directory-hierarchical form. When I do need graphs, I write dot files and use graphviz to generate images (VS Code has a plugin for it) - such graphs are typically data not notes. Still, I would recommend Obsidian to non-programmers.
I would love to see a video from you about managing a calendar across a team. I am a firm believer in using tools that are popular, fast, and always available, but I’m not sure how to best handle a calendar.
I work in a small company (less than 10 people) and my boss has this philosophy- if it isn’t in his iPhone iCloud calendar, it isn’t happening. As such I now have a calendar app that’s chock full of meetings and events that make it hard to get a glanceable look at my day. And if someone wants time off - put it in your calendar that everyone else is subscribed to.
It feels like there has to be a better way - but I’m not sure what would be as seamlessly integrated with my boss’ iCal.
I’m not a programmer in the slightest, but I really love your videos. Thank you for making them!
People regress back to general-purpose tools they already know how to use, and are general-purpose enough to kind of work for everything.
Calendars, spreadsheets, post-its.
HR systems that have an approval process for time off often have an ical link to subscribe to. Perhaps your boss could do that? Good luck there
There is a reason why NO NON-PLAIN-TEXT method of programming has ever caught on.... great video!
Thank you! I'm convinced the benefits can extend to most digital teams, not just programmers!
Here's something inspiring: github.blog/2013-09-17-3d-file-diffs/
@@NoBoilerplate Thanks, looks interesting.
An other thought re plain text, maybe a tangent here: It is kind of curious that we use plain text to command AI to generate PICTURES ... I don't know why this feels significant but I think this is something to ponder.
@@Axel_Andersen Agreed, the first time I got chatgpt to solve a networking problem blew my mind.
But do remember, it's only pretending to know what it's talking about - use your team of 1000 interns carefully! My video on this is here btw th-cam.com/video/glpR1MD1UoM/w-d-xo.html
this videos are dopamine hits
More meetings does not increase productivity; meetings are the layer 8 equivalent of thread synchronization, and Amdahl's Law very much applies to multiprocessing at the human layer too.
Meetings are the result of some other business process failing.
Instead of institutionalizing yet another weekly meeting to fix what the failing process broke, change or replace the failing process.
Thank you for coming to my TED Talk.
That's the thing I love about standups: a single tightly scoped meeting cuts down on having so many others!
"These are Hats, not roles"... Amen! Thanks for making me believe that I am not alone in thinking that ScrumMaster is a not by definition a role... 🎉😊❤
Such a waste of time in our industry! Try this video for my agile take th-cam.com/video/9K20e7jlQPA/w-d-xo.html
@@NoBoilerplate tx ! 🔥
I thought "hat" meant the same thing as "role".
This was extremely useful, thank you for your concise and informative videos. I first subscribed due to my interest in learning more about Rust, but now your channel has become goldmine to me for general purpose information on effective software development strategies. Keep up the great work.
I'm so pleased to hear that, thank you, I will! :-)
This reminds me of my last internship. Major problems faced before and the decisions made for it was nit written anywhere. Like the ongoing migration frim SQL to NoSQL database and whst was does before making that decision was undocumented. A senior told me why it happened but left out a lot of details. I has to ask around a lot to know why things were the way they were.
My entire career can be summed up as "convincing people that they need to simplify, not add more and more plugins, tools, and toys to their workflow"
UNIX Philosophy applied to systems and processes. Data portability. Common and uniform data formats. The keys to speed, efficiency, cost savings, and adding value to existing data is the same: Simplicity.
Couldn't agree more! Stay tuned for my video on the unreasonable effectiveness of Linux Desktops :-D
@@NoBoilerplate Will do :) this video earned you a sub from me, will definitely be enjoying more
@@BenThatOneGuy wonderful! 🙂
As a programmer, the idea of my non technical colleagues using git terrifies me.
I'll happily use Jira and confluence and not ever move away from it.
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface.
It won't work for some people, I acknowledge. But it will work for far more than you might think!
@@NoBoilerplate I organize and lead an non profit group, that focus on creating tools on non violent communications and doing outreach on the streets for animal rights.
I also do this to find, test and practice tools that are capable to create societal change for the better.
My issue - I am not tech savy. And I tried all the tools. Also coming to the conclusion that markdown is the way to go - although I start to like org mode...
But for now, I am working logseq and Tana for my personal pkms..
But I still have the issue, how share my work/skills/knowledge in the best, "open" and secure way.
Notion still isn't it - and my work on Insta isn't it either...
I would pay you, for giving an course/lecture for an multidisciplinary team on teaching how to use Git.....
Git with merge workflow is easy to explain to anybody. The hard part is to help non-technical colleagues to select a plain text editor that's actually good. And no, Notepad or Word are not reasonable options for writing plain text files.
That said, I think rebase workflow is clearly superior to merge workflow if your team can handle it.
@@MikkoRantalainen it is fun until the first merge conflict
@@MikkoRantalainen it's easy to explain. It is incredibly difficult to get people to understand.
Hilariously enough this just solved several non-programming problems I have.
Can't believe I never thought of this myself. The advice feels so obvious and I can't wait to implement this in my day to day.
we're so swept up in the 'normal' business bs, it's easy to forget!
I run a small software services company and I do almost the exact same thing. me and my team love it. Amazing video ❤
Fantastic!
Can't help but think about how much of this I'm doing in Obsidian while watching this.
And how terrified I am that Obsidian will not last.
Obsidian doesn't have to last, the Open-Source community (led currently by Logseq) is quickly building open versions of this kind of app.
As history has shown us, the Obsidian company will inevitably end or be bought and become bad at some point, and yet we will exceed their vision with open source.
The reason I'm so relaxed about this, specifically in Obsidian's case, is that the data storage method of Markdown is EXTREMELY portable. I have already been delighted that my whole Obsidian Vault can be used unaltered (and even simultaneously!) in Logseq.
The Logseq plugin ecosystem lags, Obsidians, but have you noticed how nearly all the Obsidian plugins are already open source?
I'm optimistic, either Obsidian will become open source, or Logseq (or others) will become Obsidian :-)
My video on Obsidian, if you've not seen it, is here: th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
I rarely find videos that I agree with every word of you have articulately summed up what I’ve been trying to say at work for years. You have made my day because I can send this link to my colleagues instead.
I'm delighted! With this channel, I hope to nudge the needle of the world in a small way. :-)
Did you see my agile video? A similar video on that: th-cam.com/video/9K20e7jlQPA/w-d-xo.html
@@NoBoilerplate Thanks, I’ll watch it now! You’re renewing my urge to start a channel myself, although I’m not sure if I can do it this well.
@@lawrencejob There's never been a better time to start a channel, I think the audience are tired of the same high-energy lolrandom meme-filled videos and grateful for some calmer content!
If you'd like advice and/or a push, that's just the sort of thing I could coach you in a mentoring session!
Git is really nice and by far the most polished revision control tool out there. And (like most tools) is the most effective when you take your time to understand why it works the way it does and use it 'idiomatically'.
All in all, Git is _the choice_ you should make when starting a typical project today. But will it always be this way?
I think the most interesting competitor that's shaping up is Pijul. It takes some of the theory behind Darcs, but makes it scalable and efficient. It simplifies the workflow, effectively getting rid of any need to rebase and making merge conflicts happen only when truly necessary. Even though it is based in some formal ideas taken from pure math (category theory at that lol), it really seems to be easier to wrap your head around even for a non-technical person.
Pijul is still an experimental tool. You can do real work with it (I've successfully used it in one little personal project already), but I'm not gonna argue everybody should switch to it as fast as possible. There are still rough edges and missing niceties we can be used to coming from git.
Also, it's written in Rust.
you should have led with the rust point! :-p
Thanks! I'll check it out.
Totally get what you're saying about markdown. I spend far too much time in Excel correcting formatting from something that colleagues pasted in from elsewhere. Inconsistent fonts and text sizes make spreadsheets a bitch to work with. Would love it if my spreadsheets could be locked down to a single font and text size. Formatting stuff in MS Office products is an absolute productivity killer.
You might love Jupyter Notebooks
Code and markdown in a visual editor!
As a student, I don't think this is feasible for me. I can't really expect group members to learn git, github, and what the hell a pull request is.
I'm sold for all my personal project though
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR.
I wrote a whole document just to teach git, and everytime I need to work with a new team I just pull it out
@@w花b The stakes are just too low for me to push that hard
Changing how you work requires an amount motivation/excitement, and for small school projects, nobody really cares enough (I certainly don't)
@@NoBoilerplateI would love to see your raw 30 minute presentation
I agree. I’d love to have something to share with my coworkers and managers
Brilliant! Glad to hear someone so effusive about Markdown, too.
Such a great and rational video on resiliency and self-reliance. I’m also sick of dealing with the whims of companies and their walled gardens (tempting as they are).
Plain text will live forever! :-D
5:20 Okay, you almost got that git joke past me
I had to think about it for a few seconds, good one lad!
I'd really like to see a video following up on your line "Storage is cheap, if you're smart"
I agree, but I'm still curious to see your thoughts.
Well spotted, I removed an entire 4-minute section from my original draft and replaced it with that teaser.
This deleted section now forms the basis of a new video, the draft title of which is "THE UNREASONABLE EFFECTIVENESS OF LINUX WORKSTATIONS" ;-)
Every single euphoric understanding that I have come across in my life since the days of productivity started. This guy here has a video about it.
I feel that all your emphasis of using all the github-specific features (issue tracker, actions, project view, teams, etc) defies most of your plaintext argument. Those are just another online software suite of management features, which are not portable, and not at all plaintext downloaded, offline files. Maybe I was expecting a method for managing tasks as a git repo itself (moving files of notes around, etc)
It's difficult to separate my desire for purity in doing as much in plain-text as possible, with the practicality that GitHub (and other web hosts) have some features you're not going to want to miss, but can't yet get in plain text.
So, in this video, I propose a compromise. Yes, Issues, Projects and even PRs are outside of git, but because they are tied so closely to your repo, I still recommend them, as a concession to practicality.
I still prefer GitHub projects to JIRA because it's the same tool, bound up closely to the repository, where the work is actually happening. My assumption is that you'll never change your git host, so these add-on tools (that are broadly similar in all GitHub competitors) are ALSO never going away. The Pact remains!
I'd love to learn more about git-native issues and projects, though my first thought is that if they're stored in markdown, you can build them in whatever editors you would like (as in the obsidian kanban screenshot at 7:19).
I'm putting my ideas together here: github.com/0atman/markrequests
There was a magnificent word processor for DOS called “Word Perfect 5.1” (invoked by typing in wp51) which had a mode to display (and edit) all the control characters that accumulate, when you start adding italics, underline, character fonts, etc. It was amazing, the file would become positively infested with italic-on, italic-off, italic-on, italic-off, just groups and groups of these switches accumulating between characters. What I learned is to eliminate all that I could use good old Microsoft Notepad. Copy the entire document with Ctrl-a, Ctrl-c then in Notepad execute Ctrl-v, Ctrl-a, Ctrl-x. That pastes the content (which rejects ALL format codes), selects it all again, then cuts from Notepad. Then you can replace back into Word Perfect (or Word, or any other word processor) clean of all formatting.
I use only the .txt file type, I don’t have any use for markdown.
I'm sorry to hear you don't like the abundance of meetings. Maybe drop me an invite and let's synchronize on this, maybe we could organize a huddle and have a brainstorming session, or even a roundtable conference call (with mandatory cameras on)!
instantly banned XD
Where have you been all my life! I knew git is great, and I knew in the back of my head something was deeply wrong with my company's documentation hygiène but this just blew my mind entirely. Totally bringing it up Monday.
On topic of offline access and plaintext, showing all features of GitHub going a very different direction as you can't access any of that either offline or migrate to other git host easily.
Migrating to another Git host should be as simple as cloning all branches, setting the new origin, and then pushing everything to the new origin.
@@mr-nimbusAs soon as you start using features that are GitHub specific you lose the ability to easily migrate.
@@mr-nimbus good luck taking your issues/actions/anything but the wiki and the code with you
It's difficult to separate my purity argument for doing as much in plain-text as possible, with my practicality argument that GitHub (and other web hosts) have some features you're not going to want to miss.
So, in this video, I propose a compromise. Yes, Issues, Projects and even PRs are outside of git, but because they are tied so closely to your repo, I still recommend them, as a concession to practicality.
I still prefer GitHub projects to JIRA because it's the same tool, bound up closely to the repository, where the work is actually happening. My assumption is that you'll never change your git host, so these add-on tools (that are broadly similar in all GitHub competitors) are ALSO never going away. The Pact remains!
I'd love to learn more about git-native issues and projects, though my first thought is that if they're stored in markdown, you can build them in whatever editors you would like (as in the obsidian kanban screenshot at 7:19).
this is cool to watch.
i'm a software dev, and i used to build my own tools to manage this problem, with all kinds of wonderful additions. But i kept making new ones, whenever updating the old ones was too much work.
then i noticed that i am slowly 'devolving' into just being git.
so now i just use Git.
This is the way
Great video with great ideas.
I'm glad someone's finally calling notion and trello garbage.
BECAUSE THEY ARE.
Whilst "garbage" they do still have uses.
You can defend anything by saying "it has its uses"
I like Notion.
garbage has its uses haha
Superb content as always - thank you for reminding us of the importance of grounding decision making in truth and documenting it in processes like ADR in easily accessible future-proof tech that's plain and simple.
Thank you so much!
The most beautiful thing about working via Git Repos is that personal local environment doesn't matter as long as it works with git
I don't care which editor for files you're using, use what is best for you
As long as it can meet the Git Standards of Style while pushed
If you're finished with your work just push it up into the Repo and the Project Management can merge in their own time, while allowing multiple versions of one project to choose the best before merging into the permanent version
BTW, I found this cool little thing called PIJUL, think Git but built-in RUST
Very simple & easy-to-scale & FOSS & focussed on patches instead of versioning
(I can't post any links here cuz YT)
oh cool! The link is pijul.org if anyone else is reading this.
An interesting system, though not one I can recommend for corporate use just yet :-D
I wish companies would just use this instead of jira jesus
I love the way that you create your scripts in Markdown, especially the line splits for each frame of the video. Another amazing video!
All credit to the Advanced Slides plugin, and the Reveal.js community! mszturc.github.io/obsidian-advanced-slides/
I desperately want to work in a plain text(markdown)/git workplace. But trying to introduce these tools to non-developers is met with complete apathy.
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface.
It won't work for some people, I acknowledge. But it will work for far more than you might think!
“The Jira Effect” I felt that one hard. I used Notion for a long time for personal note taking and project management. Absolute horror after the 10th project. Everything was cluttered and we had legacy structures everywhere that never got updated. We still use a PM tool, but a more minimalistic one and I move personal note taking into Obsidian
I'm delighted for you, I make all my videos in the Advanced Slides plugin in obsidian, my whole second brain is stored in it, and my most popular video, somehow, is an intro to it! th-cam.com/video/DbsAQSIKQXk/w-d-xo.html
I love git, but getting anyone but a Programmer to use it is just unrealistic.
Github Desktop should have been finished / feature-complete along time ago, until then its a dream.
You'd be surprised what people will learn when they can clearly see the benefit of it. (the thesis of my whole channel, really!)
I've taught an entire multidisciplinary team of designers, business people, and managers to use GitHub, and I did so with a simple 30-minute demonstration. They don't need to even know about the command line, just uploading files, editing markdown, and making a PR, all through the web interface.
It won't work for some people, I acknowledge. But it will work for far more than you might think!
This struck a chord with me, I love obsidian and this looks like a great way to expand and keep trackof my notes
GitHub's wikis use the same [[link]] format as obsidian, so storing an obsidian vault in a wiki gives you a web editor for free! An incredible trick!
I like the idea of keeping documentation and rules, etc. as text file/markdown, but how would one deal with graphics? A lot of technical descriptions in particular greatly benefit from having diagrams explaining the rough outline of things, but I do not know of a good way to embed graphics in a text document _in an editable way_. Any ideas?
Have you heard of mermaid? Or simply just link the image with markdown
How about drawio or mermaid?
The interesting thing about drawio is that you can generate a png or svg which in itself embeds the xml that made it.
So you have a myDiagram.drawio.png which you can embed into markdown AND edit with drawio.
Then there is also Mermaid, which many Markdown Readers implement. It uses the code block to define diagram structure
yes!
As Toan said, mermaid is FANTASTIC, and natively supported on github and obsidian docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams
normal images are fine too, they preview well, though they don't get visual diffs (yet! though there are third party actions that do this).
amusingly "ADR" also stands for "alternative dispute resolution", which formally is some other thing that has nothing to do with Nygard but sounds like it could conceivably be related