Absolute truths I unlearned as junior developer (2019) • Hacker News Board

Re: Absolute truths I unlearned as junior developer (2019)

#181

Post by ChrisMarshallNY » Mon, Jun 06, 2022, 2:08 PM UTC

snarf21 wrote: post #180

ChrisMarshallNY wrote: post #117

> That’s why mentors are so important, and the team you work with is worth so much more than a couple bucks in your paycheck. Don’t accept a junior position where you’ll be working alone, if you can help it! And don’t accept your first role (or, honestly, any role) based on salary alone. The team is where the real value is. Couldn't agree more. Of course, with today's attitudes towards us olds, and the average term o…

Mentorship is about more than writing "great code". I'm 6 months at a new place as an old . I've already imparted a lot of lessons about working with difficult team members, picking your fights, how to let go of "perfect", there are more important things than being right, etc. My team is already less stressed, more productive and generally happier. :D

Yes. Totally agree. My comment on code quality was just one tiny aspect of a large continuum.

Strong teams are critical to doing big stuff. You get strong teams through lots of “soft” skills.

And also keeping employees for multi-year stints.

Re: Absolute truths I unlearned as junior developer (2019)

#182

Post by sseagull » Mon, Jun 06, 2022, 2:20 PM UTC

jseban wrote: post #168

kqr wrote: post #150

Earlier quoted context omitted.

Large groups of people with a common goal can coordinate within themselves. They don't need to hear "do X, now do Y" from someone else. And if they do, they can appoint that someone else on their own -- it's how the world's free countries operate, after all; and a country is bigger than a company. The only reason people think this doesn't work for companies is that they haven't experienced the "common goal" part -- m…

Well you have the burden of proof for these extraordinary claims, in what way is this different from the pitch of a cult?

The book "Turn the Ship Around" by David Marquet is basically along these lines. He worked to turn a poorly-performing submarine in the US Navy to one of the best. The gist is that he enabled autonomy and shared vision to reduce the top-down heavy handedness that they were usually used to, allowing for more efficient decision making.

That's a gross generalization, and it is still very hard to conceptualize, but thought provoking.

Re: Absolute truths I unlearned as junior developer (2019)

#183

Post by [deleted] » Mon, Jun 06, 2022, 2:24 PM UTC

silisili wrote: post #37

camjohnson26 wrote: post #4

The truth I had to unlearn is that coding is a solitary activity, and that coding is the most important part of a senior software engineer’s job. Now I rarely have the chance to code for a few hours straight because if I have enough information to write code then all that’s left is the easy part. The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the…

I hate that this has become the norm. Sometimes, even most of the time, tight clean code and proper data structures and clean smart queries are vital for both cost and performance reasons. That smart(experienced) people think up how to approach a problem and throw it over the wall to the juniors makes me sad, even if it has become somewhat commonplace. I was actually offered a position doing exactly that for a rather…

[deleted]

Re: Absolute truths I unlearned as junior developer (2019)

#184

Post by beepbooptheory » Mon, Jun 06, 2022, 2:30 PM UTC

sbarre wrote: post #154

beepbooptheory wrote: post #148

Can people even be "junior" anymore? Its relatively hard to find those kinds of positions anymore, or at the very least they are somewhat sparse. Thought it was interesting that this month, much more of the "Wants to be hired" postings were juniors compared to what people were looking for in the "who's hiring" postings. Ive ctrl-fed the monthly job postings for 'junior' for the better part of year, and its getting le…

