Hacker News Reader

Comment by incepted | Hacker News Reader

Sounds like the author is sharing a personal story here. I'm guessing he wrote some FP code and one his coworkers complained about it.

OP, two pieces of advice:

- Ask yourself why your coworker went to your boss instead of talking to you directly

- Work on your communication skills with your coworkers. I'm guessing you have an attitude that's rubbing them the wrong way (I've seen a lot of this coming from people who are trying to impose advanced techniques upon a team that's not ready for those).

It's startling how so many bright programmers possess so little social awareness.

View on HN

It's amazing how you can tell so much about a person just by reading one short article. To me, your advice comes across as condescending. Maybe you need to work on your communication skills too?

Regardless, what's the practical solution to managing complexity in a team "that's not ready"? At some point, most projects get complex enough that you're going to have to do _something_ that someone is going to find confusing. It could be functional, OO, whatever.

If you've got complexity to manage and can't use reasonable tools to manage it, you may have bigger problems. Pandering to the hypothetical lowest common denominator developer isn't going to help much, because they're probably not going to "get it" anyway and will likely make a mess in any case.

> To me, your advice comes across as condescending. Maybe you need to work on your communication skills too?

And now we've come full circle

Brian McKenna is a public figure who people could easily have encountered in other ways.

In my experience many functional programmers, myself included, do generalize where they don't need to (e.g. writing a function to accept any F[_]: Foldable when it's only ever called with List). At which point asking them to justify the abstraction is entirely justified. Conversely in cases where fancy functional techniques really are improving maintainability it's usually pretty easy to demonstrate this by comparing two implementations side by side.

An advantage of using the most general signature possible is it restricts the things you can actually do with the values involved, which can make it easier to provide correct implementations.

Exactly. More generally, this is what code reviews are for. On top of the personal issues that might be occurring there, it looks like that team doesn't do code reviews.

Code reviews are not just to make sure the code that goes in is sound, they also help getting multiple team members familiar with the entire code base.

> It's amazing how you can tell so much about a person just by reading one short article.

I take it you never heard of Brian McKenna before?

Reply on news.ycombinator.com