Last weekend I attended the second instalment of the CodeDaze conference, the historic Buffalo Central Library in Downtown Buffalo, NY. CodeDaze is a general topic tech conference, indiscriminate towards programming languages, but with a lean towards tackling people problems. Phusion made my (first ever) trip to the US possible, joining CodeDaze sponsors as a bronze supporter.

The Transactional Fallacy

Avdi Grimm (@avdi) started his software career 20 years ago, consulting C++ and OOP (Object Oriented Programming) until he found out he got the design paradigm all backwards. Alan Kay, a source of authority having designed Smalltalk, regrets using the word object when he coined OOP, when the "focus should have been on messages instead".

Comparing OOP's "messages" to real messages (like in the letters we send to a loved one), words and reality don't quite match. There's a cognitive dissonance. Avdi refuses to be "the next person critiquing OOP", but he does question modelling its processes as transactions. Transactions are synchronous, you can't put them aside for later. The ramifications of a transactional life, are non-trivial, says Avdi. "I had very clear goals for life, I wanted kids and a wife and I wanted to work from home, and whilst advancing my career to achieve said goals, all steps I took were in service to this vision. I was fixated on the return value. I spent 2 decades to bring my life to a perfect, static state and forgot to take notice of the intermediate status, only to find out it was never about objects, it's about processes."

Instead calling for Process Oriented Programming, Avdi urges us too to 'be a graceful process'. "We're not brains in jars. Getting older means ever more closing doors, we're not granted a complete rewrite. Learn living in the present."

Mark Bates

In I fought the Code, and the Code Won, Mark Bates (@markbates) maintains a 'Rails-like' framework for Go aptly named Buffalo. On writing Buffalo's API, and bumping its version to a production-ready 1.0, Mark says: "failing is fine", and "it is ok to delete code". He continues, "your code is not a living, breathing thing", although we might sometimes (like to) think so. Mark learned this the hard way. Trying to do right by the project and its community, Mark followed all the right steps, but iteration after iteration failed to see his generator design was flawed, and consequently every step thereafter. "Code is your pair programmer, when you're in the zone, that's your code working with you. When it fails, it is trying to tell you something."

The Great Migration

Jessica Tai joined Airbnb in 2014. Jessica's team was tasked with scaling their Ruby on Rails monolith (dubbed the Monorail), which meant migrating to a microservices system, examplified by the likes of Twitter and Netflix. Where their old system was perfect for the small team in 2008, add 1000 engineers working on the product and deploys easily took 4 hours.

Airbnb's SOA (Service Oriented Architecture) adoption is still in beginning stages, but the migration already vastly improved latency, introduced clear service ownership and faster build & deploy times. Jessica also briefly touched on regression testing with Diffy, comparing new code with last known good code.

Shy Ruparel

Shy Ruparel (@ShyRuparel) is a Developer Evangelist at Contentful. In Serverless Python & The Secret Origin of the Power Rangers he shows the power of serverless and a CSM like Contentful, building a geeky little microsite about the origin of the Power Rangers.

Accessibility & Code Reviews

Adrian Roselli (@aardrian) has been developing accessible, effective web UIs since 1993 and was an invited expert in the W3C HTML Working Group. He warns that most disabilities (vision impairement, hearing, mobility and cognitive impairements like dyslexia, memory issues, or distrations) come in pairs. They layer and multiply invisibly. Add other situational elements to the mix - content not in your native language, different keyboard layouts, noise, multi-tasking - and it's a miracle we ever get anything done.

"We're all doubling as tech support for our family, making stuff more accesible will alleviate some of that pressure from you", Adrian urges us to do a thought experiment and make UIs better for the future you. Sharing ample tips for better accessibility - like text alternatives for images, hyperlink standard practices, field labels and (color) contrast values - Adrian stresses that accesibility is not a checklist, it's about making sure stuff just works.

I loved Adrian's so-called 'selfish user stories', like:
In order to click links as a user with no elbow room in coach class with a tiny trackpad, I want click areas to be large enough and adequately spaced.

Colin Dean (@colindean) first experienced reviews in his student newspaper of Westminister college. "Nothing went into the paper without at least a minor review." Colin has done and was subject to code reviews since... forever, and has seen some bad practices in his time. "We're reviewing code, not the person who wrote it."

In Code Review is an Architectural Necessity, the major things Colin urges us to look for in our code reviews include algorithmic complexity, exception & error handling, exception, class & variable naming, logging sufficiency & level, style conformation, long lines & methods, readability and single-purpose per commit.

A good code review is the systematic examination of proposed changes to a codebase, and solves mental model synchronisation and tribal knowledge development. Code reviews ensure maintainability, compliance, & security, and must be short, thorough, and automated where possible.

Bots & Droids

Coraline Ada Ehmke wrote a bot for the 'lonelyhackersclub' on IRC, and then moved 'Alice' to Slack when the group moved to the platform. Using Google's Cloud Natural Language API, Alice maintains the context of an initial question when she's asked follow-up questions.

Coraline Ada Ehmke

Ruby is a bit of an unpopular choice for a bot, but Ruby is the language Coraline is familiar with and it allows her to experiment without caring too much about performance. Coraline speaks fondly of Alice's 'emergent behavior' (she doesn't like the word 'bug') and has her greet the crowd, asks Alice if buffalo is a verb, and entertains a game of escape the room.

In A Droid’s Journey with mRuby & Go Heroku's Terence Lee and Chase McCarty build 'Ruby on Robots'. A library aptly called Artoo offered no support, and Gobot missed the necessary drivers for the R2D2 droid. Using the app that came with the droids for a while, Chase would send a full bug report and receive a bunch of files he then saved to Dropbox. Doing some packet sniffing, they'd repeat the process a couple of times, looking for patterns and from that they created an R2D2 driver.

