Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why senior developers fail to communicate their expertise

nair.sh

Post reply on HN
Print view View original

341–350 of 361 posts

Re: Why senior developers fail to communicate their expertise

#341

Post by 9rx »

jeltz wrote: post #298
dragochat wrote: post #287

Earlier quoted context omitted.

your "physics" grounding is exactly why it feels so odd - software is by its nature anti-physicalist math and logic are closer to a basis for software abstraction - but they were scary to business people so a "fake language" was invented atop them - you have "objects" that don't actually exist as objects, they are just "type based dispatch/selection mechanism for functions", "classes" that are firstly "producers of t…

I feel that is a bit of a false history. OOP was invented by people trying to simulate physical systems, e.g. Stroustup, the Simula people and their contemporaries not business people. Arguably it was popularized later by business people and enterprise Java developers. But that happened way later. I do not think OOP ever really worked out well as can be evidenced by it no longer being as popular and people having alm…

This is also a bit of a false history. OOP was squarely invented with Smalltalk. The term was literally conceived for Smalltalk to describe its unique (at the time) programming model. While objects most certainly predate Smalltalk, it was Smalltalk that first started exploring how objects could be oriented.

OOP didn't really take off either, but mostly because it is hard to optimize and impossible to type.

Re: Why senior developers fail to communicate their expertise

#342

Post by hathawsh »

tsunamifury wrote: post #232
hathawsh wrote: post #165

Earlier quoted context omitted.

Isn't that interesting? The job of exploring a theory or model to such an extent that it can be expressed in computer code always seems to fall on the shoulders of a software developer. Other people can write specifications and requirements all day long, but until a software developer has tackled the problem, the theory probably hasn't been explored well enough yet to express clearly in computer code. It feels like s…

Sorry this is just the interior trapped nonsense that engineers find themselves in. Please touch grass Product designers have to intuit the entire world model of the customer. Product managers have to intuit the business model that bridges both. And on and on. Why do engineers constantly have these laughably mind blowing moments where they think they are the center of the universe.

I actually agree with this. Product designers and product managers are often essential and sometimes they do up to 99% of the work of figuring out how something should work. To accomplish that, they often do things well outside the role of a software developer. On the other hand, in my experience, only someone with a software development mindset seems to be able to complete the last 1% (or 10%, or whatever) that reveals and resolves certain kinds of logic issues.

Re: Why senior developers fail to communicate their expertise

#343

Post by judahmeek »

asdfman123 wrote: post #86
gib444 wrote: post #62

Earlier quoted context omitted.

Exactly my experience. You describe it more diplomatically than I do hah. To me, young people just don't seem to know, or want to know, that information and knowledge can be gained from a person. It's the arrogance of youth x100 They have a supercomputer in their pocket/on their desk, and an AI that knows 'everything'. I can't imagine what it's like being a teacher right now. How's your AI going to explain the office…

I like to play an online strategy game, openfront.io. The way to win is to take out someone who is gaining power before they get too powerful. It's just basic game theory, and you see it everywhere. However, it's so annoying in the workplace when your two options seem to come down to try to dominate or be dominated. Especially if you care about quality code and don't care for meetings. As far as I'm concerned, I thin…

I think it's odd that your company has a fairly decent promotion metric (those who seek to spread knowledge through docs & meetings get promoted) and you seem to want nothing to do with it while also complaining that your coworkers don't respect your opinion.

I kind of get it as you have expressed that promotion is not your goal. However, organizational influence comes through promotion as your org & only those with influence at your org can change that.

What do you think would be a better system, that decoupled promotions from influence & enabled you to provide your experienced opinion without getting into management?

Re: Why senior developers fail to communicate their expertise

#344

Post by genghisjahn »

dasil003 wrote: post #325
hibikir wrote: post #209

Earlier quoted context omitted.

A non-trivial part of the big difference between the juniors that seem talented and "get it", and those that don't is precisely their ability to form accurate enough world models quickly. You can tell who is going at the "physics" of software and applying them, and who is just writing down recipes, and doesn't try to understand the nature of any of the steps. It's especially noticeable when teaching functional progra…

I vividly remember the moment this clicked for me. I had spent the better part of a decade being interested in programming and essentially learning recipes. It wasn't until I was a couple years into a CS degree and starting to work professionally as a web developer, that I finally had an epiphany of what software actually was, and the degrees of freedom that it actually has. It's very hard to put into words because i…

I've had conversations with people who wanted to learn how to code. I found that teaching someone how to code is tedious experience. It's just a bunch of memorization and bafflement at how quickly someone else can do things at the keyboard. I've since come to realize that wanting to learn to code is NOT a good starting place. It's best to have a vision. What's the problem you are wanting to solve? If writing software is a way to solve that problem...well NOW we have something to learn around. We have a vision. We have a goal. And learning the syntax and cs concepts is no longer an end of itself, it's just an obstacle to get through to accomplish the vision. You bring enough of these visions to completion, you'll find you've cleared a LOT of obstacles and wow, you've gained a lot of software knowledge.

