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

251–260 of 361 posts

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

#251

Post by saiya-jin »

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…

Ha, reading first part I got incorrect feeling you are actually proud of that approach, I thought 'geez not again this'. Luckily I read till the end :) I see it all the time, well most of the time these days. I call those folks smart juniors, and it literally doesn't matter if they have 1 or 20 years of experience.

Smart juniors know most if not all design patterns, read Mythical man month, and so on, and... is super eager to try new technologies, languages, frameworks and is literally running around with shiny new hammers desperately looking for anything resembling nails. And then they do some stupid decisions because they don't grok the power an optimized boring old DB can bring in.

Then comes a guy like me with 20 years of experience who has seen damn well how such projects end up 5-10 years down the line with half if not most of the original team gone, and cuts half of that crap out while keeping genuine added value, because we are not running kindergarten for devs who want to have fun at all costs all the time, we work for our business who pays us and expects good, stable and relatively quick deliveries, rest are details on our side. You can't be taken seriously by business if you behave like that, no matter how good your intentions are.

IMHE bleeding edge stuff and trying new things for the sake or avoiding boredom will consistently break more down the road than it will help fixing. We incorporate technologies which whole team can grok and be proficient in, not just some bored superstar. Build your CV elsewhere if you desperately want as many technology entries as possible, there are companies like that, and good for them. IMHO these folks anyway don't stay around for too long so full added value is even questionable, the grass is always greener elsewhere, at least till they get there. Could be boring for some, I call it seasoned (yet still endless amount of stuff to learn, but that's fine this won't change till my retirement).

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

#252

Post by tdeck »

SillyUsername wrote: post #60

Lip service is an important skill when dealing with toxic individuals. If it's unimportant to the project, agree and move on. E.g. "your code is badly written, but we've a tight deadline so I'm letting it pass the review". If it was a real issue it wouldn't pass, this is usually just stylistic criticism (unless of course you've ignored good practices like SOLID etc ;) ) and indicative of a new senior who still can't…

This is all fun and games until that person leaves the team or goes on vacation and some other project's tight deadline unexpectedly depends on understanding and fixing their poorly written code. People really discount the value of maintainable and understandable code until they've been in this position multiple times. Some people never learn it because they "fix" or modify things without understanding them, cause problems, and never reflect on how that happened.

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

#253

Post by yowlingcat »

sanderjd wrote: post #107
asimpletune wrote: post #82

Most advice about programming is about writing code, but we rarely ever consciously consider how to improve at reading code. One way to do that is to read more code. If you read really good code, and I mean really read it, like a book, and absorb it, then you will improve so much. This kind of improvement is the most impactful, because you also spend most of your time as a programmer reading code than writing new cod…

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…

> but being able to inspect the runtime state and get a sense for the data layout makes the experience so much richer.

That's kind of the problem and why it's a crutch. If you get better at reading code and reasoning about it without needing to use a debugger, it'll make you even more productive for when you actually do need to reach for it. The opposite is not true.

Being able to read code deeply in the setting of code review and point out structural issues without needing to execute that code or strap on a debugger is an enormous superpower, and one of the biggest skills that differentiates an early-career or mid-level engineer from a senior engineer in those that I've hired and managed. Over time, you do a lot more reading code than writing it if your codebase does its job successfully.

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

#254

Post by yowlingcat »

epgui wrote: 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…

You had me at numerical algorithms but I'm not sure I agree about functional programming and type theory. I used to like functional programming and type theory when I was younger and found it completely useless as I moved further along in my career.

I'll make a different suggestion: set theory (which builds intuition around relational data modeling) and distributed systems (which builds intuition around building scalable services and software architecture) are by far the most important theoretical foundations I've had to actually apply at scale. That's followed by data structures & algorithms and discrete mathematics (for the rare times I really do need to write some optimized inner loops).

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

#255

Post by juped »

Verdex wrote: post #240
juped wrote: post #225

Earlier quoted context omitted.

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

I'm sorry I replied; I thought you were confusedly misinterpreting the article by reading something about cargo-cult practices into it, but I now think you're just sort of emitting nonsense, and so it turned out to have been pointless.

edit: Actually, on reflection,

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

I consider this extremely aggressive, rude, and to bear no relation whatsoever to anything I typed. I don't understand what causes people to talk in bad faith like that.

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

#256

Post by epgui »

yowlingcat wrote: post #254
epgui wrote: 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…

You had me at numerical algorithms but I'm not sure I agree about functional programming and type theory. I used to like functional programming and type theory when I was younger and found it completely useless as I moved further along in my career. I'll make a different suggestion: set theory (which builds intuition around relational data modeling) and distributed systems (which builds intuition around building scal…

I don't want to be dismissive of set theory, because it has an extremely rich History and is still seen by most as the foundation of maths, but I believe there are some fundamental issues with it that make type theory a more appropriate foundational choice for general computation and programming language theory/design. There's a reason theorem assistants and proof languages are based on some version of type theory, rather than set theory.

To a first approximation, type theory and set theory play similar roles. There has been a lot of noise in recent years around replacing set theory with type theory as the foundation of maths, at least in the context of proof assistants and programming language theory.

But nonetheless, I agree that knowledge of set theory can't hurt (and practically speaking, you can't go far in your maths journey without it).

(I would also note that functional programming is a special case of relational programming.)

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

#257

Post by yen223 »

I_Am_Nous wrote: post #248
CM30 wrote: post #48

The first item is also why it's good to be skeptical about things you learn on video sharing services like YouTube too. If you sound credible and present your ideas in a professional way, people will take them seriously regardless of how flawed they might be. In a world where a fair few 'essayists' have been exposed for just reading Wikipedia articles and Reddit posts, it's definitely good to try and not associate ho…

This comment just made me consider LLMs as similar to the essayists you mentioned - they read the "right" answer somewhere on the internet/during training and then can regurgitate it in a way that makes sense without consideration of how true it is in practice.

Humans were hallucinating responses given a prompt long before LLMs were a thing. Just look at any comment thread.

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

#259

Post by EFreethought »

eschneider wrote: post #176
hiAndrewQuinn wrote: post #118

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.

It is amazing to me how many people do not write things down. It's like everybody wants to turn every job into a contest to see who can spin the most plates in their head.

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

#260

Post by tharne »

austin-cheney wrote: post #3

1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care. 2. The only purpose of software is automation. There is ultimately no other goal. When your peers start talking about frameworks, easiness, a bunch of tools, or other bull…

I don't know why you're getting so many down votes here. What you say is unpleasant but it's all true.
Post reply on HN