Hacker News Reader

Comment by amir734jj | Hacker News Reader

But good luck figuring out how that code works. Disclosure I work at Microsoft and I work with ropes with millions of lines of code.

View on HN

I think the best skill I learned at Google was figuring out how other people's code works. You read the documentation, and then you make some RPC. It doesn't work as documented. You go read the other service's logs and see an error message, but it doesn't make any sense. You search the codebase for that error message. You find that the super deprecated do not include field is mandatory; it's sent to some other service that thinks it's important. 10 minutes later, you fix your code, the RPC works, and you're on to the next thing. No meetings, no calls, no emails, no time zone coordination, no bugs languishing in some queue that you're not even sure it's the right one... just a solution!

I was really surprised how uncommon this is outside of Google. People will hit an issue with a library, file a bug, and just sit there blocked without ever opening up the malfunctioning code and reading through it. Why turn a one player game into a multiplayer game unless you really have to? Reading code is what you do for a living!

Like anything, it's a skill that you need to develop, but it's one that will make you really productive.

I find this difference also between people who grew up on open source vs proprietary software.

I'm nervous about running in production software I can't open up and look at how it works under the hood. I often use that ability to understand my systems better.

Some people just don't care about that. They're used to paying a support agreement and opening a ticket or calling a support rep instead. I will never get it but clearly that's how some people like to, or are at least used to, operate.

This is a great insight, thanks for sharing.

I wonder how developers at companies like Apple and Microsoft are able to be productive with hidden code.

So I guess the other side of the coin is that some people are very good at managing their vendors, internally or externally. This is another useful skill to learn. I'm not that good at it, but it's good to have both options in your toolbox.

People do do this. The problem is the docs never get fixed and everyone needs to do what you just did. Great if you have essentially infinite money; otherwise bad.

To me documentation is largely a lost cause, it starts out behind the code and stays that way forever, because the machine can't execute the documentation. Yes, the human maintaining the code is more important than the computer running the code, but when you have an infinite number of tasks to get done, what the computer accepts is a pretty good stopping point for most people.

Personally I see a lot of value in documentation (that's how I learned the basics of programming and the systems I use), but since it's always out of date and wrong, I tend to undervalue it. Maybe that's a mistake.

This is why I like Flask+Connexion or FastAPI - endpoints are generated from Swagger docs or vice versa.

FB is eons ahead of Microsoft in this regard. Their homogenous development experience eliminates tonnes of learning curve and busywork that you get with thousands of unique repos, build pipelines and and environments.

Reply on news.ycombinator.com