6 ms·

That doesn't explain the useless engineering theater that these companies engage in, like code review and "readability", that drastically reduce IC velocity. If

That doesn't explain the useless engineering theater that these companies engage in, like code review and "readability", that drastically reduce IC velocity. If FAANG supposedly "only" hires the "best and brightest", then why are they so untrusting of their contributions? I mean, I've never worked in a team that large. A big part of that is because I can't imagine asking someone else's permission to write code. If a company can get so big that they can't trust their developers to release code, maybe that company is just too big? Companies like Google are a joke. All the Cap'n Crunch you can eat, but do your job and write some code and get it into production? Can't have that! EDIT: the largest company I ever worked at only had about 300,000 employees.

dang 4y ago
We detached this subthread from https://news.ycombinator.com/item?id=34735099 https://news.ycombinator.com/item?id=34735099.
ethanbond 4y ago
Writing code isn’t hard, maintaining it is.
- moron4hire 4y ago
  [flagged]
TheLonelyGecko 4y ago
You should try code review, it’s a great tool.
- moron4hire 4y ago
  I can't see how. If I were to be in an environment where there are multiple developers who can understand even the basic mathematics of geometry and linear algebra too do what I do (that's a tall order. It hasn't happened once in 20 years that I've worked in a company that has had even one other developer that knew anything beyond basic algebra), why would they spend their time telling me how to do my job, rather than just doing their job? If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it? It's kind how my children argue over basic things like bedtime. They insist it's only "fair" if one of them turns off the light and the other closes the door. And if the light is already off when they enter the room, then the door closer is going to get pissy and turn the light on to make his brother get up out of bed and turn it off. It's a meaningless exercise developed to give the illusion of control.
  - chasd00 4y ago
    > If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it? well.. fair point. Code review guarantees nothing, if there is an issue found there's going to be delay to fix it as it rolls back through the process. I hate "process" as much as anyone else but I learned during COVID its importance. I implemented a vaccine system for a state government with a team starting at 3 and growing to over 100 in about 8 weeks. It was the hardest thing i ever did and "process" saved my ass and kept CNN off my front lawn a few times. It also was a real thorn in my side when i needed to get things done. Process vs getting-shit-done is a balance and it's rarely perfect.
  - snovv_crash 4y ago
    I struggle to believe that your coworkers don't understand the basics of LinAlg and geometry. It seems much more likely that you write code which is hard to parse, can't be explained, and your concept of maintenance is rewriting it from scratch because you don't understand it a year later either. Writing code that other people understand is an independent skill from solving the particular problem at hand. If your colleagues don't understand your code, either you need different colleagues, or you can't write understandable code.
    - bambax 4y ago
      > Writing code that other people understand is an independent skill It's also the main skill of a developer. Code is for people.
      - chasd00 4y ago
        >> Writing code that other people understand is an independent skill > It's also the main skill of a developer. Code is for people. If there are any people reading this starting out in their career, i can't stress how important this is. Being able to write beautiful code and being able to explain it to your peers and see them take off with it and do amazing things is the single most important skill as a software engineer IMO. I would put it above any algorithm riddle, esoteric language feature, tool expertise, or anything else.
threeseed 4y ago
Code reviews aren't unique to FAANG or other large tech companies. Might want to look into Github to see all of the many open source projects that are doing code reviews for every PR.
- moron4hire 4y ago
  Stockholm syndrome, or cargo culting, take your pick.
  - dang 4y ago
    Would you please neither start nor perpetuate flamewars on HN? You did both here. Not cool. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - VirusNewbie 4y ago
    Is this a parody account? Performance art of what we all collectively think a terrible engineer would seem like? This seems too fake.
    - dang 4y ago
      Personal attack is not allowed on HN, so please don't post like this, regardless of what another commenter does. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - moron4hire 4y ago
      [flagged]
      - ctvo 4y ago
        What does any of this have to do with you thinking code reviews are worthless and slows down velocity? A whole reply of strawman arguments while tossing in the word 'milquetoast' doesn't make it intelligent. As others have pointed out: code reviews exist for many complex projects even outside of these big companies. Code reviews existed before these companies.
trieste92 4y ago
Username checks out
mcv 4y ago
> useless engineering theater that these companies engage in, like code review and "readability", Oh boy. Sure, if you're small, working on your own or at an early startup, you can get away with ignoring code quality and just hack away to rapidly do amazing things. As soon as someone else is going to have to change something about that unreadable code, you're going to wish it had been written with a bit more readability. Moving fast is great for a quick PoC, but if you're going to take that straight into production, you'll see tech debt pile up fast. Although with large companies, there's also the fact that large companies are just intrinsically slow. I've had plenty of projects where I moved faster than the company could deal with. But also some where some people greatly appreciated the speed at which we could pivot and respond to their needs. But that speed was always built on a basis of readable, maintainable code. And every time we had to deliver something too fast, we followed it up with a period of refactoring to clean up the tech debt, so the next time we needed to, we'd be able to be fast again.
bambax 4y ago
Code reviews are not about "getting permission to code"; yes, they are a form of quality control, but they're also a way to share knowledge among a team, so that if you decide to quit suddenly, your coworkers can make sense of your code.