Beep beep

For their 'DeeToo' library, Terence and Chase opted for embedding mRuby in Go. DeeToo is extensible (for when new droids are introduced) and allows one to coordinate multiple asynchronous tasks.

Mapping & Testing

Kerri Miller's fascination with maps carried over to her development career. Showing some terrible network diagrams, Kerri concludes that people in software are (and I quote) 'crap' at making maps.

Now, maps are also an abstraction of reality and inheritely flawed. A map can only be correct when it's on a 1:1 scale. But code is 1:1. Right? Kerri evangelizes the DOT language and contributed to a Rails gem she ended up taking over as the maintainer. Mapping a monolith with DOT allowed Kerri and her team to untangle elements into separate API calls.

Kerri Miller

Sarah Withee (@geekygirlsarah) treated us to a Primer on Functional Programming.

Chris Hartjes works with the Test Engineering group at Mozilla and maintains OpenCFP. Evangelizing TDD, Chris celebrates build tools, saving us from remembering error-prone sequences. Computers are good at doing stuff over an over again, freeing up mental energy for other tasks.

Code reviews often descend into critiques of style over substance, Chris says. Code stylers and sniffers are as neutral a party as we can install to migitate these discussions. Touching on empathy, Chris admits it's the most difficult 'tool' to implement. "People think empathy has no place in programming, but technical brilliance alone is not enough. Programming is all about collaboration.

Healthy companies

Aaron Aldrich (@crayzeigh), in Distributed by Design: A Feature, not a Bug, talked about the being-home-for-dinner culture at Elastic, a distributed company with 1000 'Elasticians spread over 32 countries'.

In her keynote, Emily Freeman (@editingemily) stresses that no-one should glorify historical figures on the belief they came from a life of success. Negativity bias might have been a crucial element to the human race persisting but now that we don't need to protect ourselves from lions anymore, it just creates stress and anxiety. "It's convenient to attribute your success stories to luck, or some external factor, whereas other people are successful because they're intelligent." Emily asks people in a position of power to share stories from when you were wrong. "A culture of being right all the time is toxic."

In Suffering, authenticity, productivity: Lessons I learned from bipolar disorder, (Amy Isikoff Newell) gives us a primer on mental health issues. Quoting Wikipedia: "Invisible disabilities are chronic illnesses and conditions that significantly impair normal activities of daily living. In the United States, 96% of people with chronic medical conditions show no outward signs of their illness, and 10% experience symptoms that are considered disabling."

Hiding who we are or how we're suffering takes enormous energy. It sucks energy away from our actual work. Covering up doesn't change the reality, it just makes everything worse. Some barriers to authenticity in the workplace Amy attributes to the patriarchy, include:

• Thinking feelings are unimportant and inappropriate in the workplace,
• Thinking people's struggles outside of work don't or shouldn't affect their work,
• Dominance structures that make people feel anxious and judged,
• Pressure not to admit weakness.

Amy encourages us to listen carefully and share our own stories. "We are not machines churning out code. We are suffering humans trying to make hard things together. Let's build workplaces that acknowledge that."

Lessons in Ethical Development

"The moment that you're faced with an ethical dilemma isn't a good time to start thinking about where your line is", Jamey doesn't waste any time getting to the point. Jamey quickly realized the dichotomy of good and evil in Star Wars isn't as simple as it seems.

Referencing the 7 step process for ethical decisions, Jamey drops a bomb on us: "99 careless people and 1 malicious person is materially no better than 100 malicious people." We need to examine where we as individuals can do the most good. "You could quit - even if they will replace you with someone who will do the job - and put your skills to better use elsewhere. But rebellion from the inside doesn't have to be 'Death Star' level sabotage. You might be able to convince your employer to change their practices or blow the whistle responsibly."

When people are scared it might feel safer to succumb to pressure to do things they're not comfortable with. Which is especially true for marginalized people. All the more reason to use your privilege when you have it.

In We are 3000 Years Behind: Let’s Talk About Engineering Ethics Hayley Denbraver warns us that we build the stuff that a lot of people have come to rely on for the most mundane of things. And we should be held responsible for those tools, maybe not code-of-Hammurabi responsible (where people were held responsible for their work even into loss or death) but pretty darn responsible.

A more modern approach is gatekeeping, or licensure to formalize responsibility. The whole point of licensure is not to prove that you're a good person, but malpractice can lose you your license.

The 'Software Engineer' title doesn't mean anything outside our corporate practice. If you dont have an ethical framework or a lot of knowledge, that doesn't mean you'll hurt anyone per se, and we do have some rules, but the sufficiency of the laws is up for debate. Software Engineering is by design more open than Civil Engineering, and Hayley doesn't want that to change, but she does want to see increased accountability. To that end Hayley suggest promoting ethical literacy, taking code reviews more seriously, assigning the appropriate value to the 'Senior' title, and she encourages us to pretend like we are licensed (and act accordingly). "Ask yourself would I put my name on this?"

In What Can Computers Do? (Sam Phippen) warns us for the computer's ability to transfer styles. Deepfakes technology led to some creative gifs, but most notably faceswapping and porn. "Of course, dudes use it for the creepiest possible application." deepfakes_faceswap's Manifesto starts with 'faceswap is not porn', which, if you need to state that explicitly, means there's fire where there's smoke.

"Code doesn't know what it's being used for. We need to consider the worst possible application of our technology. And we're going to need to create pressure to detect and stop this."