lynchdt

Irish accent appears to break it.

I mostly agree with this. If you observe the KPI set used to run support teams, especially with large inbound you will see NPS used as a proxy for quality of resolution but folks mostly don’t respond to those prompts.

More interesting to support team managers are things like deflection rate (didn’t get to an agent) involvement rate (needed an agent) and eventually resolution rate (resolved issue). The last one in the absence of feedback is only a very weak proxy for a resolved issue.

If you consider customer support a cost center, you can guess how managers would optimize these numbers.

I don’t necessarily think there is much wrong with this - having a good product with excellent design, build and proactive support (docs, manuals, walkthroughs, proactive comms) - is likely very good for both customers and the business serving them.

I mean sources of incoming work, could be a quick question, an ask for something, automated alarm or a bug.

Slack makes it super hard to stay on top of this and systematically triage the low from the high value.

I work mostly with Engineering teams, and consider slack inbound a pathology. Slack is great for collab in places, but it’s not a strong way to manage inbound, IMO.

The teams I’m responsible for make it easy for their stakeholder to raise issues, asks in a more deliberate, calmer way e.g. via GitHub issues or manager email. In exchange, we commit to mutually agreed response times on certain categories of business critical issues.

Generally, I don’t think it takes an ADHD diagnosis for slack inbound to completely kill your productivity, it’s a general problem. I don’t have ADHD but have strong empathy for how this must be a complete nightmare for you.

Perhaps have a manager put some structure on your inbound on your behalf?

The best advice I can give is don’t treat it like an irreversible fork in the road or a path that won’t ultimately make you a better engineer. Find the right environment and give it a go!

I wrote a bit more detail here: https://www.linkedin.com/pulse/become-better-engineer-try-ou...

Yeah, it’s really hard to be overly critical. You could argue the government did its civic duty here, public sentiment was overwhelming in favor of reduced restrictions.

Unfortunately, as detailed elsewhere in comments, enough of the populous didn’t respond in kind in fulfilling theirs - which is what the decision needed to work.

That said you could also argue this was predictable. Our diaspora are scattered about the globe, and coming home for Christmas is a common event and our UK border basically doesn’t exist. Similarly, folks who are originally from elsewhere in the EU flying home for Christmas then back.

Overlay the drinking/socializing culture, which hits its busiest period around December and watch the R number tip upwards.

Full disclosure: I agreed with this government decision at the time, but was quite surprised / shocked at the resultant case explosion.

Also Irish. +1 on your assessment here. The virulent strain narrative was peddled by the Irish government who went against medical advice and tried to deflect blame. The evidence doesn’t support the narrative.

I think the COVID-fatigue angle is quite interesting though. As critical as I am of the government they were under a lot of pressure from the populous to provide some sort of respite.

I didn’t leave voluntarily, miss a lot of things but I absolutely don’t miss this.

I’m surprised this book didn’t come up sooner, it’s a fantastic book.

To my knowledge the only book mentioned here that takes the time to define technical leadership and present models of leadership suited potentially to different circumstances.

I might add ‘The art and science of doing engineering’ by hamming and recently republished by stripe.

The more leadership or management books I read the more inclined I am to respect Taleb’s approach of looking for old timeless material rather than what’s new or hot.

Most of what Gerald Weinberg has written qualifies IMO. Tom DeMarcos books also.

This is the crux of it. Even to a well calibrated tech recruiter, the resume reads thin on substance.

Maybe I was a little terse in my response. Humility often comes hand in hand with a growth mindset and a real eagerness to learn. Not hiring for that limits the long term upside of the hire ie you get what you get right now.

Some perhaps unsolicited advice from a hiring manager in a company very similar to the great ones in which this writer was unsuccessful.

- Rare programmers won’t identify themselves as such.

- Most great companies hire for humility as a trait.

That's great context, thanks!

This is a pretty cool idea, so I signed up and eventually got...

'report will be ready shortly'

Would be great to have a lot more context on what this means.

2200 on food per month, utter nonsense. 380 on baby kit per month for children in preschool? Nonsense.

Recently moved to SF with family of 4, combined income of about 130k less than this and living well including private elementary schools and preschool.

Don't need a car here, even with a family.

We furnished our place with a bunch of stuff folk were giving away for free

We eat well, sometimes out.

This us utterly hypnotic. Nice work.

So the 'Daily Mail' makes the front page of HN. Interesting times.

We tried Evernote for business in our office for around 6 months. The sharing and communication feature-set was really bad. In a shared notebook we ended up with 'conflicted copies' of lots of important notes that really needed to be an authority on things. The 'Work Chat' feature is spectacularly bad and unusable - to the point of comedy. Most of us flipped way to using Google Apps and Keep Notes, which just really nails collaboration and keeps everything nice and simple.

In my opinion Google doesn't get enough credit for it's Apps offering. I see lots of articles on here and elsewhere that deride it as a 'search company' that 'can't build product' - but I really think they're quietly building an excellent product suite.

Nice job man, this is some great work for somebody your age. I know 'senior engineers' twice your age who couldn't write these notes, nevermind code it up.

http://acuman.us/about.txt

Are you sharing source?

Nice work, this is great stuff.

It's all hunky dory, mostly, until you jump from 2090 to 2100. At that point the apocalypse hits, obviously.

I tried to write something somewhat balanced, with respect to engineering a feature while leaning quite heavily on MongoDB. It has worked out quite well for us, and we continue to see relevant updates to the MongoDB product that remove some of the hoop jumping, which is encouraging.

This is really cool, nice work.