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

151–160 of 269 posts

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

#151

Post by temac »

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…

It depends on tons of factors. Yes there are things besides designing and coding, and they can be harder depending on people and projects, but some strong links to the technical parts are always needed, in the sense that a manager is not an evolution of an engineer. Cutler wrote non negligible parts of NT. Linus doesn't "code" much anymore but still has an enormous technical impact.

Limiting the dichotomy to "coding" vs anything else is really weird because coding is just a part of design, and never should have been considered the absolutely only essential part of software engineering -- and that's the case regardless of your seniority. Otherwise you can as well be considered a kind of secretary with additional specialized skills. Even if you don't recognize the other activities you are still doing them, at least temporarily in your head even when working on a project alone.

And also there are tons of areas where code/design can still be tricky even for highly talented people. E.g. writing a state of the art compiler is not necessarily easy even when the problem has been well defined.

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

#152

Post by ratww »

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…

> “Code is a liability” “Don’t solve problems with code that can be solved in other ways”

In my experience managers tend to parrot those, but it is almost always coders (technical managers who get their hands dirty still count) who actually knew when a problem can be solved without code in an elegant, scalable, way.

Again IME, when managers are left to their own devices for those decisions it's often "send an email telling users they can just [mis]use feature X for that", or "yeah just install Intercom and support will handle" or "ask users to open a support ticket to perform this feature". Solutions which will often creates more problems for support people, customers/users, non-technical users, or even developers later because often they have have to do something with non-structured chat data.

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

#153

Post by magicalhippo »

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…

Sounds very similar to how we operate as well.

I feel it really helps being part of the customer meetings from the start, so you have a good understanding of the customer's context and needs while designing and implementing . It also allows us devs to raise potential issues much earlier, which can lead to much better solutions than if it's discovered late in the project.

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

#154

Post by sbarre »

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 out of the realization that we were not set up to take in juniors without some kind of structure that ensured they were provided guaranteed support to keep growing into their roles, since the teams across our department (of ~500 people) have such different focus. This program exposes all of them to the different facets of being a front-end and back-end developer, no matter what team they are on.

The juniors have 2 to 4 sessions per week on different tech topics, with courses taught by volunteers from within the department who sign up to prepare the course and present it.

The program has a been a huge success (both for the juniors and for the more experienced folks giving the courses), and we are starting our 3rd cohort this month.

When we opened the job posting to take applications this year, we got 450 applications in 3 days, for 10 possible positions. I wish we could expand the program to take in more people but we've found that 10 is what we can handle for now.

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

#155

Post by cupofpython »

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 used to lay bricks and now im a general contractor"

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

#156

Post by 29athrowaway »

> Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own (or with minimal feedback) for 5 years.

I learned 10x more coding C++ and Rust in my room, watching Twitch streams of people doing interesting things and watching Cppcon talks than many years of coding in other languages at work.

> Disorganized or messy code isn’t the same as technical debt.

Try fixing a production problem at 4 AM and having to read some messy code. It will make you think "why did something think it is acceptable to have this in a mission critical system?".

Try having to maintain a critical feature in a non-breaking manner and having to deal with some messy code. It is frustrating.

So, messy code is unprofessional. It's bad workmanship.

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

#157

Post by temac »

mads_ravn wrote: post #91
wruza wrote: post #67

Earlier quoted context omitted.

Probably unpopular/heretic sub-opinion: if given a chance to change the past, I’d rather NOT read books like TAOUP and other books on the same shelf. Or at least wouldn’t take them close to the heart. Because instead of collecting my own experience and fitting it to my projects, I’ve invested heavily in these patterns and rules and “gems” and built something in me that I now have to destroy with advanced therapy (not…

IMHO there is a lot of value in learning the rules and then breaking the ones, that in your judgement does not apply to a given situation. A variation on Chesterton’s fence [1], or, if more literary inclined, the parable of the camel, the lion and the child [2]. [1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence [2] http://nietzsche.holtof.com/Nietzsche_thus_spake_zarathustra...

The things is: they are not even rules, while some people think they are, but merely potential tradeoffs, interesting in some situations but that's it.

And it is highly conterproductive when people start to cargo cult them, and oh my god do they do. I sometimes wonder if the world would not have been a better place without e.g. GOF design patterns book, clean code, or SOLID, etc.

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

#158

Post by JackMorgan »

grog454 wrote: post #135
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…

> 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 managers can be excellent but code illiterate keeps showing up, but makes no sense at all.

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

#159

Post by jiggawatts »

kqr wrote: post #58
BlargMcLarg wrote: post #46

Earlier quoted context omitted.

I'd argue more people severely overestimate the need of communication quantity and management roles/responsibilities have inflated everything as a result. Worse, people who want to primarily talk are going to advocate for others to talk more. Regardless, whoever brings up what GP does is frequently bombarded with the old "communication important" or "soft skills matter" spiel in an attempt to validate the explosion o…

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 fight against the rising tide of overhead.

Just recently I tried to explain to a manager that status reports are not the most important deliverable. That the actual product is, and reporting about it is secondary.

They were aghast.

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

#160

Post by sbarre »

brunooliv wrote: post #121
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…

It's still baffling to me how short avg tenure for SWE is, in general. I feel that after a year, maybe, is when I finally start getting the lay of the land, meet some people, start understanding more of the domain and can start causing impact worthy of my paycheck. I'm now at 3.3 years at my current gig and I'm feeling like I have superpowers, if that makes sense. I think it takes time to be in a position to really d…

In my 20+ years as a developer, I've always advised developers working under me to move around and not stay in the same place too long. After 3 years it's potentially time to start looking around..

It's not just about the money, you also want to acquire varied experience and see how different teams work and tackle different problems, and expand your own experiences.

You can even come back to a previous company some years later and probably come in at a higher spot than you'd have been able to get if you stayed put and tried to climb internally! I've seen this many times.

We called it the "zig-zag"..

You do make a good point about sticking around long enough to see the outcome of decisions and the successful(?) launch of products or projects.. That is important for sure, and it should impact the timing of making a move to a new thing.

That said, things are a bit extreme right now in terms of how quickly people change jobs, but as someone else said the way salaries have exploded, you can move to the literal same job somewhere else and get a 30% raise, so it makes total sense why people are doing it.

That may not last forever, so get your raise while you can! New opportunities will always be there.

Post reply on HN