Live data from Hacker News

On Coding, Ego and Attention

josebrowne.com

131–140 of 177 posts

Re: On Coding, Ego and Attention

#131
post #84
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…

> 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? Sometimes, yes. This particular angle is explained in the article >> This is ego distraction in action. Self comparison determining effort. If we feel like we’re ahead we continue to put in the effort. If we feel like we’re not, we determine it’s not worth the effort. The reason people would pref…

Did you mean Apache Parquet? If not, what is Parque?

Re: On Coding, Ego and Attention

#132

Big tired after an intense day, and I haven't really sat down and digested the article, but it seems close enough that I think my - admittedly primitive - tip can be of relevance. If you get stuck, you tell yourself in whatever way you want, and honestly, some version of the following: "I don't understand this thing that is happening, but I know there is a cause. It does not happen without cause." Honestly, it's a bi…

Love this! I know exactly what you mean. Thanks for sharing!

Re: On Coding, Ego and Attention

#133

I read this, and I have also read "The Practicing Mind" which is exactly what this post is about. My issue isn't in understanding the premise. It all makes sense, and I get a sense of "ah hah!" every time I read it (I've read it twice). The issue for me is that I really struggle to turn this theory in to effective practice. Each time after reading "The Practicing Mind" I have tried to cognitively remind myself whenev…

Thanks for sharing this perspective! I know exactly what you're talking about. I wrote this piece and have to admit that even for me I have days when I struggle to bring this attitude to a problem or a day. I guess it's one of those hard habits to break.

What helps for me the most is intentionality. To literally set my intention for a day or for a problem right before I jump in. So if I know I'm about to jump into a tricky problem I literally take a few seconds to remind myself of the attitude I want to bring and even exactly what I want to focus on.

So this would be things like "Don't try to judge difficulty (easy/hard), just go wherever it takes me" or "Don't be afraid of the amount of work". One that super helpful for me is deliberately separating to "understanding" part of a problem from the "solving" - so i'd tell myself "I'm just trying to understand what's going on right now - solve later". Etc etc.

Hope this helps.

Re: On Coding, Ego and Attention

#134

The part about problems being either fun challenges or a nightmare really resonated with me. That's why pair programming is so important in my opinion, if you work too long in a silo the magic, fun, craft whatever of programming fades away. Just watching a coworker code or talking through problems with one can bring back that spirit of fun challenges though. Engineer morale is super important.

100% Agree.

Re: On Coding, Ego and Attention

#135

Earlier quoted context omitted.

> I disagree with this [at least for me personally]. Being a good programmer is just straight up not something that's part of my identity. There's millions of people who are much, much better at it then me, and that's totally fine. Then why did you call yourself "good", why not just a programmer? ;-)

I didn't. I said that being a "good programmer" isn't part of my identity...

Oh yeah, you're right. Hah! Sorry. It is part of my identity, which is problematic, but that's my sh*t I've been working on (for years...)

Re: On Coding, Ego and Attention

#136

Earlier quoted context omitted.

"The thing about working on yourself is that it’s actually work. Reading an article, or a book on behaviour, self-improvement and what else doesn’t actually change you any more than reading Harry Potter does." This is well put, and I think part of the reason so much self-improvement material is drivel. Generally, I've noticed that some of the most pathological people are the most into 'self-improvement' as an idea. T…

> I've noticed that some of the most pathological people are the most into 'self-improvement' as an idea. I've noticed that some of the people who spend the most time paying attention to their blood sugar are diabetic.

My point is more that they are checking their blood sugar levels without doing anything about it.

Re: On Coding, Ego and Attention

#137

Earlier quoted context omitted.

No. Programming -with intent- is the best way to get better. If I code up a 10k LOC main.cpp with stringly typed data structures, I'm not really better at programming, am I? It's like that saying: practice doesn't make perfect, perfect practice makes perfect. Programming is not literally just typing, as we all know, nor is it simply getting a Thing to compile. A lot of it is educating oneself on different types of da…

> 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 intention is to get better at something. I believe that works better than taking any arbitrary action at all, with the same goal in mind.

So it's not knowing if writing that 10K LoC program actually does help or not. I forget things I've done. I lose interest.

Then I extrapolate from this and think, then there must be some spectrum of things in between that are not practically useful, and if I keep doing them then I will not improve in the ways that I want. I will believe that maybe writing a stringly typed C++ application is just reinforcing bad habits that I will have to expend extra effort to undo later. I then believe if that's the case then I ought to not do that thing at all if I believe it's just going to hinder my progress.

The problem is that this mindset costs me a lot of my action, because I figure if what I'm doing is not beneficial for my skills then I'd better get something else. A lot of the time that "something else" is something less challenging, all the way to nothing productive at all. So I end up believing I'm just coddling myself in an attempt to avoid "wasting time" not really improving.

I think this kind of fallacy stems from a fear of banging my head into a wall expecting to get better at some point without knowing if I'm actually on the right track. At least if someone knowledgeable teaches you they could suggest so. And that fear stems from placing too much value on intellectual success as opposed to enjoying the process. If you only enjoy something on the condition you improve, then it discourages you. I've been discouraged a lot.

It could also be due to divorcing enjoyment of something from improving at it. I simply always care about improving, and if I don't see improvement then I'll lose interest. But some say that people who enjoy things just improve on the basis of doing it at all. I just can't seem to get myself to believe it, though.

Re: On Coding, Ego and Attention

#138
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…

> Is there something specific about software that means tenured projects become less and less useful/maintainable/understandable over time? Complexity. Understanding a legacy codebase is pretty much a small-scale research project. You need to gain domain knowledge, become familiar with the team, get acquainted with the codebase and its history , before you'll be able to reliably tell bad code from clever solutions to…

I disagree that the cause of the problem is complexity stemming from size, and propose that the real issue is the industry's poor history of efficient documentation. Processes to efficiently create and read documents that describe large systems are rarely in place at most of the places I've seen. That's probably the biggest barrier to contributing code to old framework Y. It's just easier to develop framework Z. I agree with you that some things can be designed to reduce complexity, but ironically whenever something like this happens, someone from an older product will glean ideas of the new one and port some of those concepts over (potentially further proving that the big problem is the lack of resources for understanding)

Re: On Coding, Ego and Attention

#139
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…

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 boosting tool ever created.

Re: On Coding, Ego and Attention

#140
post #84
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…

> 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? Sometimes, yes. This particular angle is explained in the article >> This is ego distraction in action. Self comparison determining effort. If we feel like we’re ahead we continue to put in the effort. If we feel like we’re not, we determine it’s not worth the effort. The reason people would pref…

> Python is clearly more productive that Perl

Oh please troll. Python is a few years newer than Perl and only has the patina of "modernity" (whatever the hell that is) by virtue of being last to sit at the mainstream table.

> Go is clearly more productive than many things that came before.

Where the fuck are you getting this bullshit from, Sir? What drugs are you on today? Citations???

Post reply on HN