ath0

The name is a play on the author's last name (Josh Wardle): https://www.nytimes.com/2022/01/03/technology/wordle-word-ga...

If you read nothing else, the commit message adding JIT support is worth your time: https://github.com/python/cpython/pull/113465

Do you want ferret Doctor Manhattan? Because that’s how you get ferret Doctor Manhattan.

If by any chance you’re the graphic designer who picked South Williamsburg hotspots for the iOS preview screenshots… well, hi neighbor! Good choices.

“Position in band” is often a factor in performance reviews. Consider a common process - say you’re “senior level” and in your review you’ll be rated on six categories, then given a raise based on where you are overall relative to “meets expectations.”

If you’re senior but at the bottom of the senior band, and you’re mostly “at expectations” for your level but maybe “slightly below” in 1-2 categories, you’ll probably still net out at “meets” with a normal raise. If you’re senior but the highest paid senior - that’s probably going to net out at “below” overall, or zero-to-small raise.

Counterpoint from Josh Sokol, former OWASP board member: https://www.linkedin.com/feed/update/urn:li:activity:7031305...

The OWASP nonprofit isn’t like the well-funded Linux Foundation; it runs on a shoestring budget made worse by the loss of conference revenue during the pandemic. OWASP charters events, local meetups, training content and OSS projects - the authors of this memo focus only on the OSS project needs. The OWASP board sees itself as community first and foremost; projects should seek their own sponsorships.

Lots of stuff in the comments already about dual-track and external career options.

I'd add: can you hire a deputy who enjoys doing this?

* Ask for the next project management hire to be a true TPM, and try to pull someone who's working on something boring but is really interested in getting into your area of technology. Have them run all the Jira, summarization, execution of planning processes, comms & coordination. You'll still need to own hiring, still need to do a lot of people development work and still have to get involved in marketing & product strategy - but might get some leverage in internal pieces you don't like.

* Promote or hire another person who shows interest and aptitude in management, with the explicit plan for them to be your deputy and to take on some of the "tasks you don't really enjoy," especially if scoped to a specific area. Can you structure your work so someone else is responsible for 50% (or even more) of it? Can they do the RFP first-pass reviews, and even be responsible for pushing back on things in their area of responsibility? Can they manage some of your directs, and co-lead some of the above processes within their scope? There might be someone on the team who feels underutilized, wants more visibility, has strong relationships and is willing to learn. And if there's not - that's signal for you and your hiring process that maybe you've only hired folks like you; it may be time to have a broader set of folks on the team.

Several of the concerns revolve around the complexity of managing multiple IDs (product SKUs, prices, etc) for a single subscription - and the author reaches the conclusion that this is because it's optimized for "e-commerce and not B2B SaaS".

While from the buyer's perspective, "single negotiated cost with overages" may appear simple - it's a single bill after all - on the accounting side for the company selling the product, I'd expect it's much more complicated; with potentially different tax rates for different products and complexity around producing an auditor-defensible determination for "cost of goods sold" and "marketing expense."

So for at least some of these requests, I see Stripe's posture here as helpful - it's not "requesting a dollar figure", it's "creating a detailed enough accounting trail behind that bill to operate your business." Looking across the breadth of Stripe's products, I'd give them the benefit of the doubt here.

Her speech early in the Covid-19 era was one for the ages[1]: Short, personal, reflective of history yet with a clear call-to-action for her country. I'm not British and also found it exceptional.

[1] https://www.reuters.com/article/health-coronavirus-britain-q...

I'm long past my academia phase, but recently led the PC for an industry conference (accept rate: ~15%).

