On Coding, Ego and Attention • Hacker News Board

Re: On Coding, Ego and Attention

#141

Post by Artlav » Wed, Jun 17, 2020, 2:46 AM UTC

eikenberry wrote: post #59

Did anyone else find the "Relative Distance" section seeming wrong. Not the harvard-vs-random school thing but the conclusion they draw, that you perform relative to your standing. How are students aware of their positions? Do some schools post rankings or something? When I was in school you're standing/grades were private and no one knew another students standing (aside from the obvious, people failing out and such)…

Seems wrong to me too, but for a different reason - i would expect a better school to not only attract smarter students, but to also be harder. So it should balance out to the same curve.

Re: On Coding, Ego and Attention

#142

Post by closeparen » Wed, Jun 17, 2020, 2:49 AM UTC

DavidVoid wrote: post #116

camgunz wrote: post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

> They say the way to get ahead at Google is to build a new successful product. Is that the same thing we're doing? It's easier to get ahead by building a new Z framework than to become a core committer on X framework from 10 years ago? A Kurt Vonnegut quote comes to mind: "Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance."

Aside from cleaning and lubrication, a lot of "doing maintenance" is still throwing away old material and bringing in new. Just being selective about exactly which part is at the end of its duty cycle.

People talk about it like there's something wrong when, at any given time, a few microservices are being rewritten. But I would expect that for a sufficiently large machine, on any given day a few parts are being replaced.

Re: On Coding, Ego and Attention

#143

Post by Arelius » Wed, Jun 17, 2020, 3:34 AM UTC

peterkos wrote: post #127

camgunz wrote: post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

I remember reading an article that studied junior and senior devs and discovered that there was no way to get better at debugging. No matter how much experience someone had, their ability to problem solve was about the same. I think that might have to do with this complexity, but also: software has so many ways of doing something, even within the same language -- and that gets permuted across, say, five different lan…

I feel this needs better context, because besides not being able to prove a negative, debugging is so much beyond only the essential ability to "problem solve". And as an anecdote, I've certainly gotten significantly better at debugging with my experience among many aspects. For instance the ability to recognize a somewhat common bug based on it's symptoms is something that at least within a certain context, improves with experience and is at least to some degree "getting better at debugging"

Re: On Coding, Ego and Attention

#144

Post by artsyca » Wed, Jun 17, 2020, 3:42 AM UTC

camgunz wrote: post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

I'd venture it's not so much the technique behind the individual layers but the understanding of the need for all the layers and their interactions and the best practices in given situations.

We're prone to tediously repeat the same conversations over and over and take the cosmetic approach rather than the fundamentals-first way of doing things.

Re: On Coding, Ego and Attention

#145

Post by jugg1es » Wed, Jun 17, 2020, 3:42 AM UTC

This is an interesting article because it made me consider how I think personally as a highly productive programmer but also a leader at my company. Even if I didn't touch the code, I am personally responsible for it considering that I am the lead and have - or should have -reviewed it before it went out. If you go into the assumption that you are accountable no matter what, it isn't really a big deal. If a subordinate f'd up, then you are still accountable because you should have caught it.

Thinking this way is very liberating because it means everything is your fault, but.. you are human and humans make mistakes.. so that means that this is a learning experience. If your mindset is that we are constantly learning, no mistake can ever really touch your ego.

Re: On Coding, Ego and Attention

#146

Post by scruple » Wed, Jun 17, 2020, 3:59 AM UTC

DavidVoid wrote: post #116

camgunz wrote: post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

> They say the way to get ahead at Google is to build a new successful product. Is that the same thing we're doing? It's easier to get ahead by building a new Z framework than to become a core committer on X framework from 10 years ago? A Kurt Vonnegut quote comes to mind: "Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance."

Yes, but... Job security in this industry boils down to little more than evolve or die.

Re: On Coding, Ego and Attention

#147

Post by themacguffinman » Wed, Jun 17, 2020, 4:38 AM UTC

brainless wrote: post #139

themacguffinman wrote: post #112

Earlier quoted context omitted.

