7 ms·

> In essence, developers treat "legacy" code as if it was some kind of framework or language runtime -- to be used but never to be studied to have its internals

> In essence, developers treat "legacy" code as if it was some kind of framework or language runtime -- to be used but never to be studied to have its internals understood. (I will never understand this approach to development) I was baffled by this as well for 15+ years until just last year I had a key insight: most developers don’t like to read. In fact, most people don’t like to read. Most people are intrinsically lazy and since growing your skills involves hard work, they don’t do it unless pushed to do so, either by life circumstance or necessity. Time and time again people have asked me: “how do I get really good at $tech or software engineering?” I recommend a few books or send them my standard list of must-reads. In 999/1000 cases the person approaching me gives me that defeated look that I know means: “Oh. I was hoping you’d say something not involving working hard.” Most people are polite enough not to say it to my face. When folks have problems with HTTP I ask them if they’ve read RFC 2616, and if not, I offer to bring them a nicely printed and bound copy. It typically goes unread though some use it as a reference. Only once did someone follow my recommendation and read it cover to cover. Folks seems to lack a kind of basic economic perspective. Spend a week, month, something along those lines growing your skills (or even just 30 minutes reading the docs on that thing you just spent 2 hours declaring idiotic). Yes, this means probably giving up your favorite Netflix binge, video game, or drinking on weeknights in favor of study. But once these skills are internalized they pay back for a lifetime with good returns. Yet for some strange reason people prefer to keep thinking short term and so they never learn what they’re doing. It used to make me sad but I’m making peace with it.

ornornor 4y ago
I see where you’re coming from and this was definitely my attitude in my twenties: do the hard work to understand the underlying concepts and not just become a code monkey. But I must admit as I get older, I don’t have as much time or patience to devote to this and I’m getting to terms with getting good enough to make a living rather than really understand $new_technology. I think this is partly from getting old and not wanting to sink so much of my own time and mental energy on computer stuff, but also from realizing how little it matters to most PHBs/middle managers who basically hold your fate in their hands. I’ve become much more cynical after a decade in the industry and I’ve realized how much of my own energy and health I have wasted in trying to get a deeper understanding of programming concepts. It was personally satisfying for a while, but it doesn’t pay off for most people. Most orgs want it done fast and cheap, they don’t want squeaky wheels, PHBs think in quarters and only want the thing to not blow up until after they get promoted in a year or two. Developers who deliver that kind of low cost code fast (albeit low quality) have much more stable careers, better promotions, and get bonuses. The rest of us ruin our mental health, paint targets on our backs, and don’t get as far. But man do we know our shit.
- belfalas 4y ago
  What you say is sadly true, our industry is overrun with bullshit artists and hustlers who are really only looking out for number one and the short term. I find it demoralizing at times as well. What I've found is that good companies and outfits do exist out there, but usually they can't pay as well. Or they are boutique consultancies where everybody really cares about the craft...but then you have the realities of consulting to deal with (i.e., dealing with really difficult people). I am not sure what to say other than: please don't give up hope. Things can get better but you may have to change your expectations or value system to find a place that works for you. Or if you have the stomach for it, try to build a product on your own leveraging your expertise. For myself, a difficult but necessary change has been not wrapping so much of my self-identity up in 'being a great programmer.' Yes, I know some things in tech, and that's cool, but there is more to life than technology. But just to re-emphasize: I hear you, and it's tough. Wish you the best.
  - ornornor 4y ago
    Thank you. I agree it’s sad but I also have to look out for myself. There is no point in exhausting your energy trying to fix something where no one wants it fixed at best or is actively fighting you to fix it. It’s not even your money that’s being set on fire then, but it is your sanity. Curious if you’ve found either a better company, or created your own product? It’s difficult to come to terms with mediocrity and needless toil, I went into this industry because I like well designed and efficient systems.
