Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The hardest part of being a junior developer

rachsmith.com

Post reply on HN
Print view View original

71–80 of 82 posts

Re: The hardest part of being a junior developer

#71

Post by omgmajk »

c7DJTLrn wrote: post #12
cke wrote: post #6

This one hits home for me. Early on in my career, I had a "mentor" tell me to try it on my own before asking any questions only to swear under his breath when I messed up. It was a massive source of anxiety balancing between asking a question and the risk of messing up. When working with junior engineers nowadays, I go out of my way to let them know that any question at any time is acceptable. I'll put down what I'm…

>Early on in my career, I had a "mentor" tell me to try it on my own before asking any questions only to swear under his breath when I messed up May I ask how long ago this was? Although shit colleagues and shit workplaces still exist, it feels like these days it would be shut down pretty quick by HR in the average company.

HR is not your friend, unless you work in management or above.

Re: The hardest part of being a junior developer

#72

Post by st4lz »

distantaidenn wrote: post #61
zxcvbn4038 wrote: post #55

I have not been a junior developer for a long time, but I occasionally get treated like one. One day after joining a new employer I raised my first or second pull request - and one of the longer term members of the team reviewed it and really let me have it! In every single line he found problems with my style, approach, everything - and he wasn’t really polite about any of it either. So I wrote back that it was actu…

It's their ego. I'm now at the CTO level, but I still code as a hobby (daily) and will contribute as necessary to a product with coding. A couple years ago, during a stretch with a previous client, I wrote a bit of code. With my second PR, one of the code reviewers tore my code to shreds. It was 90% styling and 10% theory. As for the styling, sure, it was fair enough. I was new to their culture and it was trivial cha…

You describe something that I experience in almost any organisation. I am not a CS grad, I've seen many projects in different technologies through the years and also have more business-oriented mindset as for software engineer. The amount of arbitrary requirements in code, especially in languages with no clear code styles (like Python) and specifically with people who don't expose themselves to different technologies (work in the same company for years or so) is a major productivity and motivation killer.

What are the useful techniques to deal with such people? Many times, it is just easier to comply to their vague requirements rather than engage in prolonged discussions, as they usually don't have the ability or will to look at things from the other side. I consider escalation to a higher management the last resort.

Does anyone produced some successful strategies to deal with that?

Re: The hardest part of being a junior developer

#73

Post by perrygeo »

ThunderSizzle wrote: post #58
blacksqr wrote: post #51

Earlier quoted context omitted.

When I was young in the pre-Slack era when you actually had to find a colleague physically to explain the problem to, this was called "cardboard engineer syndrome"; i.e., talking to a cardboard cutout of a colleague would have been just as effective.

I know this as rubber ducking. Explain your problem to a "rubber duck" on your desk. It doesn't have to be a real rubber duck.

But it's funnier if it is.

Re: The hardest part of being a junior developer

#74

Post by perrygeo »

LAC-Tech wrote: post #36

I wish developers talked and asked each other for help more. Not just juniors but seniors too. This idea that we're all supposed to solve problems in a shared code base completely independently and we're wasting time helping/asking for help is poisonous. Things get solved lot faster when someone comes in with a different perspective. And it keeps communication going. Of course maybe everyone else is a lone genius and…

Solving things faster is not always the goal. I make a point to fully "rubber-duck" the problem before asking for help. Is this slower, yes. Does this build deep knowledge in a way that is superior to just being handed the answer, absolutely. Knowledge comes from direct experience - if you always rely on someone else's direct experience to get the job done, you might move faster in the short term but are missing out on a vital part of learning.

Re: The hardest part of being a junior developer

#75

Post by madcaptenor »

perrygeo wrote: post #73
ThunderSizzle wrote: post #58

Earlier quoted context omitted.

I know this as rubber ducking. Explain your problem to a "rubber duck" on your desk. It doesn't have to be a real rubber duck.

But it's funnier if it is.

You can also use an infant. Now that my youngest is two years old this doesn't work any more.

Re: The hardest part of being a junior developer

#76

Post by perrygeo »

An important skill is being able to distinguish between "stuck due to lack of technical knowledge" and "stuck because of inscrutable bureaucracy". The first, you can research, experiment and rubber-duck your way to a solution solo. The latter, the only way you're going to find out is to talk to someone inside the organization who holds the secret sauce.

Re: The hardest part of being a junior developer

#77

Post by tjrDL6MjB2Zwwa »

jen20 wrote: post #70
tidenly wrote: post #60

Earlier quoted context omitted.

I still work on a team the person who mentored me four years ago. He's a great guy, but sometimes in front of other engineers he'll still treat me like I'm a junior - and start explaining some incredibly simple concept to me like an idiot. Sometimes things I obviously knew before even joining, like how HTTP verbs work. It's just a quirk of his without malice I think, but it does get to me depending on who its in fron…

Whenever I encounter someone attempting to be condescending while talking about “HTTP Verbs” I pull open the RFC for HTTP and demonstrate that the word “verb” literally does not appear in the document.

so what?

Re: The hardest part of being a junior developer

#78

Post by actually_a_dog »

mnhn1 wrote: post #56
actually_a_dog wrote: post #33

Earlier quoted context omitted.

That depends IMO. Is the "mentor" really the "manager?" If someone with power over your performance evaluations and future at the company is swearing under their breath every time you do something wrong, that's a problem that HR maybe should be involved in.

HR is not there to solve your problems. HR is there to protect the company. It's fine to be friendly with HR (some wonderful people work there), but remember who is paying them and whose interests they are supposed to look out for first. Definitely not yours. HR wants all the info they can get from you. They will cheerfully listen to everything you tell them. And then they will do their job, which is to analyze the s…

A hostile work environment is the company's problem.

Re: The hardest part of being a junior developer

#79

Post by actually_a_dog »

fundad wrote: post #48
actually_a_dog wrote: post #33

Earlier quoted context omitted.

That depends IMO. Is the "mentor" really the "manager?" If someone with power over your performance evaluations and future at the company is swearing under their breath every time you do something wrong, that's a problem that HR maybe should be involved in.

Someone who needs to be on a performance plan expects HR to force coworkers to be more patient? Sounds about right

What are you on about with "performance plans" and such?

Re: The hardest part of being a junior developer

#80

Post by mandelbrotwurst »

antihero wrote: post #68
distantaidenn wrote: post #61

Earlier quoted context omitted.

It's their ego. I'm now at the CTO level, but I still code as a hobby (daily) and will contribute as necessary to a product with coding. A couple years ago, during a stretch with a previous client, I wrote a bit of code. With my second PR, one of the code reviewers tore my code to shreds. It was 90% styling and 10% theory. As for the styling, sure, it was fair enough. I was new to their culture and it was trivial cha…

If they were actually competent the styling changes would have been caught/fixed with automation. If they can’t set up linting and formatting as part of their CI…well I don’t think they have any right to call themselves senior.

Yeah, I tend to take the position that the only appropriate way to request code style adjustments is via automation.
Post reply on HN