This is a article from my "Dev Chats" series where I speak to an awesome developer or techie every week or so. You can read more here. Let me know in the comments if you find these useful to you!
Introduce yourself! Who are you? Where do you work?
Hi! I’m Aurynn Shaw, and I’m founder and principal consultant at Eiara Limited. You may have seen me talking on Twitter or at tech conferences about tech culture.
I’m also a less-copious photographer than I used to be, but still can be found making pictures in my free time. 🙂
Who or what got you into programming?
Wow, that takes me back. Programming started around 15 years ago, because some people I knew wanted to run a more advanced web store than just a PDF with their offerings. I didn’t really know how to program, and so I started out modifying existing work online, from (I’m dating myself) Matt’s Script Archive.
From there, some of the people I hung out with were writing their own toy programming languages, and I thought “hm, I can do that”, and it was the most fascinating thing I’ve ever done, and I just kept going from there.
What is DevOps? What should software devs know about it?
DevOps has so many definitions at this point that it’s gotten a bit out of hand. For some people, it’s all about the tools. What continuous integration and continuous deployment we’re using, how we’re focussing on building out servers in the cloud.
For me, it’s not. It’s the cultural questions that ask why we’re building in the cloud, why we’re choosing one technology over another. All technologies come with a context and a set of assumptions, and when we choose them we are choosing to integrate that context and those assumptions, and without considering the changes our cultures require to use those tools, our use of them will fail.
So, software devs should know that the tools are important, but the culture of knowing what other people do, respecting those skills, and working to support their efforts is DevOps, is what gives DevOps is power and meaning, and what makes it so very transformative.
How is the tech scene in Wellington, New Zealand compared to Calgary, Alberta, Canada?
It’s hard for me to comment, really. I was working for a remote company while I lived in Calgary, and my interactions with the broader tech community were a bit limited.
Calgary was, to my knowledge, very much an oil & gas sort of town, which meant very large companies with very large Windows-based infrastructure, and the startup and smaller tech scene was initially quite nascent.
Just as I was leaving, Calgary’s startup scene was starting to pick up. The first co-working space, Cowork YYC, had just opened, and the first startup/founder-specific meetups had happened. The community was definitely starting to take off.
My experience with Wellington has been considerably more integrated, from Startup Weekends to the wonderfully close-knit and supportive tech community, to being able to support the absolutely pivotal and transformative Summer of Tech.
Wellington’s biggest-little-city vibe means that we can have a thriving community of small tech contributors, where we can know everyone but still have the ability to meet new people and bring newcomers into our fold.
It’s really been a privilege in so many ways to be a part of this.
How did you find the move from Dev to consulting? Any advice for others wanting to make the same move?
This has been such a transition. Being a developer was, when I learned, billed as a solo activity, where being caustic or condescending or standoffish wasn’t just expected, but a desired trait. We were supposed to be a bit nasty, and we can see those fingerprints of expectation all over our culture and ingrained behaviours.
Shifting to being a consultant means I can’t do that. At all. Meeting with clients, doing sales, all the core skills I was taught to devalue are the skills that matter so much more now, and their lack has been so illuminating in terms of how our culture creates toxic outcomes.
It’s also taught me a lot about the difference between “perfect” and “appropriate”. So, so, so often tech people, especially myself in earlier years, focus on the “perfect” or “correct” designs for technology choices, but I’ve had to learn that there aren’t perfect or correct choices, only choices that are appropriate for right now and a little way into the future.
Before I was a consultant, I was very much in the vein of “this thing that I have to work on is bad, look at all these bad choices.” And to me, coming in after it had been built, that position could be tenuously justified. But that system was built over months or years, from choices and constraints that were utterly invisible to me, and my positioning it as “bad” meant that I had no respect for those choices, or the work that was done under those constraints, only that I was “better” in some undefinable way.
But there wasn’t “better” or “worse”, just “no longer appropriate.” Learning that has been a big deal for me.
As for advice? Meet people who also consult, talk a lot about their journeys. It’s hard but oh so rewarding, and a network of people who get it when you’re struggling and need to talk about what those struggles look like is vital beyond words.
What has been your toughest lesson to learn in your software career so far?
To stop being a jerk. 🙂
No, really!
We’re taught by so many forces that we are superior, elite, better, that the choices we’ve made with our technology stacks are better or our programming languages, to our very computers.
The toughest lesson was, as I mentioned above, is that there is no “best”, only more appropriate, and that being caustic because I thought my history and experience made my ideas better or more valid wasn’t a very good thing to do to my teammates.
These lessons get taught so early, from university professors calling Python, or Java, or whatever nothing but “crap”, and we teach students that that’s acceptable, appropriate, and important to do as part of being a developer.
The hardest lessons for me have been unlearning that, to stop it, and even to this day I still struggle with it.
What would be your number one piece of advice for a successful software career?
Learn to play well with others. Software, now more than ever, is 100% a team sport and not being able to work well on a team, to respect and integrate ideas and backgrounds that are different, means that you will make bad software.
Learn as well that cultures are systems too, with similar rules to how programs work. There are pressures, causes, effects, and unintended consequences, and once we can start to observe them we can start to understand why things are the way they are, and we can stop perpetuating toxic effects and write good software.
This is important because the modern tech world is littered with artefacts from developers and scientists that don’t understand these systems, have been taught to ignore or devalue them.
Artefacts like the Google and Facebook AIs doing broad-spectrum creepy, racist and misogynistic things, to simple things like soap dispensers refusing to work on darker skin. These are unintended consequences of the social systems around us, and we need to be aware of them and actively fight them.
Have you got any hobbies outside of your job? Do you think they help your tech career in any way?
I make photographs! I also make books with my photographs, which is fun. I also play video games quite a bit, and spend a decent amount of time reading.
It’s exceedingly important to do not-tech things in your off time, in my opinion, as it’s all to easy to fall into the toxic and harmful “passion” narrative traps in tech culture, where all we do is focus on tech to look “better” to prospective employers, leading only to our own burnout and exploitation, but also the perpetuation of those social systems that rule our lives.
So, I always say “yes, doing hobbies is more important than doing the tech itself.” It puts us out of context, gives us new frames of reference to approach our problems and solutions, and introduces us to people with new ideas and backgrounds and concepts that we can integrate into our work.
What books/resources would you recommend?
I highly, highly, highly recommend The Unwritten Laws of Engineering, 2nd Edition. It was written in the 1940s, updated in the early 1990s, and describes some of the social behaviours and systems that we need to actually do engineering things well. It drove home for me, so very strongly, that the technical work is not the important part of my technical work, it is not and will never again be my core value.
I also recommend reading Intent is Magic, a discussion on how the intent of our actions doesn’t reduce the harm of the consequences. I think it’s vital to understanding the real impact of what we do, and how we are ethically responsible for our creations.
My Contempt Culture piece if you haven’t, naturally. 😉
Lean UX, on how to think about user experiences (all technical work is user experience work).
Debt: The First 5000 Years, for giving me new ways of thinking about frames of reference and how to think about spaces that might seem well-explored.
Deep Time, for making me think about long-term consequences to my actions, and how to frame communication when you’re not there to communicate.
I’m currently reading Distinction: The Judgement of Taste, a really interesting sociology text on how what we like gets constructed as we grow up. It’s fascinating and I recommend it!
Finally, make your shoutout! What would you like the readers to go have a look at?
Shout out to @Br3nda for calling me out at the right place and time.
Shout out to the Geek Feminism Wiki for being the best place to find the right examples.
Shout out to @sarahmeifor saying the things that I want to say really well, and giving me lots think about.
Shout out to so many wonderful women who gave me their time and energy and knowledge and helped bring me where I am today, whose names are innumerable.
I’m sure there’s others, but those are the ones off the top of my head. 🙂
Top comments (0)