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

321–330 of 361 posts

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

#321

Post by Izkata »

x86x87 wrote: post #309
jtr1 wrote: post #262

Earlier quoted context omitted.

TAD has just about the right sound, too. I've found it's a useful tool for very specific tasks. I found TDD perfect for writing functions or modules with a wide variety of possible state-dependent outputs. While not strictly TDD, I've also found it helpful to sit down and frame a list of desired behaviors for a piece of code as expectations first, then go through the process of writing the code and tests in tandem. I…

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

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

#322

Post by devwastaken »

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…

The reason they're doing that is because theyre going to be tested on that knowledge when finding employment. It's harder than ever to be full stack, but there's plenty of competition.

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

#323

Post by corethree »

Retric wrote: post #317
corethree wrote: post #315

Earlier quoted context omitted.

Wrong. A more complex program has more possible origins for the bug. So you need to make more hypothesises to check and verify the bug. Time and intelligence are both a factor here. Sometimes one more than the other. Clearly you don't think bugs are all solved in seconds and limited only based off of intelligence. A harder bug often needs more time to solve. This is common sense. You're just sinking with the ship now…

> 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 stating it intelligence was “one” limitation not the only limitation. Poor tooling can be a massive pain among many other things. Again though this is talking about debugging a very specific kind of unnecessarily complex code.

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.

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

#324

Post by corethree »

hef19898 wrote: post #320
corethree wrote: post #316

Earlier quoted context omitted.

>your specific use case, I cannot help you with that I don't need your help. You need it. I'm helping you realize your statement is wrong. First you make a statement saying one should read all the docs. Now you say devs should read the relevant docs. Devs do the later anyway. Your argument just evolved into the point you're arguing against. Clearly you didn't mean to do that. You just meant to read more docs then you…

All the docs, if taking literally, would mean all the docs for everything you interact with in your life. Obviously impossible, isn't it? Not every statement has to be taken literally, it seems so that on HN, more often than not, one has to be incredibly specific in ones comments. That is like talking to genie or something, really frustrating. I kind of assumed, and without going through all my comments I think I als…

>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 reading jib and task relevant documentation is not necessary, or even the comoletely wrong approach?

Did I say this? No.

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

#325

Post by smolder »

x86x87 wrote: post #308
smolder wrote: post #245

Earlier quoted context omitted.

In a sense, even the way I use print statements and other outputs to validate the behavior of a non-TDD program at each iteration could be called test assisted or something. It's just in that case, the test is the whole program at each iteration, rather than something that is fully automated and decoupled from its normal operation. Each test then expands in scope with the scope of the program, not being preserved exc…

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 try that beyond trivial programs.

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

#326

Post by hef19898 »

corethree wrote: post #324
hef19898 wrote: post #320

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? Not every statement has to be taken literally, it seems so that on HN, more often than not, one has to be incredibly specific in ones comments. That is like talking to genie or something, really frustrating. I kind of assumed, and without going through all my comments I think I als…

>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 the regulations as well as principles of installation. And they do, the good ones at least.

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.

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

#327

Post by bmicraft »

roncesvalles wrote: post #302
bmicraft wrote: post #276

Earlier quoted context omitted.

I thought that might be a possible interpretation, but then personal experience is just an anecdote and also not a thing when you're just starting out

Most people underestimate how valuable personal anecdotes are compared to sampling/survey data. Has it ever happened to you that a restaurant or other experience has thousands of rave reviews online (or even among your friends) but when you go there it's shockingly underwhelming? That happens a lot. Your personal anecdote is almost always more valuable in such cases because of several reasons including recency, authe…

Food is a very subjective thing, online reviews generally are often intentionally or unintentionally distorted, and quality/staff at those places changes too over time. Considering all these factors, that does not make this specific scenario a great more general example

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

#328

Post by red_admiral »

bloopernova wrote: post #186
red_admiral wrote: post #175

Earlier quoted context omitted.

Entities in game systems tend to behave like that too when the whole thing is under development - but then (a) arguably a monster chasing you around is just a special GUI widget with extra behaviour and hit points; and (b) when things get really complex it doesn't hurt to switch from OOP to ECS for games.

I don't have a lot of knowledge on ECS, are there any good articles out there that compare it to OOP?

This tutorial: http://web.archive.org/web/20120314005352/https://www.richar... although now defunct, makes a good start. Around halfway through there's a heading "Abandoning good object-oriented practice" which gets to the point you're asking about.

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

#329

Post by thedanbob »

apantel wrote: post #264
thedanbob wrote: post #23

> 8. Take walks. I'm fortunate enough to have an office overlooking a small pond. When I'm frustrated I go to my window and stare at the pond for a while. When I'm really frustrated I walk down to the pond and stare at it for a while. I also walk to lunch as often as I can (i.e. when it's not freezing or boiling outside). Highly recommend.

When you’re really REALLY frustrated, do you go into the pond and stare at it from the inside?

I can't say the thought hasn't occurred to me ;)

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

#330

Post by [deleted] »

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…

[deleted]
Post reply on HN