Kelly Sutton

I'm pretty disappointed by this title.

I know that it might be said in fun - and is an easy way to get clicks, but it feeds into the narrative of new, shiny tech. As the article points out at the end, there are very real engineering tradeoffs with GraphQL - and the answer isn't as easy as REST is dead, anachronistic technology that no engineer should consider (the XML analogy felt particularly inflammatory).

Kelly and I were chatting about GraphQL, and his post might be a more thoughtful engineering post: http://kellysutton.com/2017/01/02/do-we-need-graphql.html (the title - Do we need GraphQL? - is at least the way I'd expect engineers to approach the problem, where he discusses the tradeoffs)

In my MongoDB series, I point out a past case where Free Code Camp fed the hype, by telling engineers that the reason everyone had to learn the MEAN stack was due to employability in the software industry: https://medium.freecodecamp.org/the-real-reason-to-learn-the-mean-stack-employability-29011ff6b2eb

(you had to dig into the article to realize that their argument was more nuanced, and that they taught SQL first before MongoDB)

A number of "engineering" posts are not written as a thoughtful engineer might, and are in many ways marketing for the products sold (like a training program or code camp).

My experience working with Triplebyte has been great. I found them through hackernews from a post about visualizing the timeline for a job search [1].

Unlike most people in this thread, I thought their interview process was much more relevant and tangible to real engineering applications than most companies I've interviewed at. I was not presented with any gotchas or arcane algorithms questions.

Finally, the big draw to them as an engineer is that it significantly cuts down on the amount of time you spend on the phone with other companies before going on site. I'm still holding a job (hence the anonymous account), so looking for other opportunities was somewhat prohibitive to me.

[1] http://kellysutton.com/2016/10/20/visualizing-a-job-search-or-how-to-find-a-job-as-a-software-engineer.html

Perhaps you already have ideas on how to solve for this situation, but in case it helps: forcing active record model accesses to go via a layer of indirection can help with untangling this sort of thing: https://kellysutton.com/2019/10/29/taming-large-rails-codebases-with-private-activerecord-models.html

That said, for microservice extraction specifically, a bit of creative metaprogramming/monkey patching of AR to identify & categorize your callers is probably easier.

http://kellysutton.com

Stumbled upon this one yesterday, it's from a paper, but well written:
https://mzucker.github.io/2016/09/20/noteshrink.html

A long time favorite writer:
http://www.frankchimero.com/writing/the-webs-grain/