1. Curation is important both for the physical limits (venues only fit a certain number of people), attention limits (attendees will usually retain only a handful of "nuggets" no matter how packed the agenda is) and interaction limits (you can't meet everyone at a large conference).

2. If the goal of a conference is not just to "stamp" research as somehow "approved", but to encourage discovery and knowledge exchange that deepens a specific area, it's important to apply that curation filter with an eye toward best advancing the goals of the conference. That means not just going for things that are okay, but those that best resonate with other presentations / attendees / research topics.

3. While the size of any one conference has to be fixed, tech has made it infinitely easier to create new conferences and journals with other focus areas. They may not start with the prestige of a larger journal, but if the papers published start to have an impact, it can catalyze an entire subfield of work.

Some conferences can be tied exclusively to "novelty" - ACM academic conferences - but others to "incremental advancements" - the bigger industry conferences in security, like Usenix Security and some to "best explaining ideas" - like Enigma.

There are new ways to find an audience for your work and create impact - that's part of the job now.

Found headspace helpful but only really noticed after a month where I made time for it every morning. In particular I appreciated some of the techniques in different courses - different forms of attention and focus, noting, visualization. My consistency has fallen off and I can see an impact on ability to find and stay in flow; but even without a regular practice I find I’m more aware of when and how I get distracted and don’t fall quite as far away from it.

Depends on the diagnosis!

Two blog posts: [1] from Rands on skill vs will.

And [2], from Roy Rapoport on a five-step process for dealing with problems.

In both cases, it’s not enough to say you “don’t trust” your team. You have to do the work to diagnose WHY things aren’t working the way you want - do they see there’s a problem? Do they want to fix it? Do they have the skills?

Trying to fix a problem you can’t diagnose is going to be very hard.

[1] https://randsinrepose.com/archives/avoiding-the-fez/

[2] https://medium.com/@royrapoport/the-five-conditions-for-impr...

One and only one data point: the handle allowing the chair to move forward and back broke 2 months ago, about 6 months out of warranty. (Great for my partner, who now has exclusive use of the bike in her position… not so good for me.)

Support originally wanted to charge me $250 for replacement and service. A few YouTubes and a second call, the service person admitted that a $5 part would probably do the trick.

It’s taken two full months from that support call to get the shipping notification on that part.

Other than that, though - my experience with the bike and classes has been positive.

In a sense, the US government does the same thing. In the US tax code, you can can deduct business expenses to reduce taxes — ie, subtract expenses for a corporation you control from your personal income. This has been known be abused, as folks deduct their personal car, house, travel… as a result, if you have a business that goes long enough without a profit, the IRS will look really hard at it to make sure it’s not really leisure.

https://www.irs.gov/pub/irs-utl/irc183activitiesnotengagedin...

OAuth tokens used in automation tools will continue to work. Entering in username & password through auth, to automate an OAuth flow (or any other traditionally manual flow) will stop working. Breaks some puppeteer scripts too - but those have been getting flaky for a while now.

Sounds like you've mostly worked in perfectly-sized and structured corporations, where the auditors and policy-writers were perfectly connected to changing product, business and technical needs; well-staffed with policy writers and architectural governance committees who have the time, skill and background to have regular, even-handed tradeoff conversations when these issues occur, and where the engineering teams are prepped and able to engage in those conversations well.

Are they hiring?

Not really a fair assessment.

An auditor's job is often to check if you're doing what an external standard says you should be doing (SOC 2 => AICPA trust principles; FedRAMP => NIST 800-53, etc.).

Unfortunately, these external standards may be written vaguely and while you may have policies that define X as Y, the auditor doesn't have to accept your answers. For example, when PCI requirement 5 says "Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).", your policy may say "antivirus is not required inside containers that run on platforms like GKE, as these are not commonly affected by malicious software." It's very likely you'll have a discussion about your interpretation of that requirement.

In the Americans with Disabilities Act, US law states that if you're going to create a place of public accommodation, there are certain minimum standards you must adhere to, to support those with disabilities. So you must install ramps and elevators for the mobility-impaired, offer audio-only interfaces for the blind, sign for the hearing impaired, and so on. These apply pretty broadly.

We can argue whether Australia's legislation is a good thing, but "if you are going to operate here, these are the standards you must follow" is not beyond the pale.

The GSA publishes their regulations for registering .gov domains: https://www.gsa.gov/policy-regulations/policy/information-in... . In short, an authorized representative of the agency (head or CIO) needs to send a letter: https://home.dotgov.gov/registration/authorization-templates... . It's safe to assume that, since those partitions were created as part of a federal contract, those letters were a normal part of the buildout.

The thing that made this bug possible was because, while your Apple ID has to be an email address, Apple has a mechanism to avoid exposing it to third parties - unlike Google, Apple, or Facebook's single sign-on implementation; the bug seems to be in the step between verifying your identity and telling Apple whether you would or would not like your email address to be exposed.

If anything, the issue is that third parties treat the email address as a unique, unchangeable identity, and then agree to rely on Apple's assertion of what your email address is. But given how hard identity is - and the challenges in dealing with passwords, account recovery, and name changes at scale - it's a pretty reasonable tradeoff to make.

There are a bunch of great references for career ladders, broadly speaking, that discuss the rollout process and what each level means for that company. The best not only say something about the levels, but about how the levels are interpreted in line with that company's culture, whatever it means. It's very hard to get to levels beyond senior as a pure generalist: you're typically going to have to have worked on projects with significant, company-wide impact, and that usually means (a) doing something unique within a domain and (b) working with many others, in different types of roles, in your company, in order to have that impact.

Two good intro readings on career ladders:

https://labs.spotify.com/2016/02/08/technical-career-path/ http://dresscode.renttherunway.com/blog/ladder

The trade in status - what this article calls “the importance game” and “the leveling game” - are a core part of what makes conversation hard. If you want to learn more - or are having trouble getting the feel for examples of why this is so important in practice and how to use it - a book recommendation:

A previous gig gave us Keith Johnstone’s book for theater actors and writers _Impro_ as part of our onboarding. Chapter 2, “Status”, is entirely on this concept, and how status exchanges are a key part of what makes scenes interesting and relatable for viewers. At the time it felt like an odd choice for an engineering role, but after reading the detailed examples of status exchanges and how they work, they became impossible to unsee.

And that was great, because I gotta tell you, HN: applying this skill has made me a much more effective technical leader.

Wishing for status exchanges not to happen isn’t helpful - they’re happening whether you see and intend them or not, so learning how to spot and use (or avoid them) effectively made it, maybe paradoxically, much easier to have difficult, important, multi-layered conversations with people - other engineers, other departments, customers - about hard problems and get them to a good resolution.

As the industry does some soul-searching about the way power is perceived and used differently by different groups, understanding this topic should be seen as core to leveling up.

Because this is Hacker News, the discussion would be incomplete without a link to the Supreme Court case Nix v. Hedden[1].

After the Tariff Act of 1883 taxed vegetables (but not fruits), produce seller John Nix — no relation to the package manager — sued to get tomatoes classified as a fruit.

The court held that the “common meaning” mattered more than the botanical one:

“Botanically speaking, tomatoes are the fruit of a vine, just as are cucumbers, squashes, beans, and peas. But in the common language of the people, whether sellers or consumers of provisions, all these are vegetables which are grown in kitchen gardens, and which, whether eaten cooked or raw, are, like potatoes, carrots, parsnips, turnips, beets, cauliflower, cabbage, celery, and lettuce, usually served at dinner in, with, or after the soup, fish, or meats which constitute the principal part of the repast, and not, like fruits generally, as dessert.“

If you’re in New York, you can celebrate Nix’s memory by eating at a fancy vegetarian restaurant[2], or, of course, you can just use the package manager or operating system.

[1] https://supreme.justia.com/cases/federal/us/149/304/ , or see the wikipedia page https://en.wikipedia.org/wiki/Nix_v._Hedden [2] http://www.nixny.com/

Hardly! It's about impact & working with people who complement your weaknesses - think about how much you don't know, even just as an engineer.

A more senior leader I very much respect - when I was about to make the transition - put it this way: "I was doing great as an engineer but had so much I needed to get done, so they helped me put together a team of 4, which was great, because I could accomplish almost twice as much; then it was 30 people and we had a whole product I was proud of. With 200 I know I'm changing the industry..."

You have to learn different skills - how to motivate people, how to see potential conflicts and roadblocks and use them constructively - but the technical skills you bring to the table can make your impact much stronger; and I think I get to learn new ones at a much faster pace at a compromise that I can't go as deep in more than a few spots compared to full-time engineering.

The 1GB redis instance on hosted infrastructure typically comes with opinionated defaults - and tight integration with the hosting provider's other offerings - for security, monitoring, resiliency, support and license management. If you're only going to run one or two Redis instances, $500/year compared with the additional engineering time required to handle anything other than just tossing the box on the Internet starts to look pretty reasonable.

Let's dive into the "discipline" advice and get practical:

1. Find ways to create cues for yourself to separate the two kinds of activity, and use those cues to hint yourself - create that half-second of separation that gives you a chance to stop, recognize what you're about to do, and make a personal decision about whether you want to continue.

For example, split by device: your phone is for addictive and fun activities; and your laptop is for enriching activities. Or by browser: Safari is for fun and Chrome is for enriching. Or by time: fun before noon, enriching after noon.

2. Write down your intent and start to track for yourself how successful you are at tracking toward your goal. You can use iOS' screen time for this, or RescueTime, a pomodoro timer, or a tangible cue - pen and paper even - that gives you the feedback.

3. Be realistic: start with tracking and don't try to set a massive, aggressive goal ("no addicting activity") up front. You're going to need time and energy to build new habits, and you can't rely on having both consistently: it might be easier to notice your habits when you're less tired at the beginning of the week, or on days you're lucky enough to have fewer meetings. But start, try, and be consistent about getting better through time.

To be clear - this isn't novel advice - you may recognize parts of it from OKRs (write down your goals and revisit them weekly), from "one habit a month" self-help blogs, from mindfulness training, or even from cognitive behavioral therapy techniques. Various tweaks on this formula might be necessary for your personal brain chemistry. But practice can give your brain the space to notice the underlying concepts and get better at it.

(Not A Lawyer disclaimer)

There's a tax law reason why this isn't a trivial change. Best reference I could find is here:

https://thestartuplawblog.com/incentive-stock-options-post-t...

In short, to be treated as an Incentive Stock Option - which comes with benefits for you (taxed as capital gains, not as income, if you hold 1 year from exercise and 2 years from grant) and for the company (different accounting treatment and they don't have to withhold taxes at exercise time) - the option must expire within 90 days after your employment.

Some companies are now moving toward treating options as NSOs if you keep them after your employment, and ISOs if you exercise them during this period - but this kind of change comes with lawyers and accountants (and maybe even a change to the stock option plan approved by the board of directors) attached, so it's not easily negotiated for a single employee.

I support these 5 levels of logging, but given the discussion below I also would like to highlight a lesson from an SRE talk I once attended[citation needed] that really there are only three levels of alert:

1. DEBUG - Look at this when debugging, otherwise no one will ever see it. 2. TICKET - Open a ticket and have someone on your team look at this when it gets to the top of your queue. 3. PAGER - Drop what you're doing and handle this, now.

Of course, you want to track INFO and ERROR type messages because a sufficient number of them might cause someone to raise a ticket... but at scale, you probably should've built that monitoring already, and just drop INFO/ERROR down to DEBUG.

"What more valuable allocation of your time could there be than in talking directly to people?"

Taking action, based on the what you've learned while talking directly to people.

A manager's output is the the output of the teams under his or her supervision or influence[1]. That means you have to find the highest-leverage activities: sometimes that's a one-on-one conversation, up, down or sideways. Sometimes it means sitting down and drafting an email or other written document that compiles all the little details you've learned into something meaningful and actionable for the people around you. Sometimes it's about being in front of a group and enabling a conversation that you're not directly at the center of, but which wouldn't happen well without you present.

Which isn't to say your manager at the time was right to dismiss your concerns, or was doing the most high-leverage things they could do. But the perspective might be useful.

[1] High Output Management, Andy Grove (former CEO of Intel). One of several great management books that help clarify "what management is and is not". And if you have never read anything in the genre, I'd start with Managing Humans, by Michael Lopp (randsinrepose.com). Life-changing for me when I was trying to figure out the same thing, before I started doing it myself.

This is a case where the high-level point - "insecure options shouldn't be configurable" - conflicts with a reality of crypto protocols: you have to make tradeoffs based on the best known attacks and the platform you're running on, and those change over time. The best hashing algorithm, HMAC algorithm, and signing algorithm to use on a mobile device in 2007 isn't the same as the ones you'd pick today. Any protocol expected to last 10 years should allow for the selection of an underlying crypto algorithm. Maybe "none" should never have been an option - but tying the algorithm to the protocol has pretty severe drawbacks, too.

More broadly - JWT isn't just about the exchange between a single client and a server; the choice of "use cases" misses a very real constraint of multi-party protocols. Within the context of OpenID (or OAuth more broadly), it's about the relationship between an end-user, a resource owner, a client and an authorization server -- all of whom need to be able to interact with a token, and often offline.