A bunch of programming advice I'd give to myself 15 years ago • Hacker News Board

Re: A bunch of programming advice I'd give to myself 15 years ago

#321

Post by sambazi » Tue, Jul 02, 2024, 6:58 AM UTC

kortilla wrote: post #313

rightbyte wrote: post #284

Earlier quoted context omitted.

The correlation between performance and pay is really weak. In my experience, probably negative too, since most work seem to be done by junior employees while the most seniors coast around fixing some bug every now and then on something they wrote some time ago.

I’m telling you as a manager in a company that rewards productivity. We do refresher percentages and bonuses based on perf feedback from leads and peers. Coasting senior clock punchers get base salary and little more. It’s easy for high performing people with lower titles to pass seniors in TC over a couple of years due to stacking perf bonus stock grants.

how do you measure productivity?

Re: A bunch of programming advice I'd give to myself 15 years ago

#322

Post by feoren » Wed, Jul 03, 2024, 7:43 AM UTC

isotropy wrote: post #287

feoren wrote: post #236

Earlier quoted context omitted.

Nobody could easily explain why early (1950s - 1970s) fusion reactors were so difficult. It must have been that everyone was stupid and creating their own problems. No one can explain why the Collatz Conjecture is so hard to prove. It must be because everyone is so stupid and is adding incidental complexity to the problem. Why is everyone so stupid? Or, maybe, possibly, that advice is utter bullshit nonsense and some…

Fusion: Turbulence, plus Naiver-Stokes was known to be hard, plus adding in EM fields, plus the exothermic state change of the nuclei fusing introduces discontinuous jumps in the free energy. Collatz: if you replace 1 and 3 with arbitrary parameters, Conway showed that this class of problems is undecidable, so any particular instance could be arbitrarily hard.

Genuinely great responses. I'm not sure "it can be generalized to an undecidable problem" really explains why it's hard though, as the 5n + 1 problem is very easy (to prove false) and generalizes just the same. And all good points about Fusion, but my point was that it took some time (months, at the very least) for them to realize that's what was spoiling their machines. Remember that this is all a counterexample to the statement that "If you can't easily explain why something is difficult, then it's incidental complexity" -- meaning all the difficulty you are encountering is your fault (and therefore the actual problem must be easy, and you must be stupid.) That's literally what TFA says.

Re: A bunch of programming advice I'd give to myself 15 years ago

#323

Post by garcia3252 » Wed, Jul 03, 2024, 11:27 AM UTC

[dead]

Re: A bunch of programming advice I'd give to myself 15 years ago

#324

Post by isotropy » Wed, Jul 03, 2024, 7:51 PM UTC

feoren wrote: post #322

isotropy wrote: post #287

Earlier quoted context omitted.

Fusion: Turbulence, plus Naiver-Stokes was known to be hard, plus adding in EM fields, plus the exothermic state change of the nuclei fusing introduces discontinuous jumps in the free energy. Collatz: if you replace 1 and 3 with arbitrary parameters, Conway showed that this class of problems is undecidable, so any particular instance could be arbitrarily hard.

Genuinely great responses. I'm not sure "it can be generalized to an undecidable problem" really explains why it's hard though, as the 5n + 1 problem is very easy (to prove false) and generalizes just the same. And all good points about Fusion, but my point was that it took some time (months, at the very least) for them to realize that's what was spoiling their machines. Remember that this is all a counterexample to…

> I'm not sure "it can be generalized to an undecidable problem" really explains why it's hard....

Hah! I agree with this. :)

Re: A bunch of programming advice I'd give to myself 15 years ago

#325

Post by oblio » Thu, Jul 04, 2024, 3:14 PM UTC

rowanG077 wrote: post #318

oblio wrote: post #314

Earlier quoted context omitted.

None of the FAANGs or even tier 2 companies work on references, unless you invented the internet or something. And even then, there is a famous story of the dev of the popular MacOS FOSS package manager, Homebrew, failing his interview at Apple.

I don't get the point why a maintainer of a popular package failed his interview. Having a popular package has nothing to do with coding ability and much more to do with writing the right thing at the right time.

He wasn't the "maintainer of a popular package".

He was the creator/designer and main dev of Homebrew, the OSS > almost every dev on MacOS uses.

He took an idea to completion, made it production ready and used by probably millions of users.

I don't care about raw coding ability (Carmack style), if building such a large project doesn't prove at least development abilities, nothing does.

Re: A bunch of programming advice I'd give to myself 15 years ago

#326

Post by austin-cheney » Thu, Jul 04, 2024, 4:45 PM UTC

rightbyte wrote: post #284

kortilla wrote: post #254

Earlier quoted context omitted.

You don’t get the same salary and equity as a top performer. Very few companies give flat raises and bonuses without taking into account performance. And if your manager cares about productivity, the 10x programmer is going to take the cake.

The correlation between performance and pay is really weak. In my experience, probably negative too, since most work seem to be done by junior employees while the most seniors coast around fixing some bug every now and then on something they wrote some time ago.

Agreed. My primary motivation to be more productive is to free up work time for personal use. That's it. When I become a 10x developer and effectively work 1-2 hours a day I keep that to myself as a closely guarded secret. I know I will not receive 10x more pay for that increased productivity and I also know as I mention it the institution will find a way to take it from me for any number of unproductive reasons.

Re: A bunch of programming advice I'd give to myself 15 years ago

#327

Post by PaulRobinson » Sat, Jul 13, 2024, 5:49 AM UTC

wruza wrote: post #290

Panzer04 wrote: post #246

Earlier quoted context omitted.

Curious why you'd skip low level. Pay? Industry? Knowledge not helpful?

Because I ended up doing “business” things that are far from low-level, and I sort of like it, never wanted to return to C/asm.

I’m glad you’ve found a happy place in your work, but maybe take some of your own advice, drop this bit of your religion and change this to “use the right tool for the job”.

If you’re doing business logic in a micro service, C is probably the wrong choice. Python, Ruby, whatever probably makes more sense.

But if we are trying to build a (very) high-performance trading engine, or a device driver for a new piece of hardware we are building, and you are on my team and you show up with something in TypeScript because “it’s better”, we are going to need a conversation about whether you’re in the right place. I love high level languages but I also know the problem sets when not to use it.

I also know that if I am going to be writing something very low level, it’s a conscious choice and I’m going to invest in the tooling and the time to make sure my code is safe and secure.

The more generic advice might be that if you love a particular language or approach you might want to work on problems where that language is a good fit. Likewise, if you like particular problems, you should learn the language others think are a good fit in that problem space.