lethain

I've been blogging for about 16 years. Writing is an underrated way to cement what you learn any given day or year, and over time has made it possible to reach into any part of the industry and get an actual response. Writing is particularly powerful in combination with actually doing things that (are perceived to) matter; the credibility from doing both is much higher than doing either.

Concretely answering the questions asked:

1. At various points I spent a lot of time maintaining, but now it's just a static blog deployed via Github Actions onto a Github Page. I haven't done any meaningful changes in a few years, and the changes are for fun, not necessity

2. I got my first job in tech thanks to blogging: https://lethain.com/datahub/

3. My blogging has made it possible to write two pretty successful books: https://staffeng.com/book/ and https://press.stripe.com/an-elegant-puzzle (working on a third now)

4. Hard to assess, but I believe I've been able to subtly but meaningfully advance the technology industry through my writing :-)

5. A significant majority of folks are unaware that I write, and that's great! I don't think impact depends on folks connecting their colleague to the writer or whatnot

In my role as unofficial, self-appointed late-stage Digg historian [0], it's my belief that Digg ultimately had to change as the Google SEO changes had fatally wounded its near-profitability. Further, as a VC funded company it made the inevitable (and I think best for everyone involved) decision to modernize in an attempt to be a member of the Facebook, Twitter cohort rather than experience a long-term shrinking into mediocrity.

[0]: https://lethain.com/digg-v4/

Sorry, I think that sentence was a bit unclear. What it meant to convey is that we had 200 daily active Facebook uniques, essentially that very few folks used FB to connect to Digg.

Thanks for the suggestion, we’re adding a clarifying note to the report’s timeline.

(Stripe infra lead here)

This was a focus in our after-action review. The nodes responded as healthy to active checks, while silently dropping updates on their replication lag, together this created the impression of a healthy node. The missing bit was verifying the absence of lag updates. (Which we have now.)

It's fun to see that deck since my first (software) job out college was working with that team (about a year after this slide), when only two of those four mentioned individuals remained on the team, but consequently I got the pretty rare/fun opportunity to write Erlang.

We had a major advantage for new technology rollout as we did "devops" (e.g. the ops team decided they did not have bandwidth to support us and we needed to launch), and were building greenfield technology (Y! BOSS) with relatively few integration points with existing Y! technology (except for Vespa which is similar to SOLR/ElasticSearch and some weird C++ libraries that were somehow mislabeled from "junky prototype" to "high technology" and were ported forward).

Years later, my sense is that the biggest initial stumbling block was getting the existing devs to have any interest in learning a new technology / way of doing things. I think we lacked some perspective there, and should have made a much larger effort to get the team excited and trained with the technology (in jobs since, I've never had a team who turns down technology training), and could have probably won our local team over if we'd been more intentional.

Ultimately though, the final stumbling block was Y! itself, which was very focused on keeping the number/diversity of technologies low. I think at the organizational level this is probably the right decision, so I can't really fault them for that. Ironically Node.js popped up just a year or so later as the great language hope to rescue Y!, and did manage to get significant traction, so if you wanted to study adoption, finding someone who could explain how they got Y!'s Node.js adoption going in the right direction would be pretty fascination.

As a hiring manager in SF, my anecdotal experience is that most large companies are still hiring at the same pace they were a year ago, but that capital and subsequently hiring has dried up for smaller companies.

For experienced developers/managers, things seem to be business as usual, but in particular the "top tier" companies generally are more focused on avoiding false positives than in reducing false negatives, so I see us as entering a slightly unpleasant period for non-traditional and entry-level candidates.

I think many and perhaps most poor estimates are caused by initial estimates being viewed as too high for the project, and instead of deciding the project isn't worth doing at its estimated cost, instead deciding the estimates must be wrong in order to align expected project value with expected project cost.

Perhaps in a twisted future where we estimate project cost before deciding which projects to take on, we might discover our estimates are much better.

A related pathology is trading technical debt for speed, every time, on every project. The debt will be paid.

Generally the advice is to breakout GPA by major courses and overall (e.g. 4.0 GPA in major, 3.43 overall).

I'm occasionally a hiring manager for engineers, and yes, it's very possible to get a job without a tech degree. Tech interviewing usually has four major steps: 1) sourcing candidates, 2) filtering resume candidates, 3) technical phone screen, 4) in-person interview.

