Stop, Think, Code — Iterate
We are developers. We like to code. We like to build things. We like to immediately give shape to our ideas and see the outcome of our poetry.
That is why it is so difficult to really spend a reasonable amount of time planning and designing the implementation of our features.
In the past, I was using UML a lot to represent the architecture of our OOP Designs.
In this era of a more functional programming approach and of serverless things, I find myself using more mindmaps and flowcharts to show the relationship among the different parts/services and I rely heavily on Test Driven Development.
Since everything is split into smaller pieces and tiny methods that do simple tasks, don’t rely on external state nor mutate external variables, and are then composed to accomplish a bigger and more complex task, TDD is easier.
And even more important, because it gives you immediate feedback of what you are doing — and you can correct before its too late.
Test setup and tear down are too complicated because we need lots of arguments in our method? Probably we are doing too much in it.
Mocking is tedious and too elaborate? Probably we have too many external dependencies in our function.
I will write more about TDD in the future — actually I am preparing a talk about it which I´d like to give at a Meetup sometimes ( public speaking is in my 2019 goals ) maybe I could post the script or the recording of it.
What I´d really like to point out here is how essential is to stop and think before rushing into coding.
We need to remember that (does not matter if junior or senior ), and we need to do that often along the way. To reassess that we are implementing the right things in the right way.
We need to be aware of that and force ourselves, hold ourselves from the mistake of rushing into the flow only to see hours or weeks after that we implemented the wrong thing — or we overengineered — or we focused on our — wrong — assumptions regarding a requirement.
It does not matter if you believe in the 10X Developers or not.
A good developer does the right things in the right way. He/she is efficient AND effective.
Spending lots of time writing performant code which is 100% unit tested, but does not meet the acceptance criteria is quite useless (and stupid).
Unfortunately — during my career I saw many cases where we realized only at the end of the sprint that we failed because the developer was too shy — or arrogant — or fearful of critics — to organize a code design meeting or simply too “nice” or lazy to bother the stakeholders with further questions to better understand the requirements.
So before coding: Stop — Think — Iterate ( and Aks questions and TDD along the way)
Originally published at https://dev.to on May 8, 2019.
