This is a post about a simple yet profoundly influential vicious cycle that occurs frequently in software development environments.
We can one-line it like this:
Mess ➝ Incidents ➝ Trauma ➝ Restrictions
Modestly unpacked, this cycle looks like this:
Unmaintainable code is written and deployed, most likely on top of preexisting Mess. This mess gives rise to production Incidents. These incidents put the fear of God in one or more important business people or stakeholders, creating Trauma that ripples through the organization. As a result of this trauma, increasingly prescriptive process Restrictions are imposed to ensure incidents are not repeated…
Naming is important. As has been pointed out many times before, computers faithfully execute our written instructions, but we don’t write those instructions to be easily understood for the benefit of computers.
Decoupling is important. Highly coupled systems are challenging to change, and this challenge increases exponentially as the degree of coupling and the number of coupled modules increase.
Consider that not all forms of coupling are created equal. Consider also that decoupling is not without its own burdens, burdens that are compounded when the intermediate layer that forms the basis of decoupling hides contextual information or otherwise complicates grokkability…
As some of you may know, for several years now I have been interested in bringing domain holism to software projects.
App frameworks like Rails, Django, and Express know next to nothing about the domain of your application. With the right definitions you can reasonably argue that they do in fact know nothing, but my own view is a bit more generous.
Frameworks like the aforementioned are widely used to help developers build software better, faster, or more cheaply. In a perfect world all three, but we know how that goes.
What these app frameworks can’t and shouldn’t know are…
Think about the system flow and generate a set of expectations before you exercise your code.
As a long-time educator and the progeny of professors, I find few things more satisfying than teaching a thing of real value to willing and motivated students. If teaching is in your blood like it is in mine, I’m sure you have many times experienced the thrill of a student grasping a difficult concept for the first time. I’m sure you’ve experienced the satisfaction of seeing a student attain a high degree of fluency in their chosen subject over time, knowing you played an…
I’ve been reading a lot of Brené Brown lately. As part of a welcome career transition out of enterprise software and into software consulting and education, I’ve been spending a lot of time envisioning what it is I want to do for the world.
The higher-level of that hasn’t really changed a lot over the years; the implementation details have.
Simply put, I want to make people better. I want to make the world better. I have a tremendous amount to offer as a listener, innovator, and teacher.
But as I think you probably came to this post to hear…
If there’s one thing that I still don’t believe is talked about quite enough in the development world, if it’s not gender inequality then it’s probably the so-called soft skills. I’m sure virtually every programmer would agree that personal and interpersonal aptitude plays a role in one’s ability to write good software, but I definitely find myself nearer the camp that says the development of these soft skills is every bit as important as writing good code.
In fact, I would argue that it becomes progressively more important the more advanced one becomes.
Let’s start with a fundamental appreciation of…
Well we’re almost through week four here at the Iron Yard as I’m writing this, if that tells you anything.
It continues to be a lot to take in accross a lot of different dimensions, but one of the invaluable lessons that continues to be drilled into me every single day is properly scoping and breaking things down into manageable pieces.
The Laud of Small Things
Write tiny methods and you’ll have a more robust, clearer, and more versatile set of legos that you can stick together for complex operations.
Make tiny commits and you’ll keep a clearer view of…
In a great talk from last year’s Ruby Remote Conf, Peter Cooper gave me permission to write scrappy code (Seriously, he did. We can go back and listen to it together if you like.)
This was a great thing he told me, and it is especially helpful as he is far from the only person I’ve recently heard extolling the benefits of cobbling something together that works, and only then making it pretty and extensible. You know, maybe.
When you hear someone tell you to just enjoy yourself, get it done, and worry about the niceties later, I think a…
Well, we made it through week two of the Iron Yard Indy, and to quote Keanu Reeves at his finest…
It’s a little hard to describe exactly what makes the experience so intense.
If you want to quantify it in terms of its components, then I can quickly summarize for you what you may already know:
Just watched this talk on imposter syndrome by Julie Pagano for an Iron Yard assignment.
If you aren’t aware, imposter syndrome is just what it sounds like — the belief that your current station in life (or a future one to which you might otherwise reasonably aspire) is unmerited by your ability or accomplishments. It’s an issue that even the most rudimentarily self-aware person will face at some point in their life, if not cultivate a long and fruitful relationship with.
Wait. Fruitless relationship?
Regardless of how you define your fruits, the results are usually negative.
When I talk about…
Software Engineer & Coach @ Yakcellent Solutions