"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…
Software development topics I've changed my mind on
481–490 of 788 posts
Re: Software development topics I've changed my mind on
#482Good 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
#483Earlier 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.
Re: Software development topics I've changed my mind on
#484Earlier 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.
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
#485agree 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
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
#486Software 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.
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
#487Earlier 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…
Re: Software development topics I've changed my mind on
#488Earlier 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 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
#489sure, 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
#490Earlier 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.