Re: Why senior developers fail to communicate their expertise

#346

Post by necovek »

ruszki wrote: post #322
necovek wrote: post #286

Earlier quoted context omitted.

I am curious about that nit on list comprehensions in Python: what do you mean, why are they a "mistake" of language design?

So when they designed it, it wasn’t that bad for simple cases. However, with more complex nested lists, there isn’t a clear data flow, it jumps from one place to another. Especially the first term is problematic. It’s not beneficial at all for the modern IDE based development. So at the end, this is a better list comprehension in this sense: `[state_dict.values() for mat to mat 2 for row for p to p/2]` Or similar, wh…

You seem to be complaining more about for working on iterators/generators like range() and not on comprehensions themselves.

List comprehensions are inverted (syntax-wise) compared to regular program flow, but that is pretty easy to learn and adapt to (and is, imo, much better than "a = b if x else c").

Re: Why senior developers fail to communicate their expertise

#347

Post by ruszki »

necovek wrote: post #346
ruszki wrote: post #322

Earlier quoted context omitted.

So when they designed it, it wasn’t that bad for simple cases. However, with more complex nested lists, there isn’t a clear data flow, it jumps from one place to another. Especially the first term is problematic. It’s not beneficial at all for the modern IDE based development. So at the end, this is a better list comprehension in this sense: `[state_dict.values() for mat to mat 2 for row for p to p/2]` Or similar, wh…

You seem to be complaining more about for working on iterators/generators like range() and not on comprehensions themselves. List comprehensions are inverted (syntax-wise) compared to regular program flow, but that is pretty easy to learn and adapt to (and is, imo, much better than "a = b if x else c").

With my solution, you don't need to adapt... that's the whole point. There is no inversion.

Re: Why senior developers fail to communicate their expertise

#348

Post by necovek »

ruszki wrote: post #347
necovek wrote: post #346

Earlier quoted context omitted.

You seem to be complaining more about for working on iterators/generators like range() and not on comprehensions themselves. List comprehensions are inverted (syntax-wise) compared to regular program flow, but that is pretty easy to learn and adapt to (and is, imo, much better than "a = b if x else c").

With my solution, you don't need to adapt... that's the whole point. There is no inversion.

It is focused on communication flow for small data-only loops: it is much easier to reason about

  items = [ this for iterator ]
because you immediatelly see what type of data ends up in `items`. Syntax inversion overhead is very much paid for with this benefit IMO.

Again the bigger problem is the 'if', including in comprehensions.

Re: Why senior developers fail to communicate their expertise

#349

Post by ruszki »

necovek wrote: post #348
ruszki wrote: post #347

Earlier quoted context omitted.

With my solution, you don't need to adapt... that's the whole point. There is no inversion.

It is focused on communication flow for small data-only loops: it is much easier to reason about items = [ this for iterator ] because you immediatelly see what type of data ends up in `items`. Syntax inversion overhead is very much paid for with this benefit IMO. Again the bigger problem is the 'if', including in comprehensions.

> you immediatelly see

But that's simply not true at all.

Let's start with token by token:

  items
You have no clue what type of data ends up in `items`, or that something should end up in `items` at all. This is obvious.

  items =
You have no clue what type of data ends up in `items`. You just know now, that something will end up there.

  items = [
You only know that a list will be in `items`. Not what will be in the list.

  items = [ this
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`.

  items = [ this for
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`.

  items = [ this for iterator
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`. You cannot have, or you break the right to left propagation with nested cases, against what you have with this simple example of yours.

  items = [ this for iterator ]
This is the only time when you know what type is `items` or `this`.

Also `this` is a useless identifier, if you cannot transform or filter in your list comprehension. I don't like mine either that it contains pointless words...

Don't get me wrong, your example is clearly a right to left data flow. Which is not inherently bad, because `items` and `this` are new identifiers, which won't figure out by IDEs, so it doesn't matter.

Also, in my example of Python code (not my version of it, but the valid Python code), there is no need to have `if` at all to break intellisense, or break either left to right or right to left data flow several times inside the list comprehension.

Re: Why senior developers fail to communicate their expertise

#350

Post by asdfman123 »

judahmeek wrote: post #343
asdfman123 wrote: post #86

Earlier quoted context omitted.

I like to play an online strategy game, openfront.io. The way to win is to take out someone who is gaining power before they get too powerful. It's just basic game theory, and you see it everywhere. However, it's so annoying in the workplace when your two options seem to come down to try to dominate or be dominated. Especially if you care about quality code and don't care for meetings. As far as I'm concerned, I thin…

I think it's odd that your company has a fairly decent promotion metric (those who seek to spread knowledge through docs & meetings get promoted) and you seem to want nothing to do with it while also complaining that your coworkers don't respect your opinion. I kind of get it as you have expressed that promotion is not your goal. However, organizational influence comes through promotion as your org & only those with…

I actually know you're right, and am just being indulgent right now.

I just hate it because I find meetings draining.

Post reply on HN