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.
I agree with this, although I'd add that study becomes exceptionally useful after you've reached the senior level.
Until you've seen most of what the software industry can throw at you, study isn't that useful. But after you've seen it all you'll be quick to glean the relevance and importance of new concepts when studying.
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.
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. :)
I have another book recommendation: Patterns of Enterprise Application Architecture, M. Fowler. If you don't want to purchase or just want a sampling read thru the catalog of patterns. https://martinfowler.com/eaaCatalog/
Another book recommendation is Head First Design Patterns - the one I read used Java in the examples but I learned better with the style of that book than a textbook style. There are probably a lot of design patterns books out there including the original by the "Gang of Four".
The most important thing after reading about these patterns is learning when to use one and to do that you just need to go use them. Some caution though, I found myself putting patterns into use more frequently than was probably necessary simply because it was a new thing.
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.
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.
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.
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.
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.
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.
Hi Swirly, As I know, Martin Fowler’s blog is great for deep dives into software design, and newsletters like Software Lead Weekly keep you updated on trends.
For hands-on learning, focus on open-source projects or start a side project. Engage in communities like Reddit or Stack Overflow, read books (Clean Code and Design Patterns are the best) and try pair programming to learn from others.
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.
I agree with this, although I'd add that study becomes exceptionally useful after you've reached the senior level.
Until you've seen most of what the software industry can throw at you, study isn't that useful. But after you've seen it all you'll be quick to glean the relevance and importance of new concepts when studying.
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.
Thanks a lot, I will keep this in mind.
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. :)
I have another book recommendation: Patterns of Enterprise Application Architecture, M. Fowler. If you don't want to purchase or just want a sampling read thru the catalog of patterns. https://martinfowler.com/eaaCatalog/
Another book recommendation is Head First Design Patterns - the one I read used Java in the examples but I learned better with the style of that book than a textbook style. There are probably a lot of design patterns books out there including the original by the "Gang of Four".
The most important thing after reading about these patterns is learning when to use one and to do that you just need to go use them. Some caution though, I found myself putting patterns into use more frequently than was probably necessary simply because it was a new thing.
+1 for DDIA. that book helped mee ed hrow to senior.
Thank you for the book recommendation.
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)
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.
Except that it’s not recognised by corporations anyway. Too expensive.
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.
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.
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.
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.
Pretend you are prepping for a design interview then consume all the material necessary to learn that.
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.
Data structure.
Hi Swirly, As I know, Martin Fowler’s blog is great for deep dives into software design, and newsletters like Software Lead Weekly keep you updated on trends. For hands-on learning, focus on open-source projects or start a side project. Engage in communities like Reddit or Stack Overflow, read books (Clean Code and Design Patterns are the best) and try pair programming to learn from others.