[Merkur]

I read the free part. Looks interesting, but the math heritage is dominant as promised.

It seems to favor the compact and efficient kind of code that is brittle in the hand of a mildly competent junior dev, or a heavy multitasking senior.

I like smart code, in fun projects, but on the job I prefer fast to read and to reason code. Don’t try to be fancy.

So I guess that’s a book to challenge my assumptions. I like that. Thx.

[jpollock]

I know that as Kernighan's Law. Seems to be something that seniors learn over time.

https://github.com/dwmkerr/hacker-laws#kernighans-law

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

[dwattttt]

I took some time to think about why this saying bugs me, and I think I've settled on "it suggests you can't understand your limits".

I know it's explaining the joke, but you've blown past "clever" if you've reached the point where you can't debug it.

[jpollock]

When you get into team development, doesn't it become the average? So, it's not just about your limits, it's about the team's average.

Otherwise, you're the only one who can fix your code, and becomes a whole bus factor thing.

[Jach]

The limits of the team, even insisting on >1 person being able to fix any code written by the team, are probably much higher than the average of the team. Furthermore, the average isn't going to improve much if code is never written above it. This isn't to say go all out with the most clever code possible, or make things difficult for the sake of difficulty, but consider that it's possible to help upskill your team by showing them better ways (even if sometimes technically "cleverer ways") to write code. It's ok if something isn't as familiar to everyone initially -- exposure helps that. Do better code reviews, code walkthroughs, lunch & learns, book clubs, consultants to come in and teach something, there's lots of ways to improve as a team.

[rswail]

If debugging is the art of removing bugs from programs, then programming must be the art of inserting them.

[Merkur]

I once talk about the art of programming in a job interview and got flashed by a bachelor of biz with: but isn’t it suppose to be engineering? I died a little bit inside…

[rswail]

I've been a programmer for 40 years, I've never considered myself to be an engineer.

We don't have the same level of "proven solutions" and constraints and mathematical rigor that engineering has, nor do we have the legal/liability requirements of "Professional Engineers".

I hope that I qualify as the equivalent of an artisan, like a carpenter that makes furniture, that has elements of both art and craft. Even as I've moved up (and down) the hierarchy of programmer/senior/"architect"/manager.

Programmers fit the "craftsperson/journeyperson/apprentice" model much better than engineering practice.