Profile avatar
italkswe.bsky.social
I just like talking about software engineering 🤷‍♂️
141 posts 40 followers 71 following
Regular Contributor
Active Commenter

I find it really frustrating to see these misguided arguments against TDD being presented with such self-congratulation. youtu.be/kJWsFWY25GA

What is a good resource for learning C#? Not talking about syntax or Hello World, but “modern” style of it. Where can I learn to *get* modern C#?

Just read the comment section on Valentina Jemuovics post “Without TDD, your KEY DEVELOPER is the ONLY person who knows the details about the system behavior”. It’s easy to forget just how “offensive” TDD is to some people.

Why is TDD so effective? I often find myself completely caught off guard by how effortlessly it guides design. Whenever a behavior becomes hard to tests it’s (almost) always an issue with the design. It changes the game from “creating a solution” to “describing a problem”

Little did he know that by learning TDD, he had set himself on a path that would eventually lead to an obsession with functional programming…

Under-engineering is a much bigger problem than over engineering. But I think the terms aren’t well defined. Over-engineering is solving problems you don’t have (yet). Premature generalization/optimization, adding code in anticipation of requirements. 1/2

Was interviewing a candidate today and asked if they had any experience with TDD. The answer was no since they had never worked at a company where it’s was allowed… Imagine thinking that you would have to ask? And then being told no.

In the era of generative AI, the most crucial skill for any developer is testing

I love Fred Brooks and Aristoteles as much as anyone but I feel like “non-essential” would have convey his point better than “accidental”

There is a fun little parallel between Poppers “who should rule” critique of politics and @davefarley77.bsky.social s “quality _is_ changeability”.

More than anything else, testing is a tool for thinking

Hard truth: your big “to be” architecture diagram is actively impeding healthy progress

“Unit Testing Principles, Practices, and Patterns” by Vladimir Khorikov is on another level!

Optimizing for ease of change has the weird side-effect of removing emotional attachment to the code. It’s not that you don’t care but it’s just understood that it is temporary

It is more expensive to get rid of complexity than to avoid it

The AI can only generate code, not insight

The book that I recommend the most is still James Shore’s “The art of agile development” (www.jamesshore.com/v2/books/aoad2)

Perhaps the most effective, yet counterintuitive, practice of software development is slowing down

- work on less things - work in smaller batches - run the tests after each change - integrate continuously - 80 % refactoring 20% new features - new code is a response to a failing tests

Controversial take: I really like GitHub Actions

Jira is the lead piping of the software industry. It’s good to be organized around work but Jiras opinionated approach drives people mad

Writing code which is easy to change is nowhere near as hard as some people think

When I started doing TDD I was still stuck in an implementation oriented worldview. I would imagine what the solution should look like and then write the tests for that solution. Over time I gradually learned to let go this habit and focus on the tests and making sure they are as clear as possible

IME there is plenty of value in using AI in software development (TDD with copilot is is great!). But I worry that it will push more devs towards a “manufacturing” mindset of development where the focus is on finishing rather than understanding

Newly written code that has never been executed by tests or otherwise is pure conjecture. We have no good reason to expect it to work and even less reason to expect it to do what it should

So… how do you develop GitHub actions? Is there a good way to do apply a tdd-ish workflow? I’ve found some promising tools like github.com/nektos/act but nothing about specific development practices

Fundamentally software development is about “cratering knowledge”. What is the right problems to solve? What is the right decomposition of this problem etc. Being agile means applying Popperian critical rationalism in order to build this knowledge

I can’t believe this is still so widely misunderstood: Agile is *not* something you *do* Agile is something you *are* It’s an ability carefully nurtured by the team.

Often I feel like “agile” is being used as a synonym for “faster” which is unfortunate