Live data from Hacker News

Advice for new software devs who've read all those other advice essays

buttondown.email

231–240 of 361 posts

Re: Advice for new software devs who've read all those other advice essays

#231
post #98

My best bit of advice for any programmer at any level: "Don't make stuff more complicated than it has to be!" Software is complicated. Large, feature rich software is even more complicated. That's hard enough to manage as it is. The last thing you want to do is to throw a million of abstraction layers, frameworks, libraries, precompilers, transpilers, build steps, validation hooks, style checkers etc. into the mix. E…

This is so hard in practice. I just had a junior dev rewrite some of my code so that: a builder calls a constructor which instantiates a builder factory which builds a builder then that second builder creates the object. This whole system only builds one type of object. He thinks that his solution is better because it’s more extensible. I can’t make him see why it’s bad.

There’s another heuristic that he broke.

If you can easily read and understand some code, then it’s good code and you should leave it alone.

Re: Advice for new software devs who've read all those other advice essays

#232

I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC project with a discord bot and some rust code that only we will be running for now, they insisted on complete documentation, separate VMs for QA and "prod", systemd deployments, a templating system for a few strings, an ORM layer for four (4) SQL queries.. this is a…

What's tricky is that in a different context, those people would be excellent contributors. Like in a mature product, who wouldn't love a developer who works on documentation, builds out a staging environment, and makes the codebase more scalable? But it just doesn't make sense when you haven't shipped anything yet.

I disagree; there is almost never a "right way" and pragmatism and reality-based outlook always trumps "right way"-ism. This is especially true for mature products, which almost always have some history behind them: shifting requirements, "seemed like a good idea at the time, but with the experience we have now it probably wasn't", shifting trends in the industry, constraints in terms of dev time or budget, etc. Often this is sub-optimal, but it works well enough, so it's fine.

And never mind that opinions on "the right way" differ. Previous poster mentioned ORM: some people think "the right way" is to never use an ORM, some think "the right way" is to always use it.

Right Way Guys will insist that your codebase will always needs to be scalable, whether it makes sense or not. You've got a B2B product that will only have a few hundred customers? Doesn't matter. It needs to be scalable. It's the Right Way.

Right Way Guys will insist that this kind of ugly module that hardly sees any changes and is basically bug-free will need to be rewritten to The Right Way once they add a minor trivial feature. It doesn't mater it works fine. It's The Right Way.

Right Way Guys make things worse. Always.

In the case of juniors: they can be taught. They're just juniors. That's okay.

In the case of seniors: good luck... I'd argue these are among the worst people you can hire.

And you really don't need to be a Right Way Guy to write a few docs or set up a staging environment.

Re: Advice for new software devs who've read all those other advice essays

#234
post #147

My two cents as a professional engineer coming from biochem: While computer science / programming is very young and light on the science side, it has solid foundations in mathematics, and the mathematics that are true today will always be true. So I argue (without providing any proof) that it is almost certainly a good idea to “follow the maths” in your learning journey. I think this is as true for numerical algorith…

Arguably, biochem also has "solid foundations" in physics. Would you recommend someone in your field to "follow the physics" in their journey?

Re: Advice for new software devs who've read all those other advice essays

#235

My 1¢ of advice: State is the enemy. Minimize state wherever you can. This includes state as in your code, state as in how many things you need to hold in short term memory to do your job, state as in how many project specific details you need to remember, all of it. State is the enemy. If you can derive it from first principles, always try to do so.

I cannot stress enough how much you can reduce "how many things you need to hold in short term memory to do your job" by just keeping a notebook (or file, or wiki, or whatever works for you) and writing things down.

I've been writing everything down in a notes app recently and I love it. If I think of a good Christmas gift for my brother in July, it goes in the app. If someone recommends an interesting-sounding book, it goes in the app. If an app at work has a specific or convoluted build process, it goes in the app.

As someone who spent his entire childhood getting in trouble for forgetting things, it's been life-changing. Computers remember things so much better than my dumb brain.

Re: Advice for new software devs who've read all those other advice essays

#236

I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC project with a discord bot and some rust code that only we will be running for now, they insisted on complete documentation, separate VMs for QA and "prod", systemd deployments, a templating system for a few strings, an ORM layer for four (4) SQL queries.. this is a…

[deleted]

