DEV Community

loading...
Cover image for Stop, Think, Code - Iterate

Stop, Think, Code - Iterate

dvddpl profile image Davide de Paolis ใƒปUpdated on ใƒป2 min read

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.

coding like crazy

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.

weeks of coding can save us hours of planning

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)


Photo by Matthew Henry on Unsplash

Discussion (3)

pic
Editor guide
Collapse
bananbe profile image
Mateusz

Nice post, I totally agree with this approach. Everyone should be reminded about that from time to time.

Collapse
themichaellamb profile image
Michael Lamb

Thanks for this! I absolutely agree that there is great value in planning the work you want to do. It means I get to put my whole effort into it.

Collapse
ca55idy profile image