Don’t newly produced meds require new FDA clearance/approval, with clinical testing and all the like? I mean how else can you prove that your new drug production is effective and causes no new harms
I do avoid uv run for this reason but it’s useful for managing python projects. The speed claims actually have a lot to do with efficient caching, and I run several projects on the same Python (patch) version with similar packages on the same system
The part I find challenging in the senior-staff twilight is that having deep technical knowledge means I can solve short term problems, just as requests, fast and effectively.
The author mentions that you should spend time understanding the frustrations from other teams, but that takes up loads of time and I don’t like being the person who talks and talks but doesn’t push code and ship features. I’d love to hear how others have experienced that
Like you, I dislike the "talker" role for people on IC ladders. I often encourage those people to switch to Director+ roles.
The flip side is people who get and stay too far into the weeds. Solving little problems here and there is a great way to keep your finger on the pulse of what's actually going on.
But if you get totally bogged down in details, you are probably avoiding your leadership responsibilities. You should be observing the structural or strategic opportunities, and then dragging the org(s) in that direction.
Sometimes you do that by writing some code to prove a point, other times you do it by getting the nearest VP to take something on as a commitment. For me, personally, I find that the style of work waxes and wanes. Sometimes I get almost no code committed in a month :(. Other times, I get to go off and do some work that nobody else would have done.
I prefer the latter, but I respect that my job requires the former. Many of the people who you see spending all their time talking believe that's the most responsible use of their time. They might not personally prefer it!
Once upon a time my grand-grand-boss explained that he had no problem hiring top-notch engineers - pick up the phone, call recruiters for new candidates, connect the incoming stream to the interview pipeline, two months later you get the requested quantity of engineers. OTOH there is no repeatable process to hire someone who will help identify the right problems and drive them to resolution. So if such person is found they will be pushed towards doing things that have no obvious success recipe and away from the things that do.
> I don’t like being the person who talks and talks but doesn’t push code and ship features
I’ve experienced this. The critical realization for me was that most of those problems which I know I can solve quickly, without even having to write a Jira ticket or groom them into a sprint or whatever, are problems I should let someone else solve.
Sure, I can do them faster than others and pretty well. But if they’re truly things I can knock out in a day or two, they’re things that other staff can knock out in a week or two, and learn from the experience, and at that size they likely don’t require the standard of quality that I delude myself that I hold myself to.
At the lead/staff level, it’s far better to look for the kind of problems described in TFA: problems that are complex to identify, and for which the appropriate solutions aren’t always the obvious ones. My time is spent much better looking for those than being a 10x-speed senior engineer or whatever. There are actual senior engineers for that; I’m paid for the kind of work that they don’t or can’t do (yet, and to help model and mentor and train them to be able to do it), not to do the kind of work they already can do—whether I would do it faster/better doesn’t matter.
It’s case-by-case of course; sometimes a simple issue is critical or obscure enough (or tempting enough to override my iffy-at-best self-discipline) that I’ll jump on it. But I generally try to remember that a lot of the stuff I could look heroic for fixing in a jiffy is probably both not worth my salary allocation in the eyes of my grandboss, not critical time-wise, and a potential learning/accomplishment opportunity for others.
Yep. Look for the problems that aren't going to get solved without you - either because nobody else sees the problem, nobody else is positioned to be the solution, or because your skills uniquely line up. That can't be all you do, but it's the highlight reel.
I find that I often tik-tok between organizational work and deep technical work. (I come close to the "solver" archtype on https://staffeng.com/guides/staff-archetypes/). There are weeks-months when I am not writing a ton of code. I'm still doing technical work, but it's architectural documentation, experimentation, or discussion where my contributions aren't directly visible in commits. Then there are weeks where I ship dozens of PRs.
I'm often thinking about 1-2 immediate term problems (what am I coding on now), 5+ medium term problems (what am I planning to work on next or moving such that someone else can work on it), and then a handful of long-term problems ("this is currently intractable, how do I convince leadership/this other team/etc. to make it possible for someone to actually address the technical problem I care about").
1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness.
2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks.
You can limit chit chat very well this way.
You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition.
For technical teams, almost every single thing I ship:
1. cements a new pattern or contributes to a new one that my team can use
2. improves cicd speed or checks
You can usually knock out the non technical team work and pick off 1 from technical team work along the way
Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort.
I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle
Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals
I think that's a completely natural source of frustration for someone who is used to being able to put hands to keyboard and solve problems quickly, but IMO the higher you climb the ladder, the more you have the opportunity and responsibility to take a longer view and to delegate - which often means that other people are pushing the code.
Radiologists very often have to weigh up different theories, guidelines based on the symptoms. The certainty of their diagnosis is their added value, or if they don’t know they will tell you why.
An AI telling you it could be X or Y because theory ABC… is the academic answer and a luxury clinicians don’t have. AI doesn’t give you what you want. I don’t see any added value in using generic AI models for this
You’re completely right, this is why currently ultrasound reconstruction happens on FPGAs. They would need a lot of them given the number of transducers.
https://pmc.ncbi.nlm.nih.gov/articles/PMC6057541/
MRI physicist here as well. I have a basic understanding of ultrasound, and this looks like an array of transducers organized to perform tomography, just as CT did for Xray.
However Ultrasound quality depends highly on transducer-skin contact.
Any physicists here to comment on the effects of sonar through liquid and the effects on image resolution and field of view?
This is precisely why you do it in water - the water-skin contact is effectively perfect, as is the water-transducer interface, and the body of water is easily characterizable; in effect you are scanning one large object that consists of a body of water that just happens to have a human body in it, and then extracting the body from that scan.
The water is a clever impedance matching trick. The contrast in density between air and human flesh is high, so the waves all reflect off the surface rather than penetrating and reflecting off the internal structures we care about.
That's why normally you're concerned with really good transducer contact (squeezing out any air) or use a gel to match impedance.
I'm a bit rusty on CT, but I'd guess the resolution is proportional to the total number of transducers in the array (e.g. larger sensing surface equals tighter resolution) since you're basically taking a Fourier transform of the incident wave.
This has factored out product development, which is more than compute resources. Just like any industry, some organisation needs to take ownership and responsibility to convert technology to a usable product.
That only tells what base architecture they used, but fine tuning does not increase the number of weights, it just adapts the weights to improve better on a fine tuning dataset- something they claimed they had done
reply