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

221–230 of 361 posts

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

#221

Post by sanderjd »

asimpletune wrote: post #144
sanderjd wrote: post #107

Earlier quoted context omitted.

Personally, I find it to be even better to step through code using a debugger. I think just reading down the text of a set of code files like a book has pretty limited utility. (Though better than not reading code at all!) It's like reading one of those choose-your-own-adventure books from start to end. Starting from an entry point and then digging into methods from there is better , but being able to inspect the run…

It's true that a debugger is easier to use, but it's limited in that you can't bring it all the places that you can bring your eyes. Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can.

> it's limited in that you can't bring it all the places that you can bring your eyes.

Why can't you?

> Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can.

This is definitely true, but that "mental debugger" is susceptible to incorrect assumptions about the runtime state at the point of execution. If this weren't the case, far fewer bugs would be written in the first place, as this mismatch about assumed vs. actual runtime state is where most bugs emerge.

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

#222

Post by hardwaregeek »

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…

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.

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

#223

Post by mypetocean »

rcbdev wrote: post #189
mypetocean wrote: post #55

Earlier quoted context omitted.

I'm struggling to find any information about this, either from Siedersleben or others, at least in English. Can you find any sources you can point me to? Or, can you explain further? I'm not clear, for example, what you mean by "technical code." And when you mention "the glue" are you talking mainly about APIs and protocols of all sorts (defined loosely)? This is where the edges of systems coincide and intended side…

Here's a slide deck from the Technical University of Dresden that goes into it a little in English language: https://st.inf.tu-dresden.de/files/teaching/ss11/swt/Vorlesu... If you are interested I can look for some older material, just shoot me an e-mail. Yes, I understood that type 0 does exactly what you describe - Covering the edges of type T and type A systems.

Thank you!

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

#224

Post by avgcorrection »

austin-cheney wrote: post #201
avgcorrection wrote: post #67

Earlier quoted context omitted.

What’s the point of even replying to comments like grandparent. Those points are phrased as person-specific dogmas, not advice.

What's the point of replying to any comments? Sometimes people claim to want advice and then cry and whine if its not reaffirming what they already believe. Sometimes people just want to feel smart more than be smart. There was an actual Standard study on this and the difference in output was striking.

> Sometimes people just want to feel smart more than be smart.

Yeah.

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

#225

Post by juped »

Verdex wrote: post #162
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…

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 somewhat cringey one-sided conversations.

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

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

#226

Post by staunton »

hardwaregeek wrote: post #222
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…

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.

What's even more tricky is that almost all (successful) projects start out small and it takes immense discipline and foresight to catch up on "maturity" at the right stage in the project.

Chances are, you'll get bogged down with these "maturity" things from the start and never build anything successful, or you'll go fast (perhaps catching a glimpse of success) until nobody can keep working on the project once those "maturity" things start to matter.

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

#227

Post by durumu »

rTX5CMRXIfFG wrote: post #95
mlinhares wrote: post #89

Earlier quoted context omitted.

That completely removes a whole slew of useless comments when people are reviewing code, it's such an amazing win, every single language should have it's styleguide published and a tool that forces it without any options.

The key to style guides is to not have so many rules. Agree on the number of spacing and where to put braces. Past that, it’s obsessing on form over function, which you cannot control simply by virtue of having many people work together on the same codebase. You should worry more about how things are named, the number of abstractions used, and whether the code has any comments explaining the writer’s intent.

I think you can have as many rules as you want as long as there's something like black or rustfmt, just a script you run that auto-formats your code. You never have to worry about the rules because there is no configuration thus nothing to argue about. Sometimes your code gets formatted weird but who cares, just do your work.

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

#229

Post by staunton »

ilrwbwrkhv wrote: post #220
sevagh wrote: post #161

Despite reading essays of other devs telling you how you should dev, have faith in yourself. Over time you'll develop your own proclivities, instincts, etc., and end up writing your own essays to the next generation. People writing essays are not writing it from some impossible point of knowledge or privilege. They're just you in the future.

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.

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

#230

Post by asimpletune »

sanderjd wrote: post #221
asimpletune wrote: post #144

Earlier quoted context omitted.

It's true that a debugger is easier to use, but it's limited in that you can't bring it all the places that you can bring your eyes. Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can.

> it's limited in that you can't bring it all the places that you can bring your eyes. Why can't you? > Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can. This is definitely true, but that "mental debugger" is susceptible to incorrect assumptions about the runtime state at the point of execution. If this weren't the case, far fewer bugs would be written in t…

> Why can't you?

Honestly not trying to be rude, but that would be because of how eyes work. The moment you do anything that goes beyond looking at code, is the moment you've met that limitation I described above.

The other part you brought is totally valid, it's just all about tradeoffs. If you prefer using a debugger in situations where I would read the code, then more power to you.

Actually, it's funny, because the original article talked about the One True Way (or whatever his exact wording was), and how we all go through a phase where we discover that for ourselves. I think this thread in a way has been an expression of that concept. Anyways, thanks for your thoughts, I'll remember this next time I'm struggling with the ol' brain debugger ;-)

Post reply on HN