Hacker News Reader

Comment by gpapilion | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

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.

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.

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.

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.

Is Git not the most used VCS?

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.

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.

Reply on news.ycombinator.com