Keynote: Lies Developers Tell Themselves - Billy Hollis - NDC Minnesota

All humans sometimes deceive themselves, and developers are no exception. From "I can get this done in a week" to "My job is to write code", developers often convince themselves of things that are only partially true - or even outright ridiculous.

These seductive-but-false notions are factors in everything from poor software quality to unnecessary stress on developers and other team members. In this session, developer/designer/architect Billy Hollis will bring out his top ten uncomfortable truths about software development, with some humor to make them easier to hear.

[a.distant.observer]

It’s uncanny (and unfortunate in some ways) how accurately this describes my own thought processes and career as a developer. So many good takeaways from this.

[betterstories]

I know it's not the main point of the talk, but I've been straight up saying the fighter jet thing about all modern cars for years. Touch screens don't need to be everywhere, least of all in human controlled vehicles! Drives me nuts!

[jonahandersson]

I like Billy’s talks. I like this one too!
It is worth sharing to all developers, tech managers, business managers, etc. and even those new devs in the industry.
Thanks for the great presentation, Billy!

[ngr]

"There is no wrong answer. This is a test of character. Because whatever answer you give has to be in connection with reality and honest" - 9:30

[vkottler]

What's sad is this isn't really an "individual developer" problem - this is often a company-wide culture problem. Corporate leadership loves to be the tone-setter in diabolically bad estimations, including advertising to customers and the public before any engineer has vetted any timeline or work scope.

[OldieBugger]

I used to designing + coding + talking with the end-users. Not exactly an easy job, but very rewarding in the end.

[OldieBugger]

"I can get this done in a week" - When my boss ever needed a quote from me for an offer, I doubled it. Then he TRIPLED my already doubled quote... and quite often that meant very very busy six weeks for me.

[NickRoman]

"What is the weirdest bug you've ever encountered?" I am impressed that someone could even answer a question like that. I mean, maybe if you had lots of examples jump to mind, you could just pick one and it wouldn't have to be the weirdest. But just being able to remember something like that in 10 seconds or less without having prepared a story is impressive.

[enkephalin]

I knew an HP software engineer, supervisor for a DoD contract, confide to me that he worried that he lost the ability to code. I really hadn't imagined that, and still find it difficult to.

[moandrez]

Having such a great presentation helps to make software developers grow instead of having them go the expert beginner path. Thank you! 🙏

[OldieBugger]

One evening I had this great idea, while drinking beer in a small pub. I just had to go the front desk at ask the bartender for a pencil and some paper. I got them, I wrote down the fuction headers (C code) for this idea I got. The next couple of weeks I spent writing the bulk of my idea as proper C code. And I still think it was my best idea ever.

[paviad]

Seeing the length of this video I was like "I am NEVER going to watch it through to the end" and I said that to myself every 10 minutes into the video, until I finished watching it to the end.

[BryonLape]

Removing project managers from SDLC really helps with the first one.

[deyan.todorov]

Righting Software by Juval Lowy, is one of the best books which I've ever read. When you finish it you will start thinking not for functional decomposition, BUT decomposition based on volatility which is something totally different!

[enkephalin]

No meeting lasts 90 minutes "because there's a lot to explain". It's because bosses have a captive audience and are addicted to the attention.

[madskaddie]

About "lie: business rules go in code". As a programmer (disclaimer made :)), I highly disagree with the author. For several reasons:
1. from my experience, non-programmers really struggle with defining rules (eg, programming the rules), even the simpler ones and even with DSLs that would simplify.
2. Tthe author talks of "complexity" of code; it is likely to be also considerably complex in non general purpose programming environments/DSLs. For example: pick some random web project and try to understand the CSS rules associated with it. Now imagine that you have to change something or add a feature using some existing pattern. Good luck :) (and CSS is not as complex as business rules)
3. If a DSL is used to simplify the life of the (non-programmer) user, there will be rules that simply aren't definable in the DSL domain. If the those complex rules are possible, there is a high change that is not a DSL but a general purpose language
3. Users will fail defining the rules, since everybody make mistakes. Debugging every business rule engine that I'm aware of or can imagine is pure simple pain
4. To many dynamic changes may lead to undefined behaviour. No one really knows the rule at the time something happened. I'm willing concede on this one

[jnswiwh]

36:00
That's a tough one,
As most people can't speak at the speed of thought. this is practically guaranteed to happen.
'mind wanders off, thinking about things' will happen
whether that thing is related to the thing being said, or whether there's also listening going on, that's harder to tell.

The amount of times I've been accused of 'not listening' because 'I looked like I was also thinking' (I was), I lost count by the age of 10 basically.
My response when anyone actually bothers stating that accusation, is thinking for a moment whether I should lie and agree to save their ego, or give the honest answer of 'here's a bulletpoint list of everything you've said thusfar, here are the ways they are related, here are the action-items I took away thusfar, here's where I expect the real point is still coming/where I would ask 'which of these things were you working towards/do you need me to do?' if you were to end the conversation here'.
As the overlap between 'people who feel comfortable stating such an accusation (in public)' and 'people who would accept a public display of 'your accusation is factually incorrect and you aren't as much _smarter than everyone else_ as you like to pretend that you are' ' is very small.


I see the loop of:
- I can trivially keep up with everything you're saying and still am basically waiting for you to continue talking (so I start thinking about other stuff as well)
- I think I see, I only have half of your attention. Let me slow down to accommodate.
(with increasing frustration on both sides)
on practically a daily basis.

[brujua]

Good talk, I will be reading righting software. The 'don't try to be cool' and the 'be innovative' points are in tension with each other

[ralphboardman]

Rule number 4: the feature they don't know they will need... it comes after rule number 3: the feature they are insisting is essential will be the first one they ask us to modify or remove

[jnswiwh]

49:00
Another tough one.
Is the 'there is basically only one good way to do things, and it is ours'-statement something that should either be ignored or considered reason for skepticism? Absolutely.
Is it also located on [the location reserved for the sales-pitch], anything put there should either be ignored or considered reason for skepticism? Also yes.