Live data from Hacker News

On Coding, Ego and Attention

josebrowne.com

81–90 of 177 posts

Re: On Coding, Ego and Attention

#81

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…

The way I first heard it was "There's no magic in the world."

Every effect has a cause, and when debugging your job is to know your codebase well enough to be able to quickly pinpoint that cause.

Re: On Coding, Ego and Attention

#82
post #62

Earlier quoted context omitted.

I'm not sure I agree, because the situation is in my opinion not symmetrical. Work without reading about it: might work, and often does. Reading about it without doing the work: way less useful.

Spend a week in the lab to save a day in the library?

I should have been clearer: I was talking about motivational or self-improvement sort of books and articles, as is the topic of TFA.

I wouldn't try it with lab work, though pioneering work sometimes was that way ;)

Re: On Coding, Ego and Attention

#83
There is a perspective shift that comes (usually but not always) with age I think.

When I was younger I got into computer programming, for the first ten years (1987-1997) I thought I was hot shit because I could do things with computers that no-one else I knew could even understand (with the exception of a family friend who was a programmer in aerospace) then I ran into other programmers on-line and realised that there where other much better programmers in the domains I was interested in (strangely I never got into programming games, I always liked utilities and 'productive' stuff).

So I doubled down and resolved to be the best programmer I 'knew' again except this time I knew hundreds or over the years thousands of programmers an impossible treadmill.

Sometime in my late 20's/early 30's (so ~2007-2008) I realised that not only wasn't I ever going to be the best programmer I knew, I really didn't know much about programming in the general sense if you look at the whole field (no-one does really except the odd person) so I re-framed it, I was going to be a better programmer than the me of a year before and focus on the other skills I'd let languish over the years what I'd often derided as 'soft' skills (I don't think I was ever an arse-hole but I was the guy who'd sit in the corner muttering with the headphones blasting thrash metal).

In the end what I realised was that after all this, I like programming, I like providing value and when it comes to work the best thing I can get is feedback from a user whose life I've improved by making whatever I've touched that little bit better.

If I can do that then it was a good day.

The freedom from all this is I learnt to play again, if I'm interested in functional programming I'll go poke at that for a bit, if I'm interested in algorithms I'll go poke around over there - free from the the self-imposed need to compete I get to satisfy my own curiosity and nurture the devs on the team I run.

With 7 billion people on the planet it's statistically unlikely you are ever going to be the best and even if you are it's likely in only one dimension.

I noticed that the programmers I normally really admire are all older than me and seem to be excited/happy about technology and wondered how they kept that enthusiasm for so long in an industry where so many seem miserable and I think I can hazard a guess now.

Oh and because the universe loves a punchline, I have a dev on my team now who is determined to prove himself the best programmer, never says a word and listens to thrash metal all day while muttering, he's talented so I'm curious to see how he figures it out.

Re: On Coding, Ego and Attention

#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 prefer working on a newer project/framework/whatever is that there is a higher chance they might be able to contribute meaningful code / support. I am admitting to that, and I am sure many have similar thoughts. It is purely guided on where one thinks success is achievable.

Also keep in mind - progress is being made. Python is clearly more productive that Perl. Or Django vs CGI/FastCGI. So 15 years ago, if that were my two choices for two projects, I would have taken the path of Python. Not just because it was new & shiny then.

Fast forward a decade, Go is clearly more productive than many things that came before. Kafka is clearly easier to manage than home-grown queues via databases and flat files. So why should I stick to old process?

The problem I feel is lack of arriving at any standards for anything basic. We have 10 message queues, but limited interoperability. We have 50 popular databases, but no easy migration. We don't even have universal support for Parque in all languages even though it has been around for a while. When can I grep a parque file? Something as simple as Azure blobstore and Amazon S3 can be linked together without arcane and inefficient copying.

Re: On Coding, Ego and Attention

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

