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
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.
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.
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.
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.
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.
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 [email protected] . 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.
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.
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.
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