CRUD and data serialization is an incredibly broad and diverse field. It's like saying "we've been moving our hands and feet for centuries, how can we not just say: this is how we move our hands and feet?" Software has so many more possibilities to explore than carpentry which is constrained by our current physical technology. It's far better to encourage engineers to explore these diverse possibilities than to encou…

This is my way of thinking: 99.99999% of applications out there still will store their CRUD into a standard relational DB and run on standard operating system with standard protocols. Sure you can create a lot of fuss all around it, but I feel we create a lot of fuss because of ego, because we want to be perceived that we came up with new ways. The reason to not conform is ego. Software is perhaps the cheapest ego bo…

Good. The only people who come up with new ways are the people who have the ego to try, and the world is richer for it. I'm glad the world is filled with engineers who try and fail and learn instead of those who would rather not create a fuss.

Re: On Coding, Ego and Attention

#148

Post by saghm » Wed, Jun 17, 2020, 4:42 AM UTC

camgunz wrote: post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

Humans have been constructing houses and doing maintenance on them for a few thousand years, but we've only been writing software for a few decades. We certainly didn't reach out current process for framing houses in the first few decades of carpentry.

That being said, I assume that the first few decades of carpentry didn't undergo as many changes as software has in its first few decades. My theory is that software changes so quickly because it can be bootstrapped. When framing a house, you can learn from the process so that you can make the next frame better by changing the process, but the output of that process (the house frame) doesn't directly affect the next time you attempt it. On the other hand, you can write software that invents an entirely new process for editing software (e.g. a compiler or interpreter), which then you can use to write software that might not have been possible before. You can then repeat this process with the new software, creating yet another paradigm for writing software, and so on. More generally, when a process produces a tool that can then be used for to do the process in a new way, the process will be able to evolve much more quickly than if updating the process can only be updated with the output from other processes.

Re: On Coding, Ego and Attention

#149

Post by travisjungroth » Wed, Jun 17, 2020, 4:49 AM UTC

nonbirithm wrote: post #137

williamdclt wrote: post #89

Earlier quoted context omitted.

> If I code up a 10k LOC main.cpp with stringly typed data structures, I'm not really better at programming, am I? I think you are , you are better having done that than before. It might not have been the best improvement you could have gotten out of it, but still. The relevant XKCD is this one: https://xkcd.com/1414/

An unresolved mental dilemma is a part of a lot of my worry and inaction. Basically it goes: If you just keep working, will you always keep making progress towards where you want to be? I don't necessarily mean "if you just put in the effort then you'll succeed," which I do not believe in. People talk about "practice with purpose." You have to know the parts that you need to improve on and correct them if your actual…

1. For each activity that you want to improve in know exactly why you want to improve. If it’s because you hope it’ll be fun later but it’s not fun now you should probably stop. There will be a time it’s less fun than it was in the beginning and you’ll give up then anyway. If it’s to get to do something different on the other side, stop expecting enjoyment and just pay the price.

2. Bias towards action. If you want to start running, just go run. Don’t read about it. Don’t sign up for a race. Don’t buy better shoes. Just go run for a while (or write some code or say all the Spanish words you already know out loud).

3. Spend 10-20% of your training time (do not go outside of this range) on improving your training. This is when you watch that video about your activity. People naturally gravitate towards 0 or 100% of time in planning. “A little bit” is the best but rarely done.

4. Check in with someone better than you on a regular schedule to make sure your training is progressing well. Weekly is very good. This could be a coach, mentor, partner, something like that (not an accountability buddy).

Re: On Coding, Ego and Attention

#150

Post by l0b0 » Wed, Jun 17, 2020, 5:05 AM UTC

colordrops wrote: post #107

camgunz wrote: post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

The differences between carpentry and software engineering is that the problem space in carpentry is much smaller and pretty much static over time. It's rare for carpentry tools to get an order of magnitude more powerful over the course of a decade, and for 100 people to work on the same carpentry project.

Basically, this and other comments show that the analogy completely breaks down. The scales, changes in scales, and degrees of freedom are just utterly different from anything physical humans build.