Comment by Mouse47 | Hacker News Reader

Comment by Mouse47 | Hacker News Reader

Parent Full thread

Yup. I've seen 55+ year old programmers write what was essentially a message queue persisted in a database table, processed by a cron job. We frequently had problems with duplicate processing of messages, due to multiple cron jobs running at once.

I've personally argued against a key-value store schema in SQL Server and was in favor of a flat-table design. In our case, there were records of different 'types', and each type may have a number of fields always be null. Looking back, I'd probably do something like this:

   Entity
       common attribute 1
       common attribute 2
       etc

   Entity_Type1
       entity_id fk references Entity,
       type1_attribute 1,
       etc

He was certain that the flat-table design would take up more space since it would 'have to store every attribute every time'. Most of these were varchars, so (looking back) that was straight up false. Not only that, but in a key-value schema you have to store the name of the 'column' (key)... every time. I was unable to articulate the harms of key-value schemas when it comes to queryability...even though our existing system was filled to the brim with 'unions' due to a key-value schema. I lost this argument.

Each of these developers refused to use git, in favor of visual source safe. I know.

All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing.

I've lost count of the times I've been steamrolled in discussions. I'm not sure if it's my age or if I'm just lacking that much socially. When you lose an argument over key-value schemas of all things it makes you really question if you know what you're doing...

>All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing.

I'm and old programmer and I've been arguing against business logic in SPs since SQL Server 6.5 and have been losing ever since. That's not an old/young argument.

It's because vendors (in this case MS) recommend putting code in SPs. I suspect it has to do with lock-in. I use the database for what it was made for, and only what it was made for: to persist and retrieve data. Anything else should be in the code.

Also, key/value schemas are terrible and slow, but sometimes they're the only way to get the dynamic nature of what you are doing. The best compromise I've seen of that is to have the values you know are going to be used a lot by groups/customers flat, then have the key/value schema for anything oddball.

I guess the moral of the story is old/young doesn't really matter. It's know / don't know what you are doing. I guess it boils down to thinking about what you are doing. Key value is very dynamic but I'll bet it's slow. Do we need fast more than dynamic? Is there a compromise that will satisfy both requirements? Many people don't think that deeply and just want to get it finished.

When I was young, the dot bomb was the "great filter." After that, there were a lot more people who knew what they were doing because they survived. It sucked though, I don't recommend it.

> I'm and old programmer and I've been arguing against business logic in SPs since SQL Server 6.5 and have been losing ever since. That's not an old/young argument.

> It's because vendors (in this case MS) recommend putting code in SPs. I suspect it has to do with lock-in.

If i recall correctly, back in the dark ages of Classic ASP and SQL Server 6.5, database stored procedures was the only feasible way of implementing a reasonably performing web application.

No, we had middleware back then. It was ugly text over sockets, or worse, DCOM, but it worked. That was more ISAPI than classic ASP. If nothing else, we could create a queue table in a database and have a Windows Service pick it up.

Ah DCOM, fun times.

Back in SQL 6.5 days (and all the MS SQL versions up to, i believe, 2005), "precompiling" queries in stored procedures was recommended for performance reasons. It was even asked on hiring interviews, at least to me.

>That's not an old/young argument.

Oh I wasn't saying it was -- just providing examples for when the hand-waving/dismissive attitude by senior developers isn't really backed by anything. I'm pretty skeptical of 'because I said so' answers nowadays (by both young and old devs).

>then have the key/value schema for anything oddball

Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)

Yes, I'm prepared to defend any design decision I have all day if I have to. I like discussing / arguing things because someone else might have thought of something I didn't consider. It's about making a good product, not about who wins. I use the pro/con model. That's probably lost on most people, especially defensive ones. I get aggravated by "because I said so," too. When you're older, you don't get dismissed as much if at all.

My mentor was a huge arguer, that's probably where I got it from. He'd start talking louder and spittle would come out at me and everything. It was ugly, but I got used to it. We'd go at it for hours, but we both knew when we came up with the right decision and were receptive to it. I like to think I'm quite a bit more tactful than he is though.

>Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)

Oh god, I suffer over schema design decisions more than I should, but sometimes, relational just doesn't fit what I'm doing. What's really helped is I got stuck doing reports for a huge schema my 2nd two years and I really saw what crappy design could do to performance. My favorite is when a schema has missing foreign keys on 80% of the tables. It's like they discovered foreign keys 3/4 of the way through the project and didn't bother to retrofit them.

Eh, I've seen some fresh college grads advocate the same stored procedures and silly k/v stores in relational DBs; someone told them that "model code must be isolated; stored procedures are the best way to do that" and they took that as gospel.

And I have been steamrolled in discussions with 20-somethings as well. "Don't worry, I'll always give you enough time to refactor the tree shaking caused by this design," from a first-time manager is probably my favorite, followed by "this must be re-written, there's no way to salvage it in-place."

They went from consistent if slow progress in defusing the landmines in the old backend to eight months of re-writing everything (frontend included since the data model was also changed) and trying to claw their way back to parity.

Bad programmers will be bad programmers, regardless of age. At least age will put a polish on average developers, letting them work above their raw potential simply because of "I've seen this before; here's how it was solved".

I work in an organization that is relatively balanced as far as age goes (I'm 45). The most senior-level engineers tend to be older than me, though there are a few younger guys (still over 30). Perhaps I'm just fortunate, but here's what I've observed:

We tend to be fairly agile with regard to new technologies, and much of that is driven by the architects. A few of the young folks will recommend bleeding edge platforms/libraries/techniques. Some of this stuff has been accepted, some of it hasn't. It is almost always filtered through the lens of experience ("what happened when we tried to introduce x? ").

Experience counts, primarily because one group has been burned in the past by accepting recommendations from just-out-of-college engineers. That's not to say the younger devs don't know anything, but they have precious little experience shipping actual product.

(We work in the medical domain, so "move fast and break things" doesn't work so well in a highly-regulated industry).

On the other hand, our senior build engineer is more, uh, established in his ways, and we are currently stuck on an antiquated version control system. This particular engineer also wields quite a bit of influence to the larger company, so his way tends to be the way we go (unfortunately).

At the end of the day, I think you find stuck-in-their-old-way folks in an industry. This is not at all unique to software engineering.

In some cases, the Old Ways and the Old Software is better, and it takes wisdom and experience to identify these cases. "Because it's old" is almost never a good reason not to use some software or technique (code does not rot). "Because it's new" is sometimes a good reason to try something, though.

"""All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing."""

I remember when this was the thing to do; to store as much as possible in stored procs. Fat server (the server here being the database server), thin client.

That has changed, and changed again, and no doubt it will be different in the future again. The problem with our profession is that it isn't always easy to determine which changes are actual progress, and which are a fad or fashion.

(Anecdotally: I also remember having to replace ~100 lines of Python with ~60 stored procs and views in Access. This was code that was very unsuitable to be done in a database. The Python code did the job fast, and was readable and understandable; the Access queries were NOT, and it took them minutes to do the same thing. But, management considered Python "unmaintainable" because it was "an obscure language"... so they preferred the Access "solution".)

Nowadays stored procedures hype equivalent is AWS Lambda.

git is a good litmus test. If they're old and refuse to use it, they're probably a close-minded dinosaur.

If they like git and know it well, they're probably old, full of the experience and benefits you're looking for, _and_ energetic, growing and open-minded.

(I said "probably" because it's not perfect. But it's a pretty good heuristic).

Reply on news.ycombinator.com