5 ms·
That's nuts, dude I'd take ONE top faang engineer over 8 government software contractors. There's so much tribal knowledge out there that people in the Midwes
by VRay 5y ago
That's nuts, dude
I'd take ONE top faang engineer over 8 government software contractors. There's so much tribal knowledge out there that people in the Midwest just don't have, not to mention a can-do attitude.
It blew my mind the first time I worked with a guy from Microsoft on something. We were having issues with some code, and he just popped open the kernel and started actively debugging things that I'd only vaguely even heard about. I feel like I was twice as good at engineering after that experience alone.
I had the same experience from the other direction later on.. a team of smart, hard-working coders had been dealing with stability/perf issues for years on some product. I was able to root cause and straighten all of them out in a couple of weeks, even though this was in an area of software development using a set of tools I'd never touched before.
I'll bet a single FAANG-hardened code wizard could outperform 20 or 30 government coders.
- mrsalt 5y agoCan you expand on what do you mean by "just popped open the kernel"? I'm genuinely interested in this kind of "tribal knowledge" you talk about. Maybe there is something we (those reading this thread) could learn and make use of.
- sterlind 5y agomaybe WPA, which lets you sample stack traces from user-mode all the way through drivers? Or DbgView, which lets you see printk output from kernel mode. Or hell, maybe even Windbg debugging the kernel of a Windows VM over simulated serial (you need a checked build of Windows to get the most bang for your buck there, though.) the hardest-core thing I've done was step my way through Windows startup into the container subsystem, on a real, physical target machine I had connected to my dev machine over FireWire. I felt like Indiana Jones. (It helped having the source code though!)
- VRay 5y agoI think Sterlind already covered about as much as could fit in a casual comment online.. The basic idea is that you draw a box around your system, then check all the inputs and outputs. If the inputs are good and the outputs are bad, you open the box and draw boxes around what's inside. Don't be afraid to dig through heap dumps or decode assembly if you have to, although when you hit that point you're probably just going to have to swap out whatever component is misbehaving
- deleted 5y ago[deleted]
- sphotavada 5y agoI created an account for the sole purpose of telling you how much of an auto-masturbatory, gatekeeping wiseacre you are.
- oalae5niMiel7qu 5y ago> I had the same experience from the other direction later on.. a team of smart, hard-working coders had been dealing with stability/perf issues for years on some product. I was able to root cause and straighten all of them out in a couple of weeks, even though this was in an area of software development using a set of tools I'd never touched before. I've done this at a company full of ex-Googlers. Some programmers are simply incompetent, no matter where they've worked.