Re:Ask HN: How to improve as a struggling junior software en...
by throwawaybbq1 on Sunday April 10, 2022 @05:48AM
(#30975671)
In an R&D org where this is not a thing (pair programming). Any pointers on how to get started? (mechanics wise .. who controls the keyboard? Is the senior dev supposed to be quiet unless an issue? Is there talking throughout?)
Re:Ask HN: How to improve as a struggling junior software en...
by wfaler on Sunday April 10, 2022 @02:32PM
(#30980161)
Depends:
If you work remotely, using VS Code Liveshare or IntelliJ CodeTogether (depending on tooling) works a charm.
In office environments, I once worked in a place where each workstation had two sets of mice and keyboards connected.
Main thing about pairing is communication: one person "drives", while both people talk through what they are doing/thinking. The non-typing partner can be a "map reader" of sorts, thinking ahead. It really will be different from person to person.
The benefit of remote setups with two people working the same code in their own editor is one person can run ahead and write the tests, while the other writes the implementation code (and both communicate what they're doing).
What either setup has had in my experience is constant communication between the parties.
This is a decent article as well: https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effec...
I know with todays inflation in "senior" titles, it comes earlier, but personally, I have low trust in anyone who hasn't done the job for 10+ years.
As more concrete advice: Own the fact that you are green & new. Ask the "dumb" questions. If you are unsure on how to start something, ask "what would be a sensible, concrete first outcome on the way?". Ask, ask, ask.
Also, as a junior, it is immensely valuable to pair on problems and code with more senior members. So if it's not a thing, maybe suggest if you could try pair programming from time to time in the team. It reduces bugs and errors even for very senior people.
Finally, mistakes happen. Sure, try to avoid them, but don't freak out when they happen, just find a solution to correct it. Every mistake you make is a mistake you are less likely to make again (but some of them, you will make again, and that's fine). If you are able to do expensive mistakes on production systems, I'd suggest it's more of a process problem than a people one.