sponaugle

I used about 64MWh last year, not counting what I used for EV charging (Which is on a separate meter). I also produced about 20MWh from Solar. With the EVs I would guess the total is around 70MWh.

Some of this extra is certainly my 6kw homelab + HVAC for that. ;)

I have met more other founders that came from large engineering state schools then the next tier-up of prestigious schools, with one exception being Stanford. Of course these larger schools produce far more students. Purdue (where I went) generates over 3000 new engineering graduates every year.

From the hiring perspective - A degree from from ivy school means so little compared to the actual skill level of the applicant. I honestly could not tell you where the last 10 people I hired went to school, or if they even did.

Amazon and MGM Studio announced today that Stargate is coming back in a new series.

A 68030 based computer - https://github.com/jeffsponaugle/roscoe

It has been a super fun experience so far - I'm using CPLDs instead of an FPGA which makes the logic a bit more era period. I have a working system now with the math coprocessor, SRAM, DRAM, and other device support.

I am just about ready to get the VGA card I designed produced so I can work on debugging the design.

While this is fundamentally a system that ss less powerful than my apple watch, it is just fun to work on. Going back to very first principles debugging, building tools, and of course getting to exercise an old logic analyzer!

This has to be an AI written article to say so little in so many words, with so many dashes!

And don't forget to use lots of – em dashes!

"But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team."

That is a good summary of the progression of a successful CTO. The capabilities of the team is a summation operations, not a selection operation.

This might be best said as you want your CTO to be ABLE to build and operate your products, but not actually do it.

I like to say that my job as a CTO is to be able to do the job of most the people that work for me, but most of the people that work for me are much much better at it.

"But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones."

The distinction might be something more subtle - I think s good CTO should maintain a deep technical skill, but should do so without putting the technology of the company in jeopardy. I write code, and am a CTO, but I don't write code for our products. I write code in order to continue to develop and maintain deep technical skill. I also manage our technical operations, so I make an effort to a good understanding of the technical areas that are needed to operate - networking, device configuration, IP, etc. In a pinch I am fully capable of making a configuration change to a Cisco switch or a Palo Alto firewall, but in practice I have a team of people that are much better at those tasks. That allows delegation and understanding.

I have not read that book, but ordered it just now. Thanks for the recommendation.

I'm also a CTO, and the comment about 'delegation' is something I think is important. The decision of what and how to delegate is IMHO something that is easy to get wrong. It is hard to do right all the time.

It is easier the better your team is, so hiring people that are better/smarter than you is the first step. I like the concept that I can do the job of most of the people that work for me, but all of them can do it better. There are times where direct involvement is important - sometimes for big decisions but also sometimes for small ones that need something extra to make it across the line. I like what you said about "org accountable, engineers inspired, and keeping the big picture in". That is a good summary.

This is an interesting question - I am a CTO at >1B tech company and there is no doubt that part of my role is exactly this - Technology Strategy.

How do I do it?

(1) It is my job to be familiar with a wide range of technologies, which might include tech stacks, but us mostly tech offerings. The tech offerings means lots of meetings with companies that build tech that we might use. Some of those are useful, most are painful.

(2) Actually using technology - IMHO - This is one of the most important aspects of the CTO job. I code all the time, but not for any of our products or operations. I code to learn so I can help make better decisions. We use Kafka for instance, and when we first started using it I built a cluster in my homelab so I had a better idea how it worked. The same with Hadoop, Cassendra, and a few different flavors of Kubernetes. The T in CTO is for 'technology', but it really should be for 'technical'.

(3) Perhaps the single most important thing - I try to hire people that are much smarter than I am, always. The amount I learn from people that are smarter/faster/better is many orders or magnitude greater and more valuable than the reverse.

(4) All the rest of the CTO job needs to support this - so budgeting, head count plans, spending strategy, patents and IP, roadmaps, decisions, etc. All of these details have to roll up and hopefully support a strategy.

This description is accurate to what I have seen and what I do. I'm a CTO of a >$1B tech company, and my roles is focused around the technology innovation, and that includes evaluating and prototyping new tech. In my particular case that role also includes the operation of our technology because that is very central to our business - and also extremely focused on high reliability.

When I was CTO of my startup I had far more direct engineering development work, but that is typical in the building stage.

As for the core of this post, the one thing I do agree with is the ability of the CTO to actually be technical. I write code all of the time, but not for our products. The goal is to remain both technically proficient but also focus that proficiency on leadership.

Not only that, but CPM (Counts per min) is measurement device specific. Using a very sensitive pancake probe will generate much higher CPM than a geiger tube from the same source. You have to look at calibrated units (usV/hr for example). Of course uSv has it own problems given the exposure model.. but better than CPM!

Indeed - There are not that many jeff sponaugle's, but I seem to get the email for the others from time to time!

