Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

321–330 of 704 posts

Re: Software engineering topics I changed my mind on

#321

Post by beagle3 »

vmception wrote: post #305
beagle3 wrote: post #288

Earlier quoted context omitted.

The problem you point to is the ORM, not the DBMS. And if you think “of course, but how can you OOP properly without objects? (And thus ORM if you use an RDBMS)” — you might join some of us in the conclusion that OOP is way overrated. Don’t get me wrong, it is exceptionally useful when it’s a natural fit, like in GUI systems and some aspects of game programming. But in many places, it is completely unfitting, and com…

My point is that I dont need to do plain text queries or need to make queries simpler or worry about what I just did to a row when I am using NoSql Whereas I have all those concerns with DMBS, the ORMs want to help but just add more problems

Having used ORMs, SQL and NoSQL, My experience is that NoSQL is basically never the right choice for anything. It saves you minutes in the beginning in return for hours within a week’s time, then hours in return for days, then it just keeps costing.

Especially since Postgres supports JSON properly, I’ve found no reason to use anything else except perhaps when you want eventual consistency, which couchdb may do better out of the box, but is a whole big can of worms.

Added: I find DALs are the only acceptable layer over relational data, and other than BLOBs (which unfortunately no database seems to deal with nicely, and are thus relegated to the file system), everything that fits into a NoSQL fits at least as well into a modern RDBMS (e.g. Postgres)

Re: Software engineering topics I changed my mind on

#322

Post by kenhwang »

hordeallergy wrote: post #318
projectileboy wrote: post #299

Earlier quoted context omitted.

In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors.

Why not just have casual conversations instead? Standups are one those things that people disagree on endlessly without discussing context - their worth depends on the team. On my current team they're worthless. I'd rather have casual conversation, but that's like squeezing blood from a stone. Departure planning underway.

Some people just don't like casual conversation and wouldn't initiate conversation on their own. If you have enough of those types, no communication wold happen. Ad-hoc conversation tends to be interruptive which is not desirable for people on maker schedules.

Either way, standups is just one communication strategy. Pick the communication strategy that works with the style your team feels comfortable with. There's rarely one solution fits all when it comes to communication.

Re: Software engineering topics I changed my mind on

#324

Post by bawolff »

rmk wrote: post #290
bawolff wrote: post #21

Usually i disagree with these types of lists, but this one seems pretty spot on. My only quible would be that only code quality static analysis is useful. Security static analysis on the other hand (e.g. taint analysis to find security bugs like XSS) is pretty overrated most of the time unless you work really hard to make it fit in your context. I also think linting rules are important, not for what they actually do,…

