I had a conversation that almost became an argument with a someone I manage the other day. It revolved around how we should do just the basic parts first as that's what the business needs quickly and the code base is in a bad state right now so I didn't want to build new features on a poor foundation, particularly as those new features might not be forwards compatible and might have no way of fixing.

Once basic is in, refactor and cleanup, add secondary features. Their point was to just do it all at once in a big bang. It devolved into them getting angry and telling me to leave them out of all future discussions because now we "aren't ever doing the secondary features", just give them the task and leave them alone.

I let this go, but now I've found out they went to another high up person on the team and presumably lied to them about what was said.

What to do?

Just casually learning if I don't fix a bunch of stuff I know nothing about in a technology I have never touched within 2 weeks the company loses a 100k contract.

Should book holiday.

Today I was told that full stack is another name for a shit developer who wont be able to develop anything good because they aren't focused on one skill.

But it was by a person who claims to like OOP but doesn't know the 4 principles, SOLID, GoF, or DDD. So I take it with salt. But he claims his entire company follows this philosophy.

I think that some developers just decide that they're hot shit and refuse to talk about any other skills they don't know about since they must not be needed if they don't know them. Code is code.

Dear .Net developers.

I wrote this tonight:
https://github.com/Future-Forward-S...

Please let me know if I am extremely clever, or extremely stupid.

P.s. I know it's not exactly ports and adapters. Rename needed maybe.

That you can't get by on intelligence. School had not prepared me for actually learning.

"Where's the database server gone?"

How do you move clients from an old and insecure integration API, to a new implementation?

I'd live in a ditch

What's a good way to guage someone's domain modelling expertise in an interview? I don't want to make people go do an at-home project because we aren't big enough to be filtering candidates who won't do it, simply because they can't be doing that for every application.

Technology I can ask questions about, but stuff like DDD I think it's hard to know without seeing them work.

By any chance can someone explain logarithms to me and how they relate to complexity growth? I can do the calculation but it's only from memorisation. I just don't understand how it relates to a graph.

I am working on an event driven system that uses a message bus and has a few services that talk to each other asynchronously via the bus.

I'm writing in memory integration tests for one of those services, but I just realised the fundamental flaw here with such tests. I only have 1 application running, but I need several. This is quite a serious flaw I should have seen before.

Anyone else tried integration testing event driven distributed services? I imagine all I can do is stub the message broker...

Today I spent 9 hours trying to resolve an issue with .net core integration testing a project with soap services created using a third party soap library since .net core doesn't support soap anymore. And WCF is before my time.

The tests run in-process so that we can override services like the database, file storage, basically io settings but not code.

This morning I write the first test by creating a connected service reference to generate a service client. That way I don't need to worry about generating soap messages and keeping them in sync with the code.

I sent my first request and... Can't find endpoint.

3 hours later I learn via fiddler that a real request is being made. It's not using the virtual in-process server and http client, it's sending an actual network request that fiddler picks up, and of course that needs a real server accepting requests... Which I don't have.

So I start on MSDN. Please God help me. Nope. Nothing. Makes sense since soap is dead on .net core.

Now what? Nothing on the internet because above. Nothing in the third party soap library. Nothing. At this point I question of I have hit my wall as a developer.

Another 4 hours later I have reverse engineered the Microsoft code on GitHub and figured out that I am fucked. It's so hard to understand.

2 more hours later I have figured out a solution. It's pure filth..I hide it away in another tooling project and move all the filth to internal classes :D the equivalent of tidying your room as a kid by shoving it all under the bed. But fuck it.

My soap tests now use the correct http client with the virtual server. I am a magician.

Today I used NDepend to analyse my new jobs code base. It looks like the classic big ball of mud :(

Can anyone point me to some example of a .net project that doesn't scale because not using async await for IO?

I'm not sure how to measure impact of not doing this...

I tried SOAP for the first time today. It wasn't bad. I had a client for the service built automatically instead of writing my own.

Why is SOAP dead?

!Dev

Bought my first house :) 3 bedroom house to myself. It's insane to me.

Logarithms give me a headache

Learn more about networking, revisit computer science fundamentals, memorise agile frameworks, practice DDD properly, learn about basic property and conveyancing law for my new job, get through 1 tech book every 2 weeks, revisit Linux as it's been a long time, learn the basics of developing and deploying with azure, learn terraform and docker, finally finish building my own product that has been going for 3 years now, continue learning about mobile development and build a mobile app for my new product.

Should be fine xD

Are there any class based JavaScript test frameworks? I dislike the whole describe/it setup. I know it's basically the same thing, but I prefer the class setup in .net with xunit. I like being able to write abstract classes for tests..

Maslow's hammer is my new favourite quote.

