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.
There are, of course, exceptions, and those are the junior developers who excel the most but they are few and far in between.
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.
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.
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.
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
Good times indeed!
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.
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.
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.
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.
Complete bullshit. The only thing it's a sign of is that you're not curious or passionate about linux.
Knowing about and being interested in linux may be a positive signal, but the opposite is not a negative signal.
Knowing linux is not a requirement to be a good professional programmer working in webdev.
And electron, don’t forget about electron.
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.
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"
> Isn't that the case?
Yes, of course. But there is certainly a wide variance in people's understandings of all the command line tools and uses cases that they are presented with in their own work and experience.
Software engineering is a huge field with a ton of use cases and different contexts and applications and domains. It's really all over the place. There is some patience needed when interfacing between all of these.
I took this opinion towards some presentations for co-workers and their came back to me saying that they have gotten, even if a glimpse, a broader sense what can be done. That really transcends a bit from the hot-new-tech rush, because these bits are foundational, in one way or another, to our unix/linux/bsd systems.
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!
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.
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.
Even when companies specifically state otherwise, it's how they usually behave.
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.
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.
Define new. Programming has been known to pay well since at least the 1990s.
> 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.
In fact I didn’t know much at all about computer science other than some prerequisite class I was bored out of my mind in.
Gates was, however, on the Forbes rich list since the late 80s, and richest person in the world from 1995, so I find it hard to believe anybody really money-driven wouldn't have known this at the time.
I would consider myself a decent programmer I have a masters degree, and have a deep technical understanding of multiple areas. I've plenty of experience and have shipped successful products.
I've never (not once) in my life used a GUI ftp client, and I can futz my way around an SCP command to shuffle a file around if I need to.
I can make the same argument against someone who refused to use a new development environment because they understand how their compiler works under the hood.
Just because someone doesn't know something that you know doesn't mean that you're better than them, it means you're different. Personally, i would rather have someone on my team who understands how to extract logs from cloudwatch/datadog/new relic than someone who insists our VPN solution has FTP access to our servers.
Also, it is ok and to be expected for fresh graduates to have only knowledge in most important areas for them. Even people who want to learn a lot more then necessary are better off focusing on learning more in the immediate area they will actually use at first.
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.
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.
Thats where mgmt should step in. Its really only a couple people.
#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.
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.
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.
Perhaps the dev thought it should be a tool that you will be using every day, or a thing to maintain in the future.
For example, in what you wrote, I really understood the thing you wanted to do by reading what you've finally did. Perhaps the input to the dev should have been: "Hey we have to do this, and we need this mock data from this HTML to start developing. First we take the data out. Don't worry much about how you do it, even if it's nasty. We don't need a full-fledged production-grade "HTML data extractor" to do this. This is data that we would be importing twice at max. So even if you lose 15 minutes copypasting it into a CSV file, it's fine".
If your boss at the workplace you've been working probably "within the month" or a little longer tells you to write a program to do X, you'll maybe pulling all your knowledge out to write a program to do X as if it were the most important program in the world.
I don't necessarily do BDUF or anything, but I generally do more "engineering" than is often directly necessary. Partially, it's my personality. But part of it is that in my experience, prototypes have a way of becoming production systems.
Last time I had to do a prototype for work, I split the difference: working quick and dirty, just meeting the minimal requirements, but also documenting what we would need to do if we decided to move forward with it. That felt like a good balance.
I use it until I realize it’s not quick after all. Now I default to writing one off scripts.
For something like this, the first thing I'd do is extract the first row manually in Vim, recording my actions as a macro, then use that macro to extract the rest. That would take a few minutes tops, depending on the structure of the data it might take seconds or there might be a bit more massaging necessary, but no more than about 5 minutes for this step. I have a keybinding that maps execution of the macro in the q register to the spacebar to streamline this process; I double-tap q to start recording, press q again to stop recording, and press/hold the spacebar to execute that q macro. In my experience, 2 or 3 passes are usually enough to cleanly extract a table of data from some random HTML page.
If the job was a once-and-done, then I'm already done. If I am meant to be creating something that can be re-used later, then I still do the above anyway and now I have the result with which to test whatever more permanent solution I'm writing.
GUIs are nice to get into but are also limiting because they were designed with assumptions about how I use the program. Compared to the commandline they feel like they have a wall built around them that prevents me from making them interact with the rest of the system. Some GUIs are less limiting but in turn not any more beginner-friendly than the commandline.
Ultimately it’s just an interface to programs that output mostly text. It took me a really long time to wrap my head around that. Programs that have a GUI and programs that run in the terminal use the same building blocks.
I remember compiling, flashing and debugging Windows CE images (10? maybe 15 years ago?) from an IDE (Visual Studio). It was super comfortable. Setting breakpoints, jumping to any kernel thread, navigating the call stack, watching memory and variables. All from the IDE. The development process was super fast.
Now between dmesg and logcat, I have to debug reading and grepping thousands of lines of log. Also adding printk, ALOG and all sort of logging functions to the code, recompiling, reflashing using a terminal with ADB, etc.
> Ultimately it’s just an interface to programs that output mostly text
For example, double-clicking on a compilation error and showing the error in an IDE is priceless. I know there should be some Vim plugin that does that, but it's out-of-the-box on every decent/modern coding IDE out there (VScode + ssh, which I use for AOSP, for example). Even better if the IDE shows only the errors/warnings the compiler emitted.
Also, try to find the error line between 10000's lines of building log when you compile a kernel/AOSP in parallel with -j20.
It's normies all the way down.
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.
The new grads I talk to now at work only complain that they didn't learn how to use "advanced" debuggers/IDEs in college. They are fine on the terminal.
> 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.
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.
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.
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.