Comment by vbezhenar | Hacker News Reader

Comment by vbezhenar | Hacker News Reader

Parent Full thread

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.

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.

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.

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".

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.

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.

Not everyone do that tho. And that includes pretty good senior engineers I work with.

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.

> 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.

> 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

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.

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.

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.

> 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.

Reply on news.ycombinator.com