AWebOfBrown 4y ago
> Folks seems to lack a kind of basic economic perspective. I agree with most of what you said, but this seems a bit ironic. Your suggestions almost exclusively involve large investments of time with little established proof that they are efficient. Do you genuinely believe reading RFC 2616 "cover to cover" is an efficient way of solving the specific problems they came across? I would wager most developers wishing to be "really good" actually have a concrete desire like a greater paycheque or employer in mind. If that is true, I doubt reading someone's booklist necessarily is their fastest pathway, and their economic perspective is exactly what stops them doing so.
- belfalas 4y ago
  Um. In what I wrote I said a week or a month. That is not a large amount of time. I think you missed the spirit of my writeup.
- twawaaay 4y ago
  A person that spends considerable portion of their time really learning new things will initially be slower at their work than people who only do work. But over time this person will be getting better and better and better and at some point they will be able to do their job on the fraction of their time while still keeping momentum and learning more. This has been my experience. I have been spending 3/4 of my working hours learning new things for the past about 17 years after I realised this. The actual work takes a very tiny part of my day. Software development really is a knowledge sport. Writing code is actually pretty small part of the task -- knowing what to write is the important part. If you are able to "write down the answer" so to speak, without spending much time getting there, you can be 10 or more times productive than everybody else, easily.
BadBot 4y ago
At the risk of being another intrinsically lazy developer who's not going to follow through, what is your standard list of must-reads?
- deleted 4y ago
  [deleted]
- candiddevmike 4y ago
  Not OP, but anything related to the kind of stuff you're working on. I'm doing WebAuthn stuff right now and I am reading through the spec before/to help falling asleep. Specs are extremely terse and dry, and I never liked reading them. I pushed myself to read a few and now I find myself craving that kind of technical documentation in my work. The WebAuthn spec is pretty interesting and also has some even more interesting drama on GitHub issues.
- twawaaay 4y ago
  I guess whatever helps you better understand work you are doing? My reading list at any point is tied to whatever I am doing in my private or professional life. If my boss asks me to help grow the company my reading list will contain a bunch of stuff about company growth. If I have money to invest but no knowledge of investing -- you will see me listening to investing books while cooking, taking walks, commuting or long distance driving. Basically, whenever I face a problem I look around for literature to help me with it. I really hope to have an original problem in my life. Until then I assume that whatever problem I have there is somebody who wrote a solution to it and if I can't find it it is just because I wasn't searching hard enough.
- belfalas 4y ago
  Many more beyond this but these are my for sures. People / Soft Skills: * How to win friends and Influence People - Dale Carnegie * Secrets of Consulting - Gerald Weinberg * Peopleware - Tom DeMarco & Timothy Lister * Nurtured by Love - Shinici Suzuki * Turn the Ship Around! - David Marquet * Never Split the Difference - Chris Voss http://dhemery.com/articles/resistance_as_a_resource/ http://dhemery.com/articles/resistance_as_a_resource/ http://dhemery.com/articles/managing_yourself_through_change/ http://dhemery.com/articles/managing_yourself_through_change... Macro Skills: * Toyota Production System - Taiichii Ohno * Workplace Management - Taiichii Ohno * Thinking in Systems - Donella Meadows * Fifth Discipline - Peter Senge Agile: * Extreme Programming, Explained (2nd ed.) - Kent Beck (the annotated bibliography is a goldmine) * Chaos: Making a New Science - James Gleick Programming: * Implementation Patterns - Kent Beck * Test-Driven Development, By Example - Kent Beck * Refactoring (both editions) - Martin Fowler * Refactoring to Patterns - Joshua Kerievsky * Practical Object Oriented Design - Sandi Metz * Functional Programming in Scala - Chiusano & Bjarnason * Growing Object-Oriented Software, Guided By Tests - Freeman & Pryce ("The Goose Book") * Modern Java in Action - Raoul-Gabriel Urma * Java Concurrency in Practice - Brian Goetz * Grokking Algorithms - Aditya Y. Bhargava Architecture: * Righting Software - Juval Lowy * Release It! - Michael Nygard * Site Reliability Engineering - Beyer, et al. ("The SRE Book”) * Domain Driven Design - Eric Evans * Introduction to Permaculture - Bill Mollison and Mia Slay * Fun with a Pencil - Andrew Loomis Design: * All books by Edward Tufte, especially “The visual display of quantitative information” * The Elements of Typographic Style - Robert Bringhurst * Understanding Comics - Scott McCloud * Design of Everyday Things - Don Norman * Notes on the Synthesis of Form - Christopher Alexander * The Timeless Way of Building - Christopher Alexander