Agree 100%. Watch a few videos on youtube from Mentour Pilot. The cognitive load is such a huge factor in so many accidents and close calls. There are also equally many accidents that could have been prevented with just a bit more automation and fault detection. Perhaps the most amazing thing is that after an accident, it can take years to get a real corrective action across the industry. It would be like level 10 CVEs taking 5 years to get patched!

Eliezer (the author of this piece, in 2023) is best described as a 'technical blowhard'. He very much likes to pontificate about things that are so unrealistic that they sound like a great fiction novel. His career has moved into the stage where he tells people the great work they are doing is going destroy the world while sitting comfortable in an arm chair. He loves talking about an industry that he isn't actually in.

'I'm really into retro computing having collected over a hundred 80s 'home' computers (all non-PC/Mac)," I like where you are going with this! I have a small collection of vintage hardware, but a bit more cross brand: https://youtu.be/XHvdqB6LSg0

The dot pattern example reminds me of Starlfight, which took advantage of the color effects on composite output from a CGA card. Great stuff!

My favorite Cosmos episode (#9)!

I'm running 100G CWDM4s in my homelab, and those only take about 4w each for the optics, so I suspect with the PCIe card it is less than 10w.

1kW sounds pretty good to me!

My homelab is between 4 and 8 kW continuously, depending on what I have running. Cooling that homelab is another 400-1000 watts depending on outside air temp.

Hold my beer!

"Grid tied solar won't put power into the grid when the grid is down. It's the one reason I didn't grid tie."

Why would that prevent you from being grid-tie? I have 53 panels (~21kw) grid tied and pushing to the grid, but in the event of grid failure my panels will still operate and push into my 42kwh battery array which will power the entire house. ( The batteries take over as the 'virtual grid source). I can then augment the batteries with generator and run fully off grid for an extended amount of time ( weeks in my case ).

"I wonder what this really means. Operating Expense = R&D + Marketing/Admin + Misc. stuffs."

True, but there is so much in the Marketing/Admin and Misc stuff at Intel. They make CPUs that they sell to OEMs. How can they possibly need the marketing staff they have. They do so many trade shows as well that are a waste.

The could layoff 25% of their staff and still have plenty of people to do the right things.

Agree on the newsworthy.. quotes like this are not super valuable... however the concept is that without real R&D the actual manufacturing is not as valuable. Of course it is better than no manufacturing, but in EUV, the real magic is in the process development.

What Pat said is 100% correct. The actual manufacturing of EUV ICs is incredible difficult, only eclipsed by the difficulty of figuring out HOW to do it. Doing the fabrication here in the US is great, but the much more difficult and key skill is the 'figuring how to do it'. Modern EUV is unbelievably complicated, and there are a continuous supply of new engineering problems that at first glance often don't even appear to be solvable.

In many cases you have an idea and it take 2-3 weeks to determine if it made any difference, and the feedback loop just gets slower after that. The steps in EUV requires some extreme engineering, and it is that core engineering talent you want to develop. The fabs are complicated, but the recipe is the key.

(Note I worked at Intel in the 90s, funny enough in Pat's group)

I have both. 2 Cat6As plus a SM fiber to each AP location. The APs need power over POE. I just added in my first AP that was 10g (Ubiquiti XGS), and that uses POE over 10g.

I was not referring to wiring going thru studs, but along studs. Nail plates are very effective for going thru studs, but often wire is ran along the side of a stud. If it is a large bundle and you don't keep it centered on the side of the stud it will be close to the surface right where a screw could miss. Of course putting some kind of shielding or sleeve could work, but that is very uncommon in house building.

Smurf tubes work great, but are not practical in some high density environments, especially a house with steel structure and I-beam joists. I used these for some locations in my house, but not all.

These are great and common regrets in house wiring. I'm actually recording a video series on this exact topic right now. There are some things in electrical that are so easy and cheap to do but just get skipped over. Electricians are typically very very cheap (in a good for you the consumer way). However this tends to lead to under-building in a modern tech house.

This is correct - I have pull strings in my conduits at my house for that reason. Pulling fiber down my 1000ft driveway would be difficult to do if the pull string was another fiber.

You can pull a new pull string in empty conduit pretty easily with a shop vac and a ziploc bag.

In a home buildout, running fiber is surprisingly inexpensive and easy to do. There is one area to watch out for - In most US homes drywall is installed with screws that go into studs so if you have large bundles of wire or fiber be careful how the sit relative to the surface of the studs. Often the drywall screws will be off by a bit an miss the stud. If you wire bundle is large enough and it is a 2x4 wall vs a 2x6 wall you can lose a number of wires with a puncture.

A second common problem is the wire installer pulling the fiber around sharp corners, sometimes with staples and zip ties. Fiber is surprisingly resilient, but very sharp bends will cause significant problems. Using armored fiber can help this a bit.