DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 967,611 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for Inking and thinking in software project
Aga Zaboklicka
Aga Zaboklicka

Posted on

Inking and thinking in software project

This post was originally published on my Jump Start blog

It's not the ink–it's the think

β€œIt's not the ink–it's the think,” wroteΓ‚ Robert Mankoff (New YorkerΓ‚ cartoon editor), answering to the question how to get ideas for cartoons by people who want to submit them toΓ‚ The New Yorker. "There really is no trick–you just have to think of them" he said.

It's the same in creating a software.Γ‚

Turning Problems into Code

Writing the actual code is only a small part of the process. Opening IDE to bang out a solution upfront is rarely the case. First, you have to understand the problem and break in into pieces. After some time you will start to see the patterns and solve the problems without too much thinking about them, but even then the more complicated tasks will require quite a think.

Understanding the Problem

I like to write down the problem.

I draw it on a whiteboard or on a flipchart. It gives me space to think and write extra ideas or different approaches. I see the dependencies clearer this way. When working on the complicated task IΓ‚ ask myself: What do I know about the system that it's about to be built? What should be built? What goes inside and what's the expected outcome? How it connects with the existing system.

In enterprise projects, you usually have user stories, requirements etc that help you answer those questions :)

Breaking complex programs into pieces

Smaller features are easier to manage. Easier to test. Easier to write. So think in small batches. Complex applications are composed of smaller programs working together.

Driving Design with Tests

Think of the result from the start is one of the best software development practices. Developers do this usingΓ‚ test-driven development, orΓ‚ TDD (see more in Google).Γ‚

Writing the Code

Figuring outΓ‚ whatΓ‚ you want to write before you figure outΓ‚ howΓ‚ to write it seems an obvious first step. But many developers take a shortcut. They charge straight at the water and dive deep to get out of breath pretty soon.

Taking the time to design the program speeds things up in the further development. A poorly designed code is hard to maintain and extend.Γ‚ The untested, unplanned code in production, requires painful changes to it later.

And who likes to do the maintenanceΓ‚ only?

Top comments (0)

DEV has this feature:

Settings

Go to your customization settings to nudge your home feed to show content more relevant to your developer experience level. πŸ›