BlueTemplar 4y ago
Or, if it's directly related to the problem at hand, do it during job hours. Especially since reading is great, but actively engaging with what you have just rea, d by trying to solve some related small scale problem, is even better !
marcus0x62 4y ago
> I was baffled by this as well for 15+ years until just last year I had a key insight: most developers don’t like to read. In fact, most people don’t like to read. Most people are intrinsically lazy and since growing your skills involves hard work, they don’t do it unless pushed to do so, either by life circumstance or necessity. I knew a developer who said of such people “they spent six months in the lab to avoid two weeks in the library.”
- twawaaay 4y ago
  There are some interesting things here. I may agree that most people intrinsically lazy but I don't think this is what is going on here. I think at least to some degree people sort themselves into projects. Typically, the better ones that are also happy and capable with reading other people's code command ability to place themselves into projects that seem like more intellectually rewarding -- which means they are much more likely to form the original team for a new project than to join a project that is already legacy and is not meant to be rewritten. What strikes me is that it actually is easier to write new code than to properly maintain/refactor old, foreign code. Working with large amount of old code requires a lot of hard, real planning and decisionmaking and learning to live with and adjust to decisions made by others in the past. This hits "maintenance teams" twice -- not only they face actually more difficult task but they are also less likely to get good devs to help. It does not help that management is usually less likely to give resources to teams in maintenance mode than to teams that are developing new toys.
  - belfalas 4y ago
    > What strikes me is that it actually is easier to write new code than to properly maintain/refactor old, foreign code. Working with large amount of old code requires a lot of hard, real planning and decisionmaking and learning to live with and adjust to decisions made by others in the past. Right on the money. Everyone loves greenfield because you get to build things up from scratch, try out your own ideas, and there's this feeling of tremendous velocity. You feel like you're just tearing through code, kicking butt, delivering wins. Then the difficult requests start to come in, which usually means feedback from real human users. That's when the rubber hits the road and the grumbling begins. And like you said, once the project is seen as maintenance it is 'not sexy' despite the fact that all successful software definitionally makes the most money while in the so-called maintenance stage.
BurningFrog 4y ago
I kinda specialize at getting into legacy code bases, understand how they work, and quickly be able to make changes and clean things up. But I don't think I've read any books on that. What I do is read the code! I think can do this mostly because I'm interested in it. SW projects die because the code isn't maintained properly and becomes unworkable. So I work on being the counterforce to that, keeping the project alive. Most engineers are into writing new shiny code, and hate "cleaning up other's mistakes". That's also often rewarded. The results are well known :)
- belfalas 4y ago
  Yep, that is definitely a skill. And you are doing exactly what I recommend: slow down and take the time to read the thing and understand it. Then go forward from there. Your interest also shows that you are intrinsically motivated, which many people are not. You’re right that there are very few books available showing people how to do this. Usually “Working Effectively with Legacy Code” is recommended but it’s just one book and so can’t cover everything. It’s an area where on the job training and experience definitely makes a difference.
