7 ms·

> Make sure your team has the time to master these tools What a luxury!

by actionowl 8y ago

isodude 8y ago
Really though, if you can't master the tools, maybe you should avoid them.
- jacobr1 8y ago
  There are degrees here. Depends what kind of scotsman we are talking about. Having a general understanding of the uses of the tool, understanding what feasible in general, some best-practice rules of thumb and knowing how to google for details gets you most the way there. You could call that mastery. It certainly requires greater expertise than "I read a blog post and changed a few things until it seemed to work." But the bar is much lower than: is familiar with the source code; or even you can use the tool for common uses cases without recourse to the documentation. I think you do need to invest in getting over that initial learning curve such that your tools aren't "magic." You have a conceptual mental model of what is going on. And I agree that takes much more than a token effort. Yet for me, that also stops short of mastery.
  - isodude 8y ago
    Well, it should at least be possible to become master. "I know how this works but someone else did the grunt work". I always aim for simple to use tools, if I need to I can dig deeper and just-fix-the-problem. Or replace it at a whim. So I agree with you. Infrastructure code is really tough when it's scaling, so keep your modules in shape/order and small/easy.
- opportune 8y ago
  has the time to master =/= can't master At a lot of companies, asking "can I have a week to play around with these new tools/frameworks before I get started with them" will be met with "no way". Of course, not saying that's good: often the new tools are strong enough that you would still long term get massive development time savings even with the upfront costs. But a lot of managers and PMs are only focused on "shipping" ASAP, never mind the technical debt or maintenance costs (and to be fair, sometimes you need to ship ASAP... but sometimes you don't)
  - flukus 8y ago
    I think the comment still stands though, if you can't master the new tools including for reasons like the company not giving you time to learn them then maybe you (the company) should stick to the old tools. Doesn't apply if the new tools are forced by management, but often it's the developers driving new tech.
    - isodude 8y ago
      And according to bus factor there should be more than one that could master it. Or at least possible to do another hire.
    - actionowl 8y ago
      > Doesn't apply if the new tools are forced by management That's the reality I was trying to capture with my original comment. For example if you're moving from on-premise servers or a simpler cloud provider (Rackspace, Digital Ocean, or Joyent) to AWS there is no way to escape learning AWS, and the last thing you want to do is manage everthing through the web console so you will need to learn a new tool to manage the infrastrucutre when your old tools don't work with the new stuff. Management and sales types hear about how great, fast, and agile the cloud is and don't consider that it also takes some time to do things right, and there's is no way around learning lots of AWS specific bits at the very least.
- Cthulhu_ 8y ago
  Indeed; work with tools you CAN master. Often you have to make the decision between managed services, PaaS and IaaS, each rung involving a lot more specialized knowledge you need to know. Each one also having more potential savings - because managed services (Firebase, DynamoDB, things like that) trade cost for ease of use / lack of setup / maintenance.
- actionowl 8y ago
  Wow, thanks for the insight! All this time I thought I was supposed to be using tools with a half-assed understanding. It makes so much sense now! :) Seriously though, what I was suggesting is that some companies make promises to their customers, on behalf of their engineering team without understanding (or properly estimating) the impact and technology involved. Then it's a mad rush to get something delivered. I understand this is a bad way to do business but it's a sad reality.
  - isodude 8y ago
    You made the perfect target for my point, sorry about that :) I think it's a good point to really push at though. Something we as techs need to push up in the agenda of management. Yes, and then everybody is upset that things aren't delivered on time/riddled with bugs. There's no way escape out of sync management. It feels like there's a personal vendetta here?
    - actionowl 8y ago
      > Something we as techs need to push up in the agenda of management. And you're absolutely right, we should. It just seems like a losing battle at times, that's all I was trying to convey.
      - auslander 8y ago
        > .. we as techs need to push up in the agenda of management > .. It just seems like a losing battle at times Bad management. Managers in tech companies must have tech background. I was burned before, joining big banking corps, where managers are just bureaucrats, quit with regret for a lost time. Next time, I will vet the management layer before joining.
rawoke083600 8y ago
Can't we all jsut keep using "bash" :) I never want to work with Ansible again ! Having to edit yaml files and learn Ansible concepts and language... Bash is still very understandable and the common denominator on linux ?
- oblio 8y ago
  Bash development is hard to scale. You'd need quite a bit of rigor and there's few best practices available for when you want/need to write shell scripts. You can do it, but at the end of the day you still end up with a bespoke solution.
  - rawoke083600 8y ago
    Bespoke solution into a well-understood and used language...
    - oblio 8y ago
      You'd be surprised at the "well-understood" part. https://www.oilshell.org/blog/tags.html?tag=shell-the-bad-parts#shell-the-bad-parts https://www.oilshell.org/blog/tags.html?tag=shell-the-bad-pa...
      - rawoke083600 8y ago
        Agreed :D

