Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

buttondown.email

Post reply on HN
Print view View original

331–340 of 361 posts

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

#331

Post by Rayhem »

jorisd wrote: post #204
zaptheimpaler wrote: post #134

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…

I'd argue that they're not completely wrong in doing those things. Many of those things you list really don't take too much time to do, like writing systemd units or using an ORM. But they really help when anyone needs to take a look at things in the future or someone else wants to contribute as well later on. Besides, they're easier to do when things are still fresh in the mind, and these kinds of chores rarely get…

> This being a hobby project may also be a reason why the other programmers want to do things right; they may get satisfaction and learn new things by doing it this way!

Exactly my thought. Hobby projects are great opportunities to practice those skills since, if you don't, they don't manifest.

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

#332

Post by corethree »

hef19898 wrote: post #326
corethree wrote: post #324

Earlier quoted context omitted.

>All the docs, if taking literally, would mean all the docs for everything you interact with in your life. Obviously impossible, isn't it? No but even if C++ is the central language of my stack your comment can reasonably be interpreted as suggesting me to read the entire C++ spec. That's not an outlandish interpretation given how many people interpreted what you said this way. >So, ehy exactly do you think that read…

Man, you just did. If your job is C++ development, yes, I absolutely expect you to be familiar with the full C++ documentation and master the parts relevant for your specific usage of it. If C++ is only part of your stack, replace familiarity with C++ specifically with familiarity of your whole stack. I do the same with everyone, actually, myself included. Plumbers have to know the specs of their tools, materials and…

>Man, you just did.

I just did what. Be clear with Your sentences.

>If your job is C++ development, yes, I absolutely expect you to be familiar with the full C++ documentation and master the parts relevant for your specific usage of it.

So you were unclear. You want someone to master only parts of of the stack but read the full spec. This is completely inconsistent with what you said earlier. You are moving the goal posts. Still it doesn't Make sense to read 1800 pages of the C++20 spec.

Do you read the English dictionary because you use English?

>And the easiest way to get that familiarity is reading the damn documenents. If you cannot be bothered with that, well, let me say I am happy I don't have to work with you.

Then you would be happy to not have to work with the overwhelming majority of programmers on the face of the earth. You being in the minority would make you the problem. Not others. Programmers in general read the spec and docs relevant to the task at hand. They do not generally read the full formal specifications and documentation of what they need.

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

#333

Post by x86x87 »

smolder wrote: post #325
x86x87 wrote: post #308

Earlier quoted context omitted.

Sort of. The way i'm thinkjng about it is that you do write the tests and the final output would resemble what you woukd get with TDD, it's just that you put a little more thought into the structure of your software before starting to write the tests

I get what you mean. I was stretching the idea a lot. What I described might be more aptly called "iterative development", and is really basic. There is an even further extreme than that from TDD, though. It's of course possible to write a program without even ephemeral, manual tests, just intuiting how it will work as you build it instead of checking and iterating... but anyone with experience knows better than to t…

Yes. I have a name for your method also: debugger free development (DFD!). While controversial with some my theory is that if you need to attach a debugger to understand what is going on with a live program you've already lost. Logging (ie printf++) and metrics should allow you to understand what happens at all times. You may need to adjust the log level but that's about it.

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

#334

Post by x86x87 »

Izkata wrote: post #321
x86x87 wrote: post #309

Earlier quoted context omitted.

Yeah. To me it's about not being a zealot about it. If I can get 80% of the value with 20% of the effortby tweaking it I think that makes sense.

"Just a TAD is all you need." https://www.merriam-webster.com/dictionary/tad

Could have been worse. Could have gotten: https://www.urbandictionary.com/define.php?term=Tad

Hmm... Wait. Is that worse?

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

#335

Post by Retric »

corethree wrote: post #323
Retric wrote: post #317

Earlier quoted context omitted.

> A more complex program has more possible origins for the bug. So you need to make more hypothesises to check and verify the bug. This isn’t a discussion about all bugs but the class of bugs created from dealing with clever code. Very difficult bugs may be fairly quick to solve in comparison to simple bugs that require some long process to replicate. Time to solve really doesn’t map well to difficulty. >Clearly you…

>This isn’t a discussion about all bugs but the class of bugs created from dealing with clever code. Very difficult bugs may be fairly quick to solve in comparison to simple bugs that require some long process to replicate. Time to solve really doesn’t map well to difficulty. It does. A bug solved in seconds is usually considered less difficult than one solved in weeks. It maps easily. >False, you clearly missed me s…