dang 4y ago

We detached this subthread from https://news.ycombinator.com/item?id=34735099 https://news.ycombinator.com/item?id=34735099.

ethanbond 4y ago

Writing code isn’t hard, maintaining it is.

moron4hire 4y ago
[flagged]

TheLonelyGecko 4y ago

You should try code review, it’s a great tool.

moron4hire 4y ago
I can't see how. If I were to be in an environment where there are multiple developers who can understand even the basic mathematics of geometry and linear algebra too do what I do (that's a tall order. It hasn't happened once in 20 years that I've worked in a company that has had even one other developer that knew anything beyond basic algebra), why would they spend their time telling me how to do my job, rather than just doing their job? If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it? It's kind how my children argue over basic things like bedtime. They insist it's only "fair" if one of them turns off the light and the other closes the door. And if the light is already off when they enter the room, then the door closer is going to get pissy and turn the light on to make his brother get up out of bed and turn it off. It's a meaningless exercise developed to give the illusion of control.
- chasd00 4y ago
  > If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it? well.. fair point. Code review guarantees nothing, if there is an issue found there's going to be delay to fix it as it rolls back through the process. I hate "process" as much as anyone else but I learned during COVID its importance. I implemented a vaccine system for a state government with a team starting at 3 and growing to over 100 in about 8 weeks. It was the hardest thing i ever did and "process" saved my ass and kept CNN off my front lawn a few times. It also was a real thorn in my side when i needed to get things done. Process vs getting-shit-done is a balance and it's rarely perfect.
- snovv_crash 4y ago
  I struggle to believe that your coworkers don't understand the basics of LinAlg and geometry. It seems much more likely that you write code which is hard to parse, can't be explained, and your concept of maintenance is rewriting it from scratch because you don't understand it a year later either. Writing code that other people understand is an independent skill from solving the particular problem at hand. If your colleagues don't understand your code, either you need different colleagues, or you can't write understandable code.
  - bambax 4y ago
    > Writing code that other people understand is an independent skill It's also the main skill of a developer. Code is for people.
    - chasd00 4y ago
      >> Writing code that other people understand is an independent skill > It's also the main skill of a developer. Code is for people. If there are any people reading this starting out in their career, i can't stress how important this is. Being able to write beautiful code and being able to explain it to your peers and see them take off with it and do amazing things is the single most important skill as a software engineer IMO. I would put it above any algorithm riddle, esoteric language feature, tool expertise, or anything else.

threeseed 4y ago

Code reviews aren't unique to FAANG or other large tech companies. Might want to look into Github to see all of the many open source projects that are doing code reviews for every PR.

moron4hire 4y ago
Stockholm syndrome, or cargo culting, take your pick.
- dang 4y ago
  Would you please neither start nor perpetuate flamewars on HN? You did both here. Not cool. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- VirusNewbie 4y ago
  Is this a parody account? Performance art of what we all collectively think a terrible engineer would seem like? This seems too fake.
  - dang 4y ago
    Personal attack is not allowed on HN, so please don't post like this, regardless of what another commenter does. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - moron4hire 4y ago
    [flagged]
    - ctvo 4y ago
      What does any of this have to do with you thinking code reviews are worthless and slows down velocity? A whole reply of strawman arguments while tossing in the word 'milquetoast' doesn't make it intelligent. As others have pointed out: code reviews exist for many complex projects even outside of these big companies. Code reviews existed before these companies.

trieste92 4y ago

Username checks out

mcv 4y ago

> useless engineering theater that these companies engage in, like code review and "readability", Oh boy. Sure, if you're small, working on your own or at an early startup, you can get away with ignoring code quality and just hack away to rapidly do amazing things. As soon as someone else is going to have to change something about that unreadable code, you're going to wish it had been written with a bit more readability. Moving fast is great for a quick PoC, but if you're going to take that straight into production, you'll see tech debt pile up fast. Although with large companies, there's also the fact that large companies are just intrinsically slow. I've had plenty of projects where I moved faster than the company could deal with. But also some where some people greatly appreciated the speed at which we could pivot and respond to their needs. But that speed was always built on a basis of readable, maintainable code. And every time we had to deliver something too fast, we followed it up with a period of refactoring to clean up the tech debt, so the next time we needed to, we'd be able to be fast again.

bambax 4y ago

Code reviews are not about "getting permission to code"; yes, they are a form of quality control, but they're also a way to share knowledge among a team, so that if you decide to quit suddenly, your coworkers can make sense of your code.