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

71–80 of 361 posts

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

#71

Post by dudul »

rcbdev wrote: post #11
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…

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

What is the difference between T and O?

Otherwise, yeah, the separation of domain specific code and "infrastructure" code is not novel at all.

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

#72

Post by andai »

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

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

#73

Post by hudell »

max_sendfeld wrote: post #62
loloquwowndueo wrote: post #50

Earlier quoted context omitted.

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

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 once worked on a project that would not even compile if a function had a param without a comment explaining the purpose of that param written with a specific format. Every comment was validated on compile time, you couldn't even comment code just to test something. Life was hell.

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

#74

Post by heelix »

Code reviews are so impactful. Learning how to have others look at your code and provide feedback, and you looking at others and provide feedback is huge. Mixing in the junior devs into the mix, where they feel safe to ask what is going on here or why, is the perfect comment canary. Taking the journey from 'ugly, but acceptable' to polished only comes from feedback and looking at other's code.

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

#75

Post by digitalsushi »

SillyUsername wrote: post #60

Lip service is an important skill when dealing with toxic individuals. If it's unimportant to the project, agree and move on. E.g. "your code is badly written, but we've a tight deadline so I'm letting it pass the review". If it was a real issue it wouldn't pass, this is usually just stylistic criticism (unless of course you've ignored good practices like SOLID etc ;) ) and indicative of a new senior who still can't…

The wink emoji is leaving me with the sensation I am out in the dark on something everyone else knows.

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

#76

Post by aleph_minus_one »

andai wrote: post #72
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 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.

> I think this is explained by the fact that most business logic is dry

I don't think that business logic is dry per se. The problem in my opinion rather is that in other parts of the software project, there is much more openness with respect to

- trying out new things in new ways

- making the code more elegant

- seeking abstractions

- ...

than in the business logic area.

Believe me: for the kind of business logic that I see at work, I could immediately see ways in which the (non-trivial) business logic could be made much more elegant by using clever mathematical ideas, but suggesting such ideas to other colleagues or the bosses is like talking to a brick wall.

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

#77

Post by hef19898 »

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.

Until the piece of software, or the system, in question is migrating, why would that matter?

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

#78

Post by billy99k »

itg wrote: post #22
billy99k wrote: post #18

A beautiful piece of code will always be outshined by something that works reliably and well.

When I was younger, I was obsessed with writing clever code to show off my programming knowledge. Over time I realized code that is easy to understand is much more valuable.

Same here. I've had really simple pieces of code in production for a decade with no issue.

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

#79

Post by aleph_minus_one »

gwervc wrote: post #29
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…

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

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

#80

Post by deely3 »

andai wrote: post #70
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…

True. On the other hand, don't try to make things simpler than they are. https://en.wikipedia.org/wiki/Waterbed_theory

I believe we have another name for this theory: leaky abstraction.
Post reply on HN