Live data from Hacker News

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

buttondown.email

11–20 of 361 posts

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

#11

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 model, type A contains domain-specific business logic, type T technical code and type 0 is the glue. One should strive to keep these highly cohesive and especially loosely coupled.

I found this an interesting way to think about software and it made me realize that a majority of projects contain mostly type A code while most stuff university teaches is how to write type T code.

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

#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 own problems faster rather than asking other people about something, because the docs often have the answer.

Read the source code of popular software you use (including the libraries of your favorite language). You can learn esoteric knowledge about programming just by looking at other people's code. One benefit of OSS is that many eyeballs can shave code down to very efficient forms, and you can take those forms for your code.

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

#13
post #6

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. 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. I feel like people exagerrate this idea to prove a point that, ultimately, sales is the gateway to money. Which is fair and important to keep in mind. But, worded like t…

I think this brings up another good point: code is NOT the whole product, but part of the product. Whether it solves an user pain point, and how easily it can be used (UX) is just as important. If you’re just coding without understanding how it fits in, you’re just a coder, not a software engineer

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

#14
post #7

Earlier quoted context omitted.

There is no excellence in software — only advanced opinion.

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.

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

#15
post #6

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. 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. I feel like people exagerrate this idea to prove a point that, ultimately, sales is the gateway to money. Which is fair and important to keep in mind. But, worded like t…

> Software only costs money.

I assume this ignores hobbyist coders.

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

#16

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.

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

#17

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…

Which documentation? If I read everything, it would take a lifetime.

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

#19

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…

Reading source code also helps steering you away from unfit projects. I've decided to replace dependencies after trying to submit a PR and realizing the code was not as robust as I hoped, or was doing too much.

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

#20

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

I do not like this comparison, mostly because it leads to out weight one for another. We currently have the situation that we are understaffed in dev and overstaffed in sales, but sales does not generate enough revenue to justify their existence. However, we can also not deliver as much features as we like, because the dev department is too small.

Post reply on HN