Ask HN: How to learn software development concepts crucial for senior roles?

Hi HN, I'm working at an early stage startup, and want to learn about concepts and patterns that are crucial for senior roles, like: - Batch Processing - Messaging Queues - Microservices - Design Patterns - Which techniques to apply while working on a task - Properly debugging

Is there any online resource or somewhere I can see this in practice? Or any newsletter, youtube channel that discusses this in detail?

My go to sources are open source repositories where I try to understand the code bases and some PRs. But I feel overwhelmed with the resources.

17 points | by swirly-mcswirl 12 hours ago

10 comments

  • gregjor 11 hours ago
    Will Rogers said "Good judgment comes from experience, and a lot of that comes from bad judgment."

    I can't think of any substitute for experience. You can read and study what you call concepts and patterns, just like you can read about baking a cake, but you can't get experience from study. You practice, make mistakes, stretch your abilities every day, and with luck you find good mentors.

    • namaria 9 hours ago
      Yup. Can only beat search after doing search. Goes for the larger societal systems and for the individual as well, because there's no shortcut to search the space of socially acquired knowledge.
  • roetlich 9 hours ago
    Hi Swirly, most youtube videos will not help that much, other than conference talks. I recommend going more slowly, and comfortably reading books. For example "Designing Data-Intensive Applications", based on your interests. Don't read it over a weekend, read it over a couple of months.

    Your focus should also shift a little bit more towards helping others, thinking about where the whole team is going, etc.

    But give it time. As long as you keep learning, you will get there. :)

  • mysfi 5 hours ago
    Many interesting leads for where to look to learn more has been provided in the comments, but I wanted to point out the fact that learning most of these concepts and many more technical concepts boils down to understanding the problems they're intended to solve, and understanding those problems requires having struggled with them. Reading or studying alone will not take you there.
  • viraptor 7 hours ago
    There's a few conferences posting quality talks on YouTube. See Goto (https://youtube.com/@goto-) NDC (https://youtube.com/@ndc) GDC (https://youtube.com/@gdconf) Eficode (https://youtube.com/@eficode-oy)
  • Gooblebrai 6 hours ago
    I understand the point of your question and you have very good answers in other comments. However, I'd like to point out that "seniority", in many cases, is very subjective and the quality of seniority across companies varies quite drastically. So don't take seniority as a kind of heaven you need to get to by knowing a certain amount of things.
  • 2rsf 9 hours ago
    Seniority is about breadth and nor depth. While having good knowledge in many areas is important the magic in being a senior is knowing how to put everything together, communication and integration with other teams, bridging the business and technical etc.
    • hcfman 7 hours ago
      Except that it’s not recognised by corporations anyway. Too expensive.
      • 2rsf 7 hours ago
        What do you mean? most companies' job leveling matrices have that, and many times this is what differentiate a talented engineer to a senior engineer in practice.
        • infamouscow 4 hours ago
          Every company has a completely different notion of what each level does.

          People like to debate this because they built an ego around working for a title at some megacorp by way of politics. These people are also completely oblivious to how the CTO also promoted their non-technical pal from high school to senior principle staff architect.

  • giantg2 6 hours ago
    To me, the biggest things are hard to teach and are related to human processes.

    One is treating your team well and developing the juniors under you, including understanding that each individual may have different needs or require a different approach.

    Two is that the best theoretical technical approach is not usually the best real life approach. The number of times I've seen technically elegant code fail because of human systems is quite high. A real example... Yes, I see you used maps and spread operators to concatenate shared vs core values in a CSP file that's shared between multiple sites in a monorepo. How do you think we can maintain that between multiple teams when we don't have clear delineation of ownership? The code works elegantly, but the human processes around ownership to maintain it are absolutely garbage. You should duplicate the shared CSP for each site and task them with stripping out any unnecessary entries for their own file/site. If not, then at least we can open vulnerabilities against individual sites. But hey, telling my TL that didn't work so now we're in a shitty position and I got a low rating for disagreeing.

  • seowallet 9 hours ago
    [dead]
  • JSDevOps 11 hours ago
    You’ve either got it or you haven’t. It’s just the ultimate form of logical thinking.
    • marziply 5 hours ago
      I don't think you could have given worse advice is you tried