The document discusses principles for writing beautiful, sustainable code that allows for agility and happiness. It advocates keeping code simple, elegant, and expressive. Automation, logging, monitoring, and continuous delivery are recommended to improve agility and sustainability. Automating bad processes or hiding exceptions is discouraged. The goal is for code to be easy to understand for future developers.

1. Back to Basics
Simple, elegant, beautiful code.

2. Back to Basics
This is not the dinosaur talk.

3. Back to Basics
Sorry.

5. What are we
trying to
achieve?
1. Agility.
2. Sustainability.
3. Happiness.

6. Agility is not about doing sprints
“But we do stand-ups! That makes us agile!”
“We need to get these stories into iterations so that our
project manager can sign off on the project plan.”
“We do the Agile method here.”
“SCRUM.” Because backronyms are a thing.

7. Agility is not about doing sprints
Agility is the ability to respond rapidly to threat or
opportunity.

8. Sustainability
… because the professionals go home on time*
.
*
Mostly.

9. Happiness
Self-evident, much?

10. What does this
all have to do
with code?
Show us some code
already...
//TODO Implement happiness

11. What does this all have to do with code?
★ Good development practices allow for both agility and
sustainability. These, in turn, permit happiness.
★ Projects should not slow down when they get larger.
★ New team members should be able to get up to speed
quickly.
★ Teams should be able to scale effectively.
★ People should enjoy what they do.

12. What is
beautiful code?
I’ll know it when I see
it...
1. Simple.
2. Elegant.
3. Expressive.
4. Never, ever finished.

13. This is not beautiful.
Tell me: what is the reason
for this class’s existence?
Now tell me: who hasn’t
written code like this
before?

14. Some quick no-
brainers
There’s an app for that.
//TODO: Spot the sponsors

15. Use an IoC container
There’s a video
about that.

16. Use a message bus
Introduce message
brokerage early. It will
save you pain.
There’s a video about
that, too.

17. Log all the things
Logs are your friend.
Centralised logs are a
better friend.
Centralised, correlated
logs are your bestest
friend ever.
There’s an app for that.

18. Monitor all the things
New Relic. Raygun. App Insights. Montastic. Pingdom. Seq
dashboards. Consul. Plain old email.
Pick one. Pick them all. Then pay attention :)

19. Continuous delivery is a thing
When you find a bug in production, you need to be able to:
1. git checkout <that exact revision>
2. git checkout -b hotfix-all-gone-wrong
3. // fix the bug
4. git add -A .
5. git commit -m “Fixed the bug”
6. git push
and then promote that build all the way to production.

20. Automation is your friend
* Builds should run on:
- every push to every branch
- every single day.
* Automate your deployments.
- This includes your databases!
- And your configuration transforms.
* Polish the F5 experience.

21. Some quick anti-patterns

22. Don’t automate the awful
Fixing something does not mean just automating it.
“Hey, all! I just wrote a JavaScript snippet to re-run all
the failed pipelines.”
“We had too many manual deployment processes so I wrote
batch files for all of them.”
“I put the test runners inside a loop.We run them up to ten
times each before giving up.”

23. If your DBA makes your schema changes...
… you're doing it wrong.

24. Stored procs are so 1990s...
Flares belong in the 1970s.
Mullets? 1980s.
Stored procs are from the 90s.
Don’t ask about stonewashed jeans or flannel.

25. Let the exceptions throw
If you can handle it and continue, do so. Otherwise, you’re
broken. Accept this. Move on.
Don’t string.Format(...) your exceptions. It makes them
harder to group in the logs. Use the Exception.Data property
bag instead. And log this.

26. Booleans are not your friend
if (!human.CanAcquirePet(pet)) throw new DomainException
(“This human may not acquire a pet.”);
var reasons = human.CannotAcquirePet(pet);
if (reasons.Any()) throw new DomainException(“This human may
not acquire a pet”).WithReasons(reasons);

27. Get inside the
head of whoever
comes next
Smart me codes for stupid
me.
//It’s dark in here.
//TODO: Find a way out
//TODO: Make the voices
stop!!!
//TODO: Show them some
code already...

28. Beautiful code is a mindset
* What am I thinking when I write this?
* What will I be thinking when I read this?

29. Let’s look at some code

30. If trip over it you do, fix it you should.
* Don't set traps for yourself.
* Code should be easy to reason about.
* Don’t make me mentally parse irrelevant things.
* Explain what the code achieves, not how it does it.
* Ideally, don't even make me read it.

31. Your domain model should model your domain
Use your ubiquitous language wisely. It's very powerful.

32. Check, then do, then announce
public void DoFoo()
{
// Check preconditions
// Do a foo
// Announce that a foo was done
}

33. Optimise your tests
1. Test by convention.
2. Unit test.
3. Integration test.
4. UI automation.

34. Adding new features?
Just add code.

35. Aspect injection is your friend
Weave all the things!

36. Commenting a decision your code makes?
Consider logging it instead. Future you will thank past you.
if (minions.None()) return; // no minions. Can't take over
the world.
if (minions.None())
{
}Log.Information(“No minions. Can't take over the world.”)(

37. Some final thoughts

38. What are we optimising for?
1. Agility.
2. Sustainability.
3. Happiness.

40. Thank you.