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

331–340 of 704 posts

Re: Software engineering topics I changed my mind on

#331

Post by diob »

windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

Standups aren't always necessary, but you'd need a high functioning (read communicative) team. In other words, they serve primarily as a forcing function to make sure teams are acting like teams (communicating).

I find the most useful standups are asynchronous though. It's much easier for others to follow along (and ask follow up questions), and avoids statuses devoid of usefulness (or at least makes them very apparent).

Re: Software engineering topics I changed my mind on

#332

Post by Joeri »

bawolff wrote: post #26
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…

People always talk about nosql scaling better, but some of the largest websites on the internet are mysql based. I'm sure some people have problems where nosql is genuinely an appropriate solution, but i find it hard to believe that most people get anywhere near that level of scalability.

Those very large mysql deployments typically use it as a nosql system, with a sharded database spread over dozens or hundreds of instances, and referential integrity maintained by the business layer, not by the database.

For a good example of a high volume site using a proper rdbms approach I would look at stackoverflow. It can (and has) run on a single ms sql server instance.

Re: Software engineering topics I changed my mind on

#333

Post by loosescrews »

jdlshore wrote: post #260
loosescrews wrote: post #143

Test driven development requires you to have a spec upfront. When you already have a testable spec, test driven development seems to be a net positive. It can be a good way to explore the spec before building the implementation. At the same time, you shouldn't force yourself to write all of the tests up front; additional tests will typically occur to you as you build the implementation. If you don't have external fac…

> Test driven development requires you to have a spec upfront. What? TDD was created by Kent Beck as part of XP, which is about as far from up-front design and spec as you can get.

How can you write a test for something that doesn't exist without deciding how it is going to work before building it?

Tests are a form of a spec.

Re: Software engineering topics I changed my mind on

#334

Post by kenhwang »

orobinson wrote: post #316
Shorel wrote: post #257

Earlier quoted context omitted.

There are only two options for me: MySQL or Postgres. And using AWS generally means using Aurora. Then the choice is already made. Not hard at all. Yep, my work involves heavy use of SQL and I find it better than the NoSQL insanity.

Just curious, for what reasons would you choose MySQL over Postgres?

Personally, when I want speed or easy upkeep and intend on doing dumb simple things.

Postgres is more featureful, but if you don't intend on using those features, MySQL is consistently faster and historically smoother to update and keep running.

Re: Software engineering topics I changed my mind on

#335

Post by l0b0 » 

  > People who stress over code style, linting rules, or other minutia are insane weirdos
I suspect this has to do with a combination of personal preference and never having worked with a reliable (in terms of just never changing the semantics) code formatter like Black. Sure, I don't agree with every single thing Black does, but it's still infinitely better than trying to enforce code style manually. And don't get me started about those who just don't want a code style enforced - the diffs end up a serious mess, and forget dealing with merge conflicts in a reasonable time.

Re: Software engineering topics I changed my mind on

#336

Post by kenhwang »

nitrogen wrote: post #132
blabitty wrote: post #51

Earlier quoted context omitted.

I like to half jokingly assert that microservices are a pysop to sell cloud hosting

If I were an evil tech giant, I would open source a bunch of libraries that require significantly more effort to use than necessary, and pitch them as the One True Solution. Just to slow my competitors down.

Ah, I see you've used k8s.

Re: Software engineering topics I changed my mind on

#337

Post by busterarm »

kenhwang wrote: post #334
orobinson wrote: post #316

Earlier quoted context omitted.

Just curious, for what reasons would you choose MySQL over Postgres?

Personally, when I want speed or easy upkeep and intend on doing dumb simple things. Postgres is more featureful, but if you don't intend on using those features, MySQL is consistently faster and historically smoother to update and keep running.

Also in the Enterprise, if you're doing a lot of sharding and replication across networks, Percona MySQL is a very compelling product. I say that as a Postgres diehard.

Re: Software engineering topics I changed my mind on

#338

Post by [deleted] »

loosescrews wrote: post #333
jdlshore wrote: post #260

Earlier quoted context omitted.

> Test driven development requires you to have a spec upfront. What? TDD was created by Kent Beck as part of XP, which is about as far from up-front design and spec as you can get.

How can you write a test for something that doesn't exist without deciding how it is going to work before building it? Tests are a form of a spec.

[deleted]

Re: Software engineering topics I changed my mind on

#339

Post by jdlshore »

loosescrews wrote: post #333
jdlshore wrote: post #260

Earlier quoted context omitted.

> Test driven development requires you to have a spec upfront. What? TDD was created by Kent Beck as part of XP, which is about as far from up-front design and spec as you can get.

How can you write a test for something that doesn't exist without deciding how it is going to work before building it? Tests are a form of a spec.

Either you’re making a point that’s technically correct but missing the point, or you’re misinformed about how TDD works. TDD is an iterative process that generates tests and code at the same time, in very small (1-5 lines of code) bite-sized pieces. Although it could be argued that tests are specs, they don’t happen up front.

Re: Software engineering topics I changed my mind on

#340

Post by Joeri »

martinald wrote: post #37
virmundi wrote: post #15

Earlier quoted context omitted.

Are there other constraints that might make DynamoDB a good fit? For example I made an app at a client. We could use RDS or we could use Dynamo. I went with Dynamo because it could fit our simple model. What’s more, it doesn’t get shut off nightly when the RDS systems do to save money. This means we can work work on it when people have to time shift due to events in the life like having to pick up the kids.

The problem with NoSQL is that your simple model inevitably becomes more complex over time and then it doesn't work anymore. Over the past decade I've realised using a RDBMS is the right call basically 100% of the time. Now pgsql has jsonb column types that work great, I cannot see why you would ever use a NoSQL DB, unless you are working at such crazy scale postgres wouldn't work. In 99.999% of cases people are not.

We just ported a system that kept large amounts of data in postgres jsonb columns over to mongodb. The jsonb column approach worked fine until we scaled it beyond a certain point, and then it was an unending source of performance bottlenecks. The mongodb version is much faster.

In retrospect we should have gone with mongo from the start, but postgres was chosen because in 99% of circumstances it is good enough. It was the wrong decision for the right reasons.

Post reply on HN