Ask HN: Has anyone here worked on the Windows kernel?
I've been offered a position at Microsoft to do kernel development work. This would be a big transition to me, coming from a services background (backend only).
The job's main draw to me is doing low-level work. I did some in my very first job, but for the past 10+ years, due to a number of circumstances, I've been in the services world. I really liked being a C programmer and I've kept an eye on things over the years, and did some hobby projects (on x86 and some embedded stuff as well).
There's a lot about my current job that I treasure, despite the work itself not being interesting to me about 99% of the time. It's a remote job, the work-life balance is stellar, and I get 25 days of vacation a year (this is in the US), which allows me to spend a lot of quality time with my wife.
However, I'm considering leaving because I've been having significant motivation and performance[0] issues for the last two years. Through a lot of soul searching and even help from a therapist, I've identified that the source of my issues is the nature of the work itself. Building services is just something that doesn't give me a sense of accomplishment, and I'm not attracted to the stuff at all. Some issues I've identified are:
1. Infrastructure complexity, especially since moving to Kubernetes. I refuse to touch it at this point.
2. Debugging exclusively via metrics and logs, since I can't just attach a debugger to a running server.
3. Designing systems in general. Some people love the challenge of distributed transactions, eventual consistency and all that jazz, but it just rubs my brain the wrong way. I'm not interested at all in that problem space [1].
4. The insane amount of work required to stand up even the smallest microservice: infrastructure provisioning, certificates, security reviews, GDPR compliance, etc.
5. Anything I build will end up paging some poor soul at 3am some day when something is down or under heavy traffic.
So, what I'm wondering is: what are the things that would make me say "ugh" on the day-to-day as a kernel developer? Is there a chance I'll be happier, or would I just be trading one miserable set of problems for other equally miserable problems?
I tried asking that to every person who interviewed me, but I only got somewhat vague answers like "the build can take a long time depending on what you're doing", etc. Someone complained about windbg.
[0] Even though my reviews have been good, I know deep inside I'm not doing even 10% of the good work I could do before.
[1] Ironically, I've acquired a ton of knowledge about it and I'm one of the "go to" people within my org.
173 comments
[ 2.5 ms ] story [ 205 ms ] threadThere's zero reason to think that Kubernetes is like a 4-wheel driven car for the same reason to think that Kubernetes is like a train, or Kubernetes is like a virus, or Kubernetes is like a snowman; it's completely unrelated.
That's like saying, well, you can use words to construct a lie, therefore, all words are untrustworthy.
He's saying that k8s can be powerful, but that that power can be destructive if not wielded correctly.
Personally? k8s is powerful. But you need a team to manage it, and if you're the poor sob who wants to write software but gets stuck managing k8s (due to its complexity) half the time, you're not going to be very happy.
K8's (and other similar tools) allow you to push complexity into places that are harder to troubleshoot. Its another layer of abstraction, and too much abstraction is dangerous in complex systems.
I said that saying K8s is like X requires that you show how it is like X first, before you can draw any conclusions from that analogy. Otherwise, it is not an argument and should have zero value in a conversation, other than someone stating their (unsupported) opinion.
When it comes to political discussions, I think it is reasonable to demand that everyone who chooses to participate substantiate their claims and make arguments rather than stating opinions. Misinformation about politics is serious, it can be a matter of life and death.
That standard does not apply to talking smack about Kubernetes on the internet. I can tell you that programming in Python feels like a game of operation and that programming in Rust feels like a breath of fresh air. I don't have to tell you why. You shouldn't try to argue against this, either - it isn't something I can possibly be wrong about, or that you could possibly understand better than I. You can tell me about how you feel like Rust is overhyped garbage (I have no idea how you feel about Rust, it's only an example). But why would you try to tell me how I feel?
What is the consequence if my statement goes unchallenged? Someone tries to learn Rust and is disappointed that it doesn't match the hype? Some engineer starts a new project in Go instead of Python because they don't want to play operation? Life goes on.
If you look at it through that lens, you can make sense of it. They're not saying there's a relevant similarity between Kubernetes and vehicles. They're saying that with more complex tools you make more complex mistakes, that Kubernetes may have solved problems but it also gave us more rope to hang ourselves. And I bet you'd have something interesting and productive to say in response to that idea - you obviously have passionate opinions on this subject.
I'd also note, no one ever said not to use Kubernetes. The general vibe was that Kubernetes is stressful to work with. Again, no one is making an argument - they're venting to other engineers.
That's fine, and I'm glad that people are admitting that their comment shouldn't be taken as persuasive, or anything other than self-expression. Many people think analogies are persuasive, but they're often nothing more than illogical rhetoric, and it's a critical blunder to be persuaded by an unjustified analogy.
I do run a kubernetes cluster outside work as a side project and it hardly takes me more than 2 hours per month. It mostly run cloud instance of my open source software for customers and is saving a lot of time compared to the manual process of creating dns manually, rp rules for everyone, handling of SSL, monitoring, ... Just to think about the work that would be required to get all this done outside kubernetes makes me sweat and the maintenance aspect of such a solution would make it even worse.
That's your error: you are evaluating k8s on a use-case that is not representative.
Once you scale up the number of nodes, the number of applications, and the years of uptime the complexity grows exponentially.
Now your team needs to be able to debug each component in the OS stack as well as k8s itself.
In the long run you always pay the price for unnecessary complexity - and with interests.
You might even be able to return to your old company if you hate it. Tell them directly "hey I need to give this a shot but I'd love to check-in in a year".
If you can read and enjoy these books, consider it:
https://docs.microsoft.com/en-us/sysinternals/resources/wind...
The ugh!: You will be a tiny cog in a big machine, spending very little time writing code, mostly banging your head over someone else's bugs. And M$FT still has a certain stink to it these days and that may cling to you.
You'll run into a lot of the same issues on the Windows kernel that you're getting irritated with in service development land. A lot of infrastructure is already out there, but figuring out how to use it effectively ends up being almost as much work as just rewriting it from scratch. Things are documented but poorly.
For Microsoft specifically you'll often get stuck because of problems with some other team's code, and then find yourself embroiled in multi-week battles with multiple engineers, managers, project managers, and product managers all at each other's throats.
All that said, the Windows kernel itself is a work of art IMO, and kernel development is a lot of fun. I think that if you want to make the big bucks but still work with c/c++, it's getting to the point where your choices are very limited: Microsoft, Google, Facebook, Apple, or Tableau.
Microsoft was terrible to work for, but they aren't as bad as a bad small company. At least there's HR to report gross violations to, they have a TON of great perks, the money is really good, they have good work-life balance, and it's not too hard to change teams (but if you find yourself wanting to jump to a different team, do it well before performance reviews come along, since your manager will definitely give you a bad review and hamstring your ability to move around within the company.. so you'll end up having to change companies. Not the worst thing if you do so, I guess)
EDIT: I just reread your list of complaints.. timing and consistency in the kernel are WAY more complicated than your average web services. There's also a ludicrous amount of red tape around getting anything done. I'm starting to think that you should look at Microsoft as a stepping stone in your career rather than its final destination.. it's still a good place to work for overall compared to random small companies, it'll give a boost to your resume, but it sounds like what you actually want to work on is game emulators or raspi home automation gizmos in your free time.
I’m not telling you or anyone else in these companies to suck it up, but there’s a point where employees and teams in these situations need to step back and realise what they’re dealing with, and adjust their mindset accordingly.
Personally, I like identifying and unfucking bottlenecks. Sometimes explaining why something is so fucked to the people being fucked can go a long way.
The pity is often how the most qualified talent for resolving poor behaviour is so often subordinated into slopping out the pigsty. There needs to be a foundational next step.
Edit: since Fairchild we've been scared of merely assembling raw talent under a thin layer of management capabilities and from this is developed the pseudo matrix management system that e.g. Microsoft operates.
I don’t like it either, but I can’t really do much about it. If you realise you’re in a difficult organisation, you can at least start to take action, or take a different tact (or leave). Being annoyed about the situation is probably just going to make you more and more unhappy because the system won’t (or can’t) change in your desired timeframe.
What's funny is that the guy agreed with everything I thought, he saw the problems that were hamstringing me (and everyone else), he had complete authority to fix the problems.. and so far as I can tell, he wasn't having any luck with it
The best fix seems to be to tell people to quit being jerks to each other and focus on making good products and making customers happy, but good luck getting that to happen.
One of the main criteria for performance reviews was suddenly something along the lines of "Teamwork" that captured what a non-toxic, non-Ballmerized good person you were. Of course, all that happened is that the best backstabbers and the weaseliest scumbags manipulated their way into high "Teamwork" scores, and anyone who sat down and focused on productive work/helping others got screwed on that score just like everything else.
There’s going to be SOME of that stuff any time you have more than one person in the same building, but a decade under the iron fist of Ballmer has permanently ruined Microsoft as an organization.
Judging by the presenters at CPPCon, a significant fraction of highly-skilled and highly-paid C++ devs are employed in the High Frequency Trading (HFT) industry.
They meet OP's criteria in many ways as well, as HFT trading tends to be "very close to the metal", optimised to death, and often involves solving deep technical problems. It's diametrically opposed to modern web development practices.
I’m pretty sure that you could donate a big chunk of the million+ ill-gotten dollars to charity and make a lot of good things happen
This is documented in Zachary's Showstoppers book:
https://www.flyingpigbooks.com/book/9780759285781
It appears that performance and architecture improvements are very hard to get accepted (and the kernel suffers for it):
https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-...
It is a great piece of engineering, but it is likely for a developer that is more comfortable making small changes within the hierarchy than for any revolutionary ideas (unfortunately).
If Cutler hadn't found his way to Microsoft, then they probably would have ended up on a BSD kernel, as Apple did. As it was, Microsoft sold their Xenix business around the time of Cutler's arrival.
It’s a fractal shape too. You see the same sort of intrapersonal weaponry at the division level, the org level, the group level, and even within teams
Maybe it even continues to a Herman’s Head-style inner conflict for good company men
Presumably Tesla and Uber must have some “native” code being written somewhere in-house too, and someone mentioned the HFT industry
There are a lot of decent jobs out there that will keep you comfortable, too, even if you can’t bring in 300k+.
> 2. Debugging exclusively via metrics and logs, since I can't just attach a debugger to a running server.
You often can't do this in kernel/OS development work either. Serial printf logging is often required. It can be a real "my tools to debug my tools are broken" slog.
> 3. Designing systems in general. Some people love the challenge of distributed transactions, eventual consistency and all that jazz, but it just rubs my brain the wrong way. I'm not interested at all in that problem space [1].
I'm not sure I understand this issue. I mean, kernels have subsystems for doing stuff; you might need to design one someday? But it won't be dull-as-dishwater web technology stacks, it'll be you writing data structures directly in C/C++ or Rust if MS goes there.
Tools like windbg probably work great until you are debugging the code that runs when windbg tries to take over. Or you’re debugging something sensitive to interrupts and it’s literally impossible to keep up with a tool like windbg. Or you a debugging something that overwrites windbg in memory because you have a corrupt pointer. Or you triple-fault the machine and it reboots with so much prejudice that windbg doesn’t have a chance. Or you’re poking at hardware that the debugger can’t usefully interact with. Etc.
Basically, in the kernel, a lot of the things that a working kernel does to hold your hand aren’t available. So there’s a lot of time spent just thinking or adding logging statements or otherwise using low tech tools. (Or using high tech instrumentation or sanitizers!)
Kernel development is great :)
https://designintools.intel.com/Silicon_View_Technology_Clos...
Most of the time you can do kernel dev with a serial port and printf though.
https://docs.microsoft.com/en-us/windows-hardware/drivers/de...
These days I mostly use gdb (which is incredibly buggy for such things) attached to QEMU’s gdbserver. It works except when I doesn’t.
>I'm not sure I understand this issue. I mean, kernels have subsystems for doing stuff; you might need to design one someday? But it won't be dull-as-dishwater web technology stacks, it'll be you writing data structures directly in C/C++ or Rust if MS goes there.
Ah, I meant designing distributed systems. Like, figuring out the difference services, storage requirements, databases, then planning out the infrastructure. It's really not my cup of tea. I do enjoy designing systems/subsystems/components as long as they're within a single host :)
The culture in games is very healthy from my experience and one of the best compensation in the games industry.
Microsoft is incredibly siloed. Each team is essentially their own mini company and they're mainly guided by large top line metrics but there's no top down overall vision on what something should look like. It's like those party games where everyone has to draw a portion of a drawing. It comes out looking like a disaster even if every individual portion is good. This also means that product management doesn't work with any particular team either. You essentially get some random big metric and are told "make this metric better" without any context. Everyone is duplicating work and there's nowhere to learn from
Microsoft Teams is a disaster in so many ways. In the most obvious way, it's very very slow and a pain to use. This subtly hinders teamwork because no one wants to use teams. In other ways, there's no global search so finding stuff in other orgs is impossible. The teams "channels" are essentially shitty forums that are unintuitive to use. You'll never get a channel about hobbies and stuff and even if you did it's hard to find and they're usually dead. Everyone uses private group chats including each team but these have zero discoverability. What this means is you'll never have a golang channel or something where people share and chat about stuff. Most people have a facebook group where they chat about stuff (wild).
Every team has their own onboarding down to what hardware you should get. In theory this allows for some flexibility but what this actually means is that no one has any idea how you should be onboarded and you essentially are sent to flounder until you pick stuff up.
Everyone is doing everything. Every person is their own product manager, scrum master, manager, and also programmer. There's so much duplicated process overhead it's wild.
They have not handled remote well. They insisted on trying to send me a desktop computer. I asked for a laptop and they couldn't give it to me and they instead sent me a used intern laptop. They gave my sibling a used surface tablet. This is a 2 trillion dollar company and they're unwilling to shell out 2k for a basic workstation computer with 6-8 cores and 32gb of ram. Not a huge ask. Also some stuff is only accessible through a direct hardline in the office. Whether you want to use a desktop or not is irrelevant. It's mainly how cheap they are when it comes to hardware.
EVERYTHING has to be Microsoft software for the most part. If you think nih syndrome is bad at your company, imagine you're at a company where they've been making mostly mediocre versions of other software for the past 30 years. Yeah. I'm not a huge splunk fan but trust me when I say the azure equivalent is much shittier.
The pay isn't top notch. In fact it's pretty bottom barrel for a big company and if you can pass the microsoft interviews you can pass somewhere else. Their interview process is also a nightmare. I went through 4 different recruiters and it took me 2 months between passing to get an offer letter. The whole thing was insane. They initially offered me such a paltry amount it made me laugh.
Everyone is a lifer because anyone else has left. Imagine talking to your boss about docker or talking to him about IntelliJ and he's never heard of it because he's been at Microsoft for 20 years.
There's a lot of weird "not racism" but might as well be where certain ethnic groups have taken over certain orgs and speak in their primarily mother tongue despite being in the US in a US based company. It makes teammwork really hard.
You need a separate laptop to log into any production resource. Production resource is a loose term because that also includes int environments and anything on azure. I have 2 laptops and a desktop that I'm forced to remote into it's ins...
Microsoft is great. It's an amazing place to make impacts in many different areas of technology. Work teams used to be more siloed, but that's changed a lot in the last 6-7 years. We regularly work across teams at GitHub and Microsoft to get things done with great cooperation.
As for Teams vs. Slack vs. Discord, it's a personal taste thing. I'd rather have Teams over Slack + Zoom 1000x.
Take the Windows kernel job! Worst case, it's not a fit and you move on, like any other job. Best case, you stick around for a long time and have a great career working on tech that 1B+ people use.
When Robert Downey Jr. was trying to talk Gwyneth Paltrow into joining "Iron Man", he said to her something like, "do you want to work on art house films the rest of your life or do you want to be in something that people actually see?"
Windows is massive... it's the largest code base that I'm aware of. It has a ton of process and procedures and test cycles because... it's Windows. Of course you can't just freelance there. But you can "be in something that people actually see", and most SV startups will never even get 1,000 users, much less 1,000,000,000+, and more if you count the users on Azure services using Windows indirectly.
Sounds like a bastardization of Jobs on convicing John Sculley manufactured by a PR person:
Steve Jobs and John Sculley, then PepsiCo president, were sitting on a balcony overlooking New York’s Central Park. Jobs turned to Sculley and said, “Do you want to sell sugar water for the rest of your life or come with me and change the world?”
https://www.forbes.com/sites/carminegallo/2016/11/12/how-ste...
That's like asking someone who cooks at a fine-dining restaurant to work at McDonalds, "do you want to make pretentious food for 40 cashed up foodies and critics a day, or do you want to make food for hundreds of regular people a day?"
People pretending that Facebook, Google, Microsoft, et al are noble endevours are deranged. It's like rooting for Walmart to win the World Series of Retail.
A pet peeve of mine is pizza joints who serve a different pie every time, depending on who's in the kitchen. If I have a great pizza, I expect to get it again, but rarely do. Consistency is hard.
https://www.amazon.com/Old-New-Thing-Development-Throughout/...
Also read - Showstopper
The windows org has a reputation of being dysfunctional although I never personally observed this, and personally think even if it were true it would be in the higher level parts of the stack.
Kernel dev was my original dream but I fell in love with Excel during my internship. I definitely think you should go for it.
I think what you should do is, if possible, arrange for a short call with some of the team mates that you are going to work with. Just a casual one about how the kernel team day to day work looks like there. If not with the team, then maybe with your manager.
Unless someone from that team or some ex-kernel team member replies here, all the rest of these posts are just speculative and not worth basing your decision on.
I don't hate the competent developers at Microsoft (of course they exist, there have been source code leaks) - I just very strongly dislike the machine that is Microsoft. I don't think the machine has reformed.
The concern for me would be the fact that windows is no longer a fully offline experience running on people's desks. A large part of the kernel team is working on features that only benefit Azure and you may get some of the same services exposure there as you claim to be so burnt out on.
Asking to discuss the role more with the team to get a better sense of what they're doing, how they're doing it, and who their customers are seems like the path forward IMO.
And the IIS team, and the networking team, and…
I think you are coming at this from the wrong perspective. Rather than thinking about how to avoid work you DON'T like, think about what you DO like and then decide if the new job would offer more or less of that.
Personally, I've found that every five years I end up sick of working on the same kind of problem and I have to go work on something completely different. Maybe that's where you're at.
Is it difficult to transition? Yes, in that if you spend 10 years learning SystemA, then it will take some time with SystemB to build up to the _same level of expertise_ that you enjoyed on SystemA.
The neat thing about learning one OS or system _deeply_ is that the deep knowledge gifts you with frameworks for learning the next-system.
I wrote software on various *nix'es during my university time, then worked on OS/2 (yes, "OS-who?"), Windows, and now I'm at Google, (my work involves 80% Linux 20% Win). It took me some time to re-build my skills on each environment/platform, but it's been a great ride and a lot of fun.
(P.S. earhart@ pointed me to this thread, and says hi to all y'all: Evan, JonO, JVert, LandyW? Dan?)
Source: 33 years experience hopping all over the spectrum
Ultimately, it's all just code and problem solving. And you can usually find a way to leverage your expertise in one domain into a different domain.
Kernel code is amazing, especially the parts written by the early members like DaveC, MarkZ and others.
For me the biggest part was working with a group of extremely smart people who were very nearly the best programmers in the world.
I really miss that outside of Microsoft. I would imagine that you can get the same experience if you worked with the Linux kernel dev team or some of the other few places in the world like FAMGA where you can work.
My suggestion is to go for it. After leaving MS I found peace by working with the open source community and open source software.
Hope that helps, happy to discuss further.
I would say James Mickens sums things up nicely in "The Night Watch[0]." For example, you mention debugging with logs and metrics -- this snippet came to mind:
Mind you, I absolutely _love_ working on low-level stuff, and I wouldn't trade the time I get to spend actually doing that for anything. That said, the complexity of modern operating systems, CPU architectures, interconnects, and peripherals creates opportunities for frustration and confusion that honor no bounds of reasonability or decency.[0]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf
I know I can; I don't even need any of my fingers.
https://mickens.seas.harvard.edu/wisdom-james-mickens
Edit: reference source decades of being quite intolerable myself. Takes one to know one. And by my experience incredible good fortune and more decades to repent.
I also have gotten a lot slack for it. But I see it as a way to convey that new feeling of wonder and awe a child has upon entering a new world. Challenge the assumptions, make up some nice words, pretend very hard that your academic title is an actual thing that gives you some blessed superpowers (as is the way that people often treat it!). I love it. It's truth wrapped in humor to soften the blow to the ones that think themselves overly important. The "shocked ones" are the ones that I try to avoid in life anyway, nice discussions begin at the edge of your comfort zone.
We loaded the connection in varying patterns for about an hour. ZERO CRC errors. Scratching our heads, we decided to punt. Then suddenly the CRC error count started climbing on my scope. I shout into the speakerphone, excitedly, what did you all just do? They’re like “nothing but unplug the scope from the patch panel”. “Please plug it back in”. CRC error count stopped.
Diagnosis: faulty patch panel.
Such luxury! I just spent a couple weeks getting FreeBSD booting in the Firecracker VM and most of my debugging was performed by inserting hlt instructions into the FreeBSD kernel and looking at whether virtual CPU halted or hit a triple fault.
Ah, I see the gentleman works directly in binary.
JFYI:
https://tinyapps.org/blog/200702250700_why_in_my_day.html
This might be my all-time favorite quote that I never to get use in relevant situations because nobody is around who would get the reference. I think of it almost every time I hear the word "tool"
Only comparable experience I can think of is "breaking" the terminal via bash_profile and then not being able to fix bash_profile via the terminal. Or locking yourself out of a web server via security configuration update.
That: uh-oh! moment.
The main thing I'd consider in this is the work/life balance. Will it allow the same stellar level of that? People vary in their priorities. For some it's interesting/fun problems to solve, for some it's impact, but for me it's work/life balance, presuming of course that the work side isn't a hateful stressfest. No amount of remote work or flex schedule will make up for absolutely hellish work environment, and I had something like that once. (I ended up taking a 30% pay cut that I could just barely afford and got the heck out)
So I'm sorry that I can't speak to the kernel work itself, but instead the framework for making the decision. If the work/life balance will remain constant then you're only risking the possibility that the work won't be any better, and hopefully no worse. If the work/life balance for the new job is also uncertain then (for me) that would be a bigger risk consideration.
Finally, you should consider the worst case scenario: The work is worse, the work/life balance is also worse. How easily can you shift to something better? If you have the chops to work on the Windows kernel then I'd wager that if you hit the worst case scenario you could get out of it without too much trouble, but you're the only one who knows whether or not that's true.
Best of luck to you, sláinte, and may the wind be always at your back.
Microsoft's work/life balance is good in my experience; managers respect your time, product deadlines rarely or never cause long-hour rushes, and if your role lacks an on-call rotation then you won't be woken up in the middle of the night. But other companies may be far worse, and Microsoft is big enough that one person's experience never truly generalizes.
For time off in particular, as of my last experience 2 years ago, MSFT's US policy on paid time off was stingy by American tech company standards:
* There is no scheduled period of the year where everyone gets paid time off. (LinkedIn has 2 such weeks a year but it manages its HR independently of the rest of Microsoft.)
* You accumulate 3 weeks of vacation PTO per year of work for your first 6 years at the company, then 4 weeks per year for years 7-12, then 5 weeks per year for years 13+.
* Unused vacation days expire at the end of the calendar year following the calendar year in which you accumulated them.
* When you leave the company, you get a "vacation cash-out:" you are paid a lump sum equal to all your unused, unexpired vacation days.
* In addition to vacation, each calendar year you get 2 weeks of paid sick leave and 2 "floating holidays" to use like vacation days.
For comparison, at Google you accumulate 4 weeks of vacation per year starting just in year 2, while at Netflix and many smaller companies you get unlimited vacation at the cost of no cash-out.
In practice, there is more leeway at Microsoft on PTO than this policy allows. Even when I had an otherwise poor relationship with my manager, they still looked the other way when I went on Christmas/New Year's week vacation without filing an absence request or using up my vacation days. And I have heard of divisions where after a particularly stressful and overtime-heavy year, the division Vice President told everyone to take such an off-the-books holiday vacation.
[1]: https://news.ycombinator.com/item?id=30892773
1. There will be a lot of infrastructure complexity in the kernel, just prepare yourself for that. Even worse bugs! You'll be fixing a lot of bugs, or looking at a lot of bugs, and most of these bugs are from other teams who are interacting with your component! Just order a copy of Windows Internals and get yourself familiar with how thing work.
2. Old ass engineering systems. Just as the interviewers said you will spend a lot of your time waiting for Windows builds.
Good stuff:
1. Work life balance is amazing actually. Most of the time there's very little pressure for you to get work done, as long as you're doing something no one really bothers you.
2. Since you said you hate designing systems, good news, everything has been designed for you! Your, job will mostly be implementing new features for a component.
3. Windbg is actually great and I will die on this hill. You might have to print some debug logs but you won't be looking at metrics because there's whole teams dedicated to doing that stuff. There's also tools which quickly spin up VMs for you to do some live kernel debugging.
Meh stuff:
1. The pay, could be better. That might change soon though.
Came here to say this. (Actually kd, but lots of overlap.)