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

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

#171

Post by beckingz » Mon, Jun 06, 2022, 1:37 PM UTC

JackMorgan wrote: post #158

grog454 wrote: post #135

Earlier quoted context omitted.

> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" Maybe we do. Wouldn't a better analogy be professional writers moving toward an editor/director role?

You're right! An editor probably reads more than all their authors combined, and provides feedback on what isn't up to standard. My engineering managers were expected to do the same. An engineering manager who does not read all the code and PRs is as helpless as an editor who cannot read. They cannot know who is performing well, who needs coaching, who is all talk but makes a mess, etc. The idea that engineering mana…

The sentiment I've seen is that a great people manager who trusts their engineers despite not knowing much about software can still be an above average manager.

Given that the median manager seems to be throughly mediocre, an above average manager even if they can't code or read code seems desirable.

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

#172

Post by Railsify » Mon, Jun 06, 2022, 1:39 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…

Extreme division of labor, did it work as far as pushing the product forward?

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

#173

Post by confidantlake » Mon, Jun 06, 2022, 1:42 PM UTC

tornato7 wrote: post #23

I still reminisce about the first big project I ever built. As an intern I was told high level what to do and given two years alone in a room working eight hours a day to figure out how to build it, zero guidance from anyone. I didn’t really have any concept of importing libraries or using open source software, so literally every part of this huge and complex application was custom-written by me. All UI elements were…

This is awesome. I often think I would be a better developer if I had something like this when I was first starting out. Alas, 95% of my experience is gluing libraries together to check off Jira tickets.

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

#174

Post by _rutinerad » Mon, Jun 06, 2022, 1:47 PM UTC

didibus wrote: post #22

darkteflon wrote: post #18

Earlier quoted context omitted.

I think parent’s point is that, you can be a great engineer, but also have limited knowledge of any given problem domain. What constitutes a good abstraction is driven in large part by that domain knowledge, rather than by your pure skill as an engineer.

There are abstractions that are not domain related, those exist as well, and I'd consider them more a part of product design, but software design can benefit from good abstractions at multiple levels and constantly do, but knowing how to use good abstractions and design them is very hard, bad ones or bad use of them will be worse than none. For example, a schema is an abstraction. Choosing to have a strictly defined…

A (json) schema is a specification, which is the opposite of an abstraction.

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

#175

Post by kqr » Mon, Jun 06, 2022, 1:50 PM UTC

jiggawatts wrote: post #159

kqr wrote: post #58

Earlier quoted context omitted.

Many big modern organisations are built by bureaucrats whose specialisation it is to create more bureaucracy. Thus they spend a lot of time thinking up ways to measure the work performed from various angles, create reports for their superiors, and find other ways to ride on the work of others to earn their salary instead of doing actual work. This propagates downward and soon everyone (but perhaps the most junior con…

Precisely this. I've seen every size and type of organisation from single digit employee count up to tens of thousands in huge bureaucracies. Inevitably, the paperwork becomes the goal , and no amount of pleading with middle-managers will convince them that their job is unnecessary. If they were to believe us, they'd have to quit and become unemployed. Even in my relatively small consulting org I have to actively fig…

Even more shocking: if the manager was active in implementation -- even just a small part -- they would only need a fraction as many status reports. They could just talk to the relevant people instead.

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

#176

Post by kqr » Mon, Jun 06, 2022, 1:52 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?

What would you consider sufficient evidence?

Not that I can't come up with a lot, but if it's trivial to prove I have less work to do.

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

#177

Post by snarf21 » Mon, Jun 06, 2022, 1:56 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…

Well said. We are having a similar "fight" where I work now. Way too much premature optimization. I think the one concept that takes a while to really understand is to focus on separation of concerns. It is far too easy to get encapsulation wrong. People (imo) generally forget to apply the SoC test that tells them where to draw the line. We also have a lot of parallel development where re-factoring a View (Screen) could cause a rippling failure to other people's code. Too often they try to reuse everything instead of the important part of extracting the shared business logic into a XXManager and letting the Views just be dumb. Who cares if two Views developed in parallel might be too similar? It might change in the future and don't have to worry about 1 View doing 2 jobs.

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

#178

Post by camjohnson26 » Mon, Jun 06, 2022, 1:57 PM UTC

lifeisstillgood wrote: post #45

silisili wrote: post #37

Earlier quoted context omitted.

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…

Thank you. Agreed completely I see software as a form of literacy, and it both amuses and saddens me to hear things like "I used to write code, but since I moved to management I have stopped" We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" It seems sad to note that this "move to management" is now also becoming the "move to senior engineering". This indica…

I see it more as leverage, the senior who understands good coding style and performance implications is far more useful when they can drive decisions across the whole codebase, instead of narrowly on one small feature. I’ll still take small features occasionally, but it’s more of a way to show juniors best practices so that they can improve the code they write, which is a win win for everyone.

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

#179

Post by wokwokwok » Mon, Jun 06, 2022, 2:03 PM UTC

mytailorisrich wrote: post #127

wokwokwok wrote: post #115

Earlier quoted context omitted.

I don’t know why you think that’s true “in general”. If you have a team with a senior member it, in general , what would you expect that team member to do? How are they different from the other team members? They are not senior because they’ve been there the longest. That’s stupid. That just makes them the oldest worker, not the most senior . I expect them to have more responsibility for making sure the team delivers…

I say 'in general' because that has been my experience everywhere I've known over the last 20 years. "Senior engineer/dev" is a title, this is not the same as being the 'senior member' of the team. In general (as per above) the title is given to devs with about 5 years of experience. It does mean more responsibility, but mostly in terms of being able to carry out dev. work without 'hand holding'. So I would say that…

> "Senior engineer/dev" is a title, this is not the same as being the 'senior member' of the team.

I call bs.

I should probably say, “that hasn’t been my experience”, but I just flat out don’t believe you.

So, let me get this straight. In 20 years, you’ve found that senior developer is the role given to developers who have no responsibility above what a junior developer has, they just cost more?

Rubbish.

It’s a sliding scale; I bet you those senior developers have other responsibilities; code reviews, mentoring, deployments, prod support, ci/cd.

I have never worked in, or heard of, an organisation where senior developers just get to sit around, goof off and write code all day… but get paid a senior developer rate.

Sounds great!

What organisations are these? I want to work there! Hook me up.

I think you’re suggesting that responsibility for team and project management is like a step function; you get none until you’re a principal.

That certainly hasn’t been my experience.

I honestly just have to say I flat out don’t believe that in 20 years at large organisations it has been yours either.

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

#180

Post by snarf21 » Mon, Jun 06, 2022, 2:03 PM UTC

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