4 ms·

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 ski

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.

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.