luord

49 ms·

421.
by luord 7y ago
It's interesting how the process seems... completely backwards. A group of engineers studying the CV/portfolio of the candidate followed by a culture fit interview should be the first and second thing to happen, IMO, yet for Googl
422.
by luord 7y ago
> And while the SQLite developers were able to do this work after the fact, the more 1% regressions you can avoid in the first place, the easier this work is. That mention of regressions seems, IMO, a slightly out of left field attempt a
423.
by luord 7y ago
I recommend watching the actual video. In fact, I wish that it had been shared instead of the article.
424.
by luord 7y ago
I agree with most of the points, but I have serious caveats on the first two. 1. No, the engineers should not by default be on call; the owners of the product are the first call line. If they're not engineers or if they're enginee
425.
by luord 7y ago
> Younger coders seem to believe that technical ability should be the only criteria, and it’s not the only criteria. You're the one defending rote tests (that literally only test for technical knowledge), not me nor anyone who repli
426.
by luord 7y ago
It's not often that I read about something and think "holy crap, that's genius", and that's exactly what solid is. Then again, given who's directing it, it should come as no surprise in hindsight.
427.
by luord 7y ago
> you can't expect even an amazing programmer with decades of experience to understand what the hell you were trying to do with your code -- in a reasonable amount of time. ... That's a software engineer's everyday job,
428.
by luord 7y ago
I'm having trouble seeing how anything you said in this comment is relevant to anything I wrote in mine. So much so I am tempted to ask if you accidentally replied to the wrong person. Among other things, I never "wrote off the en
429.
by luord 7y ago
Interestingly, I saw an example of the phenomenon of people getting mad at the certainty of an essay in this very site, a few days ago. Someone was telling the author that he would achieve more if he phrased his point in a more "polite
430.
Best practices for designing apps people use(thoughtbot.com)
2 points by luord 7y ago|0 comments
431.
Requirements volatility is the core problem of software engineering(stackoverflow.blog)
346 points by luord 7y ago|242 comments
432.
by luord 7y ago
As someone who attended high school during the afternoon, I am not shocked. Having to attend six am classes in college is the sole reason I didn't graduate cum laude. I had the gpa for it, but I had to repeat a subject just because it
433.
by luord 7y ago
I was reminded about the "debt is coming" post that was shared a couple of weeks back. This is a good example of that, I think.
434.
by luord 7y ago
That sounds like github in pretty much no way.
435.
Malware and HTTPS – A growing love affair(nakedsecurity.sophos.com)
1 points by luord 7y ago|0 comments
436.
Open sourcing DataHub: LinkedIn's metadata search and discovery platform(engineering.linkedin.com)
3 points by luord 7y ago|0 comments
437.
Python tools for record linking and fuzzy matching(pbpython.com)
1 points by luord 7y ago|0 comments
438.
The stuff users can't see matters too(thoughtbot.com)
1 points by luord 7y ago|0 comments
439.
Refactoring and Asking for Forgiveness(storiesinmypocket.com)
2 points by luord 7y ago|0 comments
440.
PyPy and CFFI have moved to Heptapod(morepypy.blogspot.com)
1 points by luord 7y ago|0 comments
441.
by luord 7y ago
Not that disagreement matters since he points out at the end that these are guidelines and not rules, but I particularly disagree on Freemium and answering services. The first one not only because the idea I'm working on can't pos
442.
by luord 7y ago
Most of the points come from disregarding the cardinal rule that every developer and development company should abide to (obligatory IMO): Fight for the users. In this case, you can't fight for them if you don't know what they wan
443.
by luord 7y ago
Unlike Abramov's original post, I actually agree with this one, being more nuanced. The author acknowledges that DRY (and ultimately, clean code et al) itself is not evil; it's just misunderstood.
444.
Automating MySQL schema migrations with GitHub actions and more(github.blog)
3 points by luord 7y ago|0 comments
445.
by luord 7y ago
I've gotten so cynical about this that the lyrics of "razzle dazzle" resonate in my mind whenever I'm interviewing.
446.
Evaluating Ray: Distributed Python for Scalability(blog.dominodatalab.com)
2 points by luord 7y ago|3 comments
447.
Using research grants to foster innovation(blog.heroku.com)
2 points by luord 7y ago|0 comments
448.
Reusing My Presentations(nedbatchelder.com)
2 points by luord 7y ago|0 comments
449.
by luord 7y ago
I liked this summation because the migration happened for a truly valid reason: Python really was a bottleneck. Not that I expected ESR to succumb to hype driven development, but it's nice to see for sure. On the article itself: I ju
450.
by luord 7y ago
> Try not to lose sight of the fact that type checking is supposed to be an aid to correctness and not an intellectually satisfying end in itself. Indeed, loved that closing sentence.

More ›