- bentobean 4y ago
  Reminds me of the story of the high school graduate who noticed that all of his peers were “following their passion” by pursuing various undergraduate degrees in underwater basket weaving, etc… Rather than follow suit, he went in the opposite direction and did what no one else wanted to do… he started a septic tank cleaning company. He said that it was hard work, but lucrative… and that after a while, he woke up one morning and realized that he was passionate about other people’s shit.
  - wonderwonder 4y ago
    I knew a guy in real life who's dad built a profitable septic tank company from scratch. he expected his son to follow in his footsteps and take it over one day. The son passed; he could just not see himself in that industry and went into marketing. Caused a bit of stress in their relationship.
Aeolun 4y ago
> When folks have problems with HTTP I ask them if they’ve read RFC 2616 Well, that sounds like an utter waste of time. I just wanted to know if this endpoint responded to a GET or to a POST request.
- belfalas 4y ago
  Have you yourself read the RFC? EDIT: to clarify, when I say “problems with HTTP” I mean actually understanding the protocol. Many people for example are unaware of the power of the Cache-Control header and all the things it can do. I used to ask people in interviews what the Content-Type header is for and enough senior engineers didn’t know that I simply stopped asking not to make them feel bad. It’s truly shocking how many people will go decades operating on muscle memory, never bothering to understand what’s actually happening when their code runs.
  - icedchai 4y ago
    Do you ever ask about CORS? It always seems to be a great source of confusion with even more experienced candidates.
    - belfalas 4y ago
      No, never. If the role needed someone with specific expertise or if CORS was a “hot item” for day to day development, then sure. But I’ve found that I usually don’t need to ask very complex questions to figure out if someone has skills or not.
      - zo1 4y ago
        Not OP. I'm starting to think that basic/mid level depth understanding of CORS is one of those canary-like items to judge if someone has a good grasp of web/http technologies. The other one is text encoding. You'd be surprised how many people don't know the difference between unicode and say utf8. It's all "black magic" to them at the end of the day.
victor9000 4y ago
Can we see the standard list of must reads? I'm always looking for something new.
- belfalas 4y ago
  I posted it in a reply to a different comment on the thread.
- molteanu 4y ago
  I've compiled a non-standard list, if that helps, https://news.ycombinator.com/item?id=30651273 https://news.ycombinator.com/item?id=30651273 They're not about any technology per se, but mostly about exercises in how to tackle complex systems.
molteanu 4y ago
Best comment!
LambdaComplex 4y ago
What's your solution for getting nicely printed and bound copies of things like that? Heck, how nicely bound are we talking? And how much does it cost? (I recently looked into getting a copy of a certain specification printed/bound, but found that the cost would be a lot higher than I cared to pay)
- belfalas 4y ago
  There’s a service called printme1 that’s great, I’ve used it many times. Or, if you’re into arts and crafts, you can get good home binding machines that are not very expensive. It’s actually pretty fun IMHO to punch and bind the paper but YMMV. :)

ornornor 4y ago

I see where you’re coming from and this was definitely my attitude in my twenties: do the hard work to understand the underlying concepts and not just become a code monkey. But I must admit as I get older, I don’t have as much time or patience to devote to this and I’m getting to terms with getting good enough to make a living rather than really understand $new_technology. I think this is partly from getting old and not wanting to sink so much of my own time and mental energy on computer stuff, but also from realizing how little it matters to most PHBs/middle managers who basically hold your fate in their hands. I’ve become much more cynical after a decade in the industry and I’ve realized how much of my own energy and health I have wasted in trying to get a deeper understanding of programming concepts. It was personally satisfying for a while, but it doesn’t pay off for most people. Most orgs want it done fast and cheap, they don’t want squeaky wheels, PHBs think in quarters and only want the thing to not blow up until after they get promoted in a year or two. Developers who deliver that kind of low cost code fast (albeit low quality) have much more stable careers, better promotions, and get bonuses. The rest of us ruin our mental health, paint targets on our backs, and don’t get as far. But man do we know our shit.

