I hired a programmer and after giving him his Linux laptop let him set up a few things. A couple hours later he asked me where he could get PuTTY for it, and I recognized a huge gap in my interview coverage.
> Puttygen software is not created, nor supported by Puttygen.com. The program has been tested and is believed to be safe. [...] The use of Puttygen through Puttygen.com is done at your own discretion and risk
PuTTY is (or was, in the years before WSL) the go-to SSH client for Windows. If you're a Windows user getting onboarded at a job / uni class which uses Linux machines, installing it is the first thing you'd be told. The laptop in question would obviously have a terminal emulator and SSH client pre-installed, but a Windows user wouldn't think to look for them, and they might not even know that SSH exists outside of PuTTY or that it's a separate concept to the terminal.
Sure, I'm well-aware, and am also aware that someone familiar with a GUI-based way of doing something on one OS may seek the same, or similar, GUI on another (new) OS. It's a familiar anchor in a sea of unknown, a natural thing to do for most users.
I still don't follow the evil grin. Is the apt package some kind of malware or trojan?
It's nothing evil, it's just Putty for Linux, and they say why you might want it. Mostly for people coming from Windows, but supposedly it can also deal with raw sockets that OpenSSH can't.
Ever hired someone who, when you ask them to send you an ssh key for access to something, sends you their private key? Yeah, that's happened more than once.
- microsoft is evil, I cannot delete my github account, will never use anything by this company
- if the attacker knows your *public* key they can enumerate the list of the servers you have access to https://github.com/benjojo/ssh-key-confirmer
Not everyone works in a field where the developers or engineers have public github accounts or publish their profile of things like ssh keys for the world to read.
That's more ageism than anything else. I mean surely real "programmers" know the new hotness "ghsfgusdfu", right? How could you live without?
I know companies running on SVN and they're fine. In fact, it's a better fit for them. Yes, Git is not always superior.
I'll give you a helpful concept to navigate these issues: "Cargo culting refers to the practice of imitating the superficial aspects of a process or practice without understanding the underlying logic or reasons behind it. This phenomenon is often seen in software development, where developers may adopt certain coding styles or methodologies without grasping their true purpose."
Git is over 20 years old at this point. If somebody is in their 60s now, they were in their 40s when it came out. This is not about age. They must have slept on it for a long time.
Nobody expects an engineer to be a git expert, but if a senior software engineer has heard of git only yesterday or don't have a vague concept of how DVCSs like hg or git work (DAG of commits), then something has gone very wrong.
Maybe there are use cases where SVN is superior (I can't come up with any but they may exist), and maybe engineers in that industry really are so specialized that they never get around to working on anything else!
But maybe it's because nobody else is willing to hire them.
If you are not in an environment where it is being actively used it is not something you'll pick up. Not every programmer is on HN or being cool with blogs etc. I agree not knowing about source control at all is a .. different matter. Also, 20 years is less impressive once you subtract the time it wasn't popular. Even if it was 20 years, it is still not impressive. Perhaps if you are 15-30, but to older folks it's like a drop in the bucket.
Many people are not familiar with "git" and don't have to be. Picking up "git" is a one afternoon type of thing but the parent did not mention timelines. It was just about "knowing" git and I pushed back on that.
There are so, so many tools you guys on here find indispensable that don't actually get used by vast swaths of people in the field. I sometimes wonder where all you guys work.
If you're actively looking for a job, you should have some familiarity with the common dev stack when you're looking. Today you should be comfortable working on a Mac, know Bash / Zsh, a little bit of Vim for SSHing, git, docker, react, postgres, etc.
If you don't, spend a few weeks before you start your search. You're almost definitely going to need them. Unless you're in a niche where the common stack is different.
This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing, you're going to stumble without cursory knowledge. You don't need to be an expert in it all…
> This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing,
Then I don't apply. I'm not interested in working with garbage tech.
Fair enough that I did not mention any timeline. And could’ve been general with “VCS”. And you are absolutely correct, that basics of some of these tools can be learnt in an afternoon.
In fact the industry i work in we don’t have git, but something similar to SVN (and proprietary, expensive and pathetic UI/UX)
Since, I am not in software industry, I won’t comment on whether such people might survive for more than 5 years without knowing about ‘VCS’.
However, I have slightly died inside when some Computer science students (graduate school, mind you) were using google drive with manually created timestamps as a backup strategy. The submission for this entire semester long actual project was on Github. as a final single commit uploaded a day before. (And no this wasn’t a squashed commit from a different repo.)
There might be a blurry line between people not sharpening their auxiliary tools vs never using or being slightly curious about them.
I am more of a glamour and bling on my tools person, and I don’t expect every engineer to derive the same pleasure that I derive just from tinkering with them; however, does make me wonder if there is a point when such an approach to not fully caring about simplifying your workflow (aka being lazy), might spill over into making poor engineering decision?
It's possible to always work for big tech companies and never use some popular tools like git. Not a good thing either, but it doesn't mean they're wannabe programmers, cause I've seen those too.
When I went to college (early 2010s) professors were still encouraging students to use SVN, so I probably have a fair number of peers who didn't learn git until they got out into the real world
Was the encouragement to use SVN to the detriment of git, or was it to the detriment of renaming the file multiple times, from final to final (1).zip to final-no-really-this-is-it.zip?
It was more that IT considered the college-hosted git instance "experimental" still, in multiple project courses we were required to use college hosted version control as part of the class, but those who wanted to use git were on their own to figure it out.
evil grin