Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

481–490 of 788 posts

Re: Software development topics I've changed my mind on

#481
post #317

"93%, maybe 95.2%, of project managers, could disappear tomorrow to either no effect or a net gain in efficiency. (this estimate is up from 4 years ago)" This made me laugh it is so true. My last big project at "Big Co" ( Knee surgery robot ) My small group went through 4 project managers - just for our small team. The entire project had probably 20. While a few where enjoyable to work with, there was very little val…

When org charts are from 2 reorgs ago, team members are going straight to members of other teams where collaboration is needed, the backlog is 100% maintained by the developers with no input from managers, I wonder what exactly they do outside of meetings where they usually just relay orders from higher up.

Re: Software development topics I've changed my mind on

#482
> Good management is invaluable

Good management is life and death, particularly for a startup. If you think you can do without it and you're not a good manager yourself then it's going to be a struggle to execute.

> ...you'll deeply regret building on Serverless Functions

Whatever serverless functions promise in scalability, they'll cost you in terms of complexity. Trying to build a cohesive backend entirely in a serverless environment just isn't worth it when it's trivial to boot up a simple, long-running server. Even running locally is a pain in the ass compared to `rails s` or `fastapi dev`.

God forbid your serverless environment is actually on the edge, at which point most of the stuff you're used to using won't work.

Re: Software development topics I've changed my mind on

#483
post #92

Earlier quoted context omitted.

It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...

Starting with raw SQL is fun. But at some point you find out you need some caching here, then there, then you have a bunch of custom disconnected caches having bugs with invalidation. Then you need lazy loading and fetch graphs. Step by step you'll build your own (shitty) ORM. Same thing for people claiming they don't need any frameworks.

There are plenty of libraries/packages for SQL that do all of that for you, too. The choice isn't between a sophisticated ORM and just throwing SQL text at a socket. The fundamental assumption of ORMs is broken, but much of the tooling works well and exists in non-ORM places.

Re: Software development topics I've changed my mind on

#484
post #468
post #462

Earlier quoted context omitted.

And that is extremely good compared to the same function-writer adding or changing their non-checked exception, for which an 1+ levels removed consumer gets no warning at all until the pager goes off because the system broke in production.

Unless the library upgrade is also fixing a 9.9 CVE.

That same scenario (an emergency version-change to a direct dependency) could also remove a function that your code calls! Yet that does not mean mean compiler-checks are bad, or that the solution is to make a system that lets you yeet it into production anyway.

Look, I get it: Sometimes a Checked Exception defined in a niche spot "infects" higher-level code which adds it to their signatures, because nobody takes the time to convert it into something more layer-appropriate.

But that is the exact same kind of problem you'd also get when library's NicheCalculationResult class is trickling upwards without conversion too! However nobody freaks out over that one. Not because it's mechanically different, but because it's familiar.

Re: Software development topics I've changed my mind on

#485

agree on 10/11 because i have not used DynamoDB ;) by the way, whats wrong with serverless functions? Given a long enough time horizon, you'll deeply regret building on Serverless Functions

Been using AWS Lambda for 10 years, since AWS Lambda was first released, so there really is no longer of a "time horizon" - I have not had any problems that would cause any regret, quite the opposite in fact. I also don't use the "Serverless framework", I rolled my own AWS Lambda toolchain long before the "Serverless framework" was ever a thing. So I'm not sure if the author is referring to "functions as a service" generally or specifically the "Serverless framework".

My team did recently try to set up the "Serverless framework" for a new project, and it was quickly apparent that it wasn't going to work for us. It was kind of messy, honestly. I really wanted it to work, but requiring an account on the Serverless framework website just to get Lambdas deployed was the wrong way forward for us. We just ended up using my own toolchain, which is simple and easy and does everything we need it to do, which is build the Lambda function inside AWS Lambda, and deploy the function with some basic configs.

Re: Software development topics I've changed my mind on

#486
post #478

Software development should also be seen from what stage the org is in. Software development looks super different when the org is a startup vs when the market fit is established. When you are a pre-PMF, you have to establish trust. You deliver fast, cut corners, make sure customer needs are met, value is generated. Nothing else matters. When PMF is established. You have to de-risk everything. All your work is at sta…

This. Engineers are hired to solve problems. Sometimes beautiful code and clean architecture are part of the requirements to solve the problem at hand. Sometimes… they aren’t.

Beauty is in the eye of the beholder. I would argue you didn't use design patterns enough.

Beautiful code and clean architecture is a rabbit hole.

Code should be clean enough to communicate. As long as team understand and accepts the risk, it is good enough.

Re: Software development topics I've changed my mind on

#487
post #84

Earlier quoted context omitted.

I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, th…

> I brought over the blueprints, and the technician found the schedule of beams and columns within seconds Is that really an example of the standardization you want? It shows that the blueprint was done in a way that the technician expected it to be, but I am not sure that these blueprints are standardized in that way globally. Each country has its standards and language. If an architect from a different country did…

But I can't look at the design from my desk-mate and hope to understand it quickly. We wall love to invent as much as possible ourselves, and we lack a common design language for the spaces we are problem solving in. Personally I don't entirely think it's a problem of discipline of software engineering, but a reflection of the fact that the space of possible solutions is so high for software, and the [opportunity] cost of missing a great solution because it is too different from previous solutions is so high (difference between 120 seconds application start and 120 milliseconds application start, for instance).

Re: Software development topics I've changed my mind on

#488
post #473
post #422

Earlier quoted context omitted.

consider the standard library case - e.g. there's a new kind of exception because new storage or network technology demands it. you can't add it without breaking the build of everything everywhere effectively freezing the standard library version for people who don't have the means to fix their build. that's super duper bad.

1. The standard library is special in many ways, particularly because it often isn't shipped along with your product and you can't always control what version is used. Just because something is problematic for those libraries doesn't mean it it's a bad idea everywhere else. 2. The difference between altering your un/checked exceptions is not whether consumers will have to react, but how it shows up and how badly you…

Re 1) when the standard library becomes a major blocker for the runtime version upgrade many people are seriously angry, or depressed.

Re 2) that's what it must've sounded like in theory in the conference room when they were designing that part of the language. In practice, the upgrade of the library will never happen if it breaks the build. Production should catch all runtime exceptions and be able to restart itself gracefully anyway because cosmic rays don't make sense as checked exceptions.

Re: Software development topics I've changed my mind on

#489
"Objects are extremely good at what they're good at. Blind devotion to functional is dumb."

sure, but I think the status quo is to way overuse objects. my preferred style is to bias heavily towards value objects, and to never ever use things like inheritance for control flow

"ORMs are the devil in all languages and all implementations." hard agree lol

Re: Software development topics I've changed my mind on

#490
post #153

Earlier quoted context omitted.

Video game logic: Everyone worse than me is a noob. Everyone better than me has no life.

Today Steam gives us the option of verifying whether a certain player has no life. Only half joking.

My favorite steam reviews are: "This game sucks, would not recommend." - playtime 800h
Post reply on HN