> Make sure your team has the time to master these tools What a luxury!

isodude 8y ago

Really though, if you can't master the tools, maybe you should avoid them.

jacobr1 8y ago
There are degrees here. Depends what kind of scotsman we are talking about. Having a general understanding of the uses of the tool, understanding what feasible in general, some best-practice rules of thumb and knowing how to google for details gets you most the way there. You could call that mastery. It certainly requires greater expertise than "I read a blog post and changed a few things until it seemed to work." But the bar is much lower than: is familiar with the source code; or even you can use the tool for common uses cases without recourse to the documentation. I think you do need to invest in getting over that initial learning curve such that your tools aren't "magic." You have a conceptual mental model of what is going on. And I agree that takes much more than a token effort. Yet for me, that also stops short of mastery.
- isodude 8y ago
  Well, it should at least be possible to become master. "I know how this works but someone else did the grunt work". I always aim for simple to use tools, if I need to I can dig deeper and just-fix-the-problem. Or replace it at a whim. So I agree with you. Infrastructure code is really tough when it's scaling, so keep your modules in shape/order and small/easy.
opportune 8y ago
has the time to master =/= can't master At a lot of companies, asking "can I have a week to play around with these new tools/frameworks before I get started with them" will be met with "no way". Of course, not saying that's good: often the new tools are strong enough that you would still long term get massive development time savings even with the upfront costs. But a lot of managers and PMs are only focused on "shipping" ASAP, never mind the technical debt or maintenance costs (and to be fair, sometimes you need to ship ASAP... but sometimes you don't)
- flukus 8y ago
  I think the comment still stands though, if you can't master the new tools including for reasons like the company not giving you time to learn them then maybe you (the company) should stick to the old tools. Doesn't apply if the new tools are forced by management, but often it's the developers driving new tech.
  - isodude 8y ago
    And according to bus factor there should be more than one that could master it. Or at least possible to do another hire.
  - actionowl 8y ago
    > Doesn't apply if the new tools are forced by management That's the reality I was trying to capture with my original comment. For example if you're moving from on-premise servers or a simpler cloud provider (Rackspace, Digital Ocean, or Joyent) to AWS there is no way to escape learning AWS, and the last thing you want to do is manage everthing through the web console so you will need to learn a new tool to manage the infrastrucutre when your old tools don't work with the new stuff. Management and sales types hear about how great, fast, and agile the cloud is and don't consider that it also takes some time to do things right, and there's is no way around learning lots of AWS specific bits at the very least.
Cthulhu_ 8y ago
Indeed; work with tools you CAN master. Often you have to make the decision between managed services, PaaS and IaaS, each rung involving a lot more specialized knowledge you need to know. Each one also having more potential savings - because managed services (Firebase, DynamoDB, things like that) trade cost for ease of use / lack of setup / maintenance.
actionowl 8y ago
Wow, thanks for the insight! All this time I thought I was supposed to be using tools with a half-assed understanding. It makes so much sense now! :) Seriously though, what I was suggesting is that some companies make promises to their customers, on behalf of their engineering team without understanding (or properly estimating) the impact and technology involved. Then it's a mad rush to get something delivered. I understand this is a bad way to do business but it's a sad reality.
- isodude 8y ago
  You made the perfect target for my point, sorry about that :) I think it's a good point to really push at though. Something we as techs need to push up in the agenda of management. Yes, and then everybody is upset that things aren't delivered on time/riddled with bugs. There's no way escape out of sync management. It feels like there's a personal vendetta here?
  - actionowl 8y ago
    > Something we as techs need to push up in the agenda of management. And you're absolutely right, we should. It just seems like a losing battle at times, that's all I was trying to convey.
    - auslander 8y ago
      > .. we as techs need to push up in the agenda of management > .. It just seems like a losing battle at times Bad management. Managers in tech companies must have tech background. I was burned before, joining big banking corps, where managers are just bureaucrats, quit with regret for a lost time. Next time, I will vet the management layer before joining.

rawoke083600 8y ago

Can't we all jsut keep using "bash" :) I never want to work with Ansible again ! Having to edit yaml files and learn Ansible concepts and language... Bash is still very understandable and the common denominator on linux ?

oblio 8y ago
Bash development is hard to scale. You'd need quite a bit of rigor and there's few best practices available for when you want/need to write shell scripts. You can do it, but at the end of the day you still end up with a bespoke solution.
- rawoke083600 8y ago
  Bespoke solution into a well-understood and used language...
  - oblio 8y ago
    You'd be surprised at the "well-understood" part. https://www.oilshell.org/blog/tags.html?tag=shell-the-bad-parts#shell-the-bad-parts https://www.oilshell.org/blog/tags.html?tag=shell-the-bad-pa...
    - rawoke083600 8y ago
      Agreed :D