Hacker News Reader

Comment by js8 | Hacker News Reader

> If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!"

I wonder why these "agile practices" shun the expertise so much. Instead of Y working on a similar problem as X in another month, why not make X an expert in the thing so that everybody knows about him being an expert and consults with him on a regular basis.

Is it really better to have everybody a shallow experience with everything rather than have a few individuals with a deep expertise with a particular thing?

And to have a meeting every day to "solve" this non-problem (somebody not knowing who the expert is, or supposed to be) seems really inefficient.

View on HN

That's "Siloing" which is considered a negative pattern. If X is the expert, then only X can work on that something*. X is now a bottle neck.

Natural siloing happens, but you (team) should be striving to reduce it, not encourage it.

*More accurately: work can only proceed on that something when X is available*

My point is, it doesn't have to be black and white. If your expert is less available, or has too much of the same work, or you just want a backup, you just start training someone else to be an expert in that area too. It's not costlier than what you propose, it seems that it is always better to start with having a designated expert rather than to dilute the expertise so much than no one really is.

It does not work, at least did not worked for us. The problem is that in any single situation it is easier for expert to solve it alone then explain and when then there is sudden need to explain, expert can't do it effectively. Because he was not explaining for years.

Plus, you end up being in a limited box and have harder time to grow by learning new things - project structure keeps you in box and you can't easily expand it by taking tasks to learn something new.

Finally, expert is sort of fake expert - expert only because others are kept clueless. Not because he would had such great knowledge objectively, but because we decided this is only his area. There is no other engineer to discuss issues with our to compete with.

Nobody has said it should be except for you. As I said it will occur but you should strive to spread information and learning as much as is reasonable.

Reason why I don’t want my team to overspecialize:

I don’t want them to isolate and develop tunnel-vision. I want everyone to be aware of the project goals and understand the work that needs to be done to deliver value.

My experience with teams where people are divided by topics for a long time is that unpleasant work that does not fit into a single topic well gets neglected.

> My experience with teams where people are divided by topics for a long time is that unpleasant work that does not fit into a single topic well gets neglected.

I doubt it isn't the case either way. If you neglect understanding and development of expertise, you will still end up with some people having more expertise than others, and possible blind spots. Except now you have no idea what those blind spots are. (https://news.ycombinator.com/item?id=10970937)

I think "agile practices" without pair programming misses 70% of the benefit.

If you're pairing, no one person becomes the only expert on something, and also no one person is left alone to solve all problems in an area.

Reply on news.ycombinator.com