nbm

Basically, an L5 (or equivalent level at other companies) is supposed to be largely independently competent (but not necessarily excel) in most engineering areas. They understand the context enough to determine which projects are important (including those they might make), they can identify stakeholders and communicate status and needs well enough, they can project manage enough (or make a project manager successful), they can work through others to a reasonable degree, and so forth. They'll know those areas they'll never be good at, and have some mitigations in place for those. They're self-motivated, think about their work holistically, and generally will navigate the delivery of the project without guidance - but when they need it, they'll make sure they get it.

From an interview point of view, they're probably looking for examples of that independence and self-motivation (ie, not just doing what someone told you to do), and also the step beyond just writing the code towards more holistic ownership (things like "created a new test harness along the way", "did a survey of developers", "made sure there was a killswitch", "created a rollout strategy", "convinced another engineer to share review and support responsibilities").

I'm definitely not going to defend the industry's interview processes' effectiveness at consistently and/or accurately extracting useful information (or even just the information that it is intended to). When faced with the output of the process indicating this "flat" trajectory (however inaccurate that may be), that's just how some people interpret it.

L4 is an intermediary level between new-to-industry junior (new grads generally start at L3) and mid-level (L5). In many companies, it's expected that people will reach L5 within some time period.

Failing to have grown skills and project scope to L5 level after extensive time in the industry could be interpreted by some as poor motivation or career growth planning - their thinking is that if you've been doing the same thing for years elsewhere without growing, you'll tend to be trying to do the same things for years there without growing.

Answered at https://news.ycombinator.com/item?id=21985518

