Hello friends! I’m Ty Walls, the friendly software craftsperson next door. If you’re interested in how I think, feel, and operate on a software project, this “meta C.V.” will prove illuminating.
Table of Contents
The “T” coder
When I approach a problem, I go broad, and then I go deep — like a “T”. I need the Big Picture™ if I’m to be truly effective on a project, so I go broad. Once I grasp the basics, I get in the zone and go deep. My early work as a consultant in a rural area forced me to “go broad”, branching out laterally in the industry and making me a generalist. I’m comfortable with servers and security and scripting and network infrastructure — but I’m a craftsman at heart. I love to create, and I channel that passion into the code.
I love reducing friction between an idea’s conception and its realization as a deployed feature. Maybe the friction is in the code or tooling; often it’s in the process. That’s why problem domains that currently get me giddy are Continuous Deployment, DevOps, and infrastructure as code. On a tooling and HCI level, my passion to reduce creative viscosity manifests itself as a love for Vim, disproportionate use of keyboard shortcuts, and copious scripts and aliases to automate creative barriers out of existence. I love learning and exposure to new problem-solving tools and approaches. The more I learn, the smaller I feel in the universe, and yet the more effective and flexible I feel. If I’m not continuously learning, I feel like a stagnant swamp with water striders in my hair.
Tools and languages come and go. If I tell you how I feel about some of the languages I’ve worked with, that will give you greater insight into my way of thinking.
Ruby: It just clicks with me and I feel productive. It’s interpretive and flexible nature lends itself to fast prototyping and continuous integration. The largely friendly open-source community surrounding Ruby is refreshing also.
Elm: The functional style helps avoid so many bugs. The debugging tools are amazing and nearly as friendly as its community.
Python: I like it, but it doesn’t feel as flexible as Ruby. I generally favor Ruby over Python if given the option.
SQL: It’s a great and time-tested domain-specific language.
C#. Java done right. =P The language designers made a lot of sensible choices that make it feel natural to work with. The static typing is useful in large projects for avoiding bugs, but can also feel like a straightjacket sometimes.
Java: Its semantics and core libraries take me back to the dotcom bubble. It’s verbose, suffers from patterns-itis, and has weird design decisions like including both an int and an Integer data type. I always walk away from a session of Java coding feeling like a worn out hurdler. It just gets in my way. I love coding, but code should be a means to an end. If a language or process gets in the way of me and my team, I furrow my brow in annoyance.
While still on the “Like” side, I’ll mention that C# was also pretty obtuse before lambdas and the async/await paradigm. And paradoxically, while static typing is best for huge projects, it also hobbles them with long compile times.
My philosophy on code craft
There’s a place for FP, OO, and procedural approaches to programming. That said, my OO code leans toward the functional as I avoid mutable state where possible.
I’m a stickler for style, but not my style — I adapt to the style of the project at hand.
I enjoy pairing and mind-sharing with skilled and humble developers.
For a ground-up approach to better design with low coupling and high cohesion, I practice TDD, but not fanatically.
I love crafting a beautiful and maintainable design and practice merciless refactoring, but releasing always trumps refactoring.
I strive for balance and pragmatism in all things “code”.
Principles != laws.
“It depends” usually isn’t just a cop out. Like any engineering discipline, software engineering is all about tradeoffs and compromises within a context.
My weak spots
The math in my toolkit isn’t as sharp as I’d like it to be. I understand math related to computer science and algorithms, but I get lost when an author starts up with complex mathematical proofs. At some point I need to invest time in improving my fluency in this problem-solving “language”.
I value team cohesion and harmony more than my own opinion. However, in some teams this can lead to “rule by the loudest” instead of an ideological meritocracy.
I enjoy open collaboration with people in small teams where team members are skilled, humble, kind, and trusted with large degrees of autonomy.
I strive to be a kind, open, and inclusive person.
I’m respectful of my team members’ personal lives and privacy.
I’m a big fan of sensible work hours and a healthy work-life balance.
Nothing trumps face-to-face communication, but I’m not opposed to remote work, not opposed at all… ^_^
I’ve worked as an agile coach, but I’m no corporate “Scrum Master.” I dislike the stereotypical corporate approach to managing people and projects. Rather, I prefer true “agility” over a collection of buzzwords.