Hacker News Reader

Comment by username90 | Hacker News Reader

I'm not sure causality goes that way. You communicate more if you are better at the technical parts. If you can solve most of the problem in your head and in that way predict most of the things you need before you start working you just go and ask for that information from everyone. However if you are worse on the technical side you will need more time working on the task before you have anything to talk about, and you might even miss some of the issues completely.

Forcing the second kind to communicate more wont make him better, it will make him worse. He will need to build up his technical skills before communicating more actually helps.

View on HN

In my current project, we are basically coerced into pairing nearly 100% of the time and it takes active resistance not to pair on every single little thing like "remove this item from the list in the docs". Yep, it's that extreme.

In my personal experience and opinion, pairing makes sense for knowledge distribution and figuring out something hard together. Or onboarding, getting a project newbie up to speed for a couple of weeks.

But when overdone, it simply slows you and binds expensive developer resources that otherwise could be working on a parallel thing. Especially in the remote environment during Corona times. I basically HAVE TO have an always-on Zoom/Teams call with mic and camera.

Half the team seems to really love that mode of working, but I for one am rather puzzled how you are supposed to focus and really think things through this way. Always having to articulate every single little thing and then switching control just throws your flow completely out of the water.

And one other bad side-effect I observed is that reviews are now taken much less seriously. No need to do reviews, since a PAIR already worked on it, right?

Not in my opinion - I think that reviews and subsequent communication are a much better way of knowledge sharing anyway and pairing is often just a management oversight excuse rather than a helpful technique/mechanism. Some devs also seem rather desperate to have others help them do simple tasks. It feels like those people in school who tag onto your project because they know that you and that other girl will do all of the work.

If you're in the team for 3 years I would expect you to be able to read some code and understand what it does. Or read docs of some framework. But nope, some people just NEED others to tell them how it is done and by next week they already forgot it anyways. And when I want to read some docs? Enjoy those eyes and intermittent verbal injections from that Zoom call.

Uff - I am rather frustrated, but as mentioned early in my comment, I do see some real benefits of pairing. Just not 100% of the time all the time with always-on Zoom cams.

Couldn't agree more. I worked 2 years 100% pairing, it's just too much. I also have some mildly introspective personality and the extra overhead of communicating every single word typed not only interferes with my deep thinking, but would make me feel exhausted by 4pm, instead of my normal capacity to work long hours for quite a few days before starting to realise I needed to rest.

> Some devs also seem rather desperate to have others help them do simple tasks. It feels like those people in school who tag onto your project because they know that you and that other girl will do all of the work.

Ahh, the non-programming programmer strikes again! [0]

[0] https://blog.codinghorror.com/the-nonprogramming-programmer/

Still a gem, thanks!

The non-programming programmer thing is kind of astonishing.

Are there actual CS programs somewhere where people can graduate without actually writing any code? Maybe theory, HCI, or hardware tracks? Those could still be great employees.

And don't many candidates have code on github where you can just look at the commit log and ask them about the code they wrote?

Moreover, tech companies seem to be infatuated with awful technical interviews that not only make you write code but often require you to solve some difficult algorithm puzzle at the same time.

> Are there actual CS programs somewhere where people can graduate without actually writing any code? Maybe theory, HCI, or hardware tracks? Those could still be great employees.

There are absolutely. I however, disagree with the idea they could lead to great hires.

I've also seen "masters" in CS that were really a lighter version of the undergrad coursework [0]. Of course, these were separate from the PhD track masters.

> And don't many candidates have code on github where you can just look at the commit log and ask them about the code they wrote?

Yeah. But the type of student that has an active github, even if it's full of assignments, isn't the type that will interview often. So you better make him/her an offer fast. There's a complete subset of great hires completely invisible to anyone because FAANG hired them first.

> Moreover, tech companies seem to be infatuated with awful technical interviews that not only make you write code but often require you to solve some difficult algorithm puzzle at the same time.

There's a reason they are doing it, to filter against these folks. Asking for algorithms also weeds out bootcamps where, more often than not, students are taught only one "trick" and stack and generally lack the fundamentals to be able to switch to an other stack or problem area.

[0] https://news.ycombinator.com/item?id=5786720

Reply on news.ycombinator.com