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

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

#201

Post by [deleted] » Mon, Jun 06, 2022, 4:26 PM UTC

latch wrote: post #7

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…

This is why a lot of people don't test or claim that testing takes more time since "we spend half our time fixing the tests" - a lack the experience to design code that's testable. I think it's also worth pointing out that up to a point, code that's testable tends to be more maintainable. This largely has to do with coupling and cohesion. Code that's hard to test in indicative of too much coupling and/or not enough c…

[deleted]

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

#202

Post by blueslurpee » Mon, Jun 06, 2022, 4:29 PM UTC

feoren wrote: post #195

badsectoracula wrote: post #161

Earlier quoted context omitted.

> I can almost guarantee you that any codebase with a "Player" class that looks anything like your example is a very poor codebase. It shows me they just didn't know where to start, so they started by throwing everything in there. And then there is Unreal Engine 5's ACharacter class[0] :-P. I recommend checking the superclasses too. [0] https://docs.unrealengine.com/5.0/en-US/API/Runtime/Engine/G...

First off, I'll say that popular frameworks optimize for being popular, which usually means they let inexperienced people make cool things quickly. This necessarily involves tradeoffs that end up being "walls" to more experienced coders. It's very very hard to let inexperienced people make cool things quickly without restricting power-coders. So "Unreal does it" doesn't necessarily mean it's the right choice for grea…

The technique that you have described on viewing the simple object combinations as "projections" is an excellent one; composability in your system emerges from efficiently selecting and combining these projections into the desired combination. At different points in your system you take just take different projections. Cross-cutting concerns are a breeze.

It actually all starts to feel like.... SQL! State is stored globally in a defined schema and queried as needed by the system.

But you can't do this if your compositions are preordained from on high by a rigid class hierarchy, the data is crystallized into the "blessed" projection and that's that. It's analogous to your SQL queries being constrained to solely static views. No JOIN. No GROUP BY. No WHERE.

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

#203

Post by rocqua » Mon, Jun 06, 2022, 4:32 PM UTC

TheCoelacanth wrote: post #188

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.

You need coordination. You don't necessarily need hierarchical coordination.

Coordination without any kind of hierarchy has N!/2 complexity. That gets overwhelming way to soon. Have an idea that requires everyone else to change something. N!/2 conversations to have. (Or one big meeting with the same sort of complexity). Need to change your approach to match what others are doing, gotta make a 1-on-1 connection. If they need to change their approach, they need to coordinate with others, continue for a long time.

If you want any kind of efficiency You need to have small-ish teams. I'd guess about 10 people. But lets say 50. You need to chunk up work so that teams can work in parallel. You need central oversight to coordinate the teams. This can be just a group meeting of team leaders, but the big picture should not be lost. And you need to make some decisions from this central picture.

All of this very quickly leads to hierarchy.

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

#204

Post by marcosdumay » Mon, Jun 06, 2022, 4:32 PM UTC

gjulianm wrote: post #116

LAC-Tech wrote: post #25

I deployed by ssh-ing into a server and running git pull. That sounds wonderful. Let's do that again.

There's a reason most deployments moved away from that: - Sometimes you need more complex actions to update a service than just "update the code". Migration scripts, dependent services restarts... - It's fine on one server, but the more you have the more difficult it gets - Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere.…

> Sometimes you need more complex actions to update a service than just "update the code".

Yes, software that was updated with a `git pull` always had an script or executable that gets the environment up to date with the new version.

> It's fine on one server, but the more you have the more difficult it gets

Nope, it's easy on as many servers as you want. It's just a matter of running `ssh $x (cd dir && git pull && dir/update_environment)` on a for loop. There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file.

> Too easy to say "let me just modify this thing here in production"

Well, that's a "don't".

> Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere.

And that is the one reason why this was abandoned almost everywhere, as soon as it became possible.

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

#205

Post by rocqua » Mon, Jun 06, 2022, 4:36 PM UTC

