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

71–80 of 269 posts

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

#71

Post by pojzon »

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…

Its all fine and dandy, but expect ppl will be willing to do this kind of work if you pay them few salaries worth of money.

If you want senior developer that will work as an architect, team lead, product manager etc.

(S)He better make 400k per year or more.

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

#72

Post by pojzon »

tobyhinloopen wrote: post #70

Cmon guys just write some damn tests. It’s not that hard

Its very easy to force ppl to write tests.

For example Sonar QualityGate on new code added to the code base.

Its hard to make ppl write tests that make sense and are worth running.

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

#73

Post by mypastself »

devnull3 wrote: post #3

Small piece of wisdom I received when I was an intern: "Never get sentimental with your code"

I’ve had customers request complete rebuilds of functionalities several times over, destroying weeks of effort each time… and I’ve never cared, as long I’ve clearly communicated my concerns beforehand.

I’m precious about the code only while developing it. The process is the fulfilling part to me, not how the end result is used. The approach has its drawbacks, I’m sure, but I find it very easy to not grieve over paid-for-but-unused work.

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

#74

Post by moonchrome »

dagss wrote: post #66
moonchrome wrote: post #30

Earlier quoted context omitted.

>For example, a schema is an abstraction Meh, I'd say strictly defined schema, moving database consistency logic to DB etc. is an example of a bad abstraction in most cases I've seen it used. The idea sounded really good when I was a junior, you can have data layer enforce integrity from all sources. Except most applications are exclusive owner of the DB and it's schema - even in the microservice world it's one datab…

I agree that SQL vs git is not a perfectly solved problem, but I would argue that NoSQL vs git is an even harder problem where the state of the DATA does not necessarily match what your current code says -- you need to remember/comment that some fields did not exist in past data or run jobs to migrate the old data etc; it is doable but not obviously better than the state SQL is at.

Dealing with breaking migrations is hard with or without types, but I agree that having database schema catches this sooner and more reliably (analogous to say having API schema and catching breaking changes by diffing).

But from what I've seen using schema to enforce data consistency brings more problems than benefits.

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

#75

Post by jacobolus »

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…

> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped"

You surely would hear things like “I used to write research papers but since I moved to management I have stopped” or “I used to write fiction stories but since I moved to management I have stopped” or “I used to write legal briefs but since I moved to management I have stopped” etc. if you talked to people in fields where people’s focused work is writing.

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

#76

Post by IshKebab »

feoren wrote: post #59
oconnor663 wrote: post #5

> Things like indendetation, formatting, naming – god forbid you did it differently than I would have. I agree with chilling out about this when it's a human making the changes...except now that we have autoformatters we can actually be more pedantic about this than ever before :) If the autoformatter doesn't agree with what you wrote, bam, red CI. > Everyone writes tests A big thing I've learned over the years is th…

Much of the time, once my code is the way I want, there's almost nothing to test. Any tests I write would just be an echo of the implementation itself. I think if you're using your static type system to its fullest and writing clean, "obviously correct" code, 80% of your tests are simply not necessary at all. It goes: - Bad code: almost no tests. - Good code: lots and lots of tests. - Great code: almost no tests.

You definitely have to write fewer tests in well typed languages like Rust, but you still need some tests! Maybe 1/3 as many as in something like Python, rough guess.

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

#78

Post by BlargMcLarg »

rocqua wrote: post #62
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…

What matters is not communication, but shared understanding. This is of incredible importance to get written code to actually matter. One gets the shares understanding through communication. If that is going poorly, more communication is required. So whilst we agree an abundance of communication is a bad thing, we disagree on why. It's easy to hate on time wasted on communication. Disruption to your process sucks. Bu…

>If that is going poorly, more communication is required.

No, you need better communication. Start decoupling "more" from "better". That's the crux of the matter, people trying to bruteforce communication issues by adding more communication.

Most people suck at communication. Including 99% of the people applauding themselves or each other for "great communication". We're not solving these issues layering more communication, that's how orgs die under their own weight. What they need is better strategies and to stop boggling down ICs with redundant bureaucracy, as sibling points out.

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

#79

Post by sally_glance »

kqr wrote: post #61
jseban wrote: post #50

Earlier quoted context omitted.

I don't understand this, this is the way every hierarchy work, and how every single job/management role is functioning. It's to solve the problem of communication overhead growing exponentially with larger groups of people. Why does this make you sad? And is it better to have a dysfunctional organisation where people float in and out of poorly defined roles and everyone tries to do everything? Does that really make y…

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…

This reminds me of a very interesting comment on the engineering and management practices at Intel [1]: "I often called Intel an 'ant hill', because the engineers would swarm a project just like ants do a meal."

I've seen it happen at smaller scales, great engineers in flat hierarchies without direction might not be the best idea from a business perspective...

[1] https://news.ycombinator.com/item?id=31571560

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

#80

Post by Jensson »

rocqua wrote: post #62
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…

What matters is not communication, but shared understanding. This is of incredible importance to get written code to actually matter. One gets the shares understanding through communication. If that is going poorly, more communication is required. So whilst we agree an abundance of communication is a bad thing, we disagree on why. It's easy to hate on time wasted on communication. Disruption to your process sucks. Bu…

> If that is going poorly, more communication is required

That is like saying "if your program is performing poorly, more code is required".

Post reply on HN