9 ms·

I find a version of this even with fresh out of college programmers. They just know how to type Java on an IDE, maybe some SQL (using some graphical front end)

I find a version of this even with fresh out of college programmers. They just know how to type Java on an IDE, maybe some SQL (using some graphical front end), some HTML/CSS. They can't operate in a Linux dev environment at all, can't use the command line or exit vi or perform any kind of simple shell based automation or use git without a plugin for their IDE. And they also are reluctant to learn because they are self defined into some narrow field that doesn't include all this ops trickery in our workflow that they don't consider real programming.

nicolas_t 4y ago
What kind of college grads don't know how to operate in a linux dev environment? That'd be an immediate no-hire from me.
- voidfunc 4y ago
  Most lol. You only hiring MIT and Stanford grads?
  - srcreigh 4y ago
    Stanford or MIT or UWaterloo
    - stametseater 4y ago
      Bah. I took community college courses in highschool and the basic bitch introduction C++ course at that community college had the students using linux in the lab. The second-rate university I ended up going to after highschool required CS students to learn either Vim or Emacs to pass one of the required introduction courses, and all assignments had to compile and run on linux otherwise the TAs would reject them. As far as I've seen, basic linux skills are taught if not required in the CS programs of colleges of any reputation or stature.
  - strken 4y ago
    On my first day at a frankly pretty shit Australian university, we had mandatory Linux and Solaris training. I managed to skip it because the IT guy turned his screen to me and said "What's this?" and I replied "Dunno, looks like Fedora Core", but anyone who couldn't do that sat through several hours of training on SSHing into things and using bash, after which they were expected to turn in assignments that would compile in a remote Solaris environment. This story doesn't have any real point, except maybe to say that knowing your way around a shell is up to the arbitrary whims of your university's administration and lecturers.
    - worthless-trash 4y ago
      And maybe it awakens them to the fact that there is more out there than the abstract "what i run at home" environments available.
  - m-ee 4y ago
    Stanford ain’t gonna teach you Unix either. I think they at least teach git usage in the intro classes now, but certainly did not while was there. Wasn’t a CS major but took a number of classes. The only class I took that touched on anything practical for the working world was “programming for scientists and engineers”, CME211 I think? And most people only took it because it counted for grad level math credits.
  - _moof 4y ago
    I was taught how to get around a UNIX box in CS 101 at a state school.
    - Kon-Peki 4y ago
      Purdue CS in the mid/late 1990s. All coursework, if it wasn’t handwritten on paper, was developed and submitted with your account on the department UNIX cluster. I switched majors so didn’t have any freshman courses; I certainly hope they taught people how to use the system. You couldn’t pass a class, let alone graduate, without being able to use UNIX. There were a few side benefits to this setup. First, it allowed you to use the Sun pizza boxes in the engineering admin building, which were insanely powerful (back then). Second, it meant you could use any computer lab on campus, because they all had terminal emulators installed. So while the average student waiting in line for an open Windows PC, you could go down the hall and sit down at a Mac in a lab that had maybe two other people in it. Third, you could submit all your print jobs to the service center in the basement of the math building, where they’d collated, staple, whatever you wanted and then put it in a mailbox for you to collect at your own convenience, rather than deal with the clown show at the printers in all the Windows computer labs. Good times
      - _moof 4y ago
        Oh, hey, IU in the mid 1990s here. We were doing Scheme on DEC ULTRIX boxes. (Which is also how I ended up being an emacs user. Oh well. Nobody's perfect.) Good times indeed!
  - oytis 4y ago
    I graduated in a third world country. We did have a course or two on Unix.
  - ecshafer 4y ago
    I went to a state school, 75% of the CS class used linux, 20% used OSX and maybe 5% used windows.
- fcatalan 4y ago
  The kind that went into the subject just because it pays well and are taught some kind of bimodal syllabus: Lots of heavy Math/CS stuff they forget after the test and then practical programming as defined by "industry", industry being the big consulting firms churning out Java.
  - lopkeny12ko 4y ago
    This is exactly it. I'm involved with a lot of hiring for junior developers. It saddens me how many of them are trying to get into the field not because they're passionate for programming, interested in computers, or enjoy tinkering with digital tools. They're here because they're allured by big paychecks and "because everyone else at school is doing it." There are, of course, exceptions, and those are the junior developers who excel the most but they are few and far in between.
    - nicolas_t 4y ago
      Yup, and given that my entire career has been in startups environments, people who lack that passion and interest are usually not a good hire. Not knowing one's way around linux is a major red flag because it shows they lack curiosity for their chosen profession.
- pxc 4y ago
  At my first job out of college, I met a lot of junior developers who could sort of get by in a Unix CLI, but didn't know anything except the very basics and didn't much like it. I was a Linux hobbyist from the age of 12, so I thought that sucked. Since the company had a practice where developers could give their peers educational talks, I decided to demo some of the things I use to make my Unix command line environments feel really great to work in. I found that pointing CLI-shy devs to a nicer shell designed with ease of use in mind (Fish) and some basic navigation tools like fzf and autojump got a good chunk of them genuinely excited to learn more about the command line and make their environments more comfy. I also reviewed the available in-terminal documentation tools including those they likely hadn't seen in school (e.g., tldr, bro-pages), and I think that helped make clear how efficient exploring the command line from the command line can be. (Nowadays I'd also direct them to explainshell.com and some other web resources, though I think emphasizing the 'in-band' stuff is important.) The next day, and every now and then for some time, I saw them reading the docs, writing their own little plugins and scripts and aliases, customizing their prompts, and so on. I knew about it because they sometimes even called me over to show off! It would have been a shame to blow them off because, not having seen how it can be delightful to use, they saw the terminal as something to be avoided. They were smart, capable people who just hadn't encountered a good enough pitch yet. Once the environment is comfy, learning individual tools in it becomes a lot less intimidating and more appealing to people. But you have to show them how good it can be and offer them a decent starter kit. :)