BlargMcLarg wrote: post #78

rocqua wrote: post #62

Earlier quoted context omitted.

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 communi…

Let me rephrase:

If your communication is bad, then you will need more communication to get to shared understanding.

Yes, better communication would also be a great solution. But "if you are bad at X, just do X better" is meaningless advice. Useful advice is either how to fix the problem (advice on how to do X better) or less popularly but often very useful, how to mitigate the problem (advice on how to avoid bad outcomes from being bad at X).

Turns out that more communication is essentially the only way to mitigate ineffective communication.

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

#206

Post by rocqua » Mon, Jun 06, 2022, 4:37 PM UTC

Jensson wrote: post #80

rocqua wrote: post #62

Earlier quoted context omitted.

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

I meant something more along the line of "if your code is ill-optimized, you gotta throw more CPU time at it".

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

#207

Post by rocqua » Mon, Jun 06, 2022, 4:41 PM UTC

kqr wrote: post #150

jseban wrote: post #128

Earlier quoted context omitted.

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 -- m…

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.

That's still a "manager" someone to manager better coordination. The point here is that such a role is required to get work done.

Sure, there are weird things that happen when the manager stops being a bottom-up appointee and starts being a top-down ruler. Heck that is incredibly common. But that does not mean we should do away with central figures that handle coordination. You still need those central figures.

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

#208

Post by corrral » Mon, Jun 06, 2022, 4:42 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…

Consider the manager who tries to put in a couple hours a week helping with filing (as in, organizing paper files). Let's say the filing system is very busy and constantly evolving to meet new needs.

Odds are they're just going to mess things up and annoy the people who do it as a major component of their job. Now, it may still be worth it, to keep the manager somewhat aware of how workers are doing their jobs, but it's not going to be helpful.

You need literacy to work on filing, as you need programming ability to do software development, but in either case it's not sufficient. If you're just dipping in here and there, you'll likely be screwing things up more than you're helping. There's too much context required.

Reading, writing, and programming may be forms of literacy, but if you try to jump in with tiny and inconsistent efforts to help someone write a novel—and I mean the actual writing, not helping them with organization or sales or something—you're probably doing more harm than good. Collaboration is possible even on novel-writing, of course, but very part-time efforts aren't likely to improve anything.

Programming is the same, and that's why once someone gets past about half-coding-half-managing it gets harder to keep helping with the coding, productively. It's not about literacy—the person trying to help with an hour or two of novel-writing a week is literate, after all—it's about context.

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

#209

Post by ozim » Mon, Jun 06, 2022, 4:56 PM UTC

marcosdumay wrote: post #200

ozim wrote: post #140

Earlier quoted context omitted.

Sadly it is a smart thing. But not only to get any code to prod. From my perspective it is to stop loads of stupid code/stupid solutions even way before it is written down as a task on your favorite task tracking tool. That is what meetings are for as well.

You seem to be arguing into promoting seniors into architects. The GP is arguing into promoting them to management. If the one hard problem your place has is organizing all the easy problems so they add to each other, turning your seniors into architects makes a lot of sense. And that's a very common situation. But the GP's motivation for moving them into management is basically that the organization is dysfunctional…

I am mostly thinking about technical team lead role which is not an architect and not managerial role.

Team lead does not have time to code most of the time but does code reviews and attends meetings with architects and others and works on aligning stars so things happen. Then also has to stop stupid ideas or propose how to better solve a problem for a customer.

But as I read GP post again it seems he might mean actual management.

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

#210

Post by bluefirebrand » Mon, Jun 06, 2022, 4:57 PM UTC

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…

I scare the absolute crap out of a lot of Junior developers when I tell them this.

I once said, jokingly, that "Actually, abstractions in code are bad" to a Junior and I'm pretty sure he considered quitting on the spot.

But I do think a lot of this stuff, designed to give everyone a common code philosophy, is actually just resulting in a lot of unnecessarily overcomplicated code.