belfalas 4y ago
What you say is sadly true, our industry is overrun with bullshit artists and hustlers who are really only looking out for number one and the short term. I find it demoralizing at times as well. What I've found is that good companies and outfits do exist out there, but usually they can't pay as well. Or they are boutique consultancies where everybody really cares about the craft...but then you have the realities of consulting to deal with (i.e., dealing with really difficult people). I am not sure what to say other than: please don't give up hope. Things can get better but you may have to change your expectations or value system to find a place that works for you. Or if you have the stomach for it, try to build a product on your own leveraging your expertise. For myself, a difficult but necessary change has been not wrapping so much of my self-identity up in 'being a great programmer.' Yes, I know some things in tech, and that's cool, but there is more to life than technology. But just to re-emphasize: I hear you, and it's tough. Wish you the best.
- ornornor 4y ago
  Thank you. I agree it’s sad but I also have to look out for myself. There is no point in exhausting your energy trying to fix something where no one wants it fixed at best or is actively fighting you to fix it. It’s not even your money that’s being set on fire then, but it is your sanity. Curious if you’ve found either a better company, or created your own product? It’s difficult to come to terms with mediocrity and needless toil, I went into this industry because I like well designed and efficient systems.

AWebOfBrown 4y ago

> Folks seems to lack a kind of basic economic perspective. I agree with most of what you said, but this seems a bit ironic. Your suggestions almost exclusively involve large investments of time with little established proof that they are efficient. Do you genuinely believe reading RFC 2616 "cover to cover" is an efficient way of solving the specific problems they came across? I would wager most developers wishing to be "really good" actually have a concrete desire like a greater paycheque or employer in mind. If that is true, I doubt reading someone's booklist necessarily is their fastest pathway, and their economic perspective is exactly what stops them doing so.

belfalas 4y ago
Um. In what I wrote I said a week or a month. That is not a large amount of time. I think you missed the spirit of my writeup.
twawaaay 4y ago
A person that spends considerable portion of their time really learning new things will initially be slower at their work than people who only do work. But over time this person will be getting better and better and better and at some point they will be able to do their job on the fraction of their time while still keeping momentum and learning more. This has been my experience. I have been spending 3/4 of my working hours learning new things for the past about 17 years after I realised this. The actual work takes a very tiny part of my day. Software development really is a knowledge sport. Writing code is actually pretty small part of the task -- knowing what to write is the important part. If you are able to "write down the answer" so to speak, without spending much time getting there, you can be 10 or more times productive than everybody else, easily.

BadBot 4y ago

At the risk of being another intrinsically lazy developer who's not going to follow through, what is your standard list of must-reads?

