When I sat down to write this post, I didn’t have an idea as to convey what I wanted to say. (And that’s a ridiculous thing to feel when you’re writing. )
Honestly, I just had a single sentence that I’d jotted down a few days ago and was going to flesh out in more detail.
You begin to develop a sense of intuition for how something should be designed or implemented.
It’s not even really a fully developed thought. It’s just a statement (and I’m not even sure it’s a good one) that I was going to explain in more detail. But then I stumbled across this post and found this statement:
I’ve become a big fan of the “do less & be lazy” approach to building things.
And though the post is about the performance of pages using web fonts, it’s still related to what I want to convey.
All that to say I didn’t have a post, just a statement, and I needed an opener. In reading another post, I found it in the quote above.
Of Principles and Models
Simplicity should be a key goal in design and unnecessary complexity should be avoided.
And it sounds so good in theory, doesn’t it? I mean, it feels like it’s an excuse to be lazy.
But wait. We also have all of these various ways to manage projects, build solutions, and ship projects to our customers, don’t we?
Just off the top of my head:
- the waterfall model,
- rapid application development,
- spiral development,
- incremental development,
- agile development,
- and on and on it goes.
All of these provide a recommendation, a process, or a model for how to take a solution and bring it from concept, through implementation, to delivery.
Sometimes, though, I just get bogged down.
It feels like there are X different models for managing a project and Y different principles to apply and Z different blogs shared on N different Twitter accounts telling me why I need to use [any given technology] over [any other technology] to build my solution.
Unnecessary complexity should be avoided.
But it feels like all we’ve done is introduce complexity while championing simplicity.
The Tension of the Dilemma
There are times where I feel as odds between various ways of working on projects and the principles I want to follow.
For example: Say I want to follow the incremental development model, and I want to apply the KISS principle. Or for that matter, say I want to use any of the available models while keeping in mind the existing principles.
- I’ve also read of the importance of making sure to have a good design for the architecture of a project.
- I can’t have a good architecture for the project knowing the requirements will change as we dig into the problem domain. Nor can I have a good architecture without knowing how people may use the project (be it people who will use an API or people who will use a user interface to interact with the code).
- I don’t want to design for cases that may never be used because I’ve introduced waste into a system that I’ll just need to remove, but I don’t want to build an inflexible system that’s hard to adjust over time.
- I probably should find a way to build something that’s flexible enough to support the addition of new modules but rigid enough to meet the requirements I have (even though they, as I said above, will change).
- I don’t want to ask the stakeholder (or, for those of us who aren’t as much into the enterprise, customer) too many questions because I’ll be annoying or come off as if I don’t understand what I need to build (which might be true, at first, but I have to start somewhere).
- I don’t want to be silent because it seems as if I’m not invested in the project.
This is, you know, while I’m waiting for the IDE to load. So what are we to do?
Finding That Developer Intuition
I know, I know. This seems like a long digression between two completely unrelated points.
So let me do what I can to try to take each and relate them to one another. (I can only help you’ve felt like this before. If not, I’m way off in left field with no clue what I’m doing. )
1. A Definitive Answer
I don’t have a definitive answer.
What I’ve learned, after working with several different languages, sets of tools, problem domains, frameworks, and so on is this:
Two large factors that help contribute to relaxing the points of tension with starting a new project are discipline and experience.
That is, to “do less and be lazy,” takes thousands of hours (or maybe hundreds of hours for the smart people) in a definitive set of tools have to be invested in your work.
In a sense, it has to be earned.
Because the longer you work with a fixed set of tools, languages, and problems in a given space, you begin to develop a sense of “developer intuition” for how something should be designed or implemented.
2. Taking It One Step Further
You have to make sure that you’re actively driving yourself towards getting better at what you’re doing.
This isn’t about finding the next shiny thing. It’s about excavating something new from the stuff you’ve been using for years to make yourself that much more skilled with them.
The more you do that, the harder you have to work to find something new or the more you have to learn about implementing new standards, new patterns, or new architectures.
3. Tension and Intuition Aren’t Fixed
I don’t know if all of the above ever really goes away, but I know that it’s a bit amorphous. What once showed up, say, at the beginning of a project now shows up after I’m months into a project and we all have hit up against something we didn’t previously consider.
And where there once was no intuition, it exists. But now I’m at a new place, and it lacks intuition. So here I am again.