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

271–280 of 361 posts

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

#271

Post by neonsunset »

Cthulhu_ wrote: post #165
andai wrote: post #72

Earlier quoted context omitted.

I think this is explained by the fact that most business logic is dry, and most abstractions are interesting (until you get bored of them). So you wrap your actual code in fun code to make the job bearable.

This is the likely cause - most software development is dreadfully boring. But at some point in a developer's career, they will have touched the monolith and everything is full of stars, and instead of saying "I'll just hook you up with Magento", they're like "I will build you an event-driven microservices architecture in a custom made C# framework" and disappear for six months while they work late nights. (I wish I…

This is a happier ending, could have been "he finished the project, it turned out to be bad but now everyone has to use it".

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

#272

Post by tejtm »

bmicraft wrote: post #268
programmertote wrote: post #170

Very good article and I hope more people read it. Over my career of 15 years in software (data management), I have learned exactly that. One other thing that really helped me was something that I learned in my Theravada Buddhist upbringing: https://en.wikipedia.org/wiki/Kesamutti_Sutta > The Kesamutti Sutta states (Pali expression in parentheses):[5] Do not go upon what has been acquired by repeated hearing (anussava…

I have a hard time understanding what you mean by that, could you put it in simpler terms?

I have not seen the like nor studied the field but interpret it as internal over external knowing. personal experience over dogma of any stripe.

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

#273

Post by bsdpufferfish »

codingdave wrote: post #10

The one I have a hard time explaining well enough for new folks to get is: "It is not your job to write code." We use code as a tool to solve problems. Code is the mechanism of achieving our goals, not the goal in and of itself. If we are coding just for code's sake, we'll deliver the wrong results. We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop codi…

If this were true then solutions which required no code or a line of bash would be greeted with open arms.

Having software to sell to VCs is valuable. So yes, sometimes you're payed to write code.

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

#274

Post by Arainach »

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…

Building things the right way is a chance for people to learn tools and have fun. They're more impressive if your goal with a side project is for companies to look at your GitHub page.

Documentation is crucial. I have some fairly basic If I had containerized or, at a minimum, documented my setup steps, I would not have this problem.

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

#275

Post by bsdpufferfish »

codethief wrote: post #39
throwawaaarrgh wrote: post #12

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…

> It takes more time the first time, but it saves you time for the rest of your life It saves you time until the next version of the software gets released, or until the software is superceded by some other, shinier software.

Examples of things where this has worked for me: linux man pages, internet RFCs, ECMAScript spec, RDMS knowledge, math and science theory.

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

#276

Post by bmicraft »

tejtm wrote: post #272
bmicraft wrote: post #268

Earlier quoted context omitted.

I have a hard time understanding what you mean by that, could you put it in simpler terms?

I have not seen the like nor studied the field but interpret it as internal over external knowing. personal experience over dogma of any stripe.

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

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

#277

Post by skydhash »

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?

Anything that argues composition versus inheritance.

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

#278

Post by deepnet »

arp242 wrote: post #232
hardwaregeek wrote: post #222

Earlier quoted context omitted.

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. Ofte…

A balancing act between premature optimisation and technical debt.

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

#279

Post by goalonetwo »

DevAbdul wrote: post #265
tikhonj wrote: post #241

I'm such a fan of the debugging book[1] recommended in the article that I bought a bunch of copies to give out. I've given copies to friends, interns, data scientists and even executives, and everybody who's read it has appreciated it. The book has a small number of simple techniques that are great for solving problems in any large technical systems, so it's useful for almost everybody. It's also an easy and engaging…

that's great, do you still have any to give out? i don't usually read books but i am trying to take it up lol. this may be a good way to staryt

Did...did you just ask to get a free copy of the book?

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

#280

Post by eschneider »

EFreethought wrote: post #259
eschneider wrote: post #176

Earlier quoted context omitted.

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.

Your engineering notebook is a gift to future you.
Post reply on HN