During my career, I’ve been blessed to be part of a number of growing companies. I’ve observed an occurrence during times of growth with enough frequency to call it a pattern, at this point. Or, more accurately, a leadership anti-pattern. During a recent meeting, I accidentally gave a name to this pattern: The Values Donut. Today, I want to write a little bit about what it is, some ideas about how it occurs, and some strategies to resist it.
Location: Pittsburgh, PA, USA
Dates: 4/17/2018 - 4/19/2018
Throughout much of this conference you’re going to hear people state obvious things. Sometimes, they’ll even tell you that they think what they’re saying is obvious. Why are they saying them at all, then?
It’s obvious there must be more to the story, so let’s examine what we mean by “obvious”. You’ll leave this talk encouraged and ready to apply what you’ve learned to better empathize with others. Through application, you’ll see growth in both your professional and personal life.
[TL;DR: I’m not submitting to speak at any conferences this year. If you organize a conference and specifically want your attendees to hear about the things I enjoy talking about, please do get in touch, as I’m open to a few invited-speaker slots.]
Have you ever come to the start of a new year and realized that the entire previous year went by in the blink of an eye? That happened to me this year, and while last year was full of great things, I’ve decided to slow things down a bit in 2017.
Warning: rambling ahead.
Location: Cincinnati, OH, USA
Dates: 11/10/2016 - 11/12/2016
All abstractions are lies, if they are abstractions at all, and as developers, we live our lives surrounded by them. What makes a some abstractions better than others? This will be an opinionated and empowering look at the value and nature of abstractions, with a jaunt through quantum mechanics and the nature of reality.
You know, just your average talk.
Conference: RubyConf Australia
Location: Gold Coast, Queensland, Australia
Dates: 2/10/2016 - 2/13/2016
We call it “Computer Science.” That’s comforting, somehow, because science deals with cold, hard facts. We can prove the correctness of an algorithm, or watch our skills, and our app, improve in measurable ways.
Yet, at its core, software development isn’t an act of scientific triumph, but of empathy. Software’s true worth isn’t measured in lines of code or test coverage. It’s measured by how it makes life a little bit better for someone else. Maybe your application or library makes someone’s day a little less painful, or maybe the code itself brings a smile to someone’s face.
It’s about time we have a hard talk about a soft skill.
At Keep Ruby Weird last year, I tried giving a very different kind of talk. It was a choose-your-own-adventure-style talk entitled “Choices”.
It was different because of the audience participation aspect, but also because I gave the talk on a custom presentation app that I built specifically for the talk, over many an arduous night and weekend.
Over the Christmas holiday, I worked to clean it up and get it into a state that
would be releasable. For me, this means “has a test suite”, since otherwise, the
best response I could manage to a pull request would be:
I’ve finally reached that state, and in case you missed the tweets over the holiday, I’d like to announce Venture!
Earlier this week, a friend linked me to Buffer’s post about their updated salary formula, and their online calculator that uses this formula to tell you how much you would make if you worked for Buffer.
One of the interesting things about the formula, and their online tool, is that even though they’re vocal about being a distributed team, a huge component of employee salary is based on where they choose to work. As of this writing, a “Backend/Frontend Developer” at “Master” level will make between $82,577 and $155,535 depending on where she chooses to live.
Lots of supposedly-distributed teams do this. They call it “adjusting for market rate.” I think it’s a big problem.
This year, when people asked me what I was speaking about at RubyConf, I got to say “absolutely nothing.” This is the first time in 3 years I’ve been to a conference and not actually had to give a talk.
Instead, I was blessed with the honor of curating a track of my choosing. I was further blessed by having an amazing selection of proposals to choose from. My choice was a track composed entirely of “soft” talks that ask us to question the way we think about our work. Originally, I wanted to call it “Harder Skills” in order to bait the people who think “soft skills” are a waste of time into watching. In the end, at Avdi Grimm’s suggestion, we renamed the track to “Wetware”.
I’m posting the playlist here because I think these talks are important. The playlist is in the order they appeared throughout the day, so if you missed the conference, or missed a few of the talks, you can get a sense of the arc intended for the track.
I’d like to thank the organizers for trusting me to put a track together, but most of all I want to thank Laura Eck, Amar Shah, Brandon Hays, Joe Mastey, Sonja Heinen, and Nickolas Means for putting in all of the hard work to make this track the highlight of my conference-going experience. They were incredible, and your conference would do well to invite any or all of them to speak.
Conference: Keep Ruby Weird
Location: Austin, TX, USA
We’re faced with choices every day. Sometimes the right decision is obvious, like “should I have a cookie?” (The answer is ALWAYS yes). Sometimes, less so.
This is a talk about the choices we make. Come prepared to make some choices of your own, as your choices will have an impact on the direction our journey takes!
Conference: Full Stack Fest 2015
Location: Barcelona, Spain
Dates: 9/1/2015 - 9/5/2015
Since 1884, humans have been building skyscrapers. This means that we had 6 decades of skyscraper-building experience before we started building software (depending on your definition of “software”). Maybe there are some lessons we can learn from past experience?
This talk won’t make you an expert skyscraper-builder, but you might just come away with a different perspective on how you build software.
I’ve been working on a project at nVisium that has records (of the ActiveRecord kind) with attributes that are themselves a stored domain object. Until recently, I would have probably done one of three things (in decreasing likelihood) to handle this situation:
- Use serialization to store the attributes of the domain object in JSON, then wrap the AR object in a decorator to handle translations from the “bag of data” to my domain, even though it means doing the ActiveModel dance to allow me to use this object in a form, and ActiveRecord will always see this attribute as “changed”, meaning unnecessary database operations.
- Come up with some convoluted way to represent this data using ActiveRecord
associations, even though it would almost certainly mean I’d find myself
has_onesomewhere (ick), and probably still wrapping the whole thing up to avoid using
- Gone the polyglot persistence route, even though it would mean taking on the ongoing operational overhead of managing another storage backend.
Thankfully, in Rails 5, the ActiveRecord Attributes API offers a fourth option, and it’s much nicer. Even better, we can already use this functionality in Rails 4.2. Head on over to my post on the nVisium blog to read how.
Today’s post is going to be short and sweet. Because I find myself using a few
settings in almost every single Rails app’s
config/application.rb, I want to
share them with you, along with the rationale for each.
I want to share a quick story with you. It’s about one of the most memorable things I saw at RailsConf this year.
I saw it as I was walking back to the Westin from the convention center with my CTO after the first day of the conference. We were discussing the day’s events, and what we would be doing that evening. Then I froze in my tracks, and asked him to hang on a second, so I could walk back and see if I saw what I thought I saw.
You know how sometimes you see something amazing and it takes a few moments to appreciate its gravity? So it was with Lobby:
I’ve had a couple of weeks to reflect on my RailsConf experience, and now that I have, I can safely say I enjoyed this year’s RailsConf more than any previous year.
I started out thinking that this was largely because I was giving a talk I was already comfortable with, so I could relax. I’m sure that’s part of it. And another huge part was no doubt the wonderful curation of the program by the program committee. But I think the single largest contributing factor to my enjoyment of RailsConf was my last-minute decision to volunteer as a guide, and I sincerely hope that everyone reading this considers doing so at their next conference.
Conference: RailsConf 2015
Location: Atlanta, GA, USA
Dates: 4/21/2015 - 4/23/2015
Agile. Scrum. Kanban. Waterfall. TDD. BDD. OOP. FP. AOP. WTH?
As a software developer, I can adopt methodologies so that I feel there’s a sense of order in the world.
There’s a problem with this story: We are humans, developing software with humans, to benefit humans. And humans are messy.
We wrap ourselves in process, trying to trade people for personas, points, planning poker, and the promise of predictability. Only people aren’t objects to be abstracted away. Let’s take some time to think through the tradeoffs we’re making together.
Looking for a previous post? Check the archives.