4 ms·

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 o

by 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.
- scoutt 4y ago
  One thing I learned in my 41 years is that nobody thinks like me (or you). It's not that I 'think better' or that I am 'better at thinking'. But sometimes I deal with variables that I can't correctly communicate or translate. I often think that people deals with the same information as me, and will follow my same path of reasoning. 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".
  - alpaca128 4y ago
    Building the long-term solution first is often wrong even when you need one. I use the quick and dirty method until I know I'll do that task more regularly and I know enough about the problem so I don't need to make wild guesses about the design.
    - scoutt 4y ago
      This is a clear example of what I was talking about. The fact that you use a given method doesn't mean other methods are "often wrong even when you need one". This is just the way you think and work, in the position you are now. 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.
    - watwut 4y ago
      Not everyone do that tho. And that includes pretty good senior engineers I work with.
      - recfab 4y ago
        Learning to work "quick and dirty" is something I'm actually working on improving, personally. 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.
    - Aeolun 4y ago
      > I use the quick and dirty method until I use it until I realize it’s not quick after all. Now I default to writing one off scripts.
alpaca128 4y ago
I guess it's just different workflows and preferences. I like Vim and the commandline because they don't get in my way and don't try to be clever. I don't get 3 popups every time I open a program because there's a new update available and it really wants me to create an account and it has a super important "tip of the day" I forgot to turn off. Instead I can give it a couple thousand lines from a source it doesn't need to know about and let it chew on the data and write it into a file to load in a Python script. And somehow it still all stays up to date without having to tell me. 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.
Aeolun 4y ago
I don’t think compiling kernels would really gain anything from being outside a terminal? 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.
- scoutt 4y ago
  > I don’t think compiling kernels would really gain anything from being outside a terminal? 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.

by scoutt 4y ago

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.

scoutt 4y ago
One thing I learned in my 41 years is that nobody thinks like me (or you). It's not that I 'think better' or that I am 'better at thinking'. But sometimes I deal with variables that I can't correctly communicate or translate. I often think that people deals with the same information as me, and will follow my same path of reasoning. 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".
- alpaca128 4y ago
  Building the long-term solution first is often wrong even when you need one. I use the quick and dirty method until I know I'll do that task more regularly and I know enough about the problem so I don't need to make wild guesses about the design.
  - scoutt 4y ago
    This is a clear example of what I was talking about. The fact that you use a given method doesn't mean other methods are "often wrong even when you need one". This is just the way you think and work, in the position you are now. 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.
  - watwut 4y ago
    Not everyone do that tho. And that includes pretty good senior engineers I work with.
    - recfab 4y ago
      Learning to work "quick and dirty" is something I'm actually working on improving, personally. 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.
  - Aeolun 4y ago
    > I use the quick and dirty method until I use it until I realize it’s not quick after all. Now I default to writing one off scripts.

alpaca128 4y ago

I guess it's just different workflows and preferences. I like Vim and the commandline because they don't get in my way and don't try to be clever. I don't get 3 popups every time I open a program because there's a new update available and it really wants me to create an account and it has a super important "tip of the day" I forgot to turn off. Instead I can give it a couple thousand lines from a source it doesn't need to know about and let it chew on the data and write it into a file to load in a Python script. And somehow it still all stays up to date without having to tell me. 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.

Aeolun 4y ago

I don’t think compiling kernels would really gain anything from being outside a terminal? 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.

scoutt 4y ago
> I don’t think compiling kernels would really gain anything from being outside a terminal? 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.