The source content for blog.juliobiason.me
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

52 lines
2.6 KiB

+++
title = "Things I Learnt The Hard Way - Spec First, Then Code"
date = 2019-06-18
[taxonomies]
tags = ["books", "things i learnt", "specs", "code"]
+++
"Without requirements or design, programming is the art of adding bugs to an
empty text file." -- Louis Srygley
<!-- more -->
If you don't know what you're trying to solve, you don't know what to code.
A lot of times we have this feeling of "let me jump straight to the code". But
without understanding what problem you're trying to solve, you'd end up
writing a bunch of things that doesn't solve anything -- or, at least,
anything that _should_ be solved.
So here is the point: Try to get a small spec on whatever you want to solve.
5 years ago
But be aware that even that spec may have to be [thrown
out](/books/things-i-learnt/throw-away), as the understanding of the problem
tend to grow as long as the project continue.
Yes, it's paradoxical: You need a spec to know what to code to avoid coding
the wrong solution, but the spec may be wrong, so you _end up_ solving the
wrong solution anyway. So what's the point? The point is, the spec reflects
the understanding of a problem _at a certain point_: All you (and your team)
know is _there_.
The times I stood longer looking at my own code wondering what to do next were
when we didn't have the next step defined: It was missing some point of the
solution or we didn't have the communication structures defined or something
of sorts. Usually, when that happened, I stumbled upon Twitter or Mastodon
instead of trying to solve the problem. So when you see yourself doing this
kind of stuff -- "I don't know what to do next, and I'm not sure if I'm done
with the current problem" -- then maybe it's time to stop and talk to other
people in the project to figure that out.
Another way to think this: Erik Deitrich have a post about [Don’t Learn to
Code — Learn to Automate](https://daedtech.com/dont-learn-to-code-learn-to-automate/),
something I can get behind 'cause most of us, when doing stuff, think "I need
to do this, then I pick that thingy and put it there and from there I do this
other work". Basically, we create mental models of specs, step by step, on
what we need to do. And, from there, it may be even simpler, 'cause now all
you need to learn is "First, how I do this; Ok, got it, now I get the result
from this and put there" and so on. You can even have a learning path, if
you're a beginner.
{{ chapters(prev_chapter_link="/books/things-i-learnt/disclaimer", prev_chapter_title="Disclaimer", next_chapter_link="/books/things-i-learnt/steps-as-comments", next_chapter_title="Write Steps as Comments") }}