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

181–190 of 361 posts

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

#181

Post by bluGill »

EZ-E wrote: post #68
max_sendfeld wrote: post #62

Earlier quoted context omitted.

Absolutely! I'm grateful that I don't have to worry about code formatting any more. But I remember in one of my earliest job the company used style checkers as a pre-commit hook that rejected your commit if they found trailing whitespace. That was before code formatting was part of your IDE. (Especially for us front end devs who used Notepad++ rather than an IDE at the time). And notepad++ had no easy way of showing…

I have memories at my post grad school where any deviations from the expected code source formatting led to a -1 on the mark. On the first few projects it was not rare to see students getting marks well into two or three digits negatives.

Things that don't matter much. A nice consistent style is good to have, but it isn't something worth worrying about that much.

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

#182

Post by [deleted] »

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…

[deleted]

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

#183

Post by [deleted] »

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…

[deleted]

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

#184

Post by [deleted] »

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…

[deleted]

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

#185

Post by ChrisLTD »

Waterluvian wrote: post #16
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…

Most documentation is not worth reading. It’s reference material to be reviewed on-demand. The “introductory” section that gives an overview is often useful, though. But that leads to the other problem: knowledge is not intelligence. You’ve studied some Python module but never learned that you ought to use a different one instead.

Agreed. Documentation isn't a novel or essay that you need to read to the end for it all to make sense.

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

#186

Post by bloopernova »

red_admiral wrote: post #175
lolinder wrote: post #158

Earlier quoted context omitted.

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

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

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

#187

Post by ChrisLTD »

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…

> 1. Software does not make money. Not ever.

Software creates value that you can exchange or rent in exchange for money. All the big software companies know this, their software developers know this, and that's why those developers are well compensated.

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

#188

Post by tomcam » 

    At some point you will discover the Right Way to program, the thing which makes this all make sense, and you'll be convinced that the whole field would be so much better off if everybody else programmed the Right Way, too.
Item 14: Write an article debunking Right Way whether you actually believe it or not. Free notoriety == easy job offers

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

#189

Post by rcbdev »

mypetocean wrote: post #55
rcbdev wrote: post #11

Earlier quoted context omitted.

> 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 bullshit realize they have absolutely no idea what they are doing. This relates back to a course I took about software architecture. There's a guy called Johannes Siedersleben who separates software into three blood groups: A, T and 0. According to his m…

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.

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

#190

Post by Levitz »

hbn wrote: post #169
lolinder wrote: post #158

Earlier quoted context omitted.

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

At least where I went to school, the teaching staff in university CS departments seem to be overrun by guys who haven't actually worked in the software industry since the 90s when OOP was the hot new thing. My theory is they were there when they got to build a bunch of new systems with OOP, but didn't have to stick around for the nightmare of trying to maintain those codebases.

Where I live (Tenth largest city in Spain, so not that big) I'm pretty sure I can track misconceptions about OOP to whoever taught that class in the only university that had a CS degree around here some 20 years ago. I've seen like half a dozen teachers saying the same stuff explained in the same way and I'm sure none of them understand OOP at all. Only one was able to explain why getters and setters ought to be used besides saying "it's the standard" and to provide an actual, reasonable use case for it rather than the tired examples of "Yeah OOP is cool because since both cats and dogs eat and have 4 legs you can keep a lot of the code together rather than duplicate it".

Software development is reliant on self-learning, but still, some education can be outright damaging.

Post reply on HN