What Does Really GOOD CODE Look Like? 

For the people wondering, he shows no piece of code

I like that they're talking about making code _understandable_ instead of _readable_ . I keep seeing comments on various forums that some random code snippet or another isn't very "readable". What is readable to a junior dev might differ greatly from someone with a lot of experience using a variety of different software patterns and paradigms. I often find that junior-level readable code is less flexible and harder to change, comparatively speaking, so I encourage them to think more about the effort they'd have to put into adapting the code should a set of requirements change suddenly (which happens all the time, of course!).

Love Adam's work. Very interesting scientific approach to the challenge.

A lot of times though, developers "refactor" by changing classes that work, to make them do something different, when they already did what they need. Now, this is a case of bad code quality. Instead of leaving the class mostly as is, and putting the new stuff in another class, because they really are two separate things, they decided to "integrate" the two, thereby violating the Single Responsibility Principle (SRP). When developers do that, they inevitably get stuck in a refactor loop. The longest refactor loop I've ever seen is 9 years to deliver a product that should have taken 1 year. In my mind, SRP is fundamentally the most important principle. If followed, the Open/Closed Principle (OCP) naturally follows. Combined, you find yourself not changing existing classes at all, you are just re-arranging them in potentially infinite different ways. But, the discipline of refactoring is something that is done badly more often than it's done well. I think that's why businesses get the idea that we shouldn't refactor, we shouldn't do TDD, etc.

Hi Dave. I'm wondering if you'd care to talk about some of the ideas expressed in the Joe Armstrong (of Erlang fame) thesis. For example, the benefits of structuring code so as to keep the majority of it pure, and how this in turn might drastically improve testability of that code. For anyone interested, the thesis is titled 'Making reliable distributed systems in the presence of software errors'.

I think that maintaining the ability to change your code is fundamental. It's the main goal. Other principles are just tools to achieve that.

The only thing I don't like about these interviews is that they are just a reinforcement of Dave's (and my) views about software development. Having watched hundreds of CD videos (and agreeing with Dave) I'm not really learning anything new from these interviews. Maybe it would but more interresting to see a discussion with someone that doesn't agree or reinforce Dave's views all the time. Hopefully some viewers gets something out of these interviews.

I think the problem is what people perceive as fast. Many managers perceive quick initial delivery as being fast. Writing tests to ensure quality but delivering later on initial delivery is seen as slower because they don't factor in all the time lost to the bugs. In many teams I think they just expect bugs, but want to make sure they "delivered" to the customer "on time", even if this all results in slower overall team performance and more difficult to change software over time.

Easy to change code implies the following qualities: - easy to read - well structured - good structure allows for easy extension and easy debugging (maintenance) - also a developer catches more potential bugs if the structure is good

It'd be convenient to have guest's details in video description

Yes, ease of understanding is most important in software [at every level]. Yet, few SWEs seem interested in the many human aspects of code/coding; often focus is on making it work inside some nicely looking structure. Many say code should read like a written text, but how many SWEs study effective writing: forming paragraphs, telling a story, use proper language constructs, putting sentences in most meaningful order, ...? Code I've come across is littered with 'style errors', different ordering of things in different places, blobs of code without any visual air, terrible formatting rules, ... Generally speaking, could it be that SWEs, leaning towards autistic, are happy in their own little world they control and don't seem too bothered too about the complex realities of being human?

*People who pay for projects don't care to fund or organize software development properly.* there is so much research now, and it's ignored.

I can only go fast if I can rely on what I've build yesterday. I can rely on things if they don't do too much at the same time and are tested.

So us the actual code. A picture is like a 1000 words. And what softwares are we talking about?! Business systems are easier to structure that say time sensitive critical systems. Or heavy maths heavy simulation systems.

@Dave - If you are trying to convey a professional approach to your videos, then probably the last thing you should do is film it in an empty, cavernous kitchen where the light is coming from behind you.

Bla-bla-bla…