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

171–180 of 361 posts

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

#171

Post by mightybyte »

roland35 wrote: post #153
mightybyte wrote: post #65

Earlier quoted context omitted.

> Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. I think there are times when this works and there are times when it will be a huge waste of time. In general, I think it's often very hard to tell which approach will be more efficient for you. As some sibling comments have mentioned, I think the way each person's individual brain works is a significant factor, bu…

I think a better approach is to be prepared to read the documentation a few times. For me, the first time I mostly glance through and see the entire scope of things. I normally need to work with things at least a little bit first to really be ready for a more indepth read later.

Oh yeah, memory is not perfect, and I think that very often you'll have to work with a concept multiple times to fully absorb it. I think we're saying very similar things.

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

#172

Post by i_s »

wsc981 wrote: post #138
sjducb wrote: post #98

Earlier quoted context omitted.

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.

Experience will make him see this. Experience did the same for me. It just takes some time.

Not if he does the type of job hopping typical in silicon valley. There are plenty of programmers who only stay at a job ~2 years, and never have to maintain a program over a long period. You could imagine such a person saying 'this worked well at my last job' and just keep introducing that kind of pattern to new companies, eventually with '20 years of experience'.

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

#173

Post by csallen »

wnolens wrote: post #164
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…

It often IS your job to write code though, so saying it's not is false. The code has to be the right code however. More generally, "you are solving business problems by applying software systems" That's how I describe this to junior folks. The goal is to make them focus on the business need, then they can sub critical thinking for MBAs/managers/PMs and do the right thing.

I don't mind the way codingdave put it, though. Sometimes it isn't your job to write code. In fact sometimes it's the opposite, and your job is to talk to people and explain to them why code doesn't need to be written.

Saying, "It's not your job to write code," might seem technically false, but in terms of getting the message across, I think it's striking and it works well. And getting the message across is the goal of communication, moreso than being 100% accurate.

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

#174

Post by eschneider »

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…

Reading the docs is a bit of a superpower, but life's too short to read everything cover-to-cover. What's worked better for me is to skim everything so I have some idea what's in there. Then, when I need to do "X", I know to check in the docs.

There's a balance to be found here that's likely different for everyone.

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

#175

Post by red_admiral »

lolinder wrote: post #158
sjducb wrote: post #98

Earlier quoted context omitted.

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.

> 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. Schools teach OOP as though adding new types of objects is the norm—like every type of software construct is actually a GUI widget in disguise and we're going to be adding new interoperable subclasses every other week, so we may as well get the infrastructure set…

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.

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

#176

Post by eschneider »

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.

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

#178

Post by nvarsj »

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…

Known as the KISS principle - Keep It Simple Stupid! Taught to me at university 20 years ago and still valid today.

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

#179

Post by austin-cheney »

hnfong wrote: post #102
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…

That's just wrong. 1. It's tautological that you can't make money without some form of sales. And it's tautological that if you're employee you cost money. Sure you can sell anything even a rock (see "Pet Rock"), but if the company is making money by selling software, then yes, the software makes money, otherwise your company would have its sales trying to sell rocks. 2. Games aren't for automation. They're for playe…

I have heard this all before. Its excuses to qualify low effort and mediocrity.

1. You are either actively generating money directly with your activity or you are contributing to something else that does but you are only doing a single thing at any given moment. Everything else is just pandering to justify your existence.

2. Games can be anything. You don't need a computer to play Sudoku. What separates video games from paper games is automation. Nobody has so far proven this wrong.

3. There are no tricks to practice. You are over coming challenges or spinning your wheels pretending to do so. That is why beginner experts are so common.

4. I guess you have never managed people or products.

> I'm surprised you have the audacity to write with such an absolute and authoritative tone.

I don't know you, but your words indicate I have been doing this work longer than you have been alive.

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

#180

Post by bluGill »

i_s wrote: post #172
wsc981 wrote: post #138

Earlier quoted context omitted.

Experience will make him see this. Experience did the same for me. It just takes some time.

Not if he does the type of job hopping typical in silicon valley. There are plenty of programmers who only stay at a job ~2 years, and never have to maintain a program over a long period. You could imagine such a person saying 'this worked well at my last job' and just keep introducing that kind of pattern to new companies, eventually with '20 years of experience'.

Of course really it is 6 months of experience repeated 40 times.
Post reply on HN