Hacker News Reader

Comment by scarface74 | Hacker News Reader

You shouldn’t need a DBA for a small or medium project. Any developer who hasn’t taken the time to learn basic RDMS theory like normalization, indexing, foreign keys, etc. doesn’t take thier craft seriously. Knowing the basics of how databases work is a required skill in almost any implementation.

The issue is “framework developers”. I am not opposed to learning and using frameworks but you should always know at least one level below the framework you are using.

If you are a web developer who uses Angular/React and Bootstrap everyday you should know JavaScript, CSS, and HTML well.

If you use an ORM, you should know enough about how databases work to have a mental model of what the database is doing.

View on HN

> you should always know at least one level below the framework you are using

I've never heard that good advice put so succinctly before. Has this advice been around for ages and I just missed it, or is it a newly relevant concern?

BTW, what would two levels be to, say, a React developer, out of curiosity? Would it be the browser engines? Knowing how JIT compilers work, etc.? Or would it instead be a deeper understanding of the language spec, so that you know more internal functioning? Not that there has to be a clear-cut answer.

I heard it on a podcast and I am going to butcher the explanation but they explained it as knowing the “abstract machine”.

When I started learning AppleSoft Basic back in the 80s, I knew how to optimize my BASIC programs because I knew how the interpreter worked and so knew assembly.

When I started learning C#, I knew both C, Win APIs and how the CLR worked.

But for a web developer who communicates with backend servers, I think it’s important to understand HTTP.

What podcast was that? Sounds legit! I'm always on the hunt for new dev focused podcasts.

I don’t remember the episode unfortunately. It was an episode of Software Engineering Radio (http://www.se-radio.net/)

I've heard a similar idea on Hanselminutes. The way he states it is that everything is layers of abstractions, and in order to be great at whatever your chosen layer is, you should be pretty good at the layer below it and of passable quality (think junior dev level) at the layer below that.

Actually it might have been Hanselminutes. Do you know which episode?

I've heard it a handful of times on various episodes but I know he's brought it up when speaking to folks who work primarily one layer below him.

I would think one level down from React is the DOM API, and one level down from that is the rendering engine (i.e. knowing about how DOM operations affect repaints, whether repaints block the main thread, etc.

Language-wise, I'd say babel "javascript" is the highest level of abstraction. One level below is understanding what things like JSX and class properties transpile to. One level below is understanding JIT strategies (e.g. when hidden classes deopt), memory usage of various patterns, etc. One level below is understanding specific semantics of high level APIs (e.g. exact accuracy of a high res timer implementation), or regexp memory footprint by looking at browser source code.

For a react developer I'd say one level is understanding reactive design and maybe how you would implement it in pure JavaScript without react. One level below that would be how you would implement JavaScript and maybe a bit of knowledge how the engine works and shadow Dom.

If you're running into performance problems, knowing those things isn't enough. You need to know about query plans, different complexities of each kind of join algo, etc as well as how to get the query plan, how to profile your database query, etc. Basically databases are hard and you probably will need more than basic theory for anything that is more than a low-traffic CRUD app with latency SLAs on the order of hundreds of milliseconds or more.

Currently on a project where it is taking 48 hours to run an upgrade.

No one has thought to run a query plan

(N + 1)*10000000000000000

This isn’t rocket science either. The theory behind database optimization is basically the same across every RDMS I’ve ever used (SQL server, Postgres, MySQL, and to a lesser extent Redshift). The second thing I learned about databases is how to look at a query plan and how to optimize it.

Why wouldn’t a developer’s job be to learn how to optimize a database query but would be to learn how to optimize a program?

I didn't claim it was rocket science nor that developers shouldn't learn these skills; only that optimizing a database is out of bounds of what most would consider "basic relational database theory". But beyond that, lots of developers aren't interfacing with a relational database. In a past life, I worked on embedded electronics. Other people work on operating systems. Others specialize in compilers or graphics or etc. Databases are a good skill to have, but it doesn't mean everyone should train like a web app dev either.

>Any developer who hasn’t taken the time to learn basic RDMS theory like normalization, indexing, foreign keys, etc. doesn’t take thier craft seriously.

Yet I've never once been asked about this in an interview despite using it maybe once a week for years.

O(n) on the other hand...

I had to do test on these. Some companies do it.

>you should always know at least one level below the framework you are using

I run into this problem whenever I'm interviewing for devs on my team. As a java shop, we usually get people who come in and claim to be proficient in Spring, but when I start asking them questions about the underlying technologies they blank.

My favorite weed-out question when I'm worried someone is too tied to a framework (especially when its one that isn't actively in use on a project) is to ask them to give me some examples of the limitations of it. To me, being able to recognize the things your favorite framework is not able to solve effectively is the best indicator that you aren't using it as a crutch.

I can’t think of any limitations of ASP.Net MVC with all of its extensibility and I have a fairly good understanding of both the frameworks and the underlying technology (HTTP). I’m not sure I could answer that question.

Now on the other end AWS CloudFormation for infrastructure as code, I could go on for days about its limitations.

> I can’t think of any limitations of ASP.Net MVC

1) It's a web framework. So, not suitable for command line tools, desktop GUIs or persistent message queue workers. But you can do all of that in other kinds of C# .NET app.

2) However, .NET is a Garbage Collected language and should not your first choice for e.g. a real-time device driver or OS kernel.

I was thinking you meant in the context of creating a web application but yes. You should never use ASP.Net to run any long running process even if it is kicked off via a REST call. You should use out of process web workers or some other type of queuing mechanism.

With that line of thinking the limitations are endless: I wouldnt use asp.net MVC to build a house.

Mathematically, you're not wrong. You can draw a line around the set of things that any particular software platform is good for, and the area outside of it will be infinite.

But people do try to do some of those things that I listed, using ASP.NET.

Reply on news.ycombinator.com