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

111–120 of 361 posts

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

#111

Post by AnimalMuppet »

sjducb wrote: post #98
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…

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.

Make him maintain one that someone else wrote.

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

#112

Post by corethree »

brudgers wrote: post #81
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…

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan

Not an intelligent quotation. Hardness can be defined as how long it takes to accomplish a task. Following this definition everything can be debugged. It just takes twice as long.

This definition isn't absolute and neither is the definition by Brian. The truth is much more complicated.

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

#113

Post by kevindamm »

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.

Yes, but, on the other hand having a detailed style guide does make for short and simple debate during code review.

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

#114

Post by williamcotton »

ebiester wrote: post #105
williamcotton wrote: post #84

The upshot of this is that a lot of the X you hear about have very small Y and will never get wide adoption, but it won't seem that way from how you hear about it. That's why it makes sense to be conservative. This kind of digital signal amplification is distorting any and all knowledge about our world! These will be known as the Digital Dark Ages to our great grandchildren. What, you say, with access to all this inf…

There are many ways to use the word conservative. In this case, I think he is talking about conservative in the technologies you choose to use in the critical path. You absolutely should learn languages (as but one example) outside the TIOBE top 20. You should be very selective in where you choose to implement them. (with exceptions, of course - TypeScript is likely a pretty safe choice now, but maybe wait to hitch y…

But he’s also situating this discussion in the context of how information about X reaches Y in the first place. I’ve expanded not the context but the content by replacing programming language/framework/tool marketing with every information transaction on the internet.

Again, all of this is situated in a world of upvotes, advertising, global politics, venture capital, smartphones in every pocket, etc. The systemic effects are similar across a broad range of knowledge dissemination.

It’s time to hit the brakes.

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

#115

Post by plagiarist »

That debugging book is addressing something I've been thinking about recently: how does one help programmers advance their skills from a fresh entry point? I am convinced part of that is understanding how to use tools to inspect and solve problems. I'd probably buy that book based on this recommendation alone, but it is also something I was hoping to find.

I believe other key parts of helping people advance are around teaching them how to read code and how to recognize/reduce unnecessary complexity, I don't really have solutions for that as of yet. There is plenty of text on DRY, SOLID, Law of Demeter, and so on, but I don't know how to move that knowledge from academic things one knows into tools for practical use.

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

#116

Post by corethree »

hef19898 wrote: post #27
jstummbillig wrote: post #25

Earlier quoted context omitted.

Well, at least it's obvious where this is coming from. > You will look like a genius because you'll have an encyclopedic knowledge > You can learn esoteric knowledge about programming – and you will pay an incredibly steep price for it. If you want to be effective, stay clear of this one. Systems are going to be increasingly complex to the point where it's absolutely impossible for any one person to understand it all…

How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input f…

You should try this for C++ and Linux. Read the spec of each cover to cover.

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

#117

Post by havkom »

Great article and advice!!

> Eventually the honeymoon will end and you'll learn that programming is frustrating and messy regardless of which Right Way people use, and that you can also make great software without doing it the Right Way. Over time you'll learn fifty other Right Ways and learn to mix and match them to the problem at hand.

My impression though from last few years is that nowadays many developers get stuck being Right Way Guys and are unable to broaden their knowledge and views. This is sad and I do not know the cause of that if it is true. My speculation is that it has something to do with too short attention spans nowadays to efficiently expand knowledge in combination with being to comfortable in their current positions. Or maybe something with too much incentives to only learn specific frameworks and not basic knowledge of how things work “under the hood”.

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

#118

Post by hiAndrewQuinn »

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.

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

#119

Post by jvanderbot »

sjducb wrote: post #98
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…

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.

Premature generalization is the root of all evil nowadays.

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

#120

Post by zaptheimpaler »

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.

This is broadly what reasonable people believe, but there are crazy people who WILL obsess over form and nitpick your whitespaces or other trivial bullshit if given a chance. An authoritative style guide shuts down many such detours.
Post reply on HN