Being hired in as an engineering manager requires having been an engineering manager previously (at any company), generally for a reasonable period (let's say, minimum two years of full-time management experience minimum with at least 3 direct reports), with a career YOE of around at least five years. You're generally coming in at the same pay band as a senior IC (you might be able to see this sort of information in levels.fyi), so you'll be in the same ballpark of experience/career trajectory.

If you don't have enough engineering manager experience, you can generally join as an IC (with a full IC interview loop) with a view to converting to manager. You may have additional discussions or even interviews around management as well, especially if converting to manager is something you identify as a career goal (as opposed to an option).

Converting to manager from an IC is generally pretty easy if you've shown good aptitude for leadership - the larger companies generally find it a lot easier to hire ICs than good managers externally, so internal conversions are necessary to keep up with demand for quality management attention on teams.

Yep, it could help in some cases.

It's nowhere near as standardly applied as the other approaches to release verification, though.

And in complex cases (say, a large multi-tenant service with complex configuration), it can be very hard to find the combination of inputs necessary to catch this issue. If you have hundreds of customer configurations, and only one of them has this particular feature enabled (or uses this sort of expression), fuzzing is less likely to be effective.

Since the work involved in doing a regular expression match can depend largely on the input for non-trivial expressions, one fun case (probably not the one here, though) is that a user of your system could start using a pathological case input that no amount of standard testing (synthetic or replayed traffic, staging environments, production canaries) would have caught.

Didn't take anything down, but did cause an inordinate amount of effort tracking down what was suddenly blocking the event loop without any operational changes to the system...

Services have different relationships with each others in terms of dependencies, and in terms of what you think those dependencies are.

If your idea of how things work is that services A, B, and C can optionally use service D, else use some fallback process, then if D has never failed, then you've never used that fallback process. And services X, Y, and Z which rely on services A, B, and C haven't had to deal with those services using their fallback processes either. So, instead of waiting for D to fail, you can take it down at a convenient time.

This applies to services as a whole, or services within a locality, or all services in some availability zone.

I was basically introduced to Twitch by Handmade Hero, and Casey (the host) seems to have brought a bunch of his contemporaries in as well.

Handmade Hero:

Complete game from scratch (nothing but platform libraries). Has spawned a number of small projects, like 4coder (https://4coder.itch.io/4coder) and Milton (https://github.com/serge-rgb/milton) and a lot more: http://handmade.network/

https://handmadehero.org/

Bitwise:

Complete hardware/software stack for a RISC-V computer from scratch (compiler, assembler, ...)

https://github.com/pervognsen/bitwise

Sean Barrett:

He's the author of the excellent stb header-only libraries, does the occasional live coding video.

https://www.twitch.tv/nothings2 https://www.youtube.com/user/silverspaceship/videos

Jonathan Blow:

He's the game developer and designer behind Braid and The Witness. He's designing a programming language (JAI), works on that and shows off features, as well as doing game development, on his channel. (And occasionally playing games.)

https://www.twitch.tv/naysayer88 with no schedule VODs: https://www.youtube.com/user/jblow888/videos

Martin "quill18" Glaude:

He's primarily a game streamer, but also a consistent Ludum Dare participant, with some high placement in many of them. He has a series of programming videos.

https://www.twitch.tv/quill18 Vods: https://www.youtube.com/user/quill18creates/videos

They have different approaches, but mostly ignore the chat during the stream, but often the chat has very bright folks who can help out.

You probably don't need to force the _best_ engineers go into management to achieve this - you just need someone with the necessary background and experience - and from that larger pool you can choose the ones that want to do management, and are more likely going to be good at it.

The managers I deal with day-to-day were all once ICs in the same role, but I wouldn't put almost any of them in the same category as the strongest ICs we have in technical skill. And they mostly don't make bad technical decisions - because they mostly don't make any technical decisions - they defer to their strong ICs.

Why not just hire a (hopefully) good people manager? It's hard to find good managers, but it's also not entirely likely that your best IC engineer is going to be a good manager naturally either. Whereas you know they're good at what they're doing now.

If they're not going to find a way to be more worthwhile, just don't pay them more. If they find a way to be more worthwhile (teaching, coaching, setting standards, whatever), then pay them more.

When people talk about agism and finding it hard to find a job as an older person, they're generally comparing against someone with the same capabilities and salary expectation going for the same job. (Edit:) And they're not complaining about companies not matching their salary, they're complaining about not getting an offer at all.

It isn't in comparison with the job available to new grads.

(Of course, there's the question of whether a senior industry hire is actually only worth some factor of a new grad hire.)

If you're writing code in a language that compiles to multiple CPU architectures, it's not hard to get 90% of the way towards supporting all those CPU architectures without trying much. The remainder certainly requires some effort (much less if you think about it up-front) - this is where standard types like int, long, even char, and pointers, have different sizes - and where you can't just write out the memory format to a file if that's the same file you're loading on a different platform (even with the same type sizes, because of endianness).

Writing cross-platform code, especially for early games where you're using a fairly restricted set of the platform code (and even less if you're doing a software renderer), is similarly not that hard in the common case if you've thought about it/have experience with it. There are a few different approaches, but even just having a single file that has POSIX and DOS compatibility functions (ie, above the stuff the C standard provides) and some macros could probably get you 90% of the way there.

I don't mean to downplay how hard it is to, say, support multiple renderers, which is a problem that came later, or porting code that was written without any thought given to future portability. But given they knew they were supporting two platforms, it's not that hard to do (compared to the other, actually hard, stuff they did).

The cynical view:

"We took a calculated risk, announcing the set of changes, and seeing what the fallout would be. The fallout exceeded the threshold we set, so we're now going to issue the apology we had prepared in case that situation was reached."

At FB in engineering, you generally don't get placed on a team, you choose which team you join, only after 6 weeks of "Bootcamp" where you ramp up on the technical and cultural environment. That said, you're right that even with that, people can end up joining teams which are a poor fit, so internal mobility (switching teams) is definitely valuable here too.

What size would be "relatively small" in your measurement? They're certainly smaller than their Bay Area headquarters, so "relatively", they're smaller. But for FB, at least, there are many Seattle-primary teams (ie, teams where all or most members are in Seattle), especially in infrastructure and storage.

I've worked over two years in each of the FB Menlo Park and Seattle offices, and since the move to Seattle, I haven't missed anything from the headquarters (especially once the BBQ place opened).

Most people don’t spend nearly enough time in a editor-specific language to keep it fresh and loaded at all time. So having to switch from a language/environment you’re fluent in to one you can merely get by in is a frustrating experience.

Watching Casey add some fairly powerful features in the editor in an hour or two, including using Windows APIs directly, was quite illuminating.

He's using 4coder - https://4coder.handmade.network/

He likes that its configuration language is C, so he doesn't have to learn a configuration language to get things done.

He doesn't anymore. He has a portion before the stream where he likes to talk about things that are not code-related (like his opinions on X), and he doesn't want those recorded. As I understand it, people were taking the vods and posting snippets to Youtube, which went against the spirit.

In order to really start talking about it, we'd need to see someone writing something of similar complexity and longevity live in the same amount of time, and see whether they've spent less time to get to the same place.

With the same restrictions of course - relatively little dynamic memory allocation, and hitting frame rate consistently on the lowest supported platform.

I've watched pretty much every episode, mostly live. It is pretty amazing. It also pretty much single-handedly reinvigorated my love of programming.

But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build.

https://hero.handmade.network/episodes is a must if you want to cut some corners on what you watch.

Off the top of my head, here's my suggestions:

* Weeks 1-15 are all useful - it's really a great introduction and kool-aid provisioning system

* Week 20 and 21 has some introductory lighting stuff.

* Week 23 and 24 has some good performance profiling stuff.

* Week 25 and 26 has some multithreading job queue stuff.

* Week 28 and 29 has SIMD/SSE sound mixing implementation

* Weeks 36-38 has debug/performance infrastructure

* Day 235 and weeks 48 and 49 are the start of OpenGL initialization.

* Week 74 discusses particle systems

* Weekend 3 discusses compression

* Weekends 6-14 are the core software-renderer-to-OpenGL days

* Weekend 23 is a re-implementation of lighting

The other stuff is exploration of concepts that are either specific to Handmade Hero, or are much deeper implementation detail type stuff - not entirely necessary if you're skimming.

The Alexa SXT doesn't match the first requirement - a true 4K sensor. It has a 3424x2202 sensor.

Separate from non-lock-in reasons, I'd consider using the hosted version if I could export data at a later time so I could go self-hosted in the future (say, if I start writing some code for it and there's no API that does what I want).

One of the benefits of publicly traded and soon-to-be-traded companies is that they release things like DAU in their S-1s and quarterly reports, so we don't have to rely on anecdote.

Disclaimer: I work at Facebook (but don't follow this sort of thing beyond reading the quarterly reports every once in a while)

At the core, it's really a simple iterative process - I wrote this in mine to remind me/cement it - https://www.instagram.com/p/BOflnzggBbc/

Basically, every day, write down anything that comes to mind that you should do on that day (possibly by fetching it from a page of a less granular time period, like a weekly, monthly, quarterly, or yearly list of tasks/events), as well as anything that you discover you need to do in the future (put the date of the event, or a rough time period you want it done next to the item, so it's clear you don't have to do it today). Don't feel the need to schedule it on some other page - just write it onto the current day and defer that scheduling work to later.

As you do the things in your list, mark them as completed. At the end of the day, make a place to write down stuff for tomorrow. Move all the stuff you wanted to do today that you didn't to the next day. Move all the stuff you marked for the future to a place where you store tasks for the future - this is called a "future log", and there are all sorts of variations. I'd start with a page for all tasks you want to do in the future, and "migrate" to a new page with those tasks monthly.

Generally you want a book with two (or three) bookmarks - one will be on a "future log" or "monthly spread" page where tasks you want to do soon, but not necessarily right now, in case you want to pull additional stuff to do today, and the other will be on the page with the current day where you'll do almost all your reading and writing.

In order to save migration to a weekly process, I use a layout where I put all days of one week on a single spread - https://www.instagram.com/p/BPUIKR1Am3o/

Then I can put stuff for later in the week onto that specific day, and I only need to migrate to future log, or rewrite the weekly-level tasks every week. And I don't need to do any per-day setup work, just draw the page leisurely on a Sunday night and do the migration work.

There are a ton of youtube examples of people doing planning, and a few tutorials on how the system works. Don't be put off by some of the more complex/artful/&c. stuff - you can do it in a minimalist fashion too.

* Bullet Journal 101 series by Boho Berry - https://www.youtube.com/playlist?list=PLeTUR5GAuQfupOv-_l16G...

* Engineer Dude's Simple, Minimalist Bullet Journal - https://www.youtube.com/playlist?list=PL1HerzvUph3FtUsXqsGL9...

There is also a really active set of bullet journalists (as they like to call themselves) on Pinterest and Instagram - just search for "#bulletjournal" and "#bujo" for example future logs, "spreads", trackers, collections, and so forth.

Remember - all you _really_ need is the tasks/goals/planning part. You don't need daily/weekly/... water/exercise/mood/... trackers, weather icons, calligraphy, colours, and so forth. And it's your system, so adjust as you find it works for you. I started off trying to do morning/afternoon/evening mood tracking, but that didn't work out. I also tried a daily timeline thing, and that didn't work out. So they were gone after three weeks.

I've been keeping a bullet journal-style journal for the past month and a bit, and I've found it pretty useful. I don't write any "dear diary" style entries, but I do write down thoughts I have about game ideas, camera gear research that I might want to use/rent/buy, vacation ideas, and so forth, in the bullet journal style.

Here's an example empty page for a week - https://www.instagram.com/p/BPUIKR1Am3o/

I track some things daily:

* quality things

-- mood

-- energy levels

-- activity level

-- productivity

* tick-box things

-- did I wake up before 8am?

-- did I get to work before 10am?

-- did I hit my step goal?

-- did I do any additional exercise like a really long or strenuous walk?

-- did I do some work on a personal project? (taking photos, working on my game, looking at houses, whatever...)

-- did I record my weight and blood pressure?

-- did I follow my morning/evening routine? (pack/empty dishwasher, did I remember to take my pills, ...)

On a weekly basis, I tally up a few things from my activity trackers - how many days did I hit my sleep goal of 8 hours, what was my average weight/blood pressure, how many total steps did I do, and so forth. I also convert the daily quality things into the number of "good" days and "bad" days in that week on that scale - so maybe one very good mood day and two bad mood days (and the rest acceptable).

I then write down any non-technical-work tasks (we have a task tracker already at work for technical things, after all) I want to get done (either in the future, or on a particular day), or events that I need to remember, generally in the bullet journal style. These are things like:

* Collect building badge

* Write talk submission for conference

* Develop the iPhone photos from the weekend

* Remember that the new X book is out (today, on day X) and I should read it next

* On the 30th of January, remember to send out the invite to the event

Then every Sunday I make a new weekly page, migrate all the unfinished entries forward into the next week, and start again. I'll cross out things I realise that I don't care about any more, and move things that are further in the future than the upcoming week into the "future log". Pick two to three main things to keep in mind, schedule some work onto particular days, if appropriate, and the rest into a general weekly tasks list.

I also move things like vacation or camera gear or game idea one-liners onto a dedicated page - either a full page for the idea, or a page that has a list of those one-liners.

If you're at FB, reach out to me (nbm is my unixname). 100% privacy guaranteed or your money back.

Otherwise, you should consult with your manager and a trusted (but not necessarily intimate) peer or mentor about what your options are in the space before resigning and trying another company. If you just repeat the same story at your next few places, you'll end up more behind. Perhaps you can come to value the work you find dull, find a way to prove your value to the more senior folks and be let in on the "actual work", or move onto a team with a different focus or problem set or composition.

Don't stick it out if you hate it, but make sure you give yourself the chance to find a better fit - this sort of thing translates whether it's a big tech company, a startup, or just your own confidence.

Not sure where you got the "less than or equal to a second old"? Maybe I'm misunderstanding what you mean?

There is no single system-wide imposed sampling rate, so it's up to you to set the sampling rate based on what sort of queries you want to be able to do with good enough accuracy. We have 1:1 rate data for some things (say errors served on a particular service), while a ten or a hundred thousand to one data for other things where there are, say, tens of millions of log lines per second.

Comparing to Tableau, Scuba is schema-less and doesn't require any setup beyond creating the table (which doesn't have any approval process in the way and gives you a reasonable amount of scratch space to test before you get serious) and then having data arrive. Once Scuba is aware of your column by you submitting data for it, it allows you to query/group based on it very quickly. Scuba is entirely real-time. There are some other projects to do pre-computed aggregates if that's important to you.

I haven't used Splunk in ~7 years, so I can't remember enough about it to compare well. Splunk has some structured-on-top-of-unstructured stuff in it, whereas Scuba is always structured. If you want to turn something unstructured into something structured, you generally run a separate pipeline to do that (using one of the tailing frameworks for your preferred language). In terms of the alarm system in Splunk, we have other systems for handling that using the data that flows into Scuba.

Be careful comparing the "Registered Users" metric on the page between sites. In some cases they're using total number of registered accounts on the forum, and in others they're using metrics that involve recent activity, like a "Monthly Active" metric.

Also, don't trust the numbers, even if they're cited. The current value for Twitter (500 million) is cited as being from an article in 2011 that mentioned 200 million. The Twitter company page - https://about.twitter.com/company - says the current official monthly actives is 313 million.