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

61–70 of 361 posts

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

#61

Post by hef19898 »

jstummbillig wrote: post #51
hef19898 wrote: post #27

Earlier quoted context omitted.

How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input f…

The margins are infinitely expensive. "As much as possible" has no meaningful boundary, when working in a system that is too big to hold in your head. Mastery is alluring - it's just not very effective and certainly really bad advice for new software devs, who are in the worst possible position to judge the margins and what is useful.

Exactly why new people, new to the job in general or just the system in question, need mentoring and leadership in doing so. And guess what you can do if you went through all of this? You can mentor and teach others, and if combined with doing, there is no better way to mastery than this, at least not one I am aware of.

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

#62

Post by max_sendfeld »

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.

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 trailing whitespace. So every commit was a dance of commit -> read rejection log -> remove trailing whitespace -> commit again.

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

#63

Post by mk_chan »

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…

This is the perspective I’ve come to learn as well. Fact of the matter is what you want to do (and perhaps sell) is what actually matters, not the tools you use to achieve it. Programming language, frameworks, monitoring tech, monolith, microservices etc don’t matter at all as long as you are trading fine, able to deal with failures and move on with checks for next time, able to retain/convert customers and so on. As long as the business is served by the tech within the business constraints, the tech can be abstracted away from the business. Not to say it isn’t important because you are in fact enabling or accelerating the business, but the business is what matters.

The tools only start mattering when the maintenance and usage of the tools becomes a heavy constraint to doing what you actually want to do (big tech). That doesn’t actually happen very easily.

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

#64

Post by austin-cheney »

MrGilbert wrote: post #20
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…

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

The failure to properly administer a business does not make the sales/software cost center rule less true. I have seen this failure repeated exactly as you describe a few times in my career, though. I have also seen some major brands anticipate this problem and over correct for it by hiring too many developers without any kind of discipline or unifying vision.

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

#65

Post by mightybyte »

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…

> Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover.

I think there are times when this works and there are times when it will be a huge waste of time. In general, I think it's often very hard to tell which approach will be more efficient for you. As some sibling comments have mentioned, I think the way each person's individual brain works is a significant factor, but I think there are other potentially unknowable factors that are significant as well.

The best thing I've come up with to deal with this is to use an iterative-deepening-like approach. There's a reason this algorithm (pre AlphaGo) was the most common approach for many game playing programs. The general idea is to go a ways down a particular path but always keep in mind some notion of the global suitability of this path and when it starts to look too hard, back up and investigate some other approaches to at least a shallow (but a little bit deeper than before) depth. This lets you avoid potentially costly dead-ends for relatively low overhead.

(These thoughts inspired from this nice talk: https://www.youtube.com/watch?v=Z8KcCU-p8QA)

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

#66

Post by EZ-E »

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…

Don't solve simple problems with complicated solutions

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

#67

Post by avgcorrection »

preommr wrote: post #6
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…

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

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

#68

Post by EZ-E »

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 have memories at my post grad school where any deviations from the expected code source formatting led to a -1 on the mark. On the first few projects it was not rare to see students getting marks well into two or three digits negatives.

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

#69

Post by ethanwillis »

TheHumanist wrote: post #42
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…

Many people's brains cannot absorb that much information. If I sat down and read full docs front to back I would remember maybe 3 things. I don't think this is overall practical advice. Then reading the source code too for all this stuff I like? I don't understand where one finds the time for all this? I'm not putting you down, I just genuinely am confused. I barely get my stuff done as it is each day haha

This is surely an exaggeration. 3 things? Really? Surely you would remember much more than that. And I don't mean this in a snide way. I think I just have a much more optimistic view of what the average person is capable of in regards to reading.

I think there is plenty of time but maybe not in the types of work environments that are the norm nowadays.

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

#70

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…

True. On the other hand, don't try to make things simpler than they are.

https://en.wikipedia.org/wiki/Waterbed_theory

Post reply on HN