FYI: At Microsoft, in Windows, the job might be PM or TPM, but the people aren't. A person is expected to be able to switch their focus from one to the other.
At least, that's what we PMs were told when Microsoft Windows rejiggered their PM roles
When I moved to Microsoft 15+ years ago, I went from being a developer (for 20+ years) to a PM. 9/10, would recommend. But also know that it's a very different skill set that you'll need to learn.
The simplest example of this: as a programmer, when your boss says to code a feature, you code it. But as a PM, you have to get a team to make it.
A PM's job is to figure out what the feature really is, and how complex or configurable it should be, and what the target audience is, and how you'll measure success. It also involves making sure that you feature works well with other features, and that your team is moving in the same direction as the rest of your company.
Be prepared, BTW, for the constant assumption that you became a PM because you couldn't hack it :-)
Thanks for advice, and yeah that makes sense that I’ll have to learn a whole new skill set, but I enjoy learning.
When talking about a feature, am I doing basically high level system design? Similar to what a senior engineer does (aka this should be a cache, it’s best to change this to streaming so let’s remove the audit db, etc) or is it even more high level than that?
Also lol at the last line, never heard that but I can see why people might make the assumption.
I literally had a dev manager say it to my face! "I guess you were a mediocre programmer or you wouldn't have become a PM"!
No, you aren't doing that kind of high-level design. For example, I was the PM for the "connect to Wi-Fi via a QR code" feature in Windows (you're welcome!). As PM, my job was to :
- demonstrate that this was "thing" people would want to do
- demonstrate that it slotted into the existing feature set (the existing Windows camera already reads QR codes, so we just had to use their existing hoooks)
- do a quick evaluation of the WIFI: protocol (which, BTW, sucks; it's one of the worst standards I've ever seen)
- do an evaluation of the overall market (like, what do other operating systems do)
There was also some discussions with the Windows Wi-Fi team for how to store the connection data since it wasn't a perfect fit for the our existing connection store, plus a security evaluation. You won't do anything about caches or streaming except that they will naturally fall out of your spec.
You'll learn a ton about writing convincing documents, how to find users and partners, tracking schedules, and stuff
Among other problems: the variables est and estTime are both mis-named. The correct name for "the time in New York" is Eastern Time.
Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.
Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.
Hi @rsclient! Thank you for taking the time to read the post and providing the feedback. I've gone ahead and updated the post and library code based on it.
> the variables est and estTime are both mis-named. The correct name for "the time in New York" is Eastern Time.
Yes, that is a good catch. The variables were mis-named and should have been "eastern" (ET) and "pacific" (PT) and not EST/PST given that "America/New_York" and America/Los_Angeles" were the reference timezone. If someone just wants EST or PST they would need to create a timezone bound to just that. The library supports statically typing either and would prevent EST/ET or PST/PT from being used interchangeably.
> Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.
Yes, agreed. The original naming was not correct and has been fixed.
> Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.
he library should be able to support this behavior, but it would be important for the caller to know what timezone they should be using: (i) Navajo nation would use a timezone bound to "America/Denver and (ii) everywhere else inside would use "America/Phoenix". [1]
> Among other problems
I appreciate you raising the points above! I hope you can see I am open to feedback and take improving this work seriously. If you are wouldn't mind sharing the rest of what you are seeing, I would be interested in hearing more.
What is it about computer people that they see a flood of open, free, engaging material about computers, and think, "I should put up an artificial road block so that fewer people read my writing".
The blog post presents exactly one side of the issue, "what happens if a lawyer alleges child abuse knowing it to be untrue in order to extract a settlement". But it doesn't even hint that there's another side: what is one parent is actually engaged in child abuse, and the other parent is trying to protect their kids from it".
Incorrect. The maintainer isn't ignoring anything; they are considering the request and deliberately rejecting it because of their preferred style guide.
Things to not do include: randomly picking medicine "X", have it hyped up by a weird republican hype machine, and then bitterly complain when the unwarranted, evidence-free hype is denounced for being unwarranted and evidence free.
Phrased differently: Ivermectin was picked up by the republican hype machine, pretty much at random. The medical community, seeing a lot of absolute hucksters pitch a whacky treatment, fought back with mockery and derision. As it turns out, the medical community was right.
You sound like someone who clearly bought into the derision. All the comments you made were the same shallow arguments made against it without providing any meaningful point.
All those things could be true and yet it means nothing in terms of whether Ivermectin was ineffective in treating COVID. This article proves that it was at worst on-par with general treatments and at worse better!
> article proves that it was at worst on-par with general treatments and at worse better
This is a misreading of even the abstract.
There was no ivermectin-only test. The study found ivermectin was, at best, ineffective as a complement to usual treatment. It doesn’t bother to characterise the downsides.
Going purely off memory, I don't believe the Ivermectin hype was purely random. It was thought early on that anti-parasitics may be helpful with CoViD, and Ivermectin was one that people explored. It showed some early promise, although I can't recall how rigorous this promise was. Eventually the hype machine got hold of it, but that was largely an engineered situation, where those who were interested in its early promise dug their heels in in the face of over-the-top derision and bad faith attacks like "horse dewormer" jibes, which then mixed with anxiety and conspiracy thinking on both sides and resulted in a total inability to discuss this stuff reasonably. You should also keep in mind that while all this derision is going on, there isn't actually a medicine around that shows promise. People talk about this stuff like there was a perfectly good cure going around, but that was never the case.
Finally, the OP already stated this post wasnt made to prove Ivermectin effective, but to show that its utility is not something dismissed out of hand by actual redearchers. Knowing nothing of the providence of this paper, I can't comment on whether it achueve that, but you're not moving the conversation in any kind of positive direction with your (plural) reactionary commentary, that's clearly hitting a nerve with the OP.
I used to program many different terminals, back when they were a thing.
A classic terminal only has a screen full of memory: it does have extra memory that would allow it to scroll backwards.
The ESC [ S command (CSI itself can only be used if you are sure the line to the terminal is 8-bit clean, and as a third-party developer, I could not guarantee that) scrolls the scrolling region. The scrolling region is either the entire screen, or it's just a couple of line at the bottom. A scrolling region is used so the use can have a scrolling place to type commands and Aldo have a non-scrolling area to display data.
At least, that's what we PMs were told when Microsoft Windows rejiggered their PM roles