For most companies, having a degree only matters in the first two phases, and ability/interviewability matters in the last two.

Experienced engineers avoid getting filtered out in the first two phases by working through their network, which allows them to skip those phases entirely. If you're trying to break in without any experience, it's much harder because you probably don't have a network and degrees are often used as a filter during candidate discovery and resume filtering (especially when the engineering manager is working with a recruiter).

My thought would be to proactively send your resume directly to a bunch of job postings, especially ones which go to a "jobs@$company.com". Anecdotally, I know I don't get many direct resumes these days, so I'd end up reading them, skipping any explicit filtering.

For a bit more context behind what we've done here, we also have a blog post at http://about.digg.com/blog/sifting-for-diamonds-with-the-dig... .

I know a few of us read HN as well, and would be glad to answer any questions on the Newswire product or implementation (in brief: Redis).

Starting up can be remarkably hard. As training for that process, I'd look at your current work situation as a test. There isn't an easy way to move up and the work is dull, but if you're looking to lead a new company or join a foundling company, you'll want to hone your skills at owning issues and solving them (did your entire ops team just quit? yes they did. Is your site crashing under load and you're the only one who is going to fix it? yes it is, and yes you are).

My advice: look at your current work situation and find a way to make it more interesting and work your situation to move up. It'll probably be hard, but learning to focus on overcoming problems rather than focusing on the obstacle is fundamental to being people successful when you're managing yourself. This is especially true for startups.

Regarding the hard-coded IP piece, I've run into a similar scenario wherein the early versions of the distributed counters patch for Cassandra relied on vector-clocks which used IPs as part of those clocks. Certainly not a robust design in the case of machine failure, but I've seen smart people make awkward decisions, and if someone had gone into production with that patch and lost a machine, it would have been remarkably annoying to recover (it would have required rewriting all the SSTables to a new IP, which isn't impossible or anything, but kind of a pita).

I think there may be a bit of confusion here, as the recent post about the increased number of daily stories on Digg's frontpage was written by a Digg user and posted to their blog, not written by Digg staff or otherwise endorsed by us. (I work at Digg.) Our last blog post was yesterday ( http://about.digg.com/blog/how-get-started-digg-filtering-my... ) and about a couple of new features we rolled out.

The later being the "lone wolfram" approach.

Digg is hiring on-site in San Francisco (Potrero hill) for frontend and backend developers, with a preference for people who work all the way up and down the stack. We're willing to take chances on newer developers who seem like a good fit, and also want veteran engineers who will to come in and challenge our assumptions and shake things up.

We're working at a scale where performance and data storage decisions start to matter. We're working with a modern stack (Redis, Python, PHP, RabbitMQ, gevent, Hive, etc), and the team we've put together is truly fantastic. 2010 was a topsy turvy year for us, but setbacks build character, and there are many reasons to be excited about where we are going. :)

Job specs are at jobs.digg.com , and feel free to send questions/resumes my way at wlarson@digg.com . If you're interested but concerned about the press or trajectory of Digg, definitely send an email my way, and I will send some of my optimism your way!

Seeing that Redis is a datastructure storage mechanism, I guess it shouldn't shock anyone that it maps well to existing datastructure interfaces. Maybe the more interesting aspect here is the power of having datastructure-aware datastores as opposed to trying to hide the implementation details behind (potentially) leaky abstractions.

A couple years ago a friend of mine and I wrote http://ptdef.com/ which is canvas/js as well but with randomized maps and pathfinding creeps.

I'm not sure if this quite answers the question. Although Japan certainly doesn't allow bringing in content which violates their definition of pornography, it is not clear to me that these manga would fall under that definition.

This article skims the surface of this fairly complex topic: http://en.wikipedia.org/wiki/Pornography_in_Japan#Censorship...

I think your key point is and doing so publicly. Many people use similar arguments against copyright laws to explain their illegal downloading of licensed material, but do it in secrecy. Violating potentially unjust laws in secret and for one's explicit benefit strikes me as extremely self-serving with a very small dose of morality if any at all.

Although I understand the appeal of your argument, using a 3rd party workaround to provide support for performing javascript interpretation outside of the browser--whether or not they happen to be hijacking the system's underlying javascript interpreter--is not an "Apple Published API".

I think the developers of phone gap are at fault here for suggesting that their platform/toolkit is usable on the iPhone. Whether or not developers agree with the restriction against interpreted code, it has been very clear since long before the public iphone developer kit that it was not allowable to write code in an interpreted language.

The exception to this is websites running javascript when a browser visits them (i.e. client side javascript for a webapp), and that is quite different than packaging javascript into an application and deploying that application to an iPhone.

What that reports shows is that historically college has paid off, but even with adjustment for inflation the cost of college has increased by 2.5 times over the past 70 years ( http://en.wikipedia.org/wiki/College_tuition has a great chart showing how that varies across institutions, in some schools the adjusted increase is much lower). Combined with the increased percentage of Americans attending college (from <%5 circa 1940 to nearly 30% now, http://en.wikipedia.org/wiki/File:Educational_attainment.jpg), I think it's disingenuous to rely on data based on the relative success of those who attended college 40 or 50 year s ago to someone who is graduating from college today.

College is more expensive and having a degree is much more common. Because of these factors, although I do think lifetime wage for college graduates will continue to outpace non-graduates, I also think that the relative payoff will decrease.

Apologies for over-reliance on wikipedia, it is remarkably hard to find quality sources in a minute or two. ;)

I lived in rural Japan last year, and had similar experiences with stores being open or lack thereof. There were three restaurants and two bars. One restaurant never opened for dinner, another was run by a family, was closed at 8PM and was closed on Sundays, the third was run by one woman and was closed for dinner on weekends and also tuesdays. One of the bars' closing schedule involved being closed on the third Sunday of each month. Grocery stores closed by 8.

I spent a lot of time thinking about how things must have been to live 50 years ago, and how much we've come to take (this very limited sense of) openness for granted.

I don't think there is an evidence that Apple is "playing games", they're just inexperienced at processing and delivering payments and thus are doing a bad job at it. As they say, never blame malice where incompetence is a sufficient explanation.

Actually, yes. An opinion without some kind of justification or explanation behind it isn't particularly valued by the HN community.

Suggesting that unemployment in countries with high social benefits is the product of laziness places the blame on individuals when the economic system itself is largely responsible for making it extremely expensive to hire new employees.

The limitations with the tower defense game are the result of programmer laziness rather than some limitation with JavaScript itself. If the game was reworked to use sprites instead of drawing using basic geometric shapes, it would appear much more polished. The major limitations with JavaScript versus Flash revolve around dealing with media (we had to use a Flash tool to implement conceptual sound support for PTD, http://github.com/rictic/processing-tower-defense/tree/maste...), but I think these are generally being resolved with HTML 5.

To respond to your questions:

1. With some minor effort we were able to get PTD running on Firefox, Safari and IE. (Chrome didn't exist at that point.) The performance on IE 6 and (I think) 7 were prohibitively bad though, so it wasn't actually playable. Thanks to projects like excanvas, even browsers without native canvas support don't pose a big problem.

2. I don't have Flash experience, but PTD is just a collection of static files. I never felt deployment was a problem.

Although to a large extent I agree with you when you say "[Resaerching] talents are worth more than the coding knowledge itself.", I'm not sure you're accurately representing the author's position.

Particularly his last acceptable answer is "If you have a friend who is knowledgeable on the subject... I don't care if you bother someone outside the organization with endless questions."

What the author is interested in is not having new employees disturb old employees with questions, although having new employees understand researching is a solution, it isn't his goal.

He had an excellent hook, but unfortunately there was not much of an article afterwards.

Twitter search was originally another company which was purchased by twitter latter on. It recorded and indexed tweets without any magic sauce, but in a way that other developers could as well. Thus, even if search.twitter doesn't feature a given tweet, any arbitrary API user could have it, and there is no way for twitter to remove those. Thus perfection is out of reach, and even if they did delete results from search, it would be more of an act of appeasement than an actual technical solution.