wilmoore

I'm disappointed that you missed the opportunity for a well-placed pun there :)-

I remember being on a team where I'd frequently point out that the tests were not only flaky, but useless. I suggested that we delete the useless & redundant tests and either fix or delete the flaky ones.

That suggestion was met with not only resistance, but almost hatred. I think some of them got way too attached to these tests and could no longer see the forest for the tress.

I don't understand why you'd do pair programming with two new hires!

There's nothing wrong with two new hires pairing. A few things a pair could be doing while the other is writing code:

1. Spike out a refactor of the current viewable block of code that the other pair just wrote or is currently writing. Looking at it as a spike instead of a hard refactor allows a pair partner to experiment and if the spike doesn't result in something better, throw it away; no harm done.

2. Jump ahead and spike out a function that the pair might need soon, but isn't ready to consume yet.

3. Watch for pair getting stuck and help them think. Ask questions like ... are you stuck or just taking a mental break? That's a helpful question because it makes them more comfortable taking mental breaks when they need one without fear that you're judging them.

Keep in mind, pairing is AMAZING when deployed with empathy and less judgement. For those that feel like they are being judged when pairing is likely because you are a bit judgmental when the shoe is on the other foot.

FYI, teams that pair daily, get more done and team members feel less lonely and more like a real team. Go Warriors.

10,000%

Happy birthday HN. I absolutely love this community. Once I started reading HN somewhat frequently, there is no question that I became a better developer, thinker, researcher, and writer. The topics shared here seem to have no rival anywhere else on the internet ... at least, not as far as I am aware of.

I think this is a good time to admit that when I first came here, I was a bit shy to post anything about tech or programming, but by hanging out here and practicing what I learned here, I eventually felt worthy of contributing.

Thank You.

I'm just surprised people are more outraged that Spotify complied with the artist's request vs being outraged by Spotify's horribly cluttered (and confusing) UI.

I've been fortunate enough to have worked across pretty much every portion of the stack with the exception of hardware or core networking protocols. Everywhere else, I have experience and am comfortable.

Yes, you are definitely going to be trading for more stress and it is highly possible that it will be less fun, but that's not necessarily guaranteed especially if you land in the right role, right dev culture, and right leadership; however, that's a lot of things that have to go right, which, it almost never does.

I started with database admin, then sysadmin, then dev. Sysadmin is more fun and the people and environment are generally more fun; however, dev is more fun to understand depending on what you want to do with the knowledge gained. If you plan to build something in tech, you want to use this opportunity learn to be an effective developer.

That being said, if you don't care about that, then, maybe the stress isn't worth it. I personally now value having time to myself. That's really hard to do as a dev because whether you like it or not, you are carrying those hard problems around with you all day, every day, until they are solved. It's like a weight being placed on your chest from the moment you wake up, until you crawl into bed from your work desk.

Like all things in this industry, YMMV and you'll have to weight the pros and cons.

EDIT: also, daily standup meetings kinda suck.

If you like jq, then you might also like jmespath.terminal (jpterm): https://github.com/jmespath/jmespath.terminal

What the entire recruiting industry (this isn't unique to recruiting industry) fails to understand is, if the process isn't time optimal and fair, then engineers will eventually learn the nuances of the industry and build something more automated, time optimal, and fair. If you've been an engineer for more than a few years and have been paying attention, you probably already know this.

I've interviewed with a couple teams that are using Shape Up and I got the general sense that the developers were happy with the process.

Here is the readable on the web version: https://basecamp.com/shapeup/webbook

Obligatory PDF: https://basecamp.com/shapeup/shape-up.pdf

Shape Up Your Agile (article): https://thinkfractional.blog/shape-up-your-agile/

Agreed. I suspect an open-source competitor could be much better than all of these if organized well.

anxiety === lack of documentation + lack of frequent communication + general desire to be _done_ as soon as possible

what do you do when implementing a REST endpoint like GET /things where the user can give any number of 10 query parameters to filter the result?

https://www.elastic.co/guide/en/elasticsearch/reference/curr...

My .vimrc is constantly improving. To the point where I ask myself how healthy the obsession/addiction is.

I have to concede that this _was_ my experience until about a year ago. I can recall spending many evenings and even some lunches reading and experimenting with vim configuration improvements. I too wondered if the time would pay off.

Vim has been my main editor for 8 years. About a year ago I started to notice that I was no longer spending much time at all changing my configuration; however, I was aggressively deleting plugins and complex (most-unused) key-bindings.

These were replaced with intrinsic key-bindings that I didn't previously know about they were replaced with more modern and simpler plugins. I suspect this will get even better once adopt Ale and plug.

The smaller config is oddly satisfying. I'm happy that I've stuck with Vim as it continues to provide me with a full-service experience, while getting faster, not slower, yet my config continues to get more minimalist.

I don't think there is anything out there that compares, but it's an investment and YMMV.

So, invest in yet another program that likely further exacerbates the issue just to sweep the underlying issue under the rug?

Curated configuration generally outlives data. If storage space becomes an issue, there is value in recovering storage space but config is generally small and much more important in the long term.

I agree, you didn't look very hard.

Honestly, I was expecting the music to be extremely weak. The third item I hit was fire. The design is clean, no bs; Sold.

Suggestions:

1. add autocomplete to your search box. 2. make it easier for people to give you their email address (i.e. least intrusive as possible modal that disappears after an email address is submitted). 3. pressing play on one player should pause any other players.

The right thing to do when taking a cc for a trial is to send reminder emails that they will be charged.. Which not enough do.

Wouldn't the "right thing to do" be to not auto-renew the account?

I suspect we sometimes conflate "right" and "convenient". I am curious, don't most people (especially those with technical chops) just drop a calendar event as a reminder?

To be honest, this is the kind of thing that would be great to highlight immediately on https://github.com/rust-lang/cargo or http://doc.crates.io/guide.html.

I go to those pages and I am given 0 information on how the thing actually works.

You willingly subject yourself to this? Why?

I see where you're coming from, but I feel like it would be a mistake to expect the language or std lib to try to solve problems that are effectively organizational/cultural issues.

The issue with comments written this way is that there are no details to support the claim.

Writing "see: JavaScript" doesn't really help without context. Without context, one does no know if you meant "JavaScript in browser" or "JavaScript via Node.JS" or "I simply don't like npm".

I'm not claiming there aren't any problems; however, "problems" are situational and one person's "problem" is another person's meh.

I just think it's irresponsible to not provide detail when making such claims.

They have specifically stated that they do not have any plans to support parsing JSON.

Haha, I'm actually also a Haskell programmer...building a C compiler in Haskell as my secret plot to take over the world.

Haha; I got a kick out of reading that. Nice!

I have a sideproject that's a REST API in Haskell as well, but I'm not 100% convinced yet that Haskell is right for that.

I'd be interested in what you are finding there. I have been wondering if I should start moving toward Haskell or Erlang/Elixir. So far, I've spend much more time with Erlang and Elixir and I'm liking it.

What has given you grief on the Haskell side?

Easy proofs for Haskell superiority...

Wow! I had no idea Haskell was so flexible. Perhaps I really should spend a bit more time there. I've never read anywhere else about this level of flexibility in Haskell.

If nothing else, this conversation was well worth it just for that...thanks :)

