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.

The search space is all tunes that have been played on Soundwave from all sources plus a large source with a huge catalog. Soundwave sources include Android Native, iTunes, Spotify, Deezer, Rdio, Pandora, Deezer and a few others. The authority source has a about 20 million tracks.

Bandcamp is not something we have support for right now, but it's been requested a number of times, and we like to listen to our users. Soundcloud support was a result of a very vocal group of users with the same perspective as you have.

Stay tuned!

My son is a few months old and I work for an early-stage start-up. Man, stop coding at 2am - what you're hacking will need re-hacking in the morning. Go home to your daughter. There will always be tasks on your board. The only sure thing is your daughter will grow up - quicker than your start-up will fail.

"To buy us time, we ‘sharded’ our MongoDB cluster. At the application layer. We had two MongoDB clusters of hi1.4xlarges, sent all new writes to the new cluster, and read from both..."

I'm curious about this. Why were you doing the sharding manually in your application layer? Picking a MongoDB shard key - something like the id of the user record - would produce some fairly consistent write-load distribution across clusters. Regardless - it seems like write-load was a problem for you, yet you sent all the write load to the new cluster - why not split it?

I echo this entirely - nice work guys.

"But another possibility is that we engineer the perfect happiness drug, with no bad side effects, and no one wants to do anything but lay in bed and take this drug all day, sapping all ambition from the human race."

That would be a pretty bad side effect in itself. There are some pretty nice drugs that approximate what you say, yet as a population we mostly get on with our lives.

It's not in our nature to be satisfied with any persistent state - positive, negative or neutral. So as a tail risk worth worrying about I'd put this in your terrorism category.

A documentary that starts with a slightly de-tuned low and flat piano note. Impactful.

Over the past year we have from scratch built a significant web-application with MongoDB. We also have a social graph. We build infinite-scroll activity feeds on the fly. We handle multiple writes per second and 10s of reads per second. We have hundreds of thousands of users. We have 100 million documents, growing nicely. We've forced square pegs into round holes on occasion, but nothing we were too surprised about.

It seems like you walked into to your database technology choice with your eyes fully shut. Given even a modicum of of preparation - e.g. reading the MongoDB documentation - you would have asserted the social graph use case to be a challenging one with a data-store in which relations are unnatural.

Then - because you realized you may have a sub-optimal solution, you optimize it by changing technology. And then decide to join this ridiculous anti-MongoDB internet bandwagon.

For somebody who builds "4-6 web-applications per year" and has deployed "most of the data-stores you've heard about - and some you haven't" this seems surprising.

Or perhaps not, actually.