- smarmgoblin 4y ago
  It’s more common than you think. I graduated in 2013 and can tell you there were minimal opportunities to learn how to operate a Linux command line (if you didn’t already want to). Most jobs will set you up with some IDE with the codebase preloaded and a big green compile button, it’s just easy to avoid I guess. I’ve been using Linux since 2008 and it’s the most high-yield skill set I have, it makes everything simpler and I encourage others to learn it.
  - animitronix 4y ago
    It's crazy how fast it changed then. I graduated in 2002 and you literally could not leave without knowing how to use Unix. When I started in '98 the school's email system had to be checked through terminals and my dorm hadn't even been wired with Ethernet, although we had it by the second half of my freshman year.
    - smarmgoblin 4y ago
      I believe that. Others may have had a different experience to mine. I was always searching for a class that would give me the “real” Linux experience but nothing really exists like that, I think you just have to live with the tools for a bit.
- ZephyrBlu 4y ago
  Umm, most professional programmers probably don't know how to operate in a linux dev environment bro... That is also an extremely stupid requirement. You can be a good programmer (Especially as a junior) without knowing all the linux command line tools.
  - foolfoolz 4y ago
    this is the most common. id say most people i’ve worked with start caring to learn the shell and dig into the os more around year 8 of their career
    - pxc 4y ago
      > id say most people i’ve worked with start caring to learn the shell and dig into the os more around year 8 of their career That sounds tragically late to me. It represents a serious failure on the part of those who know and love the command line to make it accessible to newcomers, imo.
      - foolfoolz 4y ago
        nah it just shows how the valuable abstractions have moved up. i bet this 8 year mark will only get later over time until it disappears
        pxc 4y ago
        Level of abstraction is largely orthogonal to the GUI/CLI divide, though. nmcli is more abstract than ip+iw+wpa_supplicant, but it's no more or less abstract than any GUI network configuration widget. The output of ls is no more or less abstract than the contents of a directory as displayed by a GUI file manager. It's the same metaphor and the same information displayed in two different formats.
  - nicolas_t 4y ago
    I haven't met a good professional programmer working in webdev who didn't know their way around linux. I've met plenty of bad programers who got into this field for money, didn't know how their way around unix, were barely able to do fizz buzz and would be better doing something else. I haven't hired them though. Not knowing one's way around linux is a sign of lack of curiosity and passion for the topic. It's obviously different in some fields (like gamedev) where the code produced by the dev is not supposed to run in a linux environment.
- jemmyw 4y ago
  Even when I graduated in 2004 there were lots of people there for the money side of it rather than much interest in programming / computing itself. I would say maybe 1/4 or less were taking more interest.
- maccard 4y ago
  If you can't onboard a fresh grad into a usable state with version control, a toolchain, and an editor in 1-2 weeks, you shouldn't be hiring fresh grads. Expecting Linux familiarity fresh out of college is just plain gatekeeping.
bmitc 4y ago
This is a somewhat harsh take. I've met plenty of programmers also set in their ways in that C or Python is the only language needed and that concurrency or functional programming is "hard" and thus not worth learning. Whereas I find concurrency and functional programming, given the correct language for it like F#, LabVIEW, Elixir, etc., is easy and manageable. It just all depends on context and experience and additionally philosophy. For me, I have been developing for several years in several different contexts and consider myself a decent software developer who focuses a lot on proper design and implementation, readability, maintainability, speed when needed, etc. However, I am relatively weak on all the various Unix tooling (I know the general basics of course) and am currently trying to address that. Reasons for this are that I worked professionally for a long time in a Windows environment. Any scripting done was via PowerShell, which is a quite powerful tool and language and something I actually often prefer given the readability, if not verboseness, of the commandlet names or via the programming language used. My more Linux oriented roles or projects are more recent and have used languages like Elixir or F#. Since both of these languages have built-in scripting, any scripting was done with the languages themselves. Elixir has such powerful tooling that, for whatever reason, I just rarely found that I needed the Unix command line tools for what I was personally responsible for or working on or what wasn't provided by Elixir or my editor in VS Code. Elixir allows you to build custom Mix commands, which is also nice. However, now I'm in an environment where many of these tools could be very useful, so I am trying to pick them up. And it's always possible that I was missing out, so it's important just to be willing to learn as things present themselves. Just stating this because context is everything.
- Fire-Dragon-DoL 4y ago
  Keep in mind that "unix knowledge" doesn't mean knowing bash scripting, but understanding a bit about the shell is the key part. You worked on windows, but you probably know about environment variables, how they are passed around, what PATH is, how to list files in a directory, cd around, copy/delete files, redirect, pipe and how to use git given your profession. Isn't that the case? I've been on Windows and learned all that as a hobbyist (I'm a professional developer, but I work on unix systems) I asked the company I work for to add as a requirement "familiarity with bash", because otherwise we would get candidates that don't know how to use PATH, or environment variables, and that was a serious problem. It's equivalent to having the requirement "know how to use a computer"
deleted 4y ago
[deleted]
HideousKojima 4y ago
I started out as a sysadmin before moving into dev and devs will think you're some sort of wizard just for understanding how file permissions or firewalls or nginx work, it's kind of baffling.
- deafpolygon 4y ago
  What's funny is I know some amount of <insert language here> owing to me being a JOAT (jack of all trades), so when they run into some issues and I'm able to debug it they wonder why I'm a sysadmin and get paid less than they do. Why ARE sysadmins like me paid less than developers? And I can't get hired as a dev because they see my CV and go, oh you're a sysadmin. I mean, try being a solo sysadmin of over 100+ production Linux servers with minimal downtime... you need a little bit of scripting/coding to handle all that!
  - siva7 4y ago
    If you're wording your CV the way it screams sysadmin right in your face the only offers you get will be sysadmin. Try emphasizing your coding experience more
    - deafpolygon 4y ago
      Correct, but it's also a common [false] view that sysadmins can't code. Even if I emphasize my limited) experience in code and leave out details about my sysadmin work, I get asked what did I do, etc. "Oh you're a sysadmin" and that's where the conversation ends. But let's gloss over the fact that I can set-up the testing and production environment on my own along with the DB, schema, do the routing, proxy and everything in between. Then, back it all up.
      - orwin 4y ago
        Try to market yourself as a devops. The pay is better than sysadmin, and if you're selective enough, the job can be great for you and your whole skillet. It took me 3 tries to get myself right where I wanted to be but when work doesn't really feel like work despite being at $BigCorp, life is enjoyable.