> It does. A bug solved in seconds is usually considered less difficult than one solved in weeks. It maps easily.

Luck wildly impacts how long ‘difficult’ problems take to solve. I’ve solved bugs in seconds someone literally spent weeks and asked multiple people to help them solve and I’ve had the same thing happen to me.

Thus actual solve time and absolute difficulty are almost orthogonal.

> The quote was suggesting absolutism one limitation. By showing the existence of an equivalency I've shown the quote is not absolute. Therefore the quote is not intelligent. Therefore your statement is false and nonsensical.

Again no, it was saying one limitation becomes significant in a specific situation. Often these bugs may not actually take long to fix, but you’ll suffer when dealing with them. Even strait forward off by one errors can be annoying when you have to reason about really tricky bits of code.

That feeling where you spend an hour staring at an IDE with absolutely no clue what’s going on sucks even if it doesn’t take that long to actually fix the issue.

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

#336

Post by rewmie »

zaptheimpaler wrote: post #134

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…

[dead]

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

#337

Post by corethree »

Retric wrote: post #335
corethree wrote: post #323

Earlier quoted context omitted.

>This isn’t a discussion about all bugs but the class of bugs created from dealing with clever code. Very difficult bugs may be fairly quick to solve in comparison to simple bugs that require some long process to replicate. Time to solve really doesn’t map well to difficulty. It does. A bug solved in seconds is usually considered less difficult than one solved in weeks. It maps easily. >False, you clearly missed me s…

> It does. A bug solved in seconds is usually considered less difficult than one solved in weeks. It maps easily. Luck wildly impacts how long ‘difficult’ problems take to solve. I’ve solved bugs in seconds someone literally spent weeks and asked multiple people to help them solve and I’ve had the same thing happen to me. Thus actual solve time and absolute difficulty are almost orthogonal. > The quote was suggesting…

>Thus actual solve time and absolute difficulty are almost orthogonal.

No it just means luck is another factor. You have luck, intelligence and length of time. Time is correlated with possibility right? You can get lucky and guess the probability on the get go.

Either way you introduced a third possibility here which goes further to illustrate that this quotation is inaccurate and not intelligent.

>Again no, it was saying one limitation becomes significant in a specific situation. Often these bugs may not actually take long to fix, but you’ll suffer when dealing with them. Even strait forward off by one errors can be annoying when you have to reason about really tricky bits of code.

False. You are absolutely wrong. The statement was made without qualification to a specific situation. Therefore it is made in the context of the universal situation meaning absolutist. Sinking with the ship again.

>That feeling where you spend an hour staring at an IDE with absolutely no clue what’s going on sucks even if it doesn’t take that long to actually fix the issue.

So? This doesn't have anything to do with the topic at hand. The topic at hand is the quotation is wrong. How you feel during debugging is off topic.

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

#338

Post by camgunz »

sjducb wrote: post #98
wolframhempel wrote: post #31

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.

What I do is make them test everything their code might do. "Oh you built a generic builder builder builder huh? I need at least 80% coverage for anything the builders might build." The code shrinkage you can achieve is remarkable.

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

#339

Post by Retric »

corethree wrote: post #337
Retric wrote: post #335

Earlier quoted context omitted.

> It does. A bug solved in seconds is usually considered less difficult than one solved in weeks. It maps easily. Luck wildly impacts how long ‘difficult’ problems take to solve. I’ve solved bugs in seconds someone literally spent weeks and asked multiple people to help them solve and I’ve had the same thing happen to me. Thus actual solve time and absolute difficulty are almost orthogonal. > The quote was suggesting…

>Thus actual solve time and absolute difficulty are almost orthogonal. No it just means luck is another factor. You have luck, intelligence and length of time. Time is correlated with possibility right? You can get lucky and guess the probability on the get go. Either way you introduced a third possibility here which goes further to illustrate that this quotation is inaccurate and not intelligent. >Again no, it was s…

> The statement was made without qualification to a specific situation.

The overall stamens includes an “if you” which is a qualifier. So you seemingly don’t understand what those words mean and objectively wrong here.

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

#340

Post by epgui »

staunton wrote: post #296
epgui wrote: post #247

Earlier quoted context omitted.

Yes. Also follow the chemistry, and follow the maths. Any answer other than "yes" falls squarely in the anti-intellectual category... But of course all the usual pragmatism applies unless you are a point particle having indefinite lifespan.

> the usual pragmatism applies That sounds like by "follow" you don't mean "study a lot"... What do you mean then?

I think you're putting words in my mouth. I meant everything I wrote literally and there was no subtext between the lines.
Post reply on HN