6 ms·

I’ve found as an industry we’ve moved to more complex tools, but haven’t built the expertise in them to truly engineer solutions using them. I think lots of org

I’ve found as an industry we’ve moved to more complex tools, but haven’t built the expertise in them to truly engineer solutions using them. I think lots of organizations could find major optimizations, but it requires really learning about the technology you’re utilizing.

smitty1e 6y ago
The whole point of being an Agile "generalizing specialist" is that one is a mile wide and an inch deep.
- gpapilion 6y ago
  Which i think is a fair approach when you’re early on. When you have a dev efficiency team you’re no longer hiring generalists.
temporallobe 6y ago
This, this, so much this. When we build more complexity into a system, the less we understand it, similar to how development frameworks create multiple layers of abstraction to the point where the developers have no idea what actual code the framework produces, much less how to fix it.
- slx26 6y ago
  Yes, we probably need people to stop thinking about tools as if they "solved" problems; what they really do is "transform" them. Now instead of having to deal with the original problem, you only need to deal with part of it and part of the new problem of using the tool that's supposed to help you, plus any leaks you might have because tools rarely solve problems perfectly. It's a trade-off, and you need to be aware of these transformations.
- SamuelAdams 6y ago
  Another way of looking at it is this is the current golden age of infosec. Think of all these complex systems developers and SysAdmins need to maintain at a company. Then think of how well each person knows each technology. Most of them will be "T" shaped, ie know one tech well but surface-level on all the others. If I know several tools really well (or better than the company's sysadmins / devs) I can probably find some security issues with them.
megameter 6y ago
It's a natural tradeoff made when we ask for generality and flexibility: Doing that means implicitly saying "I want to do less implementing and more engineering" because a complex configurable dependency becomes an object of study in itself, something that needs empirical testing to use at its best. Versus the simple thing you would author yourself: if you know the engineering tradeoffs made at the per-line level you have a decent grasp of the performance and flexibility, but you are implementing it and debugging it.
pushrax 6y ago
Also, profiling applications is surprisingly easy to learn. It boils down to looking at timestamps, and seeing what takes the longest. The majority of the effort is just figuring out where/how to get the timestamps you are looking for. I will add that I think software complexity is only going to continue increasing over the long term; it reduces in some domains, but expands in others as we develop more advanced systems. Some kind of analogy to entropy.
- franciscop 6y ago
  Totally agree. Example: now that Node.js supports native `import` and `export` from modules I can see how many JS libraries will not need a transpilation step. On the other hand TS seems to be more and more popular, which requires a compilation step.
jeffbee 6y ago
We have not "as an industry" moved to git. There's a vocal subset of git fans, but it is by no means an industry standard.
- AMC11 6y ago
  Is Git not the most used VCS?
- wolco2 6y ago
  What industry are you part of? In many domains git has replaced other version control systems. I would love to see a new approach to version control. Things like subversion or mercurial have exposed too many drawbacks for them to win back industry.
  - joshuamorton 6y ago
    Google and Facebook both don't use git. Google uses a proprietary, perforce-esque system with multiple frontends, and Facebook uses Mercurial. Among startups, I'm sure git holds a near monopoly, but if you move into other parts of the industry, that monopoly loosens.

smitty1e 6y ago

The whole point of being an Agile "generalizing specialist" is that one is a mile wide and an inch deep.

gpapilion 6y ago
Which i think is a fair approach when you’re early on. When you have a dev efficiency team you’re no longer hiring generalists.

temporallobe 6y ago

This, this, so much this. When we build more complexity into a system, the less we understand it, similar to how development frameworks create multiple layers of abstraction to the point where the developers have no idea what actual code the framework produces, much less how to fix it.

slx26 6y ago
Yes, we probably need people to stop thinking about tools as if they "solved" problems; what they really do is "transform" them. Now instead of having to deal with the original problem, you only need to deal with part of it and part of the new problem of using the tool that's supposed to help you, plus any leaks you might have because tools rarely solve problems perfectly. It's a trade-off, and you need to be aware of these transformations.
SamuelAdams 6y ago
Another way of looking at it is this is the current golden age of infosec. Think of all these complex systems developers and SysAdmins need to maintain at a company. Then think of how well each person knows each technology. Most of them will be "T" shaped, ie know one tech well but surface-level on all the others. If I know several tools really well (or better than the company's sysadmins / devs) I can probably find some security issues with them.

megameter 6y ago

It's a natural tradeoff made when we ask for generality and flexibility: Doing that means implicitly saying "I want to do less implementing and more engineering" because a complex configurable dependency becomes an object of study in itself, something that needs empirical testing to use at its best. Versus the simple thing you would author yourself: if you know the engineering tradeoffs made at the per-line level you have a decent grasp of the performance and flexibility, but you are implementing it and debugging it.

pushrax 6y ago

Also, profiling applications is surprisingly easy to learn. It boils down to looking at timestamps, and seeing what takes the longest. The majority of the effort is just figuring out where/how to get the timestamps you are looking for. I will add that I think software complexity is only going to continue increasing over the long term; it reduces in some domains, but expands in others as we develop more advanced systems. Some kind of analogy to entropy.

franciscop 6y ago
Totally agree. Example: now that Node.js supports native `import` and `export` from modules I can see how many JS libraries will not need a transpilation step. On the other hand TS seems to be more and more popular, which requires a compilation step.

jeffbee 6y ago

We have not "as an industry" moved to git. There's a vocal subset of git fans, but it is by no means an industry standard.

AMC11 6y ago
Is Git not the most used VCS?
wolco2 6y ago
What industry are you part of? In many domains git has replaced other version control systems. I would love to see a new approach to version control. Things like subversion or mercurial have exposed too many drawbacks for them to win back industry.
- joshuamorton 6y ago
  Google and Facebook both don't use git. Google uses a proprietary, perforce-esque system with multiple frontends, and Facebook uses Mercurial. Among startups, I'm sure git holds a near monopoly, but if you move into other parts of the industry, that monopoly loosens.