deleted 4y ago
[deleted]
candiddevmike 4y ago
Not OP, but anything related to the kind of stuff you're working on. I'm doing WebAuthn stuff right now and I am reading through the spec before/to help falling asleep. Specs are extremely terse and dry, and I never liked reading them. I pushed myself to read a few and now I find myself craving that kind of technical documentation in my work. The WebAuthn spec is pretty interesting and also has some even more interesting drama on GitHub issues.
twawaaay 4y ago
I guess whatever helps you better understand work you are doing? My reading list at any point is tied to whatever I am doing in my private or professional life. If my boss asks me to help grow the company my reading list will contain a bunch of stuff about company growth. If I have money to invest but no knowledge of investing -- you will see me listening to investing books while cooking, taking walks, commuting or long distance driving. Basically, whenever I face a problem I look around for literature to help me with it. I really hope to have an original problem in my life. Until then I assume that whatever problem I have there is somebody who wrote a solution to it and if I can't find it it is just because I wasn't searching hard enough.
belfalas 4y ago
Many more beyond this but these are my for sures. People / Soft Skills: * How to win friends and Influence People - Dale Carnegie * Secrets of Consulting - Gerald Weinberg * Peopleware - Tom DeMarco & Timothy Lister * Nurtured by Love - Shinici Suzuki * Turn the Ship Around! - David Marquet * Never Split the Difference - Chris Voss http://dhemery.com/articles/resistance_as_a_resource/ http://dhemery.com/articles/resistance_as_a_resource/ http://dhemery.com/articles/managing_yourself_through_change/ http://dhemery.com/articles/managing_yourself_through_change... Macro Skills: * Toyota Production System - Taiichii Ohno * Workplace Management - Taiichii Ohno * Thinking in Systems - Donella Meadows * Fifth Discipline - Peter Senge Agile: * Extreme Programming, Explained (2nd ed.) - Kent Beck (the annotated bibliography is a goldmine) * Chaos: Making a New Science - James Gleick Programming: * Implementation Patterns - Kent Beck * Test-Driven Development, By Example - Kent Beck * Refactoring (both editions) - Martin Fowler * Refactoring to Patterns - Joshua Kerievsky * Practical Object Oriented Design - Sandi Metz * Functional Programming in Scala - Chiusano & Bjarnason * Growing Object-Oriented Software, Guided By Tests - Freeman & Pryce ("The Goose Book") * Modern Java in Action - Raoul-Gabriel Urma * Java Concurrency in Practice - Brian Goetz * Grokking Algorithms - Aditya Y. Bhargava Architecture: * Righting Software - Juval Lowy * Release It! - Michael Nygard * Site Reliability Engineering - Beyer, et al. ("The SRE Book”) * Domain Driven Design - Eric Evans * Introduction to Permaculture - Bill Mollison and Mia Slay * Fun with a Pencil - Andrew Loomis Design: * All books by Edward Tufte, especially “The visual display of quantitative information” * The Elements of Typographic Style - Robert Bringhurst * Understanding Comics - Scott McCloud * Design of Everyday Things - Don Norman * Notes on the Synthesis of Form - Christopher Alexander * The Timeless Way of Building - Christopher Alexander

BlueTemplar 4y ago

Or, if it's directly related to the problem at hand, do it during job hours. Especially since reading is great, but actively engaging with what you have just rea, d by trying to solve some related small scale problem, is even better !

marcus0x62 4y ago

> I was baffled by this as well for 15+ years until just last year I had a key insight: most developers don’t like to read. In fact, most people don’t like to read. Most people are intrinsically lazy and since growing your skills involves hard work, they don’t do it unless pushed to do so, either by life circumstance or necessity. I knew a developer who said of such people “they spent six months in the lab to avoid two weeks in the library.”

twawaaay 4y ago
There are some interesting things here. I may agree that most people intrinsically lazy but I don't think this is what is going on here. I think at least to some degree people sort themselves into projects. Typically, the better ones that are also happy and capable with reading other people's code command ability to place themselves into projects that seem like more intellectually rewarding -- which means they are much more likely to form the original team for a new project than to join a project that is already legacy and is not meant to be rewritten. What strikes me is that it actually is easier to write new code than to properly maintain/refactor old, foreign code. Working with large amount of old code requires a lot of hard, real planning and decisionmaking and learning to live with and adjust to decisions made by others in the past. This hits "maintenance teams" twice -- not only they face actually more difficult task but they are also less likely to get good devs to help. It does not help that management is usually less likely to give resources to teams in maintenance mode than to teams that are developing new toys.
- belfalas 4y ago
  > What strikes me is that it actually is easier to write new code than to properly maintain/refactor old, foreign code. Working with large amount of old code requires a lot of hard, real planning and decisionmaking and learning to live with and adjust to decisions made by others in the past. Right on the money. Everyone loves greenfield because you get to build things up from scratch, try out your own ideas, and there's this feeling of tremendous velocity. You feel like you're just tearing through code, kicking butt, delivering wins. Then the difficult requests start to come in, which usually means feedback from real human users. That's when the rubber hits the road and the grumbling begins. And like you said, once the project is seen as maintenance it is 'not sexy' despite the fact that all successful software definitionally makes the most money while in the so-called maintenance stage.

