3 ms·

I disagree with the premise that I need to know what happens behind the doors to successfully use a tool. I've been using git for the past 15 years with literal

by s1k3s 4y ago

I disagree with the premise that I need to know what happens behind the doors to successfully use a tool. I've been using git for the past 15 years with literally 0 issues of merging or branching. The only rule I have to follow is "don't do stupid things with it". Branch -> push -> merge is what I've been doing all my life and it worked like a charm. Just avoid the problems and it's all going to work just fine.

omginternets 4y ago
With few exceptions, this mentality is exactly what separates well-paid senior engineers from those who write rest endpoints all day. Knowing your tools is part of the job. Knowing how your tools work is a big part of knowing how to use them effectively.
- s1k3s 4y ago
  How? I've heard this argument a lot. How does me knowing how to solve a problem I created myself make me better than me avoiding it altogether? To expand on this: how many engineers you work with know what actually happens in a CPU when they run a for loop, for example? How many of them need to know that? It seems to me that a lot of people are very successful at creating useful things without understanding the underlying tech. Isn't this why we built it?
- pdimitar 4y ago
  Senior engineers are paid to get stuff done on time while following good practices, and be proactive and communicative (and not end up on Twitter for the entire day because they couldn't figure out one project requirement by themselves, as many juniors do). Compared to a junior engineer, they have to get thrice more things right at the same time. Knowing a tool inside out can help with this, but it's not a requirement at all. It's just one of the, a-hem, tools in their box with which they can achieve efficiency. I am like many others in this thread. I don't care about GIT's "beautiful data model" one bit. I learned with time which commands are dangerous and I do due diligence to make triple sure I don't trip on them. With 2 exceptions for the last 10+ years (each took me half a day to fix) this has worked perfectly. It's quite OK to stick to what you know is safe and works well (and what pre-conditions have to be met so it works well). At this point if a customer comes around and asks me to use advanced GIT features I'll just bill them triple while telling them exactly why. I deliver, and at least 80% of the time I deliver on time, and 95% of the time with good practices and due diligence attached. How I use GIT is my business. I've been contacted by the next contractors no small amount of times and have eaten praise for how easy to track my project's change / commit history has been, too.

by s1k3s 4y ago

omginternets 4y ago

With few exceptions, this mentality is exactly what separates well-paid senior engineers from those who write rest endpoints all day. Knowing your tools is part of the job. Knowing how your tools work is a big part of knowing how to use them effectively.

s1k3s 4y ago
How? I've heard this argument a lot. How does me knowing how to solve a problem I created myself make me better than me avoiding it altogether? To expand on this: how many engineers you work with know what actually happens in a CPU when they run a for loop, for example? How many of them need to know that? It seems to me that a lot of people are very successful at creating useful things without understanding the underlying tech. Isn't this why we built it?
pdimitar 4y ago
Senior engineers are paid to get stuff done on time while following good practices, and be proactive and communicative (and not end up on Twitter for the entire day because they couldn't figure out one project requirement by themselves, as many juniors do). Compared to a junior engineer, they have to get thrice more things right at the same time. Knowing a tool inside out can help with this, but it's not a requirement at all. It's just one of the, a-hem, tools in their box with which they can achieve efficiency. I am like many others in this thread. I don't care about GIT's "beautiful data model" one bit. I learned with time which commands are dangerous and I do due diligence to make triple sure I don't trip on them. With 2 exceptions for the last 10+ years (each took me half a day to fix) this has worked perfectly. It's quite OK to stick to what you know is safe and works well (and what pre-conditions have to be met so it works well). At this point if a customer comes around and asks me to use advanced GIT features I'll just bill them triple while telling them exactly why. I deliver, and at least 80% of the time I deliver on time, and 95% of the time with good practices and due diligence attached. How I use GIT is my business. I've been contacted by the next contractors no small amount of times and have eaten praise for how easy to track my project's change / commit history has been, too.