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

101–110 of 361 posts

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

#101

Post by zauguin »

mlinhares wrote: post #89
loloquwowndueo wrote: post #50

Earlier quoted context omitted.

I think an automatic code formatted actually makes one’s job easier, not more complicated.

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.

This often leads to extremely annoying codebase because languages trying to enforce styleguides without proper options just leads to inconsistency once any code in another language leads to the codebase.

Just have an options file which is checked in with the code and enforce whatever is set in there works much better. You still avoids all the useless discussions about formatting while also allowing to set sensible settings which are consistent with surrounding technology.

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

#102

Post by hnfong »

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 players to have fun. People have also written software as some form of art. You are not in a position to dismiss them as devoid of purpose.

3. There's more to "practice" to become good at software. There are specific tricks, approaches and attitudes to become good at it.

4. "risk management, cost analysis"... What are you talking about? There are people who write great software who don't deal with this crap (because they can offload this to somebody else). Heck even great companies sometimes do this (by offloading risk to investors). You're delusional if you think "risk management, cost analysis" is needed to be excellent "with absolutely everything else". Was Michael Jordan a master at cost analysis? Was Einstein an expert in risk management?

I'm surprised you have the audacity to write with such an absolute and authoritative tone. If anything, being good at software is to recognize edge cases and situations outside of the stereotypical scenario. It seems you've done the opposite and generalized your personal experiences into some kind of absolute truth.

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

#103

Post by raincole »

cpursley wrote: post #26
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…

> encyclopedic knowledge This only works for people with excellent long term memory. I constantly need to look things up in docs and even my own readmes.

About once in a month, I google something and find a StackOverflow question about the exact thing... which is asked by myself years ago.

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

#104

Post by raincole »

aleph_minus_one wrote: post #79
gwervc wrote: post #29

Earlier quoted context omitted.

Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc.

> Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc. This is rather an argument against C#, .NET framework, and Java. :-)

Good luck telling your boss/client that you don't write C#/Java because "the document is too long to read cover to cover."

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

#105

Post by ebiester »

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 your trailer to Mojo in a production environment.)

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

#106

Post by Bjartr »

throwawaaarrgh wrote: post #14
wruza wrote: post #7

Earlier quoted context omitted.

There is. You just can’t be excellent at parts that are constantly changing. Avoid those who bumped more than 3 versions in a decade, they aren’t confident in what they want.

Excellence is a trap. It leads to hubris. An excellent programmer can be really annoying, and excellent code is unnecessary. Instead of excellence, strive for "working code", collaboration, quality, velocity, improvement, shipping the right thing at the right time. Use debt wisely and move forward.

Excellence is a trap ... Proceeds to describe characteristics of an excellent developer

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

#107

Post by sanderjd »

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 runtime state and get a sense for the data layout makes the experience so much richer.

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

#108

Post by liampulles »

If you think that you've potentially fucked up big, seek help and own up immediately. Phone the person if they are not responding to messages.

Everyone expects juniors to make mistakes, you'll earn respect if people know they don't have to worry about you delaying or trying to hide issues.

Also, ask questions! Again everyone expects juniors to lack knowledge, and yet something about our schooling makes us embarrassed to ask.

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

#109

Post by baq »

TheHumanist wrote: post #49
gwervc wrote: post #29

Earlier quoted context omitted.

Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc.

Advice like that above is honestly terrible for newer developers, I believe. It feels insurmountable for many people, myself included. I simply don't have the brain capacity to: A. Read an entire language's docs front to back. As you mentioned, maybe if it is some small, silly thing but for something like Python, Java, JS, etc... no fucking way. My brain would constantly glaze my eyes over. There is so much. B. Retai…

My usual recommendation is to read the table of contents of the manual.

This is especially important for any database you might be using. Language... meh, maybe...? But the DB - please do.

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

#110

Post by [deleted] »

loloquwowndueo wrote: post #50
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…

I think an automatic code formatted actually makes one’s job easier, not more complicated.

[deleted]
Post reply on HN