If someone wants a website that lists their company hours and has a contact form, that’s pretty much a known amount of hours for an experienced web dev. That’s about the equivalent of asking a carpenter to put in a door.

If someone wants a custom built order and inventory management system, that’s like asking a carpenter to build a custom 4 story house from some napkin sketches.

The whole reason computers are valuable is because they automate away all of the rote, repeated, predictable stuff. The unpredictable part of SWE is not comparable to carpentry, it’s more easily compared to architecture/engineering where the problem statements are vague and most of the job is getting agreements on what the thing will actually be. The carpentry part of programming is mostly predictable.

Re: On Coding, Ego and Attention

#86

Earlier quoted context omitted.

> It's same with mastering any skill. Learning to play guitar, becoming an Olympic athlete, whatever. You can't Zen Buddhism your way out of the fact that you're going to spending years and years practicing until your fingers bleed, or until you're completely exhausted, etc. The point of the article isn't that there is a shortcut around having to put in the time, it is that ego sabotages your efforts to put in the ti…

>it is that ego sabotages your efforts to put in the time Sure, but what I'm saying that that statement is almost meaningless in the grand scheme of things. Is not letting your ego get in the way a necessary part of getting to mastery? Absolutely. But no matter how much you change your thought process, or analyze the problem, you still need to eat the proverbial whale. Think of all the people who've ever played baske…

> After all, part of Zen Budhism is accepting who you are and your limitations.

The teaching is that all beings are capable of enlightenment and outlines a path to accomplish that. The concept of "you" is part of the problem and meditation on sunyata can offer insight to that.

Re: On Coding, Ego and Attention

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

Technology changes and user expectations change, and we need to adapt. And it's not my area, but this seems to be true in construction as well? The building codes change, and available materials and components change, as do their relative prices. Maybe not as fast, but fast enough to make older books out of date.

Have to disagree with most of this. Technology changes and user expectations change, but there’s a missing link here to show that either of these really necessitates Yet Another Language/Framework, launching Yet Another Product/Service, or rebuilding things from the ground up. It’s a bit like a homeowner wanting an updated kitchen and a contractor telling them they need a whole new house for it to work, when really the contractor just prefers building flashy new houses for their portfolio over doing renovations on a budget.

Also, side note: with respect to carpentry, books from 50+ years ago on wood working techniques, framing, joinery, etc. are perfectly relevant today. And many of my grandfather’s tools are still in use in my workshop.

Re: On Coding, Ego and Attention

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

From my perspective, the root cause of this problem lies in lack of one common measure for code quality, correctness and usability or even programming in itself.

Say, there are two approaches for a problem - how do we decide which one we go with? In the last 10 years I have not seen a single case where the decision was made based on something other than subjective opinions of a person or a group of people. "Past experience", "this is how it's done here", "this is the only way I can do" and countless other reasons - all of those are subjective and cannot be used for objective comparison of approaches.

You could say, "days to implement" or "money spent" is such metric - but then, there are no reliable ways to mathematically calculate this measure for any code you plan to write and then prove it in advance.

To put it another way - there is no standard unit of code/system correctness, by which we could have measured what we are actually doing or plan to do. Until one emerges, we are bound to continuously reimplement same things over and over again, justifying it by nothing else than our projections, prejudices and boundless ego.

Re: On Coding, Ego and Attention

#89
post #28

Earlier quoted context omitted.

Programming is certainly the best way to get better at programming. Some other things may help improve your ability to program, but there is no substitute for the act itself.

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/

Re: On Coding, Ego and Attention

#90
Wonderful writing. I get the same feeling about the ego thing. What makes me wonder is there are people who would like to write about ego and coding in great detail. I admire. Truly resonates with me.

from what I see others comments in HN. "Points and Counterpoints" Every article or idea doesn't work for everyone as we are a complex cocktail of ideas and impressions. if some idea resonates with you, you have found your type of the idea. so enjoy it else don't resist the idea wait for next one that might work or not. thank you for sharing in any case.

Post reply on HN