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

241–250 of 269 posts

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

#241

Post by gjulianm »

feoren wrote: post #198
gjulianm wrote: post #116

Earlier quoted context omitted.

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

> Too easy to say "let me just modify this thing here in production" This sounds crazy to me, like saying "it's too easy to say 'let me just poop on the floor right here' instead of going to the bathroom properly". What!? I can sorta vaguely understand why someone might think that's a little easier in the moment, but someone who has that little control of themselves needs serious help , if not a good old-fashioned ki…

The reality is that those things happen. Technology must inevitably deal with human problems too, it isn’t as easy as saying “just don’t do that thing”.

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

#242

Post by gjulianm »

marcosdumay wrote: post #204
gjulianm wrote: post #116

Earlier quoted context omitted.

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 && d…

> always had an script or executable that gets the environment up to date with the new version.

Which means you’re writing deployment tools already. Going from there to an abstraction that provides the primitives you use in those scripts is a natural step.

> There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file.

Indeed. But again, this shows how deployment tools evolve naturally from “git pull” to something more complex. It’s not complexity for the sake of it.

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

If only managing computers was as easy as telling people what not to do.

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

#243

Post by LAC-Tech »

gjulianm wrote: post #241
feoren wrote: post #198

Earlier quoted context omitted.

> Too easy to say "let me just modify this thing here in production" This sounds crazy to me, like saying "it's too easy to say 'let me just poop on the floor right here' instead of going to the bathroom properly". What!? I can sorta vaguely understand why someone might think that's a little easier in the moment, but someone who has that little control of themselves needs serious help , if not a good old-fashioned ki…

The reality is that those things happen. Technology must inevitably deal with human problems too, it isn’t as easy as saying “just don’t do that thing”.

No post body was provided.

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

#244

Post by icedchai »

JackMorgan wrote: post #158
grog454 wrote: post #135

Earlier quoted context omitted.

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

I must live in a alternate universe. At a previous company, the last two "engineering managers" I've worked with definitely could NOT read code. They did not read PRs, other than perhaps the title and Jira it linked to. Any technical management, including PR and design review, was delegated to the staff or principal engineer(s) on the team.

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

#245

Post by icedchai »

kqr wrote: post #194
beckingz wrote: post #171

Earlier quoted context omitted.

The sentiment I've seen is that a great people manager who trusts their engineers despite not knowing much about software can still be an above average manager. Given that the median manager seems to be throughly mediocre, an above average manager even if they can't code or read code seems desirable.

I remember reading about an actual observational study on this -- I think on HBR -- and the conclusion was basically that managers that are technically skilled have much happier employees on average. Another finding from the same study was that the statements "I feel like my manager can do my job" and "I am not looking for new work" were strongly correlated. (This sounds like the same thing but isn't.) In other words…

I think either end of the spectrum is fine: highly skilled / can do your job if needed, or not technically skilled at all / honest about it / tracks schedule / delegates all technical authority. The messy middle is where the problems happen.

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

#246

Post by icedchai »

wokwokwok wrote: post #179
mytailorisrich wrote: post #127

Earlier quoted context omitted.

I say 'in general' because that has been my experience everywhere I've known over the last 20 years. "Senior engineer/dev" is a title, this is not the same as being the 'senior member' of the team. In general (as per above) the title is given to devs with about 5 years of experience. It does mean more responsibility, but mostly in terms of being able to carry out dev. work without 'hand holding'. So I would say that…

> "Senior engineer/dev" is a title, this is not the same as being the 'senior member' of the team. I call bs. I should probably say, “that hasn’t been my experience”, but I just flat out don’t believe you. So, let me get this straight. In 20 years, you’ve found that senior developer is the role given to developers who have no responsibility above what a junior developer has, they just cost more? Rubbish. It’s a slidi…

In my experience, you are correct. In the wrong organization, you are eventually given so many "other" responsibilities, that you barely get to do any hands-on development work. You'll be doing code reviews, support, and documentation all day.

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

#247

Post by MathMonkeyMan »

cupofpython wrote: post #155
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…

"I used to lay bricks and now im a general contractor"

thank you

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

#248

Post by ge96 »

maccard wrote: post #240
ge96 wrote: post #228

Earlier quoted context omitted.

What's your bill like? Or I guess it depends on each person's interest in the cost but yeah. Maybe it doesn't have to be expensive if you do it from a "raw" way.

"it depends", but mostly I don't care, it's a rounding error compared to developer time. Digitalocean lets you deploy containers onto app service so you could do it for $5/month there. On AWS you can do it for about $15. > Maybe it doesn't have to be expensive if you do it from a "raw" way. If you look at straight $$$ cost sure, but the moment you take any development time into consideration you want to build on abst…

I see thanks for the insight, I'll keep this in mind, I did Fargate as an option but still don't know when to use but yeah, in due time will learn.

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

#250

Post by feoren »

Rayhem wrote: post #236
feoren wrote: post #195

Earlier quoted context omitted.

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…

I wholly agree with you and your commentary here is one of the most profound things I've read about software engineering in a long time. But, to play devil's advocate, > I'm guessing it's just because that is the combination that they found helps inexperienced coders make cool things quickly Is not "making cool things quickly" the essence of enterprise programming? Sure, you can make the cleanest, most perfectly abst…

> Is not "making cool things quickly" the essence of enterprise programming?

I think it's not. I'm not sure there's anything quick about enterprise programming. If you're cynical, the essence of enterprise programming is selling absurdly expensive software to clueless senior leadership that will never use it. If you're optimistic, the essence of enterprise programming is being a good data steward while elegantly handling the needs of a lot of different stakeholders and interfacing with a lot of different systems (some automated, some implemented only in brains).

In game programming, if you can't figure out a good way to get the camera to work in one particular level, you just scrap or redesign the level. In enterprise programming, if you can't figure out a way to import a particular Excel format, you could seriously harm the usefulness of your project or even lose a contract. You have to "get it done", and there are a lot of "its" to get done.

When I say "make cool things quickly", I mean that there are tradeoffs between having high velocity in the beginning (standard templates, pre-defined assets, content management systems, implement the whole thing in Salesforce) vs. maintaining that velocity through the lifecycle of a potentially very long project. I claim that one of the things that makes popular frameworks popular is because they tend to heavily prioritize the former over the latter. That is great for going from 0 code to shipped quickly, but it's the wrong choice for 5+ year projects like you see in enterprise.

In fact I think one of the (many) things that poisons modern enterprise programming is the emphasis on tools that get you going quickly, rather than tools that stay loyally by your side through the whole project lifecycle. MongoDB is quick and easy to set up, because you can just throw whatever JSON objects you want in there, without spending all that time worrying about "schema" (I do think people spend too long worrying about schema, but the answer is not to abandon it -- that's a whole other subject). But you still have a schema! It's just that now you don't have a dedicated tool to help you with it, and as your needs and data change, you're the one responsible for keeping it up to date. It seems very easy to get mismatched or out of date JSON objects in there and very hard to clean it up (although I'm no expert on JSON databases). Whereas SQL Server or PostgreSQL will support your changing schema very well throughout the whole project lifecycle. If you took over a 15-year-old project, would you rather it had been using Postgres or MongoDB that whole time? I know I'd prefer Postgres.

Post reply on HN