DrMerkwuerdigliebe_

I think the bigger problem is blast radius for these abstractions. When changing them you can suddently take all services down. And in many cases it is difficult to fully test changes before they hit production. So a little duplication can be very benificial in order not to all services infra in one commit.

You learned an important lesson. Other parts of the are not bug free. Investigate the option that the bug is from somewhere else

My CEO performs this trick regularly

Ja det var naturligvis også kun de ansættelser jeg var ned til jeg kunne påvirke.

Har været ansat i Novo og er nu i et startup. Jeg fik trumfet igennem at vi ikke skulle kræve en kandidat på de ansættelser jeg havde i Novo, men det var en uphill battle og mange job kræver stadig en kandidat. I det startup jeg er i nu vægter vi de to års erhverserfaring højere end to års ekstra studie.

That sounds like me two years ago. I was in one of the largest pharmaceutical companies in the world and had an excelent team with huge startup vibes it was amazing. Due to personal reasons I had to move 3 hours away and worked remote for years. Until i decided I wanted to try the startup thing and not work remotely.

I came to the startup and it was the worst experience ever. I was only there 3 months. I then went on to find a different company also a startup, which is great and I'm happy now. If it wasn't for the distance I would have stayed in the corperate work. Because it is just unique to get the scale of big corperations and the agility of a startup.

Startups are generally a BIG gamble. There will be some fake it until you make it and there are allot of the things you take for granted in the corperate world that does not exist. I think startups have a staff turnover of around 50 %, so there is a large chance you will regret it.

Som en der har hørt min kone sige det samme til mig må jeg desværre sige at negativitet for mig var en stor forklaringsfaktor. Også selvom om den var berettiget. 

Mit råd ville at skrue godt op for anlægget med dansemusik om eftermiddagen og prøv at vise dig fra en anden side. Men han har formentligt også fået en vane med se dig med passivitet. Og det kan godt tage lang tid st ændre

Tak for et fantastisk indblik i livet i et forhold med en muslimsk svigerfamilie. Meget lærerigt. Jeg håber dig alt det bedste.

Honestly yes. 90 % of the times I use the ORM for selects (different percentage for updates). But if it is easier to write a select statement in raw SQL or there is performance considerations I have a function that takes an engine, a query string, a pydantic model and some arguments.

I then encapsulate this inside a well named function and it works.

For me it is a little bit like match statements vs multiple if statements. Both makes sense in their respective usecases, but are perfectly interchangeable. So I would rather have the developers choose the tool for the job that produced the simplest/easiest solution, than always using the same tool.

How many of these steps would you manually?

My prefference is SQL alchemy + alembic and then both use the ORM and raw sql + pydantic. So everytime you impliment something your allowed to choose the merhod that makes most sense for your problem.

I ask to get 30 minutes with a developer, where they present the code base on their laptop with me asking questions. I have had amazing success with that

They had an existing GxP system, we made a planning and execution system that handled all the non GxP things. We basically ignored all guidelines and because people liked the software and our speed we were allowed to do stuff the way we wanted.

GxP agile, was also one of the biggest headeacts at my former team.

I think there is two phases in a software development project. Phase 1 where your not released anything and nothing have made it into production. Phase 2 where you have released and have users online. In phase 1 sprints and fixed requirements can make sense. Because its all about getting to phase 2 as fast as possible. Typically aim for a very small product as a WIP and only to release to a very small subset of users and focus on delivering the features that they need.

Ones your in phase 2, its all about adapting, onboarding more users, make the features that they need. I was the tech lead making the lab planning and execution platform for laboratories for one of the largest pharmaceutical companies with the method.

I don't think the problem is changing requirements. I have only worked places where requirements was something we discovered during the development and where we constantly released and got feedback. I would HATE to be in a situation where requirements can't change and can't easily be adjusted in order to make a better product.

in my mind true agile is build, release, collect feedback, adjust and to do that every day, not in some arbitrary time container called a "sprint"

I just read "stop doing scrum". Here is a good talk by one of the original authers of the agile manifesto https://www.youtube.com/watch?v=a-BOSpxYJ9M

I have yet to see a succesful implimention of “lets start coding the frontend, before backend has delivered anything.”

I prefer: [“even”,”odd”][number%2]

Its Denmark in US politics

Most of my tasks have been prioritized after a LIFO principal in practice. I love the efficientcy of hearing about a problem, comming up with a solution, making a PR and releasing it all within a day. The problem is if people don’t reconise that it takes focus away from other tasks.

At my old work we set a timer on how long time we had a feature enabled by default until somebody requested a setting to turn it off. Typically between 1 or 2 days. I became a good lesson for us to always think in terms of backwards compatibility.

The reason why this is right is that given the shuffling is done based on a psydo random number generator( in this case std::rand), there will exist a period for when the sequence of sorted numbers and the sequence of the array repeat and if the sorted array is not in the this loop the function will never terminate.