5 ms·

I will say as someone who has to wrangle a lot of junior devs -- don't have imposter syndrome on this. The hard part is sticking with the issue and seeing it th

I will say as someone who has to wrangle a lot of junior devs -- don't have imposter syndrome on this. The hard part is sticking with the issue and seeing it through to the logical conclusion. Many people have difficulty even conceptualizing the steps that need to be taken in order to solve a problem. If you are smart enough to get help from someone in devops and understand the advice they gave, you're doing the same stuff senior devs and CTOs do on a daily basis. We're all frauds lol

danuker 5y ago
computing is a fraud, a CPU is literally a rock that we tricked into thinking
- vvilliamperez 5y ago
  This gave me a great belly laugh
- teddyh 5y ago
  If a CPU is thinking, then all rocks are constantly thinking their rocky thoughts, contemplating the immeasurable eons of their existence. A CPU is, then, merely a rock which we have made to think some thoughts which are to our benefit.
- Ancapistani 5y ago
  You’re oversimplifying. We didn’t just trick a rock into thinking - we beat on it until it was really thin, shoved a little bit of lightning inside of it, then tricked it into thinking.
8ytecoder 5y ago
That's pretty much it. There's a certain category of people with a certain attitude towards debugging. You have to be able to break it down into steps - sometimes from "first principles". Then work up and identify where the issue is and how to resolve it. Sometimes it requires looking at logs and simulating production conditions and other times you may have to understand low level network stack. I still remember the time trying to reproduce and fix a certain issue. We had a 3-node cluster mysql database setup with one main and two replicas. The replicas are read-only. If one replica goes down, reads shouldn't be affected at all. We had an application layer on top of this to coordinate and enforce these requirements. Every which way you look at the code, there's no reason why this shouldn't work. And yet, when one node went down in production under a very particular circumstance with the network, it took down the entire cluster - not that the cluster was not reachable - it wouldn't allow reads and just hang. Tracing it took me down the hole of understanding the precise network issue (fading memory - I think the machine wasn't responding back and tcp kept retrying) + linux tcp setting (I think tcp_delack_min) + a java networking setting + how thread safety was setup in the application (do not use synchronized at the method level). It took a week to diagnose. Recently, there was a minor issue with adapting a sample Spark UDF to work with our setup and it took the developers 3 weeks and they kept giving up after every try.
- sharken 5y ago
  People in the category you describe are few and far apart in my experience. To me solving a problem like the one you describe here is one of the biggest joys of working with IT. Though it seems to come at the expense of being able to design large systems. Not sure if there is a way to be good at both.
  - nyanpasu64 5y ago
    How does skill at deep-diving into complex unknown technical problems hurt the ability to design large systems?
    - tfigueroa 5y ago
      I’d guess that taking the time to deep-dive a problem takes away from time to design large systems.
    - deleted 5y ago
      [deleted]
3pt14159 5y ago
I'm a senior dev I say this only because I have to. The problem with encouraging developers to speak up when they're stuck is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard. In some sense senior developers have a real leg up here because they know that they're capable of building systems for large companies. I've seen many junior developers fired because "they require too much hand holding" and I don't think the advice should be "speak up" but rather "make at least one friend as soon as you possibly can that you can privately ask questions to so you don't look like an idiot" and I know this advice is better for the individual than the company, but it's the reality. The selection function for new, junior employees is "can they get the things done with minimal hand holding" not "do they ask questions" and I'm not ok with that, but it is the reality and we shouldn't push juniors into situations that would get them fired before they're up to speed.
- grawprog 5y ago
  I really don't think I agree with this. The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first. Whatever the work is, the important thing is that it gets done, usually as efficiently and as good as possible. If it takes me explaining the same thing 3 times in a row to get something done properly the first time I'd rather do that than have to go back and fix things later. And honestly, everybody starts somewhere, the best way to learn is by asking questions. If someone is asking me questions, it tells me they recognize they don't know everything, care enough to learn and are humble enough to ask for help. Such qualities are rare in people and i've found every time, the people like that make the best employees and coworkers.
  - megablast 5y ago
    > The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first. Until you get the person who questions everything, draining all your time. Then they become reliant on you, and stop thinking for themselves.

danuker 5y ago

computing is a fraud, a CPU is literally a rock that we tricked into thinking

vvilliamperez 5y ago
This gave me a great belly laugh
teddyh 5y ago
If a CPU is thinking, then all rocks are constantly thinking their rocky thoughts, contemplating the immeasurable eons of their existence. A CPU is, then, merely a rock which we have made to think some thoughts which are to our benefit.
Ancapistani 5y ago
You’re oversimplifying. We didn’t just trick a rock into thinking - we beat on it until it was really thin, shoved a little bit of lightning inside of it, then tricked it into thinking.

8ytecoder 5y ago

That's pretty much it. There's a certain category of people with a certain attitude towards debugging. You have to be able to break it down into steps - sometimes from "first principles". Then work up and identify where the issue is and how to resolve it. Sometimes it requires looking at logs and simulating production conditions and other times you may have to understand low level network stack. I still remember the time trying to reproduce and fix a certain issue. We had a 3-node cluster mysql database setup with one main and two replicas. The replicas are read-only. If one replica goes down, reads shouldn't be affected at all. We had an application layer on top of this to coordinate and enforce these requirements. Every which way you look at the code, there's no reason why this shouldn't work. And yet, when one node went down in production under a very particular circumstance with the network, it took down the entire cluster - not that the cluster was not reachable - it wouldn't allow reads and just hang. Tracing it took me down the hole of understanding the precise network issue (fading memory - I think the machine wasn't responding back and tcp kept retrying) + linux tcp setting (I think tcp_delack_min) + a java networking setting + how thread safety was setup in the application (do not use synchronized at the method level). It took a week to diagnose. Recently, there was a minor issue with adapting a sample Spark UDF to work with our setup and it took the developers 3 weeks and they kept giving up after every try.

sharken 5y ago
People in the category you describe are few and far apart in my experience. To me solving a problem like the one you describe here is one of the biggest joys of working with IT. Though it seems to come at the expense of being able to design large systems. Not sure if there is a way to be good at both.
- nyanpasu64 5y ago
  How does skill at deep-diving into complex unknown technical problems hurt the ability to design large systems?
  - tfigueroa 5y ago
    I’d guess that taking the time to deep-dive a problem takes away from time to design large systems.
  - deleted 5y ago
    [deleted]

3pt14159 5y ago

I'm a senior dev I say this only because I have to. The problem with encouraging developers to speak up when they're stuck is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard. In some sense senior developers have a real leg up here because they know that they're capable of building systems for large companies. I've seen many junior developers fired because "they require too much hand holding" and I don't think the advice should be "speak up" but rather "make at least one friend as soon as you possibly can that you can privately ask questions to so you don't look like an idiot" and I know this advice is better for the individual than the company, but it's the reality. The selection function for new, junior employees is "can they get the things done with minimal hand holding" not "do they ask questions" and I'm not ok with that, but it is the reality and we shouldn't push juniors into situations that would get them fired before they're up to speed.

grawprog 5y ago
I really don't think I agree with this. The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first. Whatever the work is, the important thing is that it gets done, usually as efficiently and as good as possible. If it takes me explaining the same thing 3 times in a row to get something done properly the first time I'd rather do that than have to go back and fix things later. And honestly, everybody starts somewhere, the best way to learn is by asking questions. If someone is asking me questions, it tells me they recognize they don't know everything, care enough to learn and are humble enough to ask for help. Such qualities are rare in people and i've found every time, the people like that make the best employees and coworkers.
- megablast 5y ago
  > The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first. Until you get the person who questions everything, draining all your time. Then they become reliant on you, and stop thinking for themselves.