“You gotta know when to fold ’em”
With apologies to Kenny Rogers, one critical software development skill is to be willing to fold when a path becomes untenable.
A Challenge
Here’s an example of this:
A while ago, I was implementing a dialog in a web app. The content of this dialog was user-provided, so it was going to vary in length quite a bit. We were having trouble getting it to adapt to both the display size and the content size.
The dialog was a CSS flexbox, which should be able to constrain its max height to its parent’s size. However, we were having no luck at all. I think this was probably due to the fact that it wasn’t just one flexbox but rather was nested several flexboxes deep. It maybe shouldn’t have been — but we were past that point.
Getting it to automatically adjust its size as the content and the window change would’ve been great. That would mean the problem would be solved once and for all time, and we wouldn’t need to come back as the rest of the page’s design was tweaked.
Failing to Rise to the Challenge
After a few hours of attempting to do that, I gave up. It was too much time to sink into such a small thing. Instead, I fell back on old techniques: I registered an event handler on window size, manually manipulated the max-height CSS property to be something like “container height minus 80.” In this case, the constant represents the space our navigation and other pieces of Chrome took up.
This is objectively a worse solution:
- It’ll perform worse because we’re doing layout in JS instead of in the browser’s well-optimized layout engine.
- When we add or edit the navigation, this dialog’s height won’t adjust, and someone will need to track down that constant manually.
But at the same time, it took me about 15 minutes to put it together so we could ship that feature. That’s worth a lot!
Senior Developer: Not Wizards and Cauldrons but Mechanics and Duct Tape
I find that I want to think of senior developers as wizards who have memorized all the incantations, know all the answers, and can fix anything with a nod and a wink. And there are people like that! If you find them, definitely do everything you can to keep them.
But in my experience, the sort of “informed pragmatism” described above has proven to be among the most valuable software development skills to have.
The mastery of the arcane will come with time and practice with your tools. But — and this is where the real value shines — practical problem solving is valuable no matter your tools.
Here are a few pragmatic questions I like to ask:
What would the ideal solution look like?
An important step is to visualize what a perfect solution would be. If you don’t even know what that would be, how can you evaluate if your proposed solution is better or worse? For the example above, a more perfect criterion might have been “only updating page layout in one place.”
I find I often get wrapped up in trying to find the most elegant solution and picking some concrete specific criteria to help me distill things down to a real and achievable solution.
What are the costs of the imperfect solution?
This is very similar to the first question, and asking it differently helps keep you honest. Every solution is going to have a tradeoff: some implementations are more discoverable or obvious. Some will be more DRY. Some may be more performant. You should understand what you’re trading off.
Who can validate if I’m on the right track?
Is there someone in your organization who can weigh in? Even if that person doesn’t have the time to work on the implementation, it shouldn’t take them long to verify if you understand the problem space correctly.
If there isn’t anyone who can double-check your evaluation, then you should be very careful regardless of what implementation path you follow.
How will the next developer discover what they’re missing?
The next developer will always have to do some work to understand the code and update it. That’s unavoidable. But you can write code that requires more work or less work to accomplish that.
I find that the difference is that it’s okay to write code that takes more work to extend, but it is not ok to write code that takes more work to understand. The code is already hard enough to understand, even when it’s good.
Do the next person a favor and leave a trail of breadcrumbs. They’ll forgive your programming sins if you confess them clearly.
Software Development Skills: A Balancing Act
I’ve found that this approach helps me keep my eye on the ball and ship the product. I strive to write the best code I can, but I also try to stay aware of when there’s a tradeoff to be made. What questions do you ask to help find the balance between the “right” solution and the pragmatic one?