ncpa-cpl 4y ago
> I find a version of this even with fresh out of college programmers. I've noticed something with boot camp programmers too. Something that may have changed is that newer graduates may have studied programming because "it pays well", and not because they were computer hobbyists before deciding what to study. I've been on meetings with some programmers that didn't know how to use a gui ftp client or how to manually upload a file to a server. Because most of that stuff is abstracted now.
- JoachimS 4y ago
  Just like many other types of higher education. Doctors, Lawyers etc. A CS, CE, EE degree is for many the first step on a career path. In many cultures becoming an doctor, lawyer, engineer is something to strive for. It is an upstanding position and is well payed. Too bad being a teacher seems not to be like that anymore in many western countries. We here at HN are quite probably not the norm. Being hobbyists that have been tinkering with computers since early childhood should not be a requirement to become a programmer. If it were, the industry would not be able to scale as it has. There are simply too few of us in the human population.
- sideshowb 4y ago
  > newer graduates may have studied programming because "it pays well", Define new. Programming has been known to pay well since at least the 1990s.
  - PeterisP 4y ago
    There's a big gap between making early career choices and them materializing, also, information dissemination is slow and uneven. > Programming has been known to pay well since at least the 1990s. Known by whom? The median family in 1990 wouldn't even consider that programming as a career exists, much less that it pays well. At the dot-com boom in late 1990s, the adults would know that, but it wouldn't yet be "culturally assimilated" for the masses in the way the assumption about doctors and lawyers income was; and then you get the dot-com bust. I'd say that the time when the median high-schooler get told by all reasonable adults that "programming is a sure way to money for anyone, not just for weird geeks" doesn't arrive until 2000+ or even later; and from that time it takes ~10 years for that generation of kids to pass through school, college and fill the companies in great numbers.
