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

331–340 of 361 posts

Re: Why senior developers fail to communicate their expertise

#331

Post by j_w »

t43562 wrote: post #323
j_w wrote: post #308

Earlier quoted context omitted.

This is why the first thing you should do as a dev when somebody tells you that they want Y feature is to ask why. Non-developers have no clue WHAT they want, then know WHY they want it. The why is much more important to know, because the requestor has no clue how software works and imagines bad solutions.

In some cases it's just because they think that any "missing thing" might be the one that causes customers to reject the offering. So they "must" have everything. It's the lack of knowledge that's the problem and they don't feel that they're going to get more than one chance/feedback cycle to learn from. The product managers proposing things have their reputation tied up in them so a major feature is a chance at fame…

> might be the one that causes customers to reject the offering

This is a valid why for a feature though. Clients want it.

Now, the concern here is do the clients want it, or does sales/product THINK the client wants it?

Re: Why senior developers fail to communicate their expertise

#332

Post by Izkata »

> Imagine you get asked to build something ambitious, and you say:

> “Sure, I’ll have the Speed version ready in 3 days. Then the Scale version in about 6 weeks.”

> They get what they want, speed and momentum. You get what you want, observation and design.

Except that 6 weeks is now blocking the next thing and you'll be pushed to drop it. So this doesn't really solve anything.

I was kind of hoping at the end they'd suggest getting the non-developers involved more so they can experience the pain points they're creating. Not entirely sure how that would work though.

Re: Why senior developers fail to communicate their expertise

#334

Post by throwaway74628 »

dirtbag__dad wrote: post #191

> I don’t like senior developers who like trying new technology. I like ones that avoid more complexity. I guess the author has never worked on a dog shit system with no tests at all and constant downtime. I have worked with “complexity averse” engineers who would rather fix the edges over and over again, than roll up their sleeves and just get the job done. I just don’t believe that using new tools is at odds with a…

Any can can be kicked down the road in the name of pragmatism, sure, but IME the kind of tech debt you’re describing often comes about from lack of fear and respect for complexity and the damage it can do. Before you can reduce complexity, you must first manage it by breaking the problem into smaller parts through categories, boundaries, and contracts; so many software engineering best practices concern this aspect.

That is to say, the rolling up of sleeves usually involves first adding tests for existing behavior and then doing more-or-less what’s described. The tools involved are aside to this; “catch as catch can”

Re: Why senior developers fail to communicate their expertise

#335

Post by jake-coworker »

I don't love the title - the article is about differing perspectives/incentives in a company, not about senior developers' inability to communicate

That said, I think everyone will agree both extremes are failure modes - moving too fast and not having things work right, or building things too correctly and never building something people want.

IMO the two stereotypes in the article generally hold true, and the job of each in a healthy company is to present the trade-offs, and collect enough data to experimentally validate. And when you disagree, let the decision maker (CEO) decide, but disagree and commit

Re: Why senior developers fail to communicate their expertise

#336

Post by jake-coworker »

floro wrote: post #276
nullorempty wrote: post #51

What I found is that my willingness to communicate and share my expertise is usually not in demand with more junior developers. In general, I find developers uninterested in finding a mentor. They don't look at your linked in profile, they don't look at you as a possible source of knowledge and expertise. So it's not like I have nothing to share after 30 years of experience in the industry, I just have nobody to shar…

As a junior I will share my perspective from the other side. Companies have outlandish hiring practices. They want juniors who already know everything. That's why admitting that you don't know something is seen as showing weakness to the company in the eyes of a junior. Also, not knowing things will actively keep you from getting promoted. I'm sure it's not like that everywhere but it's juniors playing the corpo game…

One of my favorite senior developer stances is "I should be annoyed by how many questions you're asking me"

Re: Why senior developers fail to communicate their expertise

#337

Post by vogelke »

Johanx64 wrote: post #118
dyauspitr wrote: post #93

Earlier quoted context omitted.

I don’t think it’s the arrogance of youth. It’s just that this generation and honestly a big cohort of millennials are not used to gleaning information from people. A stunning number of people have been raised/educated solely by the internet. That’s the source for knowledge, not other people.

> A stunning number of people have been raised/educated solely by the internet. That’s the source for knowledge, not other people. On the internet you can learn from and sometimes interact with the best of the best, so the barrier of entry for what constitutes an "expert" is rised much higher.

I hope you're kidding. I've seen lots of 'Net people claim to be experts, and I wouldn't trust most of them to feed my cat.

Re: Why senior developers fail to communicate their expertise

#338

Post by zahlman »

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…

I'm struggling to even understand what you have in mind, because HN doesn't do Markdown formatting and asterisks are interpreted for emphasis across lines. But I've never really thought there was a problem with the syntax. To me it reads naturally, left to right: "A list ([) of the results from calculating whatever, (for) each of the (name) values that are (in) the (names) container". With multiple clauses, they're in the same order as the corresponding imperative code, which also makes sense. (Perhaps if "for" were spelled "where", it might not...)

Re: Why senior developers fail to communicate their expertise

#339

Post by zahlman »

lnenad wrote: post #4

As a /senior/ developer I really dislike blanket statements. I've seen the same amount of failures caused by > “Do we really need that?” > “What happens if we don’t do this?” > “Can we make do for now? Maybe come back to this later when it becomes more important?” as with experimenters. Every system is different, every product is different. If I were building firmware for a CT scanner, my approach towards trying out…

> I really dislike blanket statements.

... All of them?

Re: Why senior developers fail to communicate their expertise

#340

Post by imperfect_blue »

eithed wrote: post #301
Jensson wrote: post #285

Earlier quoted context omitted.

If that is what a PM needs then there aren't enough good PM to warrant a PM role for most products, so just make software engineers do that in most cases. Edit: The main role of PM is to decide which features to build, not how those features should be built or how they should work. Someone has to decide what to build, that is the PM, but most PM are not very good at figuring out the best way for those features to wor…

> not [...] how they should work So that we're on the same page, what I think should be PM responsibilities: If I have a user story: "As a customer I want to purchase a product so that I can receive it at my address" - PM defines this user story as they have insight to decide if such feature is needed. PM should then define acceptance criteria: "Given customer is logged in When they view Product page Then 'Add produc…

The problem, in my experience, is that most PMs don't add anything when it comes to drawing up the acceptance criteria.

In your example of an order placement - the PM has no special knowledge of what is a good customer order flow. Developers are usually way better at coming up with those by the dint of experience and technical knowledge of the current codebase and make the appropriate speed/polish trade-off.

PMs acts as an imperfect proxy for what the customer wants, making judgements off nothing more than their own taste. And though there are many great PMs, the taste of a PM is usually worse than that of developers and designers on average.

IMO the main business reason they exist is for organization accountability and ownership, despite the often negative value they bring.

Post reply on HN