This is great, yet another place I have to repost my resume/portfolio/blog to satisfy the trend-following recruiters and hirers... Maybe I'll just do this
# [CLICK HERE FOR MORE DETAILS](https://mysite.tld)
When MSFT bought them, I predicted they would pivot to adding features I don’t care about. I was right. They went from the best support I’ve ever seen (report an issue, get a personal email asking for details, see it fixed) to the worst (not touching a single feature I find worthwhile).
There’s about a thousand things I wish they would fix or add before this. They still don’t allow videos so every screencast demo on GitHub is still a giant GIF, right?
I used to like GitHub so much I paid out of pocket even when I was unemployed. Now it’s on my list to check out GitLab again. Companies don’t know when to stop. It’s like they created the bicycle and add another wheel every year as an improvement.
I've often wished this feature actually, especially when submitting pull requests, and you'd like to showcase the new features. I've often had to either embed a video link or convert to gif.
As someone who likes to do previews in PRs, mp4's are infinitely better than gifs. Better colors, better frame rate, better resolution, better size when you change any of those factors. It's really, really silly GitHub still don't support them.
Search has been broken since last November and it's impossible to select text when reading files in the browser anymore because they checked a JS-powered intellisense feature in. Now I usually just checkout the repository and use ripgrep to search for code.
I search and copy text from GitHub at least a dozen times a day, so I'm not sure what you mean when you say search has been broken since November. As for the code copying, could you provide a bit more info on what's actually preventing you from selecting the text?
Whoa, did I get Nat's attention? Prepare for a brain dump!
- Keyboard shortcuts: I’m always triggering these by accident. There’s no easy way (AFAICT) to block or disable them. My browser and OS already define a bunch of keyboard shortcuts. Please don’t steal existing shortcuts for non-standard uses.
- “Mobile” view: this hides so much it's nearly useless to me. (And the desktop view is a pain to use on my phone when I want to check one little thing.) 100% of the reason I use GitHub today is because -- by default, with no action required -- it displays the (entire) README, and the list of files. That’s what GitHub is.
- “?w=1” has always been one of the most useful features of GitHub. It’s completely hidden, hard to use (it messes up my browser history), and easy to forget.
- Releases/Tags: this page has only Next/Previous, no page numbers. If you want to get to an old release, you have scroll down and click "Next", and then repeat that dozens of times. “git tag” is fast (right?), so I’m not sure why normal pagination is missing here. Other GitHub lists have it. (Oh, I just found from poking around that "Subscriptions" also has only Previous/Next. I think that one's new.)
- “Issues" attachments: only a handful of file types are whitelisted, and it excludes 10 common ones I want to use (not just videos). I’ve never been able to figure out why. Is there some security issue we're avoiding by making people rename their .csv files to .txt before uploading them?
- "Issues" email responder: I see people send attachments here, and it silently drops them, instead of attaching them to the issue, or sending them a response that it doesn’t accept attachments via email. I’m tired of talking people through this. At this point, I wish I could turn off the email responder entirely, because it’s more trouble than it’s worth.
And finally, my Completely Unreasonable Requests:
- DOM stability. For example, when I'm not logged in, there's that giant "Create your own GitHub profile” banner, with the confusing “Dismiss” floating over a busy background, near the weird icon that looks like it might almost be a close button but isn't. I guess you have to always upsell, but nothing on github.com seems to ever have a stable DOM class/ID, even when there’s no reason to change it, so I regularly have to edit my user stylesheet to fix or block things I don’t want.
- “Issues" are the only major part of a GitHub project which aren't repos, so there's no easy way to back them up, or use them offline, or query them from a shell, or ... The GitHub docs always suggest some third-party API-based method for backing up Issues, and I've never gotten any of the free ones to work, and I shouldn't have to pay someone else to retrieve my own data. (The cynic in me guesses this is GitHub's primary mechanism for lock-in.) It feels like GitHub is a 2000's-era version control system, with an SVN-era bug database.
It could be a low hanging fruit that can be easily picked up.
I'm certain they have more designers or developers working on other features as well.
I remember a few years ago people were saying Github development seems to be stuck due to legacy issues and they couldn't compete with Gitlab in terms of features.
Who’s expectation? I don’t expect developers I hire to have a GH profile. Most GH links I see on resumes are thoroughly unimpressive anyway (one or two college homework assignments and an untouched fork of some open source project).
Having a good one is a plus, but having a poor one is worse than not having one.
The number of stars and forks indicate the interest in the repository to me.
I'm not sure if I'm convinced this has worked as a bookmark for my repositories: no one ever removed a star from any of them, and no one ever returned with any feedback later. It could be a matter of a small sample size, or of people never actually coming back (which is the bookmark's use case).
Almost every browser denotes 'favorites' with a star, so I’ve always thought 'starring' a project meant the same as bookmarking it or storing it as a favorite to reference later.
I totally get where you're coming from, but I follow people on GitHub exclusively because I want to see what code they're working on.
I'm not following them because we have reciprocal social arrangement where we're "friends", or because I want to chit-chat with them, or see what they're eating, or what asinine 280 character fragments of streams of consciousness that they emit into the void, or to participate in the typical "best foot forward" profile stalking and preening BS that I can't stand about social media.
GitHub is a social network, no doubt, but it is not social media and I hope that does not change.
I remember when GitHub used to have private messaging. I liked that feature. It was an easy and unified way to get in touch with other coders on there and felt less intrusive than sending them e-mails out of the blue (or opening issues for the sake of communication, as some do).
There have been times I've wanted to reach out to someone about their open source repository or a question and I've always wondered why there wasn't a messaging feature. Interesting to learn it used to be there.
There was someone working on LaTeX support a few years ago, but iirc it was very difficult to secure it enough to feel comfortable letting it run server-side for rendering. Source: I worked there when they were working on it.
What about client side rendering via MathJax? You could have your LaTeX code embedded in your markdown and MathJax could substitute it for appropriately rendered symbols as necessary.
I don't like Emojis in my documents. I think they are distracting. Tools like Notion is actively promoting it like this new Github profile docs. Does anyone else feel the same? :-)
In apps like Notion, your experience is somewhat worsened if you don't use emojis. Since there's not an easy way to add "default" icons, emojis become the de-facto means of conveying information other than typing out your meaning.
Similarly, AFAIK every document in Notion has an icon associated, and when every document just has a placeholder page icon next to it - it looks ugly.
Lol that's obvious. But, the trend is what I am concerned about and asking if others feel the same. I can't control if I am reading someone else document full of emojis. Can you imagine RFCs in this format?
To me, Emojis have a place when you're discussing with others and socially interacting. May be even in code reviews to reduce friction and add some human emotion to what you're saying in cold words. Use it to chat with people - totally ok.
Documents with emojis is definitely an anti-pattern IMO. To give an extreme example, can you imagine reading python docs with Emojis? Or Tolstoy? What about tax documents with emojis? Court proceedings? Job resumes? Aircraft emergency checklists?
> I have no interest in demanding how other people define their docs.
I definitely do not want emoji's in official documents, emergency procedures, etc. And I would demand for the same - emoji's are at best decorative, and a lot of times a distraction. Most documents that are of importance to me should be straightforwardly written - and that means no emojis.
- Tolstoy: No, he's not gonna writing anything new, so I can't imagine a way someone could insert emojis into his work.
- Tax Documents: No. Government employees won't care enough to put in the effort.
- Court proceedings: Reason same as above.
- Job Resume: Yes. Probably already exist.
- Aircraft emergence checklist: No.
Some of these are too extreme. And such a slippery slope is a logical fallacy.
There have always been people who put playful things into documentations and notes/wikis/resumes, before emoji became so wide-spread. Government documents and emergency checklists never.
> Gender difference is always an important
research topic in sociological and psychological studies from which there are many interesting findings. For example, females are evidenced to show a greater number of facial activities than males [40, 41] and observers can identify emotional states more accurately from female faces than from male faces [39]. With the advancement of data science methods, these hypotheses and conjectures about gender differences are measured and tested quantitatively through analyzing online behaviors of users at scale. For example, when the “facial expressions" (emoticons) become popular in text, researchers investigated the relationship between gender and emoticon usage and found superiority of females in using emoticons [44, 48, 54], which verifies the sociological findings about non-verbal expressivity of females [2, 18, 29].
Not that this means YOU specifically need to like emoji, but it's probably important to recognize that preferences and usage patterns differ by gender (and neurotype). Male minds (for whatever reasons) are often less likely to use and rely on them.
Interpretation of any data is fraught (nature? nurture?), but it may be that emojis make documents more legible to certain minds, which perhaps have different optimal conditions in which they process information.
So "Emoji are an anti-pattern" perhaps only holds true for neurotypes that don't depend as much on non-verbal signals when processing information. The opposite may be true for others. E.g. Cultural norms aside, maybe emoji in a resume would actually help certain hiring managers select the best candidates. (heh that's probably a more dramatic claim that I'd actually stake my case on :) )
When being overused and thrown in as plain decoration, yes. But I gotta admit, sometimes they do convey complex emotions no easily communicated over text.
Disclaimer: I am on the younger side on the age spectrum.
The examples in the tweet that spawned the discussion, they are totally overused and thrown in as plain decoration. I can barely even pay attention to the words, I'm too busy trying to figure out what the emoji mean.
There are a lot of commenters sharing their opinions of what they don't like abut Github’s interface. It is true there are a lot of quirks and warts in what is a site many of us spend a lot of time on.
Ive found browser extensions have been a great way to augment and customize my Github experience, bringing quality of life improvements that Im grateful to have every day.
My top two favorites are:
Refined Github [1] -- huge collection of quality of life improvements. e.g. always sort issues/PRs as most recently updated first, when recently pushed to a branch show a button on project page (or upstream of fork) to open a PR based on that branch, quicklink to most reacted to comment on an issue page. Also provides a surface to inject custom CSS for personal tweaks.
Octolinker [2] -- Turns require/import/include paths in files into hyperlinks to that file or repository. I use this every single day to navigate code in projects.
I know that extensions aren't a panacea, but personally I have found them be very valuable to my workflow.
Some time ago there was an article posted with a proposal for redesigning the Github UI [1]. I thought it was mostly great, but it got roundly panned on HN. In general my takeaway was that people don't like change, even when it benefits them. Was unfortunate, especially from a crowd that's supposedly all about technological improvement.
We have something similar internally - we call them personal user manuals. They explain how we like to work (e.g. communication preferences), and a little bit about ourselves.
We ask new joiners to write theirs when they join. They make a good introduction to the company and can provide guidance when wondering how best to interact with others.
A great piece of advice I heard I think from @patio11 is that you should really just host your own resume rather than letting a GitHub/LinkedIn/etc profile be your primary resume.
Why? Because context is powerful. When people are viewing your resume, you want 100% of their focus on you, and you want to present yourself in exactly the way that's best for you.
You don't want to present yourself within the context of another org's branding, site layout, etc, which by definition won't be optimised for you, and also syphons off some of that attention you want focused on you (as the most obvious example, say if the top bar has unread notifications).
The irony is with Github, hosting an HTML resume 'on' Github is possible and really easy already via GH pages. It's what I do :-) https://davnicwil.com/cv/
I like the idea... a bit concerned about the future potential that there is an expectation developers have a GitHub personal README (err "resume") tho. That's just not practical for a lot of folks either due to time, interest, or contractual reasons.
On the other hand, most profession's do have portfolio's and other mechanisms to share work with new potential employers. For some reason developer's seem to think a hiring decision should be made entirely on a a handful of 1 hour interviews conducted in a single day when their work will usually have massive direct impact on the companies product.
I think there's mostly positives to this and some downsides.
> For some reason developer's seem to think a hiring decision should be made entirely on a a handful of 1 hour interviews conducted in a single day
As opposed to... some generic profile on a central site? I don't think that is a substitute to actually talking to a candidate.
But what do I know? If I understand sites like HN correctly, talking to a person is not a good way to discover whether he/she has any skills, so maybe this is better from a recruitment standpoint. But I'm not going to create a personal profile there. For the simple reason that the words 'personal' and 'follow our format' don't go together in my mind.
I currently try to convey my (code) interests by pinning my favorite repositories on my profile, but this personal README is a ton more expressive. Looking forward to this!
This is interesting move - I'm surprised they haven't done things like this earlier. The pinned repos was never a great way to provide an introduction since it lacks too much context. I've been experimenting with my own project [0] to get much more info out of GitHub profiles to demonstrate one's skills by generating portfolio sites, but if GitHub does a good job with this it might make my solution somewhat redundant.
Like it or not, people use github for self-promotion.
It's not at all unusual for recruiters to ask about your github profile. The code repositories are the resume. The personal README is the cover letter.
