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

Absolute truths I unlearned as junior developer (2019)

monicalent.com

Post reply on HN
Print view View original

141–150 of 269 posts

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

#141

Post by matwood »

ipaddr wrote: post #8
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…

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?

Blurring the lines is a senior engineer's job (though at a larger company, this may not happen until the next level up). It's how they grow the scope of what they deliver to the company.

I would be upset if a senior engineer told me that anything in the path of delivering the final product was not their job. Defining 'job' here as understanding something and communicating/helping address/fix with the appropriate team.

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

#142

Post by kqr »

matwood wrote: post #137
kqr wrote: post #136

Earlier quoted context omitted.

I remember reading a thought experiment: after a fire drill when everyone is in the parking lot, the CEO can say, "Everyone who was in an actual call with a customer when the drill started can get back in. The rest of you stay out until someone dealing with a customer asks for your help." I imagine a lot of people in HR, marketing, and various other paper-shuffling positions have to stay in the parking lot for quite…

> I imagine a lot of people in HR, marketing, and various other paper-shuffling positions have to stay in the parking lot for quite some time. Not to mention many executives! Most of the IT people also...

In some organisations where many customer-facing employees are fairly IT literate, yup, definitely.

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

#143

Post by matwood »

wokwokwok wrote: post #115
mytailorisrich wrote: post #111

Earlier quoted context omitted.

In general a "senior engineer" is simply a dev. with about 5+ years of experience so that they are no longer junior and no longer need hand holding. There's usually no, or very little, project management, lead work. At least that has been my experience everywhere I worked in the last 20 years...

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…

> Why? …because seniority is about responsibility, and if all you do is write good code, you’re not accepting the responsibility for anyones effort but your own.

Exactly. Ownership of a certain scope.

This came out not long ago, and I love the graphic.

https://www.honeycomb.io/blog/engineering-levels-at-honeycom...

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

#144

Post by corobo »

ipaddr wrote: post #8
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…

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?

Not OP but

> Are you doing QA and managing the production servers as well

haha... yes I am

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

#145

Post by ozim »

jackblemming wrote: post #51
lifeisstillgood wrote: post #45

Earlier quoted context omitted.

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…

“Code is a liability” “Don’t solve problems with code that can be solved in other ways” “Code is grunt work, I’m an architect” “Projects fail from people problems, not technical problems” There’s truth to all of these, and yet the people who repeat them dogmatically are often programmers or managers with ultra inflated titles who write blog posts or emails all day ;) They probably didn’t even like programming and saw…

If you get developers who get stuff done well - sales people have so many stupid ideas that implementing these would hurt my brain.

Imagine implementing everything that pushy sales people throw at developers.

I only agree that "code is a grunt work" is wrong simplification but picking out which code is really valuable to write is still in my opinion much more important than just slinging out code.

My idea is that there is no "work smart or work hard" - first you have to make sure code to be written is valuable and then you work hard to code it.

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

#146

Post by zelphirkalt »

jackblemming wrote: post #51
lifeisstillgood wrote: post #45

Earlier quoted context omitted.

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…

“Code is a liability” “Don’t solve problems with code that can be solved in other ways” “Code is grunt work, I’m an architect” “Projects fail from people problems, not technical problems” There’s truth to all of these, and yet the people who repeat them dogmatically are often programmers or managers with ultra inflated titles who write blog posts or emails all day ;) They probably didn’t even like programming and saw…

My impression as well. My thoughts then are usually something like the following questions:

"Oh? Have you really sought out all the good resources and learned from them? Multiple different paradigms? Countless projects exploring ideas? Many different languages, learning their concepts? How come you stopped liking to code? What made you lose liking to make the computer do your bidding? Did you ever really like it? If you did not, did you really go all the way you were able to, in order to explore all the things? Do you really know as much as you claim to know? Or have you been 10 years in the same mainstream OOP job and only feel like your time spent doing the same thing over and over again warants you a senior title and you should move on to management, because 'there is nothing more to explore'?"

