In this post…
Growing up, I didn’t know what being a software engineer was, or what I wanted to be. However, I knew I didn’t want a “square” job (by that, I mean a very rigid job with no place for creativity). Engineering was actually inside that square, but don’t tell anyone!
If you’ve read my bio (if you haven’t, I warmly invite you to do so by clicking here), you’ll know that I dipped my toes into Architecture before getting my Industrial Electronics & Automation degree. What I didn’t know as a child was that there is beauty and creativity in engineering, and very specially in software. This is probably why I feel so passionate about creating intuitive front-ends and I care so deeply about user experience.
But let’s go back a few years, before these realisations slowly dawned on me.
I used to think being a software engineer meant coding all day.
Do you have a problem? I’ll open my IDE and write 100 lines of code to solve it.
Then, I started my career in software development. And, even though there is people who do exactly this, jump onto coding as soon as they hear of an issue, I realised something:
Writing code without understanding why is like running a marathon without knowing where the finish line is.
You’re moving fast, but you’re probably lost.
That’s why, when presented with a problem, my approach is different:
I pause.
I think.
I ask the sometimes uncomfortable questions (remember the W- questions?):
What are we trying to achieve?
Which problem are we trying to solve?
Why is this important?
Who is going to use it?
When and in which conditions will they access it?
How will they access it (desktop, laptop, tablet, mobile phone…)?
Discovering the answer to these questions means you’re halfway there.
I make a plan.
I sketch / build / wireframe a first idea.
I validate it, ideally with end-users, product owners or stakeholders.
If it still has friction points, I iterate it until it works.
Only once something proves useful I build it properly (ie. I write the code).
And because they say an image is worth a thousand words…
The key takeaway
Engineering isn’t about the number of lines of code, but the human problems we solve with them.
Summary
The “code-first” approach
- Get a ticket.
- Open IDE.
- Write code.
The “design-first” approach
- Pause and think:
- What is the core problem we are trying to solve?
- Why is this a priority?
- Who is the primary user?
- In what environment / device will they access it?
- What is the simplest valuable solution?
- What are the non-negotiable constraints?
- Plan what to do.
- Sketch a first solution.
- Validate it solves the problem.
- If it doesn’t, go back to step 1.
- Open IDE.
- Write the code.
Note
This reflection originally sparked a great conversation on LinkedIn. If you’ve ever felt like you’re running that marathon without a finish line, I’d love to hear your thoughts.
Disclaimer
I understand this SDLC (Software Development Life Cycle) is ideal and, sometimes, real-world constraints mean we can’t iterate as much as we’d like. That’s fine. Just keep in mind that jumping straight to coding might seem quicker, but will eventually set you back.
Leave a Reply