Programmers not knowing tooling is a big problem. I work in Germany and developers coming out of university here don't know GIT or Linux at all. It's not part of the education, which is so weird because when you work in a team you absolutely need to know GIT, and being able to grep things on the commandline makes your life SO much easier. When we onboard new people we often have to let them do basic Linux and GIT courses first before they are able to even start. Thank god for Udemy.
There are so many programmers that don't know anything about the tools they use. I don't have a problem with that if they put in the time to learn and catch up, but many don't do that and it hurts them when it comes time to debug or solve a production issue and they are slow.
The "companies see you as your past self" comment really resonated. Companies first choice for a role always seems to be someone that did the exact same thing somewhere else. This makes sense from an investment perspective: those people take the least amount of time to ramp up typically. But if all of your engineers have only done one specific thing their entire career, you'll lose out on a lot of breadth of knowledge.
Don't agree with your arguments on auto complete. I have 10 YOE in SWE and heavily rely on autocomplete, there is way too much info and complexity out there for me to worry about trivial things like language specific APIs. Some days I switch languages every hour, no way I'm remembering exact syntax for list comprehension in python, the correct way to handle some random git issue or if there is a better way to convert a list into an array in java other than manually... I just google or use autocomplete and move on 👀
Thank you for the comment! This is one of those it depends conversations that changes depending on the context. Relying on autocomplete for the small syntax things is perfectly fine. We all do it every day on our mobile devices and in our editors. The issue arises when we forget about the cost associated with the code we're writing or when we can't perform basic operations in the tools we use every day. If you have to reference how to commit code every day instead of learning it then that, in my eyes, becomes an issue. Then add things like Copilot and it further separates the engineer from the code and doesn't encourage thinking about the problem. Like everything in this field, it's a balance.
@@sudomateo agreed, I don't search how to create a commit every day. I guess one of the differentiating factors is how effective you are at finding information you don't remember due to lack of constant use. Other factor is figuring out when it's time to create a script/alias to optimize a common operation, like finding and highlighting errors in a directory of log files. I don't have to remeber exact syntax for find+grep, I just use the alias/script and have it as reference next time I need to find something different.
@@bact1om great points! Being effective at finding information on demand is a skill in itself. Knowing when to invest the time to create those helper scripts and aliases is also important because there's a point of diminishing return on that too. That being said, if you have a topic that you'd like to hear us talk about on video please let us know. I love these conversations and enjoy reading the comments to hear other perspectives especially from those that have been in the field longer than we have. Appreciate you chatting!
Hi Dave and Matt, be cool for some project videos. Like company X is trying to solve this problem, here's how we would approach it. Maybe something people could build along to?
This is a really great idea. I've done a few project videos in the past and have enjoyed the process. I'll plan something, maybe I'll just stream myself writing a fun little golang web project and then setting it up to run on DigitalOcean or something. The "real-life" approach you suggested sounds like something I've been wanting to do. Thanks!
This is a fantastic idea and one that I think we'll be visiting at some point. Sometimes just talking about your approach really helps spread knowledge and perspectives that you wouldn't have otherwise thought of.
I think more videos on what you expect from the junior people. What kinds of attributes make a new person on the team successful.
This is a fantastic topic and one we can totally cover sooner rather than later. Thank you Marc!
@@sudomateo hey you're that infrastructure guy! hehe, just kiddin'
Gottem
@@zachr93 haha. It be like that.
Programmers not knowing tooling is a big problem. I work in Germany and developers coming out of university here don't know GIT or Linux at all.
It's not part of the education, which is so weird because when you work in a team you absolutely need to know GIT, and being able to grep things on the commandline makes your life SO much easier.
When we onboard new people we often have to let them do basic Linux and GIT courses first before they are able to even start.
Thank god for Udemy.
There are so many programmers that don't know anything about the tools they use. I don't have a problem with that if they put in the time to learn and catch up, but many don't do that and it hurts them when it comes time to debug or solve a production issue and they are slow.
The "companies see you as your past self" comment really resonated. Companies first choice for a role always seems to be someone that did the exact same thing somewhere else. This makes sense from an investment perspective: those people take the least amount of time to ramp up typically. But if all of your engineers have only done one specific thing their entire career, you'll lose out on a lot of breadth of knowledge.
It's such a difficult thing to overcome too. Especially if you don't get the chance to work on other things during your role.
Dude your videos really inspired me with my DevOps career❤
Great conversation. This was super insightful.
amazing alpha in this channel
Great Video! I hope you can make one about how to go from devops/sre to developer / SW engineer based on your experience doing that
I think we'll cover this in our next chat! I'm just waiting to get better from being sick and then we're back at it!
@@sudomateo Thank you! Will be waiting for it and please take your time to get well 🙏
@@samarelsayed9347 thank you!
Don't agree with your arguments on auto complete. I have 10 YOE in SWE and heavily rely on autocomplete, there is way too much info and complexity out there for me to worry about trivial things like language specific APIs. Some days I switch languages every hour, no way I'm remembering exact syntax for list comprehension in python, the correct way to handle some random git issue or if there is a better way to convert a list into an array in java other than manually... I just google or use autocomplete and move on 👀
Thank you for the comment! This is one of those it depends conversations that changes depending on the context. Relying on autocomplete for the small syntax things is perfectly fine. We all do it every day on our mobile devices and in our editors. The issue arises when we forget about the cost associated with the code we're writing or when we can't perform basic operations in the tools we use every day. If you have to reference how to commit code every day instead of learning it then that, in my eyes, becomes an issue. Then add things like Copilot and it further separates the engineer from the code and doesn't encourage thinking about the problem. Like everything in this field, it's a balance.
@@sudomateo agreed, I don't search how to create a commit every day. I guess one of the differentiating factors is how effective you are at finding information you don't remember due to lack of constant use. Other factor is figuring out when it's time to create a script/alias to optimize a common operation, like finding and highlighting errors in a directory of log files. I don't have to remeber exact syntax for find+grep, I just use the alias/script and have it as reference next time I need to find something different.
@@bact1om great points! Being effective at finding information on demand is a skill in itself. Knowing when to invest the time to create those helper scripts and aliases is also important because there's a point of diminishing return on that too.
That being said, if you have a topic that you'd like to hear us talk about on video please let us know. I love these conversations and enjoy reading the comments to hear other perspectives especially from those that have been in the field longer than we have. Appreciate you chatting!
Hi Dave and Matt, be cool for some project videos. Like company X is trying to solve this problem, here's how we would approach it. Maybe something people could build along to?
This is a really great idea. I've done a few project videos in the past and have enjoyed the process. I'll plan something, maybe I'll just stream myself writing a fun little golang web project and then setting it up to run on DigitalOcean or something. The "real-life" approach you suggested sounds like something I've been wanting to do. Thanks!
This is a fantastic idea and one that I think we'll be visiting at some point. Sometimes just talking about your approach really helps spread knowledge and perspectives that you wouldn't have otherwise thought of.