I do not usually ask these questions. I rather observe and might indirectly poke for some knowledge. When I do ask some of those questions, I usually get a reply like "Meh, programming language does not matter, it is all the same." -- The usual "I don't want to have to learn more." type of response. There are many variations of this response, for paradigms, concepts, programming languages, you name it. Usually there is some overly broad generalization in it, overloooking benefits, that one approach might have over another, because they never tried or learned that approach and have no experience with it. When I hear that kind of response then I know what I am dealing with.

The person is free to show by their words and actions, that they actually _do_ have that knowledge. Otherwise I will just accept, that this person does not love coding the way I do and that they do not have a drive to go all the way of exploring so many different concepts and things. That's totally fine, coding might not be for them, or they might not like it to the same degree (and they do not have to), or they might not have been as lucky as I was and did get continuously in touch with new exciting things to learn about. Maybe they did get stuck in that OOP drudge and did really not see anything new any longer.

Whatever it is, I just hope people don't simply assume, that just because "they have been coding a in the past for x years", their experience is the same I have. I do not mean in experience quantity levels (years), there surely are many people longer in this hustle than me, but in individual experiences and concepts one gets in touch with, when exploring off the main road. There is so so much to explore and learn about. One can probably learn ones whole life and not have seen it all.

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

#147

Post by chrisweekly »

AtNightWeCode wrote: post #118
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…

Where I live the worst of this is that one is often expected to be the head of a team as well as lead developer. Sitting in meetings with people talking about personal matters was not the reason I became a developer. The purpose of having autonomous teams with agile development is to speed up development by defining responsibility between different roles in the team and to give the team a sense of ownership that will…

Yeah, I keep seeing this enterprisey top-down centralized micromanaging cargo-cult "digital transformation" so-called "Agile" rigid overspecified prescriptive process conveniently ignore the crucial SELF-ORGANIZING TEAMS aspect of the original manifesto.

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

#148

Post by beepbooptheory »

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 less and less.

Why hire a junior when surely you can find some established OSS person? Its so competitive these days, as much as I want personally for this not to be the case (so I can score a job), I dont see why any company would want to hire a junior dev anymore. Interviews I get tend to play this out. Everyone likes, abstractly, the pedagogical ideal of bringing someone in to learn, but when its their money on the line, they go for the most experienced individual they can acquire.

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

#149

Post by _gabe_ »

watwut wrote: post #56
userbinator wrote: post #16

Earlier quoted context omitted.

I blame this tendency to overabstract on the emphasis on top-down design / teaching methods. Beginners are taught to abstract whenever possible, and aren't taught when to stop. They don't see the reason behind it, and instead add abstractions dogmatically, dramatically increasing complexity in the process. When abstraction is used well it definitely decreases effort and increases flexibility, but all too often it's o…

I dont know ... way more common problem I see is unwillingness to abstract. Spaghettis are way more frequent than massive abstractions. Now the popular thing is move toward functional-like style, which leads to one stream of flow that is quite difficult to decipher.

> which leads to one stream of flow that is quite difficult to decipher.

By the definition of one stream of flow, this is literally easier to follow lol. One stream of flow as opposed to what? Several streams that branch and intermingle? Spaghetti is several intermingling branching streams which is very hard to follow. Following one stream is easy, you just follow the stream /shrug

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

#150

Post by kqr »

jseban wrote: post #128
rocqua wrote: post #63

Earlier quoted context omitted.

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

Yeah this annoys me to no end how tech people pretend that they have casually invented peace on earth, and act like it's the most obvious thing in the world. "Of course large groups of people simply just get along perfectly and efficiently without any coordination" Yeah right. It's the people who are dysfunctional who thrive in these environments because they don't have to be accountable, so their issues just disappe…

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 -- management bureaucracy discourages caring about the common goal, instead focusing on encouraging obeying direct orders.

(And then it goes on to redefine "obeying orders" as "coordination" to prevent anyone from seeing what's going on.)

Post reply on HN