Hacker News Reader

These kinds of negative thoughts are never helpful. We're all learning constantly and had to be the newbie at one time. Push them out of your mind.

I will let you in on one superpower that I was lucky to learn early... read the manuals, yes the manuals to your most important tools and practice. All of them, front to back. Very few people are willing to do this for whatever reason. Result being even if you don't know how to do something exactly you'll be able to look it up in seconds and knock it out in minutes.

Using this strategy, at one job I went from nobody to "god-like" (haha) guru-in-demand simply from reading the manual front-to-back for the Unix Shell we used... in the span of about two months. The resulting scripts I wrote automated about 50% of our team's work to single commands, which was greatly appreciated.

This! Reading in general manifests to others as if you have superpowers at times. Whitepapers, RFCs, manuals, API docs, regulations, devour them all and the doors will open so fast it will make your head spin. General advice to all, don't get bogged down thinking you need to memorize every algorithm and data structure to be a great programmer. It's more about understanding the domain you work in and knowing how to "stand on the shoulders of giants" within that domain.

Another thing about reading "everything" ... You can a) have solutions ready before other people know they have a problem; and b) in part from that, get a reputation for knowing "everything".

Never say never.

Thoughts like that are like pain. They are wonderful signals that something is wrong. Something needs to change. That doesn't mean we should seek out pain, just that it's a signal we should pay attention to.

And ignoring pain or "negative thoughts" is likely quite harmful behavior. You'll train yourself not to notice valuable signals when they happen.

I have to admit I don't love pairing at all as a way of working, but I have to grudgingly admit it has a lot of value -- when pairing a senior and junior, it's the most effective way of knowledge transfer and skill building in the junior.

I don't understand why you'd do pair programming with two new hires!

> I don't understand why you'd do pair programming with two new hires!

I don't know or think if it's the most effective way but it sure did help me build confidence approaching a large and old codebase with another new hire. I saw I wasn't the only one struggling and we were helping each other out. Maybe I just clicked with the fella, because we ended up having a great work relationship building awesome shit and friendship too. I dunno, maybe it was effective after all.

That does make sense!

Really it seems like the best way to do pairing is to switch up who's pairing with who often, not stick people together permanently. Because there are different advantages to different pairings. And an advantage to the act of switching it up itself, of developing common shared knowledge across the whole field.

Oh yea. Does anyone advocate for tied-at-the-yoke pairs other than consulting firms that like the billable hours?

> I don't understand why you'd do pair programming with two new hires!

There's nothing wrong with two new hires pairing. A few things a pair could be doing while the other is writing code:

1. Spike out a refactor of the current viewable block of code that the other pair just wrote or is currently writing. Looking at it as a spike instead of a hard refactor allows a pair partner to experiment and if the spike doesn't result in something better, throw it away; no harm done.

2. Jump ahead and spike out a function that the pair might need soon, but isn't ready to consume yet.

3. Watch for pair getting stuck and help them think. Ask questions like ... are you stuck or just taking a mental break? That's a helpful question because it makes them more comfortable taking mental breaks when they need one without fear that you're judging them.

Keep in mind, pairing is AMAZING when deployed with empathy and less judgement. For those that feel like they are being judged when pairing is likely because you are a bit judgmental when the shoe is on the other foot.

FYI, teams that pair daily, get more done and team members feel less lonely and more like a real team. Go Warriors.

Thank you for sharing. That’s helpful perspective for me, as a manager, to consider.

One thing I try very hard to do for my new onboarders is to establish trust and open dialogue with them, as quickly as I can, to make it easier for personal concerns to surface. And then listen to those concerns in full sincerity and confidence.

Do you think having something like that established would help? If you had any feedback for how your manager may have helped further, what would you tell them?

In my first dev job I was hired as 1 in a pair of jrs to start at the same time on the same team. We never got along. After about a year I was promoted and the other person was let go for performance reasons.

I never really put myself in the other jr’s shoes so thanks for sharing your story. At the time I was pretty intimidated by her and all the other engineers, I can only assume it was much worse for her.

In retrospect it was obviously a bad idea to hire 2 jrs at once. It was a small company (~10 engineers) and we were their first jr hires. I think the company thought that it would foster camaraderie and a little healthy competition, but I think most jrs have too much impostor syndrome for that to work out.

On a side note I think they did have a good onboarding program for new developers. Outside of normal jr level tasks it was roughly 50% technical support: talking to customers, collecting bug reports, reproing bugs, then finding the right engineer to fix them. Over time I started diving into the code myself to see if I could find what was breaking, then eventually putting up fixes myself. It was a good way to contribute real value to the company while learning how a codebase works.

I have such mixed feelings about healthy competition in this context. I really enjoy it. If I do something a little more performant, or a little faster, I feel good. If I don't, I legitimately look forward to learning what I could have done better (sometimes it's just "be faster" and there's not much you can do in that respect). But honestly I think I'm in the minority in that aspect. I enjoy doing LeetCode even though I'm not particularly good at it (50/50 shot at solving a medium on the first couple tries, at best). But I know a lot of people who are great developers that would crack if they thought they were constantly being compared to someone else, and these are people with the benefit of a decade+ of experience.

Impostor-syndrome is very very normal (I'm 20+ years in the industry and still have it), so rest assured you're not alone. What's most important is that despite negative self-talk you're able to learn the ropes at the pace expected by your team lead and manager.

You don't know what that other Junior Engineer's story and history is. They might not be as Junior as they appear. I've hired "junior engineers" who have been programming since they were 8 years old. Even star engineers will often be overtaken by an even hotter burning, faster shooting star engineer. It's the nature of the industry that you will eventually work with what appear to be savants. There is room in the industry for mere mortals.

Regarding getting "soft booted"; As a manager I would never call a reassignment that. I might refer to a reassignment as "aligning an engineer's assignment with their talents". Sometimes I realize I've thrown someone into the deep end and they need to be pulled out of the water and given something a bit less intense; mea culpa. If someone were truly under performing I would be putting them under formal coaching.

Negative self-talk is dangerous when it leads you into to a downward spiral of under-delivery. I've seen engineers that literally self sabotage because they talk themselves out of actually delivering as expected. They constantly focus on "learning" so much that they never put what they've learned to use in delivering their assignment. They're obsessed with catching up so much that they never even start.

If nothing else, deliver what is expected to you. If you don't understand it, ask with help breaking it down. Every hint, or vague request by a manager or lead is likely a softly stated expectation. Ask for clarification: when would you like this done? how long do you think this should take?

Regarding wasting a lead's time, in my experience (as a lead engineer at one time, and on the receiving end of lead engineer's guidance) they will tell you when you're wasting their precious time. In fact, my technical mentor once told me, "first time you ask a question I'll show you how to find the answer. Second time you ask the same question I'll show you were to refresh your memory. Third time I'll tell you RTFM".

If you're doing poorly, it's likely that you'll be told in some way or another. Otherwise, If you can, don't try to read too much into things unsaid.