devjab 4y ago
> And they also are reluctant to learn There may be some of this, but I think there is also the part where it can be really hard to learn. Typescript is my preferred language these days. Not for technical reasons, but because it lets small teams share language across the entire stack. At least in my area where React is basically "front-end" and it's tiny rivals are also Typescripted. But a lot of the eco-system is admittedly sort of silly. Say you want to use environment variables. A lot of people will use dotenv, we do too, but you can use it in many different ways. You can require(), you can import, and then you can use process.env.VARIABLE in your code. Which is fine, but really, what we consider the best practice way of doing it, is something a kin to having a config.ts file, which exports all the configuration as javascript objects. This way, you can use dotenv like this: node -r dotenv/config dist/app.js Nobody is going to tell you how to set these things up however. Well that's not exactly true, because EVERYONE is going to tell you how to do it, and in this myriad of options you're most likely going to end up with something that isn't great. React and other major frameworks with build tool will be opinionated and do it for you. React does it similar to how we do it, likely because having all your process.env.VARIABLEs exported as const means they are typed which makes it easier to debug. This doesn't mean developers necessarily pick up on it though. I've seen many React developers who don't use dotenv the way React does it, despite them having been exposed to the benefits of the react philosophy. So I think it's more than just reluctance. It's simply hard, and the internet or the community sort of makes it harder. Because you and I both know exactly why these React devs used it differently, they did it because the first 2000 100 word blog articles that you get when you google "how to dotenv" tells you how to do it "wrong". Then once these young developers venture out of their comfort zone, their impostor syndrome gets additional power when they do it "wrong" and someone calls them out on it in a less than friendly way.
RektBoy 4y ago
Depends on the country and uni. Here in CZ, best CS uni in country, first class is UNIX shell.
flandish 4y ago
I currently work with senior engs who are really more like reworked mech engs. Who want to use old versions of eclipse, on win8, install new copies of the same for diff projects, want the new associate level engs (23yo, first job, etc) to write plugins for that old eclipse so the shipped plugins that break due to age still work. Because they dont know svn command line, or how to merge without the plugin. Won’t migrate to git from svn - though that’s ok, we don't “need” distributed vc. They still think git history is so mutable its “spooky.” Though I’d love to make branches while working from home and not on the vpn… In short, and it’s just one story, really: this kind of thing happens at all levels and is really a management issue, imho. They should be pushed to expand knowledge as a priority in the workweek. Often we’re just tossed into “fix it ship it” mode and before we know it we’re 60 and cranky and yelling at clouds.
- logn 4y ago
  Perhaps these devs prefer the "fix it ship it" mode and don't see the value of learning particular skills. I find it a balancing act to be pragmatic and it involves being skeptical about investing time learning new tech. With everything there is to possibly learn, you have to ignore almost all of it... until (at the latest) it's industry standard in the niche you specialize in and then you have to be open minded that it's worthwhile to the company and personally. I have found in cultures like you describe "decision matrices" can be helpful because it allows people to consider costs, risks, do preliminary investigation, etc. That is a sort of way of providing encouragement and permission to learn things and innovate. Lunch-and-learns are another tactic to force people (or give them an excuse) to learn. Neither of those should need managers' approval to do (it's just creating a meeting invite for lunch or a wiki page). If these don't work the problem is probably the seniors internalizing management's whims instead of pushing back. But the engineers won't push back if they've never taken time to learn.
  - flandish 4y ago
    Solid thoughts - I neglected to let on that in my case the seniors lament about how new tech sucks, like python being just another perl… etc. They are “tear down prove it to me while I call things retarded” sometimes. Thats where mgmt should step in. Its really only a couple people.
vbezhenar 4y ago
There are three variants: #1. They are just stupid. #2. They don't care about work other than bare minimum to not get fired. They have better things in their life to care about. #3. They are as smart as you are, but they put their efforts elsewhere that you don't directly observe. May be they don't know how to operate Linux environment, but they spent days reading about DSP math and they can apply this knowledge to optimise some signal filter. May be they don't know HTML, but they spend that time to learn Spring internals and can compose really beautiful code out of it or solve very hard problems. I think that specialisation is not that bad. It's everywhere. Some people in IT are generalists, they know a bit of everything. I consider myself one. I'm trying to build an embedded Linux distro right now, few days ago I was writing parser for PDF to extract some information (real parser, byte after byte), few weeks ago I tinkered with STM32 program, few months ago I wrote Java service, next week I'l continue to work on React web app which is going to run on embedded device. I do everything, my knowledge helps me immensely to quickly dive into new area. But i'm absolutely far from expert and sometimes I'd spend lots of time when I lack a knowledge. For example I spent two weeks trying to start graphics on i.MX8MM board and I failed. I need to debug kernel but I just don't have that kind of skill in Linux internals. But there are people who prefer to specialise and that's fine and they would probably solve that problem in few days.
- scoutt 4y ago
  You forgot one variant: they just don't like it. Like me. I use the command line all the day, compiling AOSP and kernels, and drivers, firmware, and all kind of related things for embedded. But I don't like it. To me, it feels archaic and counterintuitive (I'm autodidact). Same goes for command line editors or Vi, Vim, Emacs, etc. It's not 1985 anymore. Microsoft and Apple built an empire based on coherent (up to some point) UIs. They succeded because they might were up to something.
  - fcatalan 4y ago
    It's not just concrete things like command line or linux or old crusty editors, it's about how they lack general computer savvy and flexible problem solving skills. One example: I had this guy, it was his second job, the previous one was about some Enterprise Java thing. Intelligent and hard working, and able to learn: we were exploring Erlang for some parts of the system and he was contributing within the month, with just a bit of hand-holding. But one day we get an urgent request for new functionality in the Java parts of the org, so I hand it to him. First task is getting some static data out of a few dusty html tables deep in the intranet and dumping it on a new table in the dev DB so we can start prototyping around it. A couple of hours go past and I go check up on him. He's deep into some docs for an XML parser and ORM so he can parse the tables and get the data into the DB. He has already like 5 or 6 classes with all their getters and setters but he's not nearly halfway done. I bring up the browser console, type $ to see if jQuery is loaded in the page, then come up with a one liner that spits the insert statements on the console (I had to google a couple of times, I'm not really a jQuery dude). But then even that was a bit too flashy... he could just have coaxed the data into the database fiddling around with a spreadsheet and the DB GUI for a couple minutes. But somehow his default and almost only mental model of interaction with data was overengineered Java, no matter how overkill it was for the task.
uoaei 4y ago
As a person with an extensive background in ML, I feel similarly about CS grads attaching themselves to "AI" enterprises until they convince themselves they're an "expert" without putting in the due diligence to understand the unifying math under the hood. They end up doing stupid things with their models, completely ruining their business proposition through their lack of understanding in how the ML theory makes the implementation make sense. And then they don't even know how to appropriately judge the quality of the outputs from the reported metrics. It's normies all the way down.
arka2147483647 4y ago
You forget the immense depth of everything that is computers today. It simply is not possible to learn everything, even basics of everything, in the time to get a decree.
astura 4y ago
Are you confusing bootcamp and college? Or are you hiring people with only English degrees instead of CS degrees? Sure, I graduated from college almost two decades ago but all those "can't"s were very much part of the standard CS curriculum then. You needed those skills to pass CS 101. The new grads I work with now at are fine on the terminal. They only complain that they didn't learn how to use more "advanced" features of debuggers and IDEs in college. Exactly the opposite.
908B64B197 4y ago
> I find a version of this even with fresh out of college programmers. > They just know how to type Java on an IDE, maybe some SQL (using some graphical front end), some HTML/CSS. They can't operate in a Linux dev environment at all, can't use the command line or exit vi or perform any kind of simple shell based automation or use git without a plugin for their IDE. > And they also are reluctant to learn Sounds like you are hiring wrong. The point of a good engineering degree is to teach someone how to learn. Any degree worth something will include non-trivial coursework and projects, so they should already be familiar with some of the tooling.
rewgs 4y ago
Absolutely spot on. A very good friend of mine went through a bootcamp and very much views himself as essentially “blue collar” —- do the job, go home. It’s for money, not passion, not at all. There’s nothing wrong with that per se, but with that mentality typically comes a distinct lack of curiosity. He’ll only learn new things when directed to, and unfortunately that means that he learns little and not often. Over time, that makes the experience of being a software developer very painful indeed. We were talking about a recent problem he was having, getting his IDE and build server and virtual environments talking to each other, and it became immediately clear to me that if he knew what an environment variable was, he’d have solved this in about 5 minutes. Instead he’d been stuck for days, kind of just flailing. I also suggested spinning up a dev VM or container so that he can make snapshots, nuke it and start over, etc as he makes progress figuring it out. He flatly stated that that “wouldn’t work” for reasons he couldn’t articulate. I am almost obsessively curious about how computers work, and that curiosity led me to Linux and a nearly 100%-CLI workflow. That more than any other skill has paid off, even if viewed completely dispassionately: at least half the tools you’ll be using will have been written from this same POV, where a CLI-centric workflow and Linux are both first-class citizens. A lot of people just want to “write code” but seem to completely ignore the reality that that doesn’t happen in a vacuum. You’re using tools, and those tools very often require some understanding of the computer they’re running on. There’s some meme floating around out there about how “easy is hard” —- exercising is hard, but enduring the effects of not exercising is harder, etc. Now that I’m on the other side of it, I absolutely believe that working in the command line, ideally on Linux (but macOS will do fine as well), is the best way to pick up all the “glue” knowledge that allows you to reason your way through just about any situation you find yourself in. We do ourselves quite a disservice by calling most of these skills those of “sysadmin” or “devops” or what have you —- to me it just seems like it’s “knowing computers,” and when you’re spending your days writing instructions for computers to perform, that can surely only be a good thing.
throw_m239339 4y ago
I know plenty of fresh out of college developers that absolutely DO NOT FIT that profile. They are very proficient with shell and linux, hate IDE, are curious about all sorts of technology because they are always finding better ways to do things and aren't dogmatic when it comes to language paradigm. Your problem might be where you get your fresh out of college developers, you may get them from prestigious universities, but it says absolutely nothing about whether they actually love programming or not, or they are just in programming because of the promise of a fat paycheck.

nicolas_t 4y ago

What kind of college grads don't know how to operate in a linux dev environment? That'd be an immediate no-hire from me.

voidfunc 4y ago
Most lol. You only hiring MIT and Stanford grads?
- srcreigh 4y ago
  Stanford or MIT or UWaterloo
  - stametseater 4y ago
    Bah. I took community college courses in highschool and the basic bitch introduction C++ course at that community college had the students using linux in the lab. The second-rate university I ended up going to after highschool required CS students to learn either Vim or Emacs to pass one of the required introduction courses, and all assignments had to compile and run on linux otherwise the TAs would reject them. As far as I've seen, basic linux skills are taught if not required in the CS programs of colleges of any reputation or stature.
- strken 4y ago
  On my first day at a frankly pretty shit Australian university, we had mandatory Linux and Solaris training. I managed to skip it because the IT guy turned his screen to me and said "What's this?" and I replied "Dunno, looks like Fedora Core", but anyone who couldn't do that sat through several hours of training on SSHing into things and using bash, after which they were expected to turn in assignments that would compile in a remote Solaris environment. This story doesn't have any real point, except maybe to say that knowing your way around a shell is up to the arbitrary whims of your university's administration and lecturers.
  - worthless-trash 4y ago
    And maybe it awakens them to the fact that there is more out there than the abstract "what i run at home" environments available.
- m-ee 4y ago
  Stanford ain’t gonna teach you Unix either. I think they at least teach git usage in the intro classes now, but certainly did not while was there. Wasn’t a CS major but took a number of classes. The only class I took that touched on anything practical for the working world was “programming for scientists and engineers”, CME211 I think? And most people only took it because it counted for grad level math credits.
- _moof 4y ago
  I was taught how to get around a UNIX box in CS 101 at a state school.
  - Kon-Peki 4y ago
    Purdue CS in the mid/late 1990s. All coursework, if it wasn’t handwritten on paper, was developed and submitted with your account on the department UNIX cluster. I switched majors so didn’t have any freshman courses; I certainly hope they taught people how to use the system. You couldn’t pass a class, let alone graduate, without being able to use UNIX. There were a few side benefits to this setup. First, it allowed you to use the Sun pizza boxes in the engineering admin building, which were insanely powerful (back then). Second, it meant you could use any computer lab on campus, because they all had terminal emulators installed. So while the average student waiting in line for an open Windows PC, you could go down the hall and sit down at a Mac in a lab that had maybe two other people in it. Third, you could submit all your print jobs to the service center in the basement of the math building, where they’d collated, staple, whatever you wanted and then put it in a mailbox for you to collect at your own convenience, rather than deal with the clown show at the printers in all the Windows computer labs. Good times
    - _moof 4y ago
      Oh, hey, IU in the mid 1990s here. We were doing Scheme on DEC ULTRIX boxes. (Which is also how I ended up being an emacs user. Oh well. Nobody's perfect.) Good times indeed!
- oytis 4y ago
  I graduated in a third world country. We did have a course or two on Unix.
- ecshafer 4y ago
  I went to a state school, 75% of the CS class used linux, 20% used OSX and maybe 5% used windows.
fcatalan 4y ago
The kind that went into the subject just because it pays well and are taught some kind of bimodal syllabus: Lots of heavy Math/CS stuff they forget after the test and then practical programming as defined by "industry", industry being the big consulting firms churning out Java.
- lopkeny12ko 4y ago
  This is exactly it. I'm involved with a lot of hiring for junior developers. It saddens me how many of them are trying to get into the field not because they're passionate for programming, interested in computers, or enjoy tinkering with digital tools. They're here because they're allured by big paychecks and "because everyone else at school is doing it." There are, of course, exceptions, and those are the junior developers who excel the most but they are few and far in between.
  - nicolas_t 4y ago
    Yup, and given that my entire career has been in startups environments, people who lack that passion and interest are usually not a good hire. Not knowing one's way around linux is a major red flag because it shows they lack curiosity for their chosen profession.
pxc 4y ago
At my first job out of college, I met a lot of junior developers who could sort of get by in a Unix CLI, but didn't know anything except the very basics and didn't much like it. I was a Linux hobbyist from the age of 12, so I thought that sucked. Since the company had a practice where developers could give their peers educational talks, I decided to demo some of the things I use to make my Unix command line environments feel really great to work in. I found that pointing CLI-shy devs to a nicer shell designed with ease of use in mind (Fish) and some basic navigation tools like fzf and autojump got a good chunk of them genuinely excited to learn more about the command line and make their environments more comfy. I also reviewed the available in-terminal documentation tools including those they likely hadn't seen in school (e.g., tldr, bro-pages), and I think that helped make clear how efficient exploring the command line from the command line can be. (Nowadays I'd also direct them to explainshell.com and some other web resources, though I think emphasizing the 'in-band' stuff is important.) The next day, and every now and then for some time, I saw them reading the docs, writing their own little plugins and scripts and aliases, customizing their prompts, and so on. I knew about it because they sometimes even called me over to show off! It would have been a shame to blow them off because, not having seen how it can be delightful to use, they saw the terminal as something to be avoided. They were smart, capable people who just hadn't encountered a good enough pitch yet. Once the environment is comfy, learning individual tools in it becomes a lot less intimidating and more appealing to people. But you have to show them how good it can be and offer them a decent starter kit. :)
smarmgoblin 4y ago
It’s more common than you think. I graduated in 2013 and can tell you there were minimal opportunities to learn how to operate a Linux command line (if you didn’t already want to). Most jobs will set you up with some IDE with the codebase preloaded and a big green compile button, it’s just easy to avoid I guess. I’ve been using Linux since 2008 and it’s the most high-yield skill set I have, it makes everything simpler and I encourage others to learn it.
- animitronix 4y ago
  It's crazy how fast it changed then. I graduated in 2002 and you literally could not leave without knowing how to use Unix. When I started in '98 the school's email system had to be checked through terminals and my dorm hadn't even been wired with Ethernet, although we had it by the second half of my freshman year.
  - smarmgoblin 4y ago
    I believe that. Others may have had a different experience to mine. I was always searching for a class that would give me the “real” Linux experience but nothing really exists like that, I think you just have to live with the tools for a bit.
ZephyrBlu 4y ago
Umm, most professional programmers probably don't know how to operate in a linux dev environment bro... That is also an extremely stupid requirement. You can be a good programmer (Especially as a junior) without knowing all the linux command line tools.
- foolfoolz 4y ago
  this is the most common. id say most people i’ve worked with start caring to learn the shell and dig into the os more around year 8 of their career
  - pxc 4y ago
    > id say most people i’ve worked with start caring to learn the shell and dig into the os more around year 8 of their career That sounds tragically late to me. It represents a serious failure on the part of those who know and love the command line to make it accessible to newcomers, imo.
    - foolfoolz 4y ago
      nah it just shows how the valuable abstractions have moved up. i bet this 8 year mark will only get later over time until it disappears
      - pxc 4y ago
        Level of abstraction is largely orthogonal to the GUI/CLI divide, though. nmcli is more abstract than ip+iw+wpa_supplicant, but it's no more or less abstract than any GUI network configuration widget. The output of ls is no more or less abstract than the contents of a directory as displayed by a GUI file manager. It's the same metaphor and the same information displayed in two different formats.
- nicolas_t 4y ago
  I haven't met a good professional programmer working in webdev who didn't know their way around linux. I've met plenty of bad programers who got into this field for money, didn't know how their way around unix, were barely able to do fizz buzz and would be better doing something else. I haven't hired them though. Not knowing one's way around linux is a sign of lack of curiosity and passion for the topic. It's obviously different in some fields (like gamedev) where the code produced by the dev is not supposed to run in a linux environment.
jemmyw 4y ago
Even when I graduated in 2004 there were lots of people there for the money side of it rather than much interest in programming / computing itself. I would say maybe 1/4 or less were taking more interest.
maccard 4y ago
If you can't onboard a fresh grad into a usable state with version control, a toolchain, and an editor in 1-2 weeks, you shouldn't be hiring fresh grads. Expecting Linux familiarity fresh out of college is just plain gatekeeping.

bmitc 4y ago

This is a somewhat harsh take. I've met plenty of programmers also set in their ways in that C or Python is the only language needed and that concurrency or functional programming is "hard" and thus not worth learning. Whereas I find concurrency and functional programming, given the correct language for it like F#, LabVIEW, Elixir, etc., is easy and manageable. It just all depends on context and experience and additionally philosophy. For me, I have been developing for several years in several different contexts and consider myself a decent software developer who focuses a lot on proper design and implementation, readability, maintainability, speed when needed, etc. However, I am relatively weak on all the various Unix tooling (I know the general basics of course) and am currently trying to address that. Reasons for this are that I worked professionally for a long time in a Windows environment. Any scripting done was via PowerShell, which is a quite powerful tool and language and something I actually often prefer given the readability, if not verboseness, of the commandlet names or via the programming language used. My more Linux oriented roles or projects are more recent and have used languages like Elixir or F#. Since both of these languages have built-in scripting, any scripting was done with the languages themselves. Elixir has such powerful tooling that, for whatever reason, I just rarely found that I needed the Unix command line tools for what I was personally responsible for or working on or what wasn't provided by Elixir or my editor in VS Code. Elixir allows you to build custom Mix commands, which is also nice. However, now I'm in an environment where many of these tools could be very useful, so I am trying to pick them up. And it's always possible that I was missing out, so it's important just to be willing to learn as things present themselves. Just stating this because context is everything.

Fire-Dragon-DoL 4y ago
Keep in mind that "unix knowledge" doesn't mean knowing bash scripting, but understanding a bit about the shell is the key part. You worked on windows, but you probably know about environment variables, how they are passed around, what PATH is, how to list files in a directory, cd around, copy/delete files, redirect, pipe and how to use git given your profession. Isn't that the case? I've been on Windows and learned all that as a hobbyist (I'm a professional developer, but I work on unix systems) I asked the company I work for to add as a requirement "familiarity with bash", because otherwise we would get candidates that don't know how to use PATH, or environment variables, and that was a serious problem. It's equivalent to having the requirement "know how to use a computer"

deleted 4y ago

[deleted]

HideousKojima 4y ago

I started out as a sysadmin before moving into dev and devs will think you're some sort of wizard just for understanding how file permissions or firewalls or nginx work, it's kind of baffling.

deafpolygon 4y ago
What's funny is I know some amount of <insert language here> owing to me being a JOAT (jack of all trades), so when they run into some issues and I'm able to debug it they wonder why I'm a sysadmin and get paid less than they do. Why ARE sysadmins like me paid less than developers? And I can't get hired as a dev because they see my CV and go, oh you're a sysadmin. I mean, try being a solo sysadmin of over 100+ production Linux servers with minimal downtime... you need a little bit of scripting/coding to handle all that!
- siva7 4y ago
  If you're wording your CV the way it screams sysadmin right in your face the only offers you get will be sysadmin. Try emphasizing your coding experience more
  - deafpolygon 4y ago
    Correct, but it's also a common [false] view that sysadmins can't code. Even if I emphasize my limited) experience in code and leave out details about my sysadmin work, I get asked what did I do, etc. "Oh you're a sysadmin" and that's where the conversation ends. But let's gloss over the fact that I can set-up the testing and production environment on my own along with the DB, schema, do the routing, proxy and everything in between. Then, back it all up.
    - orwin 4y ago
      Try to market yourself as a devops. The pay is better than sysadmin, and if you're selective enough, the job can be great for you and your whole skillet. It took me 3 tries to get myself right where I wanted to be but when work doesn't really feel like work despite being at $BigCorp, life is enjoyable.

ncpa-cpl 4y ago

> I find a version of this even with fresh out of college programmers. I've noticed something with boot camp programmers too. Something that may have changed is that newer graduates may have studied programming because "it pays well", and not because they were computer hobbyists before deciding what to study. I've been on meetings with some programmers that didn't know how to use a gui ftp client or how to manually upload a file to a server. Because most of that stuff is abstracted now.

JoachimS 4y ago
Just like many other types of higher education. Doctors, Lawyers etc. A CS, CE, EE degree is for many the first step on a career path. In many cultures becoming an doctor, lawyer, engineer is something to strive for. It is an upstanding position and is well payed. Too bad being a teacher seems not to be like that anymore in many western countries. We here at HN are quite probably not the norm. Being hobbyists that have been tinkering with computers since early childhood should not be a requirement to become a programmer. If it were, the industry would not be able to scale as it has. There are simply too few of us in the human population.
sideshowb 4y ago
> newer graduates may have studied programming because "it pays well", Define new. Programming has been known to pay well since at least the 1990s.
- PeterisP 4y ago
  There's a big gap between making early career choices and them materializing, also, information dissemination is slow and uneven. > Programming has been known to pay well since at least the 1990s. Known by whom? The median family in 1990 wouldn't even consider that programming as a career exists, much less that it pays well. At the dot-com boom in late 1990s, the adults would know that, but it wouldn't yet be "culturally assimilated" for the masses in the way the assumption about doctors and lawyers income was; and then you get the dot-com bust. I'd say that the time when the median high-schooler get told by all reasonable adults that "programming is a sure way to money for anyone, not just for weird geeks" doesn't arrive until 2000+ or even later; and from that time it takes ~10 years for that generation of kids to pass through school, college and fill the companies in great numbers.

devjab 4y ago

> And they also are reluctant to learn There may be some of this, but I think there is also the part where it can be really hard to learn. Typescript is my preferred language these days. Not for technical reasons, but because it lets small teams share language across the entire stack. At least in my area where React is basically "front-end" and it's tiny rivals are also Typescripted. But a lot of the eco-system is admittedly sort of silly. Say you want to use environment variables. A lot of people will use dotenv, we do too, but you can use it in many different ways. You can require(), you can import, and then you can use process.env.VARIABLE in your code. Which is fine, but really, what we consider the best practice way of doing it, is something a kin to having a config.ts file, which exports all the configuration as javascript objects. This way, you can use dotenv like this: node -r dotenv/config dist/app.js Nobody is going to tell you how to set these things up however. Well that's not exactly true, because EVERYONE is going to tell you how to do it, and in this myriad of options you're most likely going to end up with something that isn't great. React and other major frameworks with build tool will be opinionated and do it for you. React does it similar to how we do it, likely because having all your process.env.VARIABLEs exported as const means they are typed which makes it easier to debug. This doesn't mean developers necessarily pick up on it though. I've seen many React developers who don't use dotenv the way React does it, despite them having been exposed to the benefits of the react philosophy. So I think it's more than just reluctance. It's simply hard, and the internet or the community sort of makes it harder. Because you and I both know exactly why these React devs used it differently, they did it because the first 2000 100 word blog articles that you get when you google "how to dotenv" tells you how to do it "wrong". Then once these young developers venture out of their comfort zone, their impostor syndrome gets additional power when they do it "wrong" and someone calls them out on it in a less than friendly way.

RektBoy 4y ago

Depends on the country and uni. Here in CZ, best CS uni in country, first class is UNIX shell.

flandish 4y ago

I currently work with senior engs who are really more like reworked mech engs. Who want to use old versions of eclipse, on win8, install new copies of the same for diff projects, want the new associate level engs (23yo, first job, etc) to write plugins for that old eclipse so the shipped plugins that break due to age still work. Because they dont know svn command line, or how to merge without the plugin. Won’t migrate to git from svn - though that’s ok, we don't “need” distributed vc. They still think git history is so mutable its “spooky.” Though I’d love to make branches while working from home and not on the vpn… In short, and it’s just one story, really: this kind of thing happens at all levels and is really a management issue, imho. They should be pushed to expand knowledge as a priority in the workweek. Often we’re just tossed into “fix it ship it” mode and before we know it we’re 60 and cranky and yelling at clouds.

logn 4y ago
Perhaps these devs prefer the "fix it ship it" mode and don't see the value of learning particular skills. I find it a balancing act to be pragmatic and it involves being skeptical about investing time learning new tech. With everything there is to possibly learn, you have to ignore almost all of it... until (at the latest) it's industry standard in the niche you specialize in and then you have to be open minded that it's worthwhile to the company and personally. I have found in cultures like you describe "decision matrices" can be helpful because it allows people to consider costs, risks, do preliminary investigation, etc. That is a sort of way of providing encouragement and permission to learn things and innovate. Lunch-and-learns are another tactic to force people (or give them an excuse) to learn. Neither of those should need managers' approval to do (it's just creating a meeting invite for lunch or a wiki page). If these don't work the problem is probably the seniors internalizing management's whims instead of pushing back. But the engineers won't push back if they've never taken time to learn.
- flandish 4y ago
  Solid thoughts - I neglected to let on that in my case the seniors lament about how new tech sucks, like python being just another perl… etc. They are “tear down prove it to me while I call things retarded” sometimes. Thats where mgmt should step in. Its really only a couple people.

vbezhenar 4y ago

There are three variants: #1. They are just stupid. #2. They don't care about work other than bare minimum to not get fired. They have better things in their life to care about. #3. They are as smart as you are, but they put their efforts elsewhere that you don't directly observe. May be they don't know how to operate Linux environment, but they spent days reading about DSP math and they can apply this knowledge to optimise some signal filter. May be they don't know HTML, but they spend that time to learn Spring internals and can compose really beautiful code out of it or solve very hard problems. I think that specialisation is not that bad. It's everywhere. Some people in IT are generalists, they know a bit of everything. I consider myself one. I'm trying to build an embedded Linux distro right now, few days ago I was writing parser for PDF to extract some information (real parser, byte after byte), few weeks ago I tinkered with STM32 program, few months ago I wrote Java service, next week I'l continue to work on React web app which is going to run on embedded device. I do everything, my knowledge helps me immensely to quickly dive into new area. But i'm absolutely far from expert and sometimes I'd spend lots of time when I lack a knowledge. For example I spent two weeks trying to start graphics on i.MX8MM board and I failed. I need to debug kernel but I just don't have that kind of skill in Linux internals. But there are people who prefer to specialise and that's fine and they would probably solve that problem in few days.

scoutt 4y ago
You forgot one variant: they just don't like it. Like me. I use the command line all the day, compiling AOSP and kernels, and drivers, firmware, and all kind of related things for embedded. But I don't like it. To me, it feels archaic and counterintuitive (I'm autodidact). Same goes for command line editors or Vi, Vim, Emacs, etc. It's not 1985 anymore. Microsoft and Apple built an empire based on coherent (up to some point) UIs. They succeded because they might were up to something.
- fcatalan 4y ago
  It's not just concrete things like command line or linux or old crusty editors, it's about how they lack general computer savvy and flexible problem solving skills. One example: I had this guy, it was his second job, the previous one was about some Enterprise Java thing. Intelligent and hard working, and able to learn: we were exploring Erlang for some parts of the system and he was contributing within the month, with just a bit of hand-holding. But one day we get an urgent request for new functionality in the Java parts of the org, so I hand it to him. First task is getting some static data out of a few dusty html tables deep in the intranet and dumping it on a new table in the dev DB so we can start prototyping around it. A couple of hours go past and I go check up on him. He's deep into some docs for an XML parser and ORM so he can parse the tables and get the data into the DB. He has already like 5 or 6 classes with all their getters and setters but he's not nearly halfway done. I bring up the browser console, type $ to see if jQuery is loaded in the page, then come up with a one liner that spits the insert statements on the console (I had to google a couple of times, I'm not really a jQuery dude). But then even that was a bit too flashy... he could just have coaxed the data into the database fiddling around with a spreadsheet and the DB GUI for a couple minutes. But somehow his default and almost only mental model of interaction with data was overengineered Java, no matter how overkill it was for the task.

uoaei 4y ago

As a person with an extensive background in ML, I feel similarly about CS grads attaching themselves to "AI" enterprises until they convince themselves they're an "expert" without putting in the due diligence to understand the unifying math under the hood. They end up doing stupid things with their models, completely ruining their business proposition through their lack of understanding in how the ML theory makes the implementation make sense. And then they don't even know how to appropriately judge the quality of the outputs from the reported metrics. It's normies all the way down.

arka2147483647 4y ago

You forget the immense depth of everything that is computers today. It simply is not possible to learn everything, even basics of everything, in the time to get a decree.

astura 4y ago

Are you confusing bootcamp and college? Or are you hiring people with only English degrees instead of CS degrees? Sure, I graduated from college almost two decades ago but all those "can't"s were very much part of the standard CS curriculum then. You needed those skills to pass CS 101. The new grads I work with now at are fine on the terminal. They only complain that they didn't learn how to use more "advanced" features of debuggers and IDEs in college. Exactly the opposite.

908B64B197 4y ago

> I find a version of this even with fresh out of college programmers. > They just know how to type Java on an IDE, maybe some SQL (using some graphical front end), some HTML/CSS. They can't operate in a Linux dev environment at all, can't use the command line or exit vi or perform any kind of simple shell based automation or use git without a plugin for their IDE. > And they also are reluctant to learn Sounds like you are hiring wrong. The point of a good engineering degree is to teach someone how to learn. Any degree worth something will include non-trivial coursework and projects, so they should already be familiar with some of the tooling.

rewgs 4y ago

Absolutely spot on. A very good friend of mine went through a bootcamp and very much views himself as essentially “blue collar” —- do the job, go home. It’s for money, not passion, not at all. There’s nothing wrong with that per se, but with that mentality typically comes a distinct lack of curiosity. He’ll only learn new things when directed to, and unfortunately that means that he learns little and not often. Over time, that makes the experience of being a software developer very painful indeed. We were talking about a recent problem he was having, getting his IDE and build server and virtual environments talking to each other, and it became immediately clear to me that if he knew what an environment variable was, he’d have solved this in about 5 minutes. Instead he’d been stuck for days, kind of just flailing. I also suggested spinning up a dev VM or container so that he can make snapshots, nuke it and start over, etc as he makes progress figuring it out. He flatly stated that that “wouldn’t work” for reasons he couldn’t articulate. I am almost obsessively curious about how computers work, and that curiosity led me to Linux and a nearly 100%-CLI workflow. That more than any other skill has paid off, even if viewed completely dispassionately: at least half the tools you’ll be using will have been written from this same POV, where a CLI-centric workflow and Linux are both first-class citizens. A lot of people just want to “write code” but seem to completely ignore the reality that that doesn’t happen in a vacuum. You’re using tools, and those tools very often require some understanding of the computer they’re running on. There’s some meme floating around out there about how “easy is hard” —- exercising is hard, but enduring the effects of not exercising is harder, etc. Now that I’m on the other side of it, I absolutely believe that working in the command line, ideally on Linux (but macOS will do fine as well), is the best way to pick up all the “glue” knowledge that allows you to reason your way through just about any situation you find yourself in. We do ourselves quite a disservice by calling most of these skills those of “sysadmin” or “devops” or what have you —- to me it just seems like it’s “knowing computers,” and when you’re spending your days writing instructions for computers to perform, that can surely only be a good thing.

throw_m239339 4y ago

I know plenty of fresh out of college developers that absolutely DO NOT FIT that profile. They are very proficient with shell and linux, hate IDE, are curious about all sorts of technology because they are always finding better ways to do things and aren't dogmatic when it comes to language paradigm. Your problem might be where you get your fresh out of college developers, you may get them from prestigious universities, but it says absolutely nothing about whether they actually love programming or not, or they are just in programming because of the promise of a fat paycheck.