Ad-libbing - when one only knows how to use a hammer, a lot of his problems start to look like Nails.

This is so true

"I am not happy with the quality of the product"

*Ignores

"I dislike how I am forced to work here"

*Ignores

"The team does not understand software design and is writing 2000 line single functions"

*Ignores

"I am starting to think the product cannot be saved unless we start focusing on quality"

*Ignores

"I am not happy in my job anymore because I want to work as a professional..."

*Ignores

"All I ever do now is put out fires"

*Ignores

"I quit"

We use a third party paid company to produce a service and give ongoing support for it, which all our revenue streams depend upon. They are shit and their service is shit. Here's how my conversation about testing went today.

Me: 'hey X wrote an integration test project for the service. It shows the service is broken 50% of the time. We should give their team access to it and have them run it as part of CI'

Colleague: 'They are too shit to setup CI'

PM: 'we are stuck with them so there is no point. It is what it is'

Boss: just ignores me. Not even a reply.

Some days later

Head of QA: 'Hey Dev and QA are broken'

Me: 'because their service is broken. I made so and so suggestion before but it was rejected. We will just have to accept Dev and QA are broken 50% of the time'

Head of QA: 'no we cant'

Me: 'ok so we should setup the tests to run by giving them access'

Head of QA: 'No we shouldn't. The tests can only be used by us and if they break it tells us so we can act on it, or choose not to'

Me: 'We would not want to act immediately on all our revenue streams breaking? Yes we can reverse engineer their client and fix errors as they occur, or we could just have them run the tests and a team our company pays for can stop adding breaking changes to their own API every other day. Right now it has been broken for 2 weeks.'

Head of QA: 'in an ideal world we would have an internal team so you're wrong'

Me: :)

I really don't understand how they can come to such a conclusion. Am I missing something or am I surrounded by total fucking idiots?

My colleague told me today that companies with shit code quality, complete chaos, no tests of QA of any kind, and poor security practices still make loads of money and are extremely successful so it's all a waste of time.

I detest this idea and I refuse to work like that anymore. But I also think he's right :(

I'm thinking about doing a Phd in AI. I'm a software engineer.

Anyone done similar have advice?

I login this morning

Everyone going crazy as prod is broken in a million ways. 2.5 million exceptions In 24 hours.

We talk for 1 hour and solve nothing.

I diagnose the 2 biggest sources of exceptions and explain every step I took with screen snippets to reach my conclusions

The one other competent person on my team agrees. Otherwise complete silence.

I'm told not to fix the issue because I am leaving in 6 weeks and other people have to start taking responsibility.

No one fixes the issues. Instead they leave early. Now it's the weekend and the product is fucked.

Fucking useless people. Can't wait to leave.

It is easy to believe something is over-engineered as a junior. You open a solution and get slapped in the face with a wet fish of many classes, with strange names, doing very little, with everything coming together in ways you don't understand.

My advice is to learn about design patterns, clean code, clean architecture, and model driven design. Until that point I don't think you can make such a distinction. And indeed once knowledgeable of patterns and techniques as well as the domain, the same solution can look obvious, elegant and readable.

In a field where everyone is saying 'dont over-engineer', one must be able to tell if something is actually bad, or just uses techniques you don't recognise.

Telling your senior you think something is over done just because you don't understand it is not good. First learn techniques, understand the code, then form opinions that are at least relevant then.

From someone who committed that crime.

Robert Martin says in clean code, or maybe clean architecture, that one should separate the tests into what is hard and easy. GUI tests are hard and therefore brittle and so we should test against view models.

However on clean agile he says a story is not done until it passes automated acceptance tests which in my experience are always brittle and grow so large and brittle that things grind to a halt.

What am I missing? Are stable acceptance tests possible on the GUI? Should we test only an API?

I just read Robert Martin's chapter on the Single responsibility principle in Clean Architecture.

In it he explains that stakeholders, or actors, that require their own functionality that may be similar to others should have separated code. This is because 2 actors == 2 potential reasons for change.

But this seems to run counter to DRY. Am I mistaken?

Need advice guys

Where I'm working now I'm the tech lead, but I'm not happy. I want to get deeper into infrastructure and DevOps but I have no scope for that.

I have an offer from another company. A very small raise. Supposedly will lead to tech lead in 6 months after I help them recruit a team. Offered mid. I went back and said because of uncertainty about where the role would head, and coming from where I am, I would accept the offer with the title so I have more confidence about the future of the role.

They came back with a senior role, not tech lead, saying there's no scope for that yet. They also said they envision giving me architecture control and letting me train and drive the cloud process.

But this is all heresay. I could take the role, the project is postponed, there is no team to be a tech lead for, and so no pay increase or opportunity to learn.

Opinions?

Angular universal is the bain of my professional life.