> ...it's hard for me to even consider the idea of Javascript being in the same category as Ruby.

Indeed. I think anyone would agree...they were not built for the same purpose; however, let's set some expectations here. As it relates to backend JSON APIs, what is better about Ruby/Bundler?

> Ruby was designed from scratch to be a perfect...dream

OK, that's fine. Though, I've never heard of a proven perfect language/platform, regardless of intention.

> I really want to write half a book more about why I think Ruby is so much better than Javascript...

Please, no book, but I would be happy to read one concrete example of why Ruby/Bundler is substantially better hands down. Of course, you are free to argue that you just don't like JS. I'd be fine with reading that, but I'm still curious to see a real example. I'm willing to accept that I may be wrong, but without proof, we can't get there.

Yes, Ruby is a nice looking language; still, I have not come across any proof that writing, maintaining, and deploying Ruby/Bundler is substantially better than writing, maintaining, and deploying Node/npm for backend JSON APIs especially given the gratis performance benefit and ease-of-use of Node/npm.

The same or better result with lower overhead and better performance. Before I ever wrote a line of JS intended to be executed via Node.JS, I actually thought Ruby was better as well :)

*

NOTE: I am quite aware that some Haskell lover is probably laughing and sticking their nose up at this entire conversation. That is perfectly fine because I'm willing to bet they can actually provide the concrete example I am looking for.

> That's what everyone predicted half a decade ago, yet it hasn't happened, not even the PHP death part.

Indeed. I don't think it will happen...at least not the way people are predicting it to happen. There are plenty of dev jobs that ultimately, you can pick any of the mentioned technologies and if it makes you happy, you'll find a job that will allow you to apply that skill while paying you a great salary (or hourly fee).

These debates are good fun for sure, but ultimately, it doesn't matter in most cases.

> the fact that as a language Ruby is superior to Javascript remains, even if Javascript VMs are a hundred times as fast.

As someone who frequently switches between Ruby/Rails and NodeJS (sometimes in the same day), I wonder about this statement (err, fact).

You mentioned that the Ruby language is superior and that this is a "fact". What about the Ruby (I know Node isn't really a language, but for the sake of discussion, Node,JS,npm) is substantially better that the speed trade-off is worth it (besides familiarity)?

In my case, I'm familiar with both, and I prefer Node,JS,npm. Node,JS,npm are definitely not perfect, yet still, I like it over Rails,Ruby,Gems/Bundler.

I'm not looking to "win" here; I'm just very curious now given your assertion.

For me, Scala is a great language that continues to present me with good surprises (i.e. literal curry syntax). The only issue for me is the JVM and the package/namespace system (not to mention mvn, sbt).

In this way, Erlang/Elixir is more enjoyable for me. I much prefer the Erlang module system (Python and Node.js get a special mention here as well) vs. what you get with Ruby, PHP, Java, etc.

We added it to the mix because it got increasingly difficult to tune SQL queries involved in building API responses, especially for endpoints that needed to pull data from many tables.

Had you looked into using PostgreSQL's materialized views? you can add indexes to the view with the additional bonus of the view hiding those joins from client code.