BurningFrog 4y ago

I kinda specialize at getting into legacy code bases, understand how they work, and quickly be able to make changes and clean things up. But I don't think I've read any books on that. What I do is read the code! I think can do this mostly because I'm interested in it. SW projects die because the code isn't maintained properly and becomes unworkable. So I work on being the counterforce to that, keeping the project alive. Most engineers are into writing new shiny code, and hate "cleaning up other's mistakes". That's also often rewarded. The results are well known :)

belfalas 4y ago
Yep, that is definitely a skill. And you are doing exactly what I recommend: slow down and take the time to read the thing and understand it. Then go forward from there. Your interest also shows that you are intrinsically motivated, which many people are not. You’re right that there are very few books available showing people how to do this. Usually “Working Effectively with Legacy Code” is recommended but it’s just one book and so can’t cover everything. It’s an area where on the job training and experience definitely makes a difference.
bentobean 4y ago
Reminds me of the story of the high school graduate who noticed that all of his peers were “following their passion” by pursuing various undergraduate degrees in underwater basket weaving, etc… Rather than follow suit, he went in the opposite direction and did what no one else wanted to do… he started a septic tank cleaning company. He said that it was hard work, but lucrative… and that after a while, he woke up one morning and realized that he was passionate about other people’s shit.
- wonderwonder 4y ago
  I knew a guy in real life who's dad built a profitable septic tank company from scratch. he expected his son to follow in his footsteps and take it over one day. The son passed; he could just not see himself in that industry and went into marketing. Caused a bit of stress in their relationship.

Aeolun 4y ago

> When folks have problems with HTTP I ask them if they’ve read RFC 2616 Well, that sounds like an utter waste of time. I just wanted to know if this endpoint responded to a GET or to a POST request.

belfalas 4y ago
Have you yourself read the RFC? EDIT: to clarify, when I say “problems with HTTP” I mean actually understanding the protocol. Many people for example are unaware of the power of the Cache-Control header and all the things it can do. I used to ask people in interviews what the Content-Type header is for and enough senior engineers didn’t know that I simply stopped asking not to make them feel bad. It’s truly shocking how many people will go decades operating on muscle memory, never bothering to understand what’s actually happening when their code runs.
- icedchai 4y ago
  Do you ever ask about CORS? It always seems to be a great source of confusion with even more experienced candidates.
  - belfalas 4y ago
    No, never. If the role needed someone with specific expertise or if CORS was a “hot item” for day to day development, then sure. But I’ve found that I usually don’t need to ask very complex questions to figure out if someone has skills or not.
    - zo1 4y ago
      Not OP. I'm starting to think that basic/mid level depth understanding of CORS is one of those canary-like items to judge if someone has a good grasp of web/http technologies. The other one is text encoding. You'd be surprised how many people don't know the difference between unicode and say utf8. It's all "black magic" to them at the end of the day.

victor9000 4y ago

Can we see the standard list of must reads? I'm always looking for something new.

belfalas 4y ago
I posted it in a reply to a different comment on the thread.
molteanu 4y ago
I've compiled a non-standard list, if that helps, https://news.ycombinator.com/item?id=30651273 https://news.ycombinator.com/item?id=30651273 They're not about any technology per se, but mostly about exercises in how to tackle complex systems.

molteanu 4y ago

Best comment!

LambdaComplex 4y ago

What's your solution for getting nicely printed and bound copies of things like that? Heck, how nicely bound are we talking? And how much does it cost? (I recently looked into getting a copy of a certain specification printed/bound, but found that the cost would be a lot higher than I cared to pay)

belfalas 4y ago
There’s a service called printme1 that’s great, I’ve used it many times. Or, if you’re into arts and crafts, you can get good home binding machines that are not very expensive. It’s actually pretty fun IMHO to punch and bind the paper but YMMV. :)