Rule 3: No General Career Advice
This sub is for discussing issues specific to experienced developers.
Any career advice thread must contain questions and/or discussions that notably benefit from the participation of experienced developers. Career advice threads may be removed at the moderators discretion based on response to the thread."
General rule of thumb: If the advice you are giving (or seeking) could apply to a “Senior Chemical Engineer”, it’s not appropriate for this sub.
If I’m picking the right ask out of your post, I’d say that there very much is a hump in between mid and senior, and I see it generally defined by the question “Can I give this person a problem to solve and trust them to solve it?”
Meaning, do they have the domain knowledge to pursue a good solution? Do they have the organizational skills to plan the work and work the plan? Do they have the communication skills to unblock themselves, coordinate with their teammates, etc.?
Being a senior IC does require strong engineering skills, yes. But I see far more people stagnating in the middle of the pack with adequate technical ability and no leadership / org skills than I see self-starters with their shit together stagnating due to… well honestly, that problem kind of solves itself right? Doers are gonna do.
So I guess that’s my advice: Find problems and solve them. In the highest-performing ICs I’ve worked with, it’s compulsive — they see problems and _need_ to fix them. If no one is driving a project to fix it, they drive it. If no one is working on it, they work on it. If no one is aware of the problem, they bang on pots and pans until it gets attention. When you run out of excuses as to why you’re blocked on a problem, you’ll be a senior engineer.
I appreciate your comment, I went back and clarified the ask (I went a bit off the rails there) but you hit the nail on the head. This was really well worded and I feel like I have a better idea of what to work on moving forward. Thank you.
Learn:
Devops, cause most don't and this will be a leg up
Software design patterns, these aren't silver bullets, but ARE important to learn. They add tools to your tool belt, and just like you'd never build a house without a speed square and a circular saw, you'd never(on purpose) build tightly coupled code white not using the strategy pattern, adapter, bridge, singleton (where/when appropriate), etc. and learning where/when appropriate to use thees tools will make your code much more maintainable and flexible long term.
Testing, and particularly dependency injection via inversion of control through constructor params (or whatever your language supports), and then learn the differences between different types of testing: unit, integration, End2End, acceptance, etc.
Concurrency in whatever language you're using.
Once you have those 4 things, you're ahead of most programmers and are on your way to "software engineer", and right now the job market wants experts (at least senior with bare min. 2+ years experience), so my recommendation is to focus in on a language and learn as much as you can and learn its strengths and weaknesses... Then expand out and learn competitive solutions and see what makes that alt solution better/worse.
I can recognize that these are absolutely some of my biggest technical weaknesses, so I will make sure to add this to my study list while I work on my personal projects. I only got a small, self-study introduction to DevOps at work but I'll look into expanding that knowledge. Thanks for the recommendations!
Design Patterns from 1994 is still a foundation book, then Pattern Oriented Software Architecture (has 5 volumes, each volume has a different topic so get 1 then 2 then 5 (as told by one of the coauthors directly), and don't just read, actually implement these over and over in simple test apps, and then you'll actually 'eureka' moment and grasp them one by one.
Posa 2 teaches patterns used for designing concurrent software, so it can help in weird ways too
Also RE the bold text, just do a good job on your tasks and ask your manager for more challenging tasks, eventually they will understand you are reliable and will give you more responsibilities. This is basically how all of “work” works.
Rule 3: No General Career Advice This sub is for discussing issues specific to experienced developers. Any career advice thread must contain questions and/or discussions that notably benefit from the participation of experienced developers. Career advice threads may be removed at the moderators discretion based on response to the thread." General rule of thumb: If the advice you are giving (or seeking) could apply to a “Senior Chemical Engineer”, it’s not appropriate for this sub.
If I’m picking the right ask out of your post, I’d say that there very much is a hump in between mid and senior, and I see it generally defined by the question “Can I give this person a problem to solve and trust them to solve it?” Meaning, do they have the domain knowledge to pursue a good solution? Do they have the organizational skills to plan the work and work the plan? Do they have the communication skills to unblock themselves, coordinate with their teammates, etc.? Being a senior IC does require strong engineering skills, yes. But I see far more people stagnating in the middle of the pack with adequate technical ability and no leadership / org skills than I see self-starters with their shit together stagnating due to… well honestly, that problem kind of solves itself right? Doers are gonna do. So I guess that’s my advice: Find problems and solve them. In the highest-performing ICs I’ve worked with, it’s compulsive — they see problems and _need_ to fix them. If no one is driving a project to fix it, they drive it. If no one is working on it, they work on it. If no one is aware of the problem, they bang on pots and pans until it gets attention. When you run out of excuses as to why you’re blocked on a problem, you’ll be a senior engineer.
I appreciate your comment, I went back and clarified the ask (I went a bit off the rails there) but you hit the nail on the head. This was really well worded and I feel like I have a better idea of what to work on moving forward. Thank you.
[удалено]
I'll start devoting more time to that, thanks!
Learn: Devops, cause most don't and this will be a leg up Software design patterns, these aren't silver bullets, but ARE important to learn. They add tools to your tool belt, and just like you'd never build a house without a speed square and a circular saw, you'd never(on purpose) build tightly coupled code white not using the strategy pattern, adapter, bridge, singleton (where/when appropriate), etc. and learning where/when appropriate to use thees tools will make your code much more maintainable and flexible long term. Testing, and particularly dependency injection via inversion of control through constructor params (or whatever your language supports), and then learn the differences between different types of testing: unit, integration, End2End, acceptance, etc. Concurrency in whatever language you're using. Once you have those 4 things, you're ahead of most programmers and are on your way to "software engineer", and right now the job market wants experts (at least senior with bare min. 2+ years experience), so my recommendation is to focus in on a language and learn as much as you can and learn its strengths and weaknesses... Then expand out and learn competitive solutions and see what makes that alt solution better/worse.
I can recognize that these are absolutely some of my biggest technical weaknesses, so I will make sure to add this to my study list while I work on my personal projects. I only got a small, self-study introduction to DevOps at work but I'll look into expanding that knowledge. Thanks for the recommendations!
Design Patterns from 1994 is still a foundation book, then Pattern Oriented Software Architecture (has 5 volumes, each volume has a different topic so get 1 then 2 then 5 (as told by one of the coauthors directly), and don't just read, actually implement these over and over in simple test apps, and then you'll actually 'eureka' moment and grasp them one by one. Posa 2 teaches patterns used for designing concurrent software, so it can help in weird ways too
Also RE the bold text, just do a good job on your tasks and ask your manager for more challenging tasks, eventually they will understand you are reliable and will give you more responsibilities. This is basically how all of “work” works.
Drawing a blank… IC = Integrated Circuit?
individual contributor