InFeeo
Global
technology
New
Language
Profile channel

@Jacob

No bio yet.

Since 31.05.2026

How can engineering leaders avoid becoming Bond villains?(take.survey.stackoverflow.co)
Q: Paging Charity! Our industry tends to espouse the value of collaboration, but then places on pedestals the worst models of authoritarian leadership. You have a strong following of people who view you as an alternative voice to this tendency. What advice would you give to newer managers trying to promote different values? And what advice would you have for a manager who is interested in moving into the director role?— Auntie Authoritarian———————————————-Dear Auntie Authoritarian,I was going to protest that hey, do we really put the worst authoritarian leaders on pedestals? But then I remembered all the guys who get mentioned daily in the business press, and then I remembered the whole “founder mode” groan-a-thon, and well, okay. Point taken.Except I don’t think it’s so much that we celebrate authoritarianism and sociopathy—none of these guys are exactly beloved—as we cultivate it.The number of things that need to go right to get a business off the ground is astronomical; over 90% of VC backed startups will fail. There are exceedingly few winners, so every winner gets celebrated and venerated. We humans crave our heroes, so we bend over backwards to retcon their mythology.There’s a flattening that happens, where everything ever done by a company with hundreds or thousands of employees gets rounded up and ascribed to one man (it is nearly always a man). The company becomes just an extension of his will to power in the eyes of the public and the press, and he can do no wrong.This is not healthy, as you might imagine. Even Elon Musk didn’t start off like a Bond villain. He became one after many years of this slavering hero worship.Being a leader or manager is about running the businessThis is the first lesson of leadership: you have to win at business.This is the number one job of every single manager, director, VP, C-level, and every staff+ individual contributor as well. Your job is to build the business and make it win. Which means wrestling with existential questions like:Are we building the right thing?Who are we building for, and do we know how to reach them?Do we know what they want? Will they pay for it? How much?Who are we competing against, and how are we positioning against them?What do our users like and dislike about our product?You need to be an oasis of context and clarity for the people around you, which means you need to really, truly understand the strategy, and help devise meaningful goals in that direction.If you want your values to spread throughout the industry, the best thing you can possibly do is succeed and make others want to imitate you.Why people become managersA lot of folks go into engineering management because interactions with their own managers left them feeling devalued, unsupported, and unmotivated, and they want to make sure nobody else ever feels that way. I’ve heard a lot of managers describe the job as being “all about the people”—how they feel, how you support them, how you help remind them to go on vacations and log off at 5pm and take plenty of vacation time.This is a lovely sentiment. But putting people’s subjective experience first is putting the cart before the horse. Feelings are outputs and trailing indicators, and management is about inputs.I actually agree that managers have a tremendous amount of influence over how people feel from day to day, and that it matters a great deal how we feel at work. But I think people underestimate the structural influence of circumstance.I have seen so many inexperienced managers reason that the problem with past jobs was that they kept having to do work over and over, or they weren’t able to choose their work with autonomy, or their manager was micromanaging. So when they became a manager themselves, they swore they would always protect their team’s ability to move on, work autonomously, and work without them hovering.But their diagnosis was usually off base.The problem was that they did not have product-market fit, so the solution they were trying to build kept changing, and they kept having to go back and redo discovery work.The problem was that engineering was not aligned with the field on what problems were highest priority and should get fixed first.The problem was that two different leaders elsewhere in the company were not aligned on what they wanted from this team, so they kept pingponging back and forth with their demands, forcing this team to pick up work and put down work.The problem was not that there was micromanaging or changing plans or people getting upset. The problem was that there was no shared understanding of who made the decision, what the constraints or criteria would be involved, or who the stakeholders were—or when or if a decision had been made at all.Building a company is a deeply, enduringly human endeavorI believe that humane, empathetic, compassionate leaders can build a better business than sociopaths or authoritarians can. Ordering people around and treating people like objects or subjects might be effective in the short term, but they are not long term winning strategies. They do not draw people in, they do not make people feel warmly disposed towards you.I believe people do their best work when they have agency and autonomy, when they feel creatively inspired by the work, when they feel attached to the mission and emotionally attached to their collaborators. I have experienced this for myself so many times.But having agency and autonomy, feeling creatively inspired, loving the language or the technology, feeling attached to the mission and collaborators—these things are good, but they do not add up to “good at running the business,” ipso facto.It is totally possible to be a humane, empathetic, compassionate, caring human being…and a really sloppy operator who is terrible at business.Being good at running the business is not optional. The most effective leaders are the ones who are kind, caring humans and skilled business operators. The second most effective leaders are the ones who are crappy humans but skilled business operators. After that comes everyone else.Climbing the ladder to directorThis is why I always tell new managers they should focus on learning the business. If they were an engineer, they probably love building tech and systems. If they signed up for management, they probably love running people and teams. It’s the business side that’s a real gaping hole in the track record of most new engineering managers’ experience.You asked what advice I had for advancing to the director level. Two things. First, the hardest part may be sussing out the right opportunity. At each level of hierarchy, there are approx. 1/10th as many people as the previous level. That’s true even when we aren’t going through a prolonged phase of flattening org charts and enlarging team sizes.Your best bet is being promoted from within; companies are usually quite resistant to hiring someone into a higher-level management role if they have not already done the role.Second, this. Managers are notorious for thinking everyone on their team is THE BEST. Managers are always trying to insist that everyone on their team is a 5/5 or a 4.5/5, and going to bat for them to get raises and promotions every cycle. (It would be very endearing if it wasn’t so counterproductive.)If you’re sitting here thinking, my team is awesome, they are the best, we are the best, everything is great—honey, you are not serving them well. Your job is not to be back-patter in chief.If you really want to make your team feel good, the best thing you can possibly do for them is turn them into a high-performing team, as Patrick Lencione defines it. High-performing teams are ones people will look back on fondly and wistfully for the rest of their career. But you cannot build these teams by cheerleading. You have to nurture a restless hunger for improvement in every one of you. You have to set the pace, and show the way.That takes systems thinking, courage, and credibility. And it is what executives look for when tapping managers to be directors.We earn the right to continue onThe experiences people carry around as “the manager I never want to be” are often things like the time their project got shut down and thrown out after months of work, their team got re-orged without notice, a beloved leader got fired, layoffs happened or happened poorly, new management was brought in and wrecked a culture they held dear, etc.We tend to blame “the manager” in these situations. Sometimes it is warranted, but more often it is not. It is often a sign of underlying weakness in the business.Twitter had 7500 employees in 2022 when the Elon Musk hurricane blew in. Now they have around 1500. I have nothing kind to say about what Elon Musk did to Twitter. But I also look at that situation and think, “Twitter’s leaders had 16 years to figure that out, and they didn’t. It was only a matter of time before someone was going to take it out of their hands.”Twitter’s beloved culture, its cushy policies, perks, and freebies; the work/life balance, the lengthy, consensus-based decision-making protocols and innumerable veto points, the 1700 engineers, the famously lax policies…They acted like they had won, they were comfortable. They hadn’t won.The job of every manager is to set a high standard for themselves and their teams, to run the business efficiently and with excellence. This is how we earn the privilege of serving in our role.If we don’t do it, it will be done to us.— Charity————————-Got a question you’d like me to tackle? Feel free to email me at charity@honeycomb.io (or pitches@stackoverflow.com, if you’d like it anonymized). I am interested in answering questions about observability, AI, careers, leadership, team dynamics, and ethics.
[Pilot Project] I built an automatic control system identification & code generation platform as a personal project — looking for 1–2 real-world datasets to validate it. Free, in exchange for a reference and feedback(reddit.com)
Hey everyone, Over the past year I've been building this as a personal project (no company behind it, just me): a Python-based platform that takes measured input/output data from a physical system, automatically identifies the best mathematical model for it, designs an optimal controller (PID, LQR, MPC, and others), and generates ready-to-deploy C and Python code for the hardware. I've verified it extensively on synthetic benchmarks — DC motors, thermal systems, oscillatory mechanical systems, nonlinear processes — and it's holding up well. But I need to stress-test it on **real industrial or embedded data** before I can call it production-ready. **What I'm offering:** - Full analysis of your system's data (no charge) - A complete technical report: model accuracy, controller performance, stability margins - Ready-to-compile C code + Python implementation for your hardware - Everything is yours to keep and use **What I'm asking in return:** - A brief description of who you are, what company/project this is for, and what you're trying to achieve - Your honest feedback on the report and the generated code — does it make sense? Is the output useful? What's missing? This is genuinely valuable to me as a solo developer - Permission to mention you as a reference on my CV - Permission to cite the project as a validated use case (no sensitive data published — just "successfully deployed on [type of system] at [company/domain]") I'm keeping this to 1–2 pilots so I can give each one proper attention. **What kinds of systems are a good fit:** Motors, actuators, thermal processes, fluid systems, robotics, HVAC, industrial automation, biomedical devices — basically anything where you have logged sensor/actuator data and want better control. If this sounds useful, **send me a DM** with a short description of your system and what you're trying to achieve. I'll let you know if it's a good fit. Thanks for reading! submitted by /u/pipeline-control [link] [Kommentare]
It's dead, Jim – the old Microsoft UEFI CA from 2011 expired yesterday(einval.com)
About Steve's blog, The Words of the Sledge steve@einval.com I previously wrote about the upcoming UEFI CA rollover. Well, it's happened now - the old Microsoft UEFI CA from 2011 expired yesterday: Third Party Marketplace Root (used for signing option ROMs and other software) Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 Validity Not Before: Jun 27 21:22:45 2011 GMT Not After : Jun 27 21:32:45 2026 GMT The world doesn't seem to have ended yesterday, so I guess we did ok? :-) After a lot of prodding behind the scenes, Debian and many other distributions managed to get new shim binaries dual-signed with both the old and new CAs. The members of the shim-review team did a sterling job with reviews in the last few weeks. Since I started pushing people in May, we've had 21 reviews accepted successfully - see here for the list. Great stuff! Microsoft have also been working quickly - many of those shim submissions were accepted and signed by Microsoft very quickly too, with a turnaround time of less than 1 day in some cases. Not all of those signed shims have been published and used by the distros involved yet, but expect to see them in the wild in the coming weeks and months. These binaries should be good for people to use for the foreseeable future, until either we need to do another CA rollover or (sadly, more likely) we find an issue in shim that necessitates a new release. We already have one of our new dual-signed shim binaries in place in Debian, in unstable and testing (Forky) right now. In a couple of weeks from now, we'll be rolling out very similar new dual-signed shim binaries in the next point releases for Debian 12 (bookworm) and Debian 13 (trixie). We'll also be upgrading fwupd in both those point releases, to make DB and KEK updates work better. For more information about these updates, see https://wiki.debian.org/SecureBoot/CAChanges. For your own safety, validate that your systems are updated when possible. If you don't, they may fail to boot in future.
Marfa Public Radio Puts You to Sleep(eepurl.com)
Marfa Public Radio is literally never asleep. It operates 24/7 (except when lightning strikes) and there’s so much that goes on behind the scenes to make this happen– fundraising, compliance, protocols, emergency response, maintenance…the list goes on and on.Do you lay awake wondering what FCC compliance entails? Ever wondered what NPR's code of journalistic ethics involves for the newsroom?We may never be able to explain what it takes to operate the station, but we can put you to sleep trying to.For this fall membership drive we bring you Marfa Public Radio Puts You to Sleep. It's a sleep podcast wherein we read you the boring documents essential to our jobs, in the hopes we might lull you into slumber.We do actually hope that you fall asleep listening to this, but when you wake up, help us continue to read our boring documents and keep Marfa Public Radio awake by donating to the station at marfapublicradio.org/donate.
Single Point of Failure Apps(keepandroidopen.org)
Two years ago, I bought a secondary phone. It’s a cheap Android phone that always travels with me outside of town. I’ve for the case that my main phone breaks from a fall, fails to boot after an update, gets lost or runs out of battery. The secondary phone has a set of essential apps installed. Simply put, its task is to get me to my next destination and have some hours or days to repair or replace the main phone.
Searching for a [72,36,16] extremal code(discord.gg)
Public mission A crowd search for the missing extremal Type II code The project tries to find or rule out a binary doubly-even self-dual [72,36,16] code. A construction would feed directly into related objects such as a self-dual quantum CSS code and conformal-field-theory data; a nonexistence proof would settle a long-standing coding-theory problem. How the search works: rather than sift through the astronomically many length-72 codes directly, we reason about their weight enumerators — the counts of codewords at each weight — and the finite list of arithmetic shadows those counts can take. Anchoring at a minimum-weight codeword and projecting down a residual tower, [72] → [56] → [40] → [24], forces each shorter descendant to carry a specific enumerator; computing these anchored projections, including their higher-genus (bi- and tri-weight) forms, squeezes out the constraints that decide a branch. When no code can meet the forced arithmetic the branch is ruled out, while explicitly building one up the tower would settle existence — so every result here is either an exact obstruction or a witnessed descendant. Current public posture: 72 compatible shadows remain. 51 have witnessed nonempty descendants; 21 are still unresolved as existence questions. Why this is a good crowd problem Many doors: algebra, coding theory, design theory, SDP, exact enumeration, and computational proof can all contribute. Finite checkpoints: every test has a page, an input menu row, a status, and a way to reproduce or improve the obstruction. Useful outcomes on both sides: construction gives new highly structured objects; impossibility resolves the length-72 extremal question. Automorphism group: narrowed, but not assumed A long series of papers has reduced the possible automorphism group of a hypothetical [72,36,16] code to one of just five: C1 (trivial), C2, C3, C2×C2, or C5. Excluded along the way: order 2 with fixed points (Bouyuklieva 2002); Z7, Z32, D10 (Feulner–Nebe 2011); C8, Q8, Z4×Z2, Z10 (Nebe 2012); order 6 (Borello 2012); C4 (Yorgov–Yorgov 2013); S3, A4, D8 (Borello–Dalla Volta–Nebe 2013); C23 (Borello 2014); with the short list and solvability consolidated by O'Brien–Willems (2011) and Bouyuklieva–O'Brien–Willems (2024). Full citations are in the References catalogue. We make no automorphism assumption. The trivial group C1 imposes no structure — every codeword orbit has size one — so it is the hardest case to rule out, and every test and enumerator on this site is automorphism-agnostic: it must hold irrespective of any symmetry. The narrowed list drives a parallel prescribed-automorphism search; it is not an assumption the menu relies on. If the code is found, these structures come with it A construction is not an isolated object — three structures follow, each by a proven map: A 5-(72,16,78) design. The 249849 weight-16 codewords form a 5-design: every 5 coordinates sit together in exactly 78 of them. Why: the Assmus–Mattson theorem applied to the extremal Type II code (minimum weight 16, dual distance 16) makes each weight class a 5-design, and counting fixes λ = 249849·C(16,5)/C(72,5) = 78. A code CFT at central charge c = 36. The code maps to a chiral conformal field theory of central charge c = n/2 = 36. Why: in the code–CFT dictionary (Henriksson–Kakkar–McPeak, arXiv:2112.05168) a length-n doubly-even self-dual code yields a chiral CFT of central charge n/2, whose genus-g partition function is the theta lift Θ of the genus-g weight enumerator — a degree-g, weight-18 Siegel modular form. This site computes that genus-3 Θ-projection (see the Enumerators tab). A [[71,1,≥15]] self-dual CSS code. Puncturing the self-dual [72,36,16] code in one coordinate and using the punctured dual C⊥ as both the X- and Z-stabilizer gives a self-dual CSS code (CX = CZ) with parameters [[71,1,≥15]]. Why: puncturing gives C = [71,36,≥15] with C⊥ ⊆ C, so CSS(C⊥,C⊥) is valid with k = 71 − 2·35 = 1 and distance ≥ d−1 = 15 (Jain–Albert, arXiv:2408.12752). Main route The 72 -> 56 -> 40 -> 24 hierarchy The public story should center this descent: start from a hypothetical [72,36,16] Type II code, take a weight-16 word, study the length-56 residual, descend through length-40 menus, and finally reach length-24 endpoint tests. Start [72,36,16] Type II code, A_16 = 249849 Residual [56,21,16] 5082 minimum words forced Menu [40,k,16] 132 shadows, 72 surviving Endpoint [24,1,24] local tests and exhaustions What the hierarchy buys The descent turns a global code-existence question into a finite set of compatible length-40 shadows. Each row can then be attacked by exact divisibility, local gluing, support-weight constraints, SDP layers, or direct existence searches. Forced n=72 enumerator (genus 1, Gleason) W_72 = 1 + 249849 y^16 + 18106704 y^20 + 462962955 y^24 + 4397342400 y^28 + 16602715899 y^32 + 25756721120 y^36 + 16602715899 y^40 + 4397342400 y^44 + 462962955 y^48 + 18106704 y^52 + 249849 y^56 + y^72 Forced n=56 residual enumerator W_56 = 1 + 5082 y^16 + 91168 y^20 + 507045 y^24 + 890560 y^28 + 507045 y^32 + 91168 y^36 + 5082 y^40 + y^56 n=40 menu row family (a,b) W_40(a,b) = 1 + a(y^16 + y^24) + b y^20 + y^40 |E| = 2 + 2a + b (a power of two), d(E) = 16 Higher-genus n=72 (also computed) genus-2 biweight : uniquely forced (1177 coeffs) genus-3 triweight: exact 6-dim invariant space (1 forced row + 5-dim freedom, none pinned) -> Enumerators tab Ledger from MENU MENU at a glance 132raw rows 60eliminated 72surviving 51witnessed nonempty 21unresolved existence Proof-grade eliminators TestRowsPublic label T02 pImg32dimension and fiber divisibility T05 3bNN7three-block nonnegativity T06 Smth16toggle-stabilizer Smith congruence T08 John1Johnson/Delsarte two-point bound T13 dShr1double-shortening forced intersections T19 Sim1Simonis support-weight feasibility T20 g21coupled genus-2 biweight feasibility T32 exists1route-3A direct existence exhaust C5 sub-menu — an automorphism-conditional tag The menu assumes no symmetry, but the C5 branch leaves a clean fingerprint: a code with a C5 automorphism forces a ≡ 0 (mod 5) on the length-40 row of a fixed disjoint anchor pair. So a C5-symmetric code must cast one of these 16 surviving rows (14, plus the two reinstated (7,15,96) and (8,55,144)): k6: (5,52) (15,32) (25,12) k7: (15,96) (25,76) (35,56) (45,36) (55,16) k8: (55,144) (75,104) (95,64) (115,24) k9: (135,240) (175,160) (215,80) k10: (295,432) What the tag means. Eliminating all of these by automorphism-agnostic tests would close the C5 branch with no Hermitian F16 search. The converse does not hold: ruling out C5 does not remove these rows, since a trivial-automorphism code could still realize any of them (RECURSIVE.md §30). Full list on the Menu page. Public test pages T1 through T32 Search Downloadable data Weight enumerator catalog Enumerator JSON The JSON bundle collects the enumerator-like outputs now staged for public review. Large triweight coefficients should stay machine-readable; the page can show summaries and let visitors download the data. JSON bundle Manifest JSON Genus-3 invariant spaces The invariant-space bundle collects AGL/GL nullbases, n=40 converted bases, d_n+ atoms, and n=72 candidate-space reconstruction artifacts. Invariant bundle Full triweight routines The routines bundle is meant to include row/column symmetrization, support-pruned transforms, different-prime runs, and reconciliation scripts. That makes the computation useful beyond this project. Source bundle Length-40 row family W_E(y; a,b) = 1 + a(y^16 + y^24) + b y^20 + y^40 Triweight service goal row/column symmetrization + modular prime runs + reconstruction/reconciliation -> reusable genus-3 enumerator tooling Community surface How people can help The public site should make contribution paths concrete: choose a menu row, choose a test layer, improve a certificate, or propose a new obstruction. Join the discussion Questions, ideas, and progress live in the #extremal72 channel of the Error Correction Zoo Discord — the place to ask where to start, claim an open problem, or share a computation. Join the EC Zoo Discord — #extremal72 Focused open problem: can a glue be ruled out? Many attempts to glue a known length-40 code up into the pivotal [56,21,16] residual have neither produced a glue nor proven one impossible. It is a sharp, self-contained challenge spanning exact algebra, SAT, and SDP, with a clean line between what is proven and what is only search-exhausted — a good place to bite in. Ruling out a glue — the open problem Immediate public tasks Turn each T-page into a short, checkable mathematical statement. Package the T32 direct-existence exhaust for independent replay. Upgrade T29 from linear feasibility to a stronger PSD-certified layer. Rank the 21 unresolved surviving rows by promise and cost. Prepare the full triweight routine bundle for public reuse. Write a one-page explainer connecting the code to CFT and CSS objects. Ideas sketched but not yet pursued Sharper design-theoretic constraints on length-56 minimum words. Alternative anchored SDP formulations with smaller exact blocks. Independent reconstruction from the length-24 endpoint upward. Classification-assisted searches in the length-40 layer. Public leaderboard for verified row eliminations and witnesses. Bibliography References Every paper the project drew on, each tagged with the tests and enumerator objects it fed. Generated from data/references.yml (81 entries). Search