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

31–40 of 361 posts

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

#31

Post by wolframhempel »

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. Each of them makes your project more complex by a certain factor. And not only do they add up - they multiply!

Now, that doesn't mean that you need to built everything bare bones without the help of any third party software - just make sensible choices. Unfortunately, developers are way too prone to add another shiny thing to the mix.

So here's how you decide if you really need something:

At first: You don't - continue as is.

Then: If the problem persists and the suggested solution keeps coming up, still refuse, but investigate the solution.

At last: If the problem persists, the solution seems well suited to address it and it keeps coming up - accept that you have the problem and adopt the solution.

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

#32

Post by wruza »

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 saves you time for the rest of your life

Also saves you from fragmented knowledge. When it is good enough, it will remain half-assed till your end.

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

#33

Post by marginalia_nu »

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.

In this episode of How It's Made: Mediocrity.

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

#34

Post by ensocode »

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…

Work fragmented my brain so much as I am into so many things at one time and I am sure a lot of us feel like this. This comment makes me think on how to actually do that and how much time and efficiency this would cost. Nevertheless there is truth in it. How do you manage this?

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

#35

Post by hef19898 »

aleph_minus_one wrote: post #24
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…

> We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out. I am not sure whether this is a good advice - for a quite subtle reason: I do claim that most code (including most of the code that is written "for code's sake") does solve a problem, and most programmers at least unconsciously are aware of this fact - and that's why they wr…

Assuming tue devs don't live in a vaccum, it is other people eho define the problems to be solved. Doing so consiously, and not unconsiously by chance, is what engineering does. Producing something to produce something, while ignoring the problems you where handed to solve (doesn't matter if it is clients, customers, regulators or management), is pointless.

The tricky bit is figuring what the real problem to be solved is, I agree. Ignoring that question and doing whatever comes to ones mind first doesn't really work so.

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

#36

Post by wruza »

jstummbillig wrote: post #25
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…

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…

Reading is actually cheap. You don’t have to understand everything, but being aware of the area map in general helps avoiding reinventing the wheel or looking for complex paths.

Systems are going to be increasingly complex

Coincidentally that’s where compensable expertise is.

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

#37

Post by anymouse123456 »

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…

There are some brains that do very well with this advice, but mine is not one of them.

I only seem to learn by moving back and forth between solving a real problem and finding just enough information to move forward one step. After some period of this, I'm usually able to read (and understand) a book or two on the subject, but never before. Maybe I'm a tactile learner? Not sure what to call it, but if you're not sure what kind of learner you are, try a variety of approaches and don't be discouraged if manuals don't work for you.

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

#39

Post by codethief »

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.

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

#40

Post by aleph_minus_one »

hef19898 wrote: post #35
aleph_minus_one wrote: post #24

Earlier quoted context omitted.

> We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out. I am not sure whether this is a good advice - for a quite subtle reason: I do claim that most code (including most of the code that is written "for code's sake") does solve a problem, and most programmers at least unconsciously are aware of this fact - and that's why they wr…

Assuming tue devs don't live in a vaccum, it is other people eho define the problems to be solved. Doing so consiously, and not unconsiously by chance, is what engineering does. Producing something to produce something, while ignoring the problems you where handed to solve (doesn't matter if it is clients, customers, regulators or management), is pointless. The tricky bit is figuring what the real problem to be solve…

> Producing something to produce something

A central argument of me is that this situation "produce something to produce something" rarely happens - this is in my opinion rather evil propaganda from people who hate programmers and their way of thinking. Such code nearly always solves a problem - often one that the managers don't understand.

Just to be clear: it does happen that the code solves a problem in a bad way - this is where in my opinion the trope of "code for code's sake" comes from.

Post reply on HN