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

Post by austin-cheney » Wed, Dec 20, 2023, 5:10 PM UTC

avgcorrection wrote: post #67

preommr wrote: post #6

Earlier quoted context omitted.

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

What’s the point of even replying to comments like grandparent. Those points are phrased as person-specific dogmas, not advice.

Post by circlefavshape » Wed, Dec 20, 2023, 5:17 PM UTC

austin-cheney wrote: post #179

hnfong wrote: post #102

Earlier quoted context omitted.

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

I have heard this all before. Its excuses to qualify low effort and mediocrity. 1. You are either actively generating money directly with your activity or you are contributing to something else that does but you are only doing a single thing at any given moment. Everything else is just pandering to justify your existence. 2. Games can be anything. You don't need a computer to play Sudoku. What separates video games f…

Post by andai » Wed, Dec 20, 2023, 5:27 PM UTC

Cthulhu_ wrote: post #165

andai wrote: post #72

Earlier quoted context omitted.

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.

This is the likely cause - most software development is dreadfully boring. But at some point in a developer's career, they will have touched the monolith and everything is full of stars, and instead of saying "I'll just hook you up with Magento", they're like "I will build you an event-driven microservices architecture in a custom made C# framework" and disappear for six months while they work late nights. (I wish I…

Post by [deleted] » Wed, Dec 20, 2023, 5:29 PM UTC

aleph_minus_one wrote: post #76

andai wrote: post #72

Earlier quoted context omitted.

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

Post by layer8 » Wed, Dec 20, 2023, 5:31 PM UTC

eschneider wrote: post #176

hiAndrewQuinn wrote: post #118

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.

I cannot stress enough how much you can reduce "how many things you need to hold in short term memory to do your job" by just keeping a notebook (or file, or wiki, or whatever works for you) and writing things down.