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

91–100 of 269 posts

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

#91

Post by mads_ravn »

wruza wrote: post #67
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…

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

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

#92

Post by zelos »

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…

"Senior Engineer" isn't a single job definition, is it? There's senior in the technical sense and senior in the quasi-management sense.

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

#93

Post by tpoacher »

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…

I don't understand this distinction between futureproof vs simple code. I would have thought they are the same.

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

#94

Post by chii »

tpoacher wrote: post #93
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…

I don't understand this distinction between futureproof vs simple code. I would have thought they are the same.

They might be the same, but often, future proof code is written with a future requirement in mind, and extra "hooks" added in to allow easy addition of that future requirement.

For example, you might add an orm to abstract the db specific SQL, even though you only run off one database type, because it allows you to switch in the future.

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

#96

Post by tempodox »

userbinator wrote: post #16
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…

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…

An approach that has been working for me is to work bottom-up. Think about what basic functionalities you need, and start implementing them. Once they work properly, you can start composing an orchestrating them to larger units. That way you're less prone to build Babylonian towers of superfluous abstractions and indirections. Doing it in a way that's maintainable and extensible should come with experience.

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

#97

Post by hammock »

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…

What’s the better way, Assuming the goal is for the junior to do most of the work?

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

#98

Post by unnouinceput »

Quote 1: "Next year, I’ll be entering my 10th year of being formally employed to write code. Ten years! And besides actual employment, for nearly 2/3 of my life, I’ve been building things on the web. "

Math: If 2/3 => 10, then 3/3 => X. X = 3/3 * 10 div 2/3; X = 30/2; X = 15. So the author is 15 years old and writing code since 5 years old, and during this time he was also employed. Unusual but not unheard to be employed as a child.

Quote 2: "I was 19 years old when I applied for my first technical job. The position I was applying for was called “Student Webmaster”."

Oaw there, we just calculated she's 15 so how was she 19 when first employed? Something's off on one of above quotes.

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

#100

Post by jrumbut »

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.

It's not that far off from my experience in a research organization.

We underestimate the commitment of others to helping the organization that pays for their food's success (even though we feel the commitment). Coordination is needed but if you trust and empower the ICs you can communicate a high level vision and then just look out for major problems and opportunities rather than micromanaging the people who are doing roughly the right thing.

It's a model that doesn't work everywhere but it can lead to increased creative output, happiness despite lower wages, less need for middle management, and other benefits to an organization.

Post reply on HN