Our company has a structured junior onboarding program. We take in a cohort once a year and they go through a 12-month program that happens while they are on the job in their various teams, designed to help them continue to grow their overall developer skills and also learn how things work at our company (we're a pretty big enterprise). This was sort of inspired by Facebook's internal bootcamp idea, but it also grew…

Sounds like a dream program to me! I can understand why its so popular.

Re: Absolute truths I unlearned as junior developer (2019)

#185

Post by Jtsummers » Mon, Jun 06, 2022, 2:49 PM UTC

LAC-Tech wrote: post #25

I deployed by ssh-ing into a server and running git pull. That sounds wonderful. Let's do that again.

That's how my present office does things (more or less, not git but same idea), making every box a pet that only a small number of experts can keep running. Good for the experts, bad for the customers, and turning bad for us as a project because it's pissing off the people paying to keep the lights on.

Re: Absolute truths I unlearned as junior developer (2019)

#186

Post by sidlls » Mon, Jun 06, 2022, 2:53 PM UTC

The point about over documenting is okay, but reliance on automation and tests is completely separate from documentation. They serve different purposes. The code is not (all of) the documentation. People who rely on code comments, API docstrings/comments, and tests as documentation are thinking of documentation only at the level of the interface, not the bigger picture: that's a junior mentality.

Also, documentation becomes stale and unreliable because too often too little attention is paid to it. It's not as fun as writing code, and it's arguably harder since the audience is either non-technical or has a different area of technical expertise.

Re: Absolute truths I unlearned as junior developer (2019)

#187

Post by KaiserPro » Mon, Jun 06, 2022, 2:54 PM UTC

> 5. Everything must be documented!!!!

I mean it should

> Focus on automation over documentation where appropriate. Tests or other forms of automation are less likely to go out of sync. So instead I try to focus on writing good tests with clear language, so developers working on code I wrote are able to see how the project functions with working code.

This makes me uneasy. I don't want to pick on OP, because its a common enough opinion.

However both is best. I don't think people really read tests to understand code, normally because tests are so contrived and shit they they are a burden to be ignored.

Re: Absolute truths I unlearned as junior developer (2019)

#188

Post by TheCoelacanth » Mon, Jun 06, 2022, 2:57 PM UTC

rocqua wrote: post #63

kqr wrote: post #61

Earlier quoted context omitted.

It is better to have a functional organisation where people float in and out of roles defined by the expectations of others and everyone is capable of judging basic business tradeoffs, yes. That, in my experience, makes people happier. They get to focus on important problems, help people they know, and develop their well-roundedness as human beings. I think you might be underestimating the amount of overhead that is…

That sounds incredibly amazing. Utopian. But I doubt it is possible even if all humans involved are incredible. You still need coordination.

You need coordination. You don't necessarily need hierarchical coordination.

Re: Absolute truths I unlearned as junior developer (2019)

#189

Post by li2uR3ce » Mon, Jun 06, 2022, 3:00 PM UTC

jehlakj wrote: post #9

For me, it was that I thought that being a good programmer was that I write clean code with enough abstraction and indirection to make it future proof. Boy I was wrong. Unless you’re doing the same thing you’ve done for years, you can’t tell the future. And just when your unnecessary abstraction is wrong, this the reason why we’re talking about tech debt in the first place. Because nobody wants to touch it. Unfortuna…

> Now I try to write dumb and simple (yet sensible) code until there’s a good reason for abstractions.

Good abstraction is a lot harder than most think. We tote abstraction's benefits as a reason for abstraction but fail to recognize bad abstraction and how it completely negates any would be benefit.

Too often abstraction (so called) requires a lot of research into how it's implemented. By the time you figure out enough implementation details to use the abstraction, you could have implemented it yourself quicker. It saves no time or effort but you're stuck with it because existing code is hard to part with.

If you're not reliving your users of a shit ton of implementation details then it's just not good abstraction. Code for someone who doesn't want or have time to learn the details. Often this will be your future self despite your current believe that your mind is a steal trap and would never forget how you did this stuff.

Re: Absolute truths I unlearned as junior developer (2019)

#190

Post by [deleted] » Mon, Jun 06, 2022, 3:03 PM UTC

dzikimarian wrote: post #42

ipaddr wrote: post #8

Earlier quoted context omitted.

That's not a senior engineer's job.. that's a job that has scope creeped into many roles: project management, lead developer, project owner and a trainer. Are you doing QA and managing the production servers as well?

That's exactly how we define senior engineer at my company. There's a lot of people able to produce code - even really complex and sophisticated. But you'll waste a lot of time if you're working without proper context and well organized team. From the other hand - you can't establish good context and organize team well without knowledge of what it takes to put requirements into code - therefore most efficient way is…

[deleted]