It comes up now and then — the topic of developers and those who are not. Mario Peshev had written about calling yourself a developer and the impact it has. Every time there is a certain amount of backlash from people who feel they are denied the label unjustly. What makes a developer? What makes them not a one?
Growing into a developer
Much of the issue comes down to not knowing what you don’t know.
By now I had wrote programming code for over two decades. I had solved problems with it, released it as open source, got paid for it.
Yet most of these years I had resisted when I was called a programmer or developer. Despite possessing of the aspects I had felt a certain void to be further filled.
As code became more centric to my occupation I read more of it and spend more time writing it. Not more time to write more code, but more time to write less.
That pushed me to make some qualitative jumps in how I do it. And then reflect on them and how it pushed me to (finally) grow into a developer role.
Towards complex thought
Programming is explaining computers what to do.
The textbook definition. It is as complete as saying that flying to space is achieving escape velocity. Quite a few details omitted.
I think a a more complete definition would be:
Programming is thinking what computer should do and expressing it in a way it understands.
We mistake this for easy since we are capable of thinking and expressing thought. What we miss here is a rift between capability to write and being a writer.
As we tend to have a lot of exposure to both casual and involved writing, we grasp distinction between the two. Even when we don’t ponder into details of that distinction.
As we start writing code our exposure to it is much lower at start. So it is easy to miss distinction between actions which we call coding and development.
To be a developer in programming is to be a writer, not to merely write.
Towards simple thought
Algorithm is a series of exact steps to solve a problem.
Another textbook definition and another mental trap that can take years to get out of. As we progress to complicated problems we presume to need complicated thinking and expression.
Several years ago I had opened code of a major open source project and was a bit shocked by primitive code. But then… Would I prefer an overcomplicated mess?
The development needs to focus on reducing and managing complexity, never ever increasing it. The concepts and practices of abstraction are fundamental to that. And are another skill that takes a while to pick up.
Algorithm is a series of necessary actions, taken on appropriate abstractions.
Abstraction moves complexity from taking over the thought and dissolve it into interaction of simple parts.
The abstraction is important to collaborative aspect of programming world. Once you get used to simple parts you get the reason for that library–driven landscape of programming.
Once you think in abstractions — not all need to be created by yourself. They are open for collaboration and can be combined with work of others.
Conversely staying in comfort zone of your own code holds you back, captured in giant monoliths of thought.
In a list
I think what makes a developer and sets one apart is:
- Mental discipline to think through problems and solutions.
- Mastery of programming language to express your thinking.
- Understanding abstraction — its importance to manage complexity, nuances of its possible manner and depth.
- Skill to create well abstracted programs and components.
Are there more things? Likely. I will know when I learn them. :)
David Coveney #