People with less experience consistently undervalue linting and code formatting and style. Code linting forces one to deal with code smells and innocuous errors that can cost a lot to fix once they escape into the field. Consistent code formatting and style are invaluable in (a) reducing cognitive load in picking names, which is a hard problem in computer science, (b) clarifying the structure of the code (you begin t…

I like consistent code style (i dont care what as long as its consistent) but it has never helped me come up with good variable names.

Re: Software engineering topics I changed my mind on

#325

Post by vmception »

beagle3 wrote: post #321
vmception wrote: post #305

Earlier quoted context omitted.

My point is that I dont need to do plain text queries or need to make queries simpler or worry about what I just did to a row when I am using NoSql Whereas I have all those concerns with DMBS, the ORMs want to help but just add more problems

Having used ORMs, SQL and NoSQL, My experience is that NoSQL is basically never the right choice for anything. It saves you minutes in the beginning in return for hours within a week’s time, then hours in return for days, then it just keeps costing. Especially since Postgres supports JSON properly, I’ve found no reason to use anything else except perhaps when you want eventual consistency, which couchdb may do better…

yes, I’ve encountered that in other people’s projects with increasing scope

I architect my own projects to not need more than a simple data store and scrap ideas that dont fit that archetype

Re: Software engineering topics I changed my mind on

#326

Post by zygy »

projectileboy wrote: post #299
crescentfresh wrote: post #267

Earlier quoted context omitted.

> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.

In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors.

If one had to troubleshoot a bad standup meeting, how might you turn one that feels more scripted into one that feels more natural?

Re: Software engineering topics I changed my mind on

#327

Post by busterarm »

xxs wrote: post #255
busterarm wrote: post #188

Earlier quoted context omitted.

If I had a dollar for every senior engineer I've worked with who has never heard of SQLite...

Truth be told I am yet to see a reason to use in-memory database. Datstructures, maps/trees/set - yes. Concurrent/lock free/skip lists/whatever - all great. I don't need a relational database when I can use objects/structs/etc.

ACID transactions, validations & constraints, and the ability to debug/log by dumping your data to disk which can then easily be queried with SQL.

All of the same reasons you would store relational data in a dbms...

Re: Software engineering topics I changed my mind on

#328

Post by Joeri »

potta_coffee wrote: post #185
cbdumas wrote: post #13

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything . I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservi…

I don't understand splitting an API into a bunch of "microservices" for scaling purposes. If all of the services are engaged for every request, they're not really scaled independently. You're just geographically isolating your code. It's still tightly coupled but now it has to communicate over http. Applications designed this way are flaming piles of garbage.

The idea is that you can scale different parts of the system at different rates to deal with bottlenecks. With a monolith, you have to deploy more instances of the entire monolith to scale it, and that’s if the monolith even allows for that approach. If you take the high load parts and factor them out into a scalable microservice, you can leave the rest of the system alone while scaling only the bottlenecks.

All of this is in the assumption you need to scale horizontally. With modern hardware most systems don’t need that scalability. But it’s one of those “but what if we strike gold” things, where systems will be designed for a fantasy workload instead of a realistic one, because it’s assumed to be hard to go from a monolith to a microservice if that fantasy workload ever presents itself (imho not that hard if you have good abstractions inside the monolith).

Re: Software engineering topics I changed my mind on

#329

Post by kenhwang »

eyelidlessness wrote: post #187
axaxs wrote: post #139

Earlier quoted context omitted.

Same here. Well everything except retrospectives, which I think are generally wasteful or better done in small pieces. Was afraid I wouldn't see something about overdoing microservices, but I think the monolith line covers it enough.

Retros should be like recall elections: always available, never scheduled, with a high but achievable barrier to entry and specific veto principles both ways. The point of a retrospective is "something big happened and we should learn and adapt". They shouldn't be routine, because most weeks/sprints, nothing that big happened (or something that big happened too frequently/urgently to wait for a calendar). They should…

We have an retro automatically if we have a production outage. This doesn't mean its an everyone must attend in-person meeting. Most of the time its just a writeup.

Otherwise, a lead or multiple senior engineers just exercises their judgement on when something serious enough happened that the team needs to be aware of or act on.

Re: Software engineering topics I changed my mind on

#330

Post by Chris_Newton »

PragmaticPulp wrote: post #41
cbdumas wrote: post #13

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything . I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservi…

As an engineer-turned-manager, I spend a lot of time asking engineers how we can simplify their ambitious plans. Often it’s as simple as asking “What would we give up by using a monolith here instead of microservices?” Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans. Frankly, many engineers want to use the latest t…

Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume

The sad thing is, they might well be right.

People used to not get hired for a job involving MySQL because their DB experience was with Postgres, but usually more enlightened employers knew better. Today, every major cloud provider offers the basic stuff like VMs and managed databases and scalable storage, and the differences between them are mostly superficial. However, each provider has its own terminology and probably its own dashboard and CLI and config files. Some of them offer additional services that manage more of the infrastructure for you one way or another, too. There is seemingly endless scope for not having some specific combination of buzzwords on an application even for a candidate and a position that are a good fit.

I don’t envy the generation who are applying for relatively junior positions with most big name employers today, and I can hardly blame them for the kind of job-hopping, résumé driven development that seems to have become the norm in some areas.

Post reply on HN