Me setting up my first azure devops pipeline

just spilled my coffee

After some time I picked up learning golang again. It's very different from the "high-level" world in C# I initially came from, but I am finding my way better every day.
What are your experiences / maybe projects with golang?

'nuff said

Who I hate:
People who put their tasks to ready for (integration) test without even once running it against real services and the actual database instead just the mocks of the unit tests.

=> I want to test business logic, not fix your internal server errors...

When the sprint planning is, as usual, exciting af...

Today I discovered trial and error driven development for myself:

Me, reading spec..
Spec: „Do something with an CSR“ (not the exact wording :D)

So instead of just googling C# + CSR and copying the code examples,
I went like:
What means CSR -> Certificate (Something Something)
-> could be this namespace (Something with „Crypto...“ in its name)
-> could be this class (Something with „Certificate“ in its name)
-> take the easiest overload (string is always nice)
-> try filling in the parameters from the spec
-> start debugger and inspect properties
-> repeat if necessary

I don’t know if this is the correct pattern to proceed my project with...
But hey, today it worked and now I also know, what „distinguished“ means

Me: Let's try to implement this in js...

Also me: npm install webpack webpack-cli typescript --save-dev

Today I (/ later together with some colleagues) spent almost 4 hours trying to improve a Entity Framework LINQ to SQL query.
The initial problem was, that one of our List API endpoints took longer the more you "page" (besides the long response time it had anyways).
So after
- brainstorming in the team
- brainstorming alone
- hacking around and
- shouting at screens
- googling
we
- got nothing optimized
- got confused about what EF does
- lost the believe in our development skills

So Entity Framework is really a nice thing. But as soon as you look deeper, trying to figure out what it really does between ToList() and "yeah my data arrived" it is just....demonic.

So in our last retros some of my colleagues suggested to (forced) limit the number of lines per method in order to "maximize our code quality".

In the one hand I can see the benefits of this, such as easier testability when having more sperate testable blocks of logic.

But on the other side their code contains lots of such one or two lines private methods which get most of the cases not more than one time called. (And which I then can't even test separately)

I don't understand how this should help...
Is this really a thing? Am I just not "clean" enough?
(it's c# btw)

You know that when the admins need almost a day to open the gates for the whale to swim to the sea?

When a colleague and I explained OOP to a new apprentice with I think it were just some symbols in the console changing at the same time.
We were going crazy.
He was like "Ehm...okay..."
And you would expect it to be the other way around...teaching is such a nice thing!