Opportunity cost meaning investing with standard rule of thumb returns? I think usually it's just total cost at installation divided by the product of power generation and energy cost. So that's $ / (W x $/Wh), which should reduce down to just hours that can be trivially converted to years
> Cost of alternative investments not pursued as a result of deployed capital.
Once you’re achieving 30-50% annual returns over 20-30 year horizons (PE, HFT, invite-only HF) , you stop caring about cost of capital for anything less than US$1 million.
But 10% VTI / VOO, sure, factor that 10% into your excel.
I very much do not believe them, but I don't have much to base that on other than that now there's a company doing a similar thing and projecting much longer timelines. So sadly I'd be joining you
If you have a feedback loop I'm sure you can still do it with an either implicitly or explicitly filtered PWM. Remember we're talking averages not instantaneous, so the average current through the bulb should be proportional to the average voltage across it, though the resistance will change as the bulb heats hence the feedback. You could also do this with a buck/boost regulator and current sense resistor plus op amps to create a constant current supply.
"average current through the bulb should be proportional to the average voltage across it" That is exactly correct, the reason they were seeking clarification, and the core of suggested solution.
V=I*R
If V = Hours and I = Minutes, then by necessity R=Hours/Minutes. Typically a light bulb has mostly fixed resistance (R). Adding a potentiometer to the circuit allows you control the value of R.
So lightbulbs actually dont have fixed resistance. The tempco is pretty big, and temperature of course depends on power (with an annoyingly large time lag when power is reduced).
That being said, the bulb does have a well-defined resistance at a given point in time, so voltage and current are of course not quantities that can be indefinitely controlled.
This falls into the same category as “why isn’t my power supply with voltage and current controls working correctly?!?”
Oh - it didn't occur to me that the original poster might have thought about three different circuits - one with a voltmeter, one with an amperemeter, and one driving the light bulb. Maybe that was their intention.
I originally assumed that the bulb would be somehow connected to voltmeter and amperemeter.
Just to put in my 2 cents as someone tangential and sometimes a little too close for comfort for the field: with FPGAs (aka the half of this SoC doing the real work) there's often a lot of work that goes into radiation tolerance and hardening which are different things. It's not like you can just put the chip in space and be done. You have to do things like scrubbing the "bitstream" regularly for errors, triple-module-redundancy (aka cut yourself to 1/3rd of the chip's capacity), and other stuff.
Not just the test though. In some states you need approaching 100 hours of signed off driving with an experienced driver (honor system though) and a certified course
Ah. Good fact check. I swapped the numbers on minimum community service hours to graduate high school and this. But I think my point still stands that you can't just walk in and take the test
I was (almost) just that guy for one PR. Removed something like 20% or more of the codebase by leveraging the libraries and external tools we already had in use better, but it meant almost every single thing we were doing had to use the library function instead of the one we wrote. But assuming you have good regression tests and linters, so you know the code works and it's not terrible, the review should be more about overall high level quality instead of poring over every character to check correctness. It was still a pain to review, though
You’re not an example of what we’re taking about here. Congratulations!
A better example would be if you’d changed the behavior of the library as you did this work, and the library changes introduced hard-to-detect bugs across the application.
Yes exactly. the GP isn't what we are talking about it and huge PR isn't what we are talking about either.
PR can be huge that's OK. For example, codebases that moved from Python 2 to Python 3 would have had huge PRs but the cognitive load was well understood.
As per the other person's comment, yeah basically I could have broken it up but it would've been an arbitrary demarcation. I just deleted our functions and fixed everything that yelled. Admittedly that could've been one and then leveraging the libraries better could've been another, but they would've been 2 PRs that changed almost every line. So done as one to mitigate review time.
Arbitrary demarcations can still be valuable! Just because something is arbitrary doesn't mean that it's not helpful. Working in chunks will let you take more time to review each callsite individually, and increase your confidence in the changes
In the future, I would definitely encourage you to explore a more iterative solution—fix the first 50 occurrences first, or maybe all the occurrences of a handful of functions. For example, if you have utility functions A, B, C and D, maybe fix functions A and B first, and then C and D second.
Ultimately, at the end of the day it's going to depend on how much code you're touching. If you're only touching 100 library calls, then it's probably easy to do them in one PR. But if you're updating 1000 library calls, you'll need to take a more iterative approach. Building those skills now will serve you well in the future when working on bigger codebases and harder refactors.
Well another problem is that there was a developer also working on those functions at the same time. So just like the recent post on a 25 million LoC reformat done in a weekend, it seemed better to do it in one fell swoop. If it's good enough at 25 million, I'm sure it's good enough at a few thousand
Autoformatters are deterministic tools that are tested regularly, with extensive test suites and went through a very long process of production usage and review before the reformat:
> We also built a tool to diff ripper trees across formatted files, accounting for things like rubyfmt converting single quotes to double quotes. Combined with our extensive test suite, we built confidence slowly and deliberately.
If an autoformatter is working right, it's only changing whitespace—not the actual code executed. Changing between two different implementations of the same function is very different from changing whitespace around.
They also didn't do the entire thing in one weekend—that was just the article title clickbait. they did it file by file, incrementally, over the course of months:
> Rolling out a novel autoformatter to 25 million lines of code has two big risks: merge conflicts and correctness. A bug affecting just 0.01% of lines would still touch tens of thousands of files. To manage both, we built in a per-file opt-in so rubyfmt would only format files that explicitly asked for it. Following the Developer Productivity org’s typical pattern, we started with systems we owned and could observe closely, then expanded coverage gradually as our confidence grew.
^ See how they talk about the incremental changes it took? This is what mature refactors look like. And they were only changing whitespace!
It depends a bit. But it would now mean that there are multiple ways of doing the same. Call your internal function or call the library directly. You need to put up some linting around it that people only use your function or the library function.
Otherwise you may get that you have your function, you think everywhere is using it, you make it fix a bug. And poof, you introduced bugs at the other call sites.
> Do we have thoughts on how important "senior"/"staff" is vs bullet points on resumes and the years of service?
As a hiring manager, I only read the bullet points. I’ve interviewed startup CTOs who were mid-level engineers at best and “Software Engineer” vanilla titled engineers who have shipped and owned impressive things over years.
The scale, complexity, and variety of the systems you’ve built, shipped, owned, and maintained trumps all else.
And yes we can see through the bullshit. Everyone has built a “semantic document retrieval system” in the last 3 years. That’s a weekend project, gonna need a little more to be impressive :)
Interesting. Not looking to switch roles at present but what do you make of these two projects? One done basically over a weekend, one done over many weekends
Removed a bunch of bad code and got a 1/3rd speed up
As an engineer, I just want to get an idea of where this person is at in their learning journey and what their personality is like, do they have certain intangibles, etc.
The recruiter who screens the person before they ever talk to me, on the other hand...
reply