Re: Advice for new software devs who've read all those other advice essays

#237

Earlier quoted context omitted.

Yes most self taught programmers actually have instinctively a good way of programming if they learn it through hacking. It's a direct and straightforward way of programming not ruined by object oriented thinking or any of the solid principles bullcrap. What does the computer need to do? That is a powerful mindset to get into and building on.

This is true for people who have worked on big projects or had to maintain working software over time. However, I dare you to look at the kinds of code that "Jupyter notebook only needs to run once"-scientists write... Many of them have spent a lot of time hacking and can hack together something that runs and works on one input incredibly quickly. In a business, however, that's almost never what you want.

I still think it's better than this scientist reading a bunch of books about software design patterns and trying to create something they don't really understand.

Maybe like a "bad hacked-together first instinct" is easier to correct and build on than "misusing or mangling an advanced dev paradigm that you're not even good to enough to judge whether is appropriate for this usecase."

Re: Advice for new software devs who've read all those other advice essays

#238

I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC project with a discord bot and some rust code that only we will be running for now, they insisted on complete documentation, separate VMs for QA and "prod", systemd deployments, a templating system for a few strings, an ORM layer for four (4) SQL queries.. this is a…

The situation you described doesn’t sound like “Right Way Guys”. It actually sounds like “Bikeshedding” [1]. This means giving a disproportionate amount of attention or importance to the trivial details while neglecting or giving less attention to the significant issues. Imagine a committee commissioned to approve plans for a Nuclear Power Plant. But the committee spends all their time discussing the color of the bik…

It sounds more like a case of "Use the tools you know". Like, the stated ORM toolkit may be complete overkill, but if they don't have experience doing object relational mapping by hand that's one more thing to learn to get the job done. The asserted goal is to deliver something for a group of people to use, so it's not a hobby of trying to find as many new lessons to learn as possible.

Re: Advice for new software devs who've read all those other advice essays

#239

I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC project with a discord bot and some rust code that only we will be running for now, they insisted on complete documentation, separate VMs for QA and "prod", systemd deployments, a templating system for a few strings, an ORM layer for four (4) SQL queries.. this is a…

What's tricky is that in a different context, those people would be excellent contributors. Like in a mature product, who wouldn't love a developer who works on documentation, builds out a staging environment, and makes the codebase more scalable? But it just doesn't make sense when you haven't shipped anything yet.

Absolutely and this is basically the entirety of the debate around best practices boiled down to a single word - context. There is no meaningful way to make decisions about software without the higher level context.

To be fair to them, maybe they just care more about learning new stuff instead of shipping - so in their context all of the stuff they do makes sense. For me i know how to write good code so am no longer interested in doing it, except when it's necessary :) First you must learn how to write great code, then you learn when to write simple code instead.

Re: Advice for new software devs who've read all those other advice essays

#240
post #225
post #162

Earlier quoted context omitted.

In the movie Primer, a group of four friends start a small computer business on the side. Two of them later invent a sci-fi box and then dramatic shenanigans ensue. Something I missed at first [1] was the significance of an event that happens early in the movie. They need to buy a $50 router because their existing one is broken. They have an impromptu meeting where one of the characters gives suggestions on how they…

You sound like you saw the phrase "Right Way Guy", felt it sounded pejorative (it's more gently poking fun at a common thing), and decided it must mean That Type Of Guy I Don't Like. The article is referring to the foibles common to someone who's just had their first experience with not being a cargo cultist, i.e., getting overexcited about their first taste of real understanding. Mostly these foibles involve having…

| You sound like you saw the phrase "Right Way Guy", felt it sounded pejorative

I'm not sure what it sounded like, but I'm pretty sure I didn't feel that way.

| decided it must mean That Type Of Guy I Don't Like.

... huh. That escalated kind of quickly.

| I have no idea how the Primer anecdote relates to anything at all.

Well, I had hoped the paragraph following the anecdote explained that, but I guess I can't win them all can I.

EDIT:

What I find super interesting is that my original comment was that there are some interesting success and failure modes associated with "Right Way Guy".

And I follow it up with a musing that social pressure to conform is a way for the social hivemind to protect adherents via statistics.

THEN one of the comments looks suspiciously like it's chiding my social disharmonious actions.

Very cool.

Post reply on HN