Inverting the Strategy: Think-First Development vs. Code-First Development

There are a million differentiators between juniors and seniors (sidebar: if you’re a junior looking to level up, check out this awesome list of tips) but in my experience the biggest one is how they approach the creation of new features. In a nutshell, juniors jump right in and start coding. Seniors think about the problem thoroughly and plan their approach before ever writing a line of code.

Making messes is fun (but risky)

Back when I was in college and I billed myself as an “indie developer” (that’s code for junior) my coding style was very experimental. I would take a given set of requirements, write a bunch of code really really fast, throw it at the wall and see what stuck, then iterate off of that. Rinse and repeat. And, I have to admit, for smaller projects and scrappy startups, this strategy kinda works. It’s also really fun, and it’s still the style I use for hackathons and some personal projects.

But it’s becoming rarer and rarer that I work on projects that can support this workflow. There are side effects to experimental, code-first development that may not be immediately apparent:

1. Rapid coding is a hair’s breadth away from sloppy coding. When you’re coding quickly without much forethought, you forget about important things like security concerns and strict input validation.
2. When coding this way, it’s easy to forget the fine details of requirements and code yourself into a corner without realizing it.
3. And, perhaps the most serious problem of all, this often leads to snafus that make their way up to production where your users can encounter them.

Now, I’m not perfect, and old habits can die hard. So sometimes I still catch myself developing this way. However, nowadays I’m using a new strategy which I call think-first development.

Planning is less fun (but less risky)

Here are the principles of think-first development:

1. It is essential to understand the entire scope of the problem prior to beginning development. That means all inputs and outputs, edge cases, use cases, and dependencies.
2. Talk about, think about, and ask questions about the entire system until you understand it as well as you understand the programming language(s) you’re implementing it in.
3. Documentation of the above two steps is beyond important, it’s essential. If you skip this step and keep all the design information in your head, you’ll forget and fall back to quick-and-dirty.

Understanding the full problem scope

Ah, the age old question. What problem is this system going to solve, and how will it do that? This can range in difficulty from very easy (like coding a login page) to incredibly difficult, sometimes impossible for a single engineer (like the Bloomberg Terminal). I’m going to skip the part where I explain how I’ve come to understand how to understand problem scope, because many have blogged on it and it basically boils down to this:

Ask “why?” and if you’re still confused, ask “why?” again. Ask “why?” until you can’t anymore.

Every three-year old ever, and also smart engineers.

The key takeaway here in the context of this post is this: do NOT write a line of code before you fully understand the problem scope. If you don’t, you’re walking blind into a potential minefield of issues. (experimental code is fine, but no pushes!)

Talking about the system

Everybody has a different perspective, and the job of a senior designing a new system is to take all of these perspectives in, discard the ones that don’t make sense, take pieces of the ones that do, and combine them into a cohesive whole.

I want to be sure I drive this point home since it’s so important: everybody has a perspective, from the juniorest junior to the brand-new BA to the seniorest senior. Now, as may be obvious, there is a lot of lift and noise in involving everyone in the discussion, and often new features don’t have enough lead time to accommodate this level of investigation, so take it from me: the best method for gathering a collective set of opinions is an open forum. Get everybody into a room/Zoom and start asking questions and generating discussion. Don’t forget to set up follow-up sessions if needed!

Don’t write code until every possible avenue has been explored and either considered or discarded. Everybody has an opinion, but a smart engineer knows how to sift through these and come up with a cohesive design plan!

Document everything, and document some more

I really wish I could share with you my latest system design document, because it’s really a work of art! Many hours (OK, forty) were put into creating it but it’s client-specific and I’m not in the business of leaking IP. Here’s what I’m going to do instead: below you’ll find a list of the key sections that I write when I create any standard SDD (System Design Document). Each has many, many subsections specific to the project or feature I’m designing. Also, images, links, blurbs, pseudocode, anything to demonstrate a key understanding of what will be developed.

• Guidelines – What are the core tenets of the design of the system? Things that should never be violated.
• User Stories – Which stories (link to tickets) are going to makeup the work?
• High-Level Plan – What are steps 1, 2, 3, 4…of your design? Rough outline only.
• Ticket Flow – Which ticket will be worked on first, second, third…?
• UI/UX Summaries – Include mockups and screenshots.
• API Endpoints & Integrations – Which 1st- and 3rd-party APIs will be called?
• Required Architecture – Which components will be required in the system?
• Open Questions – What are the outstanding questions about the system?

Sidenote: I have an article in my backlog to write about the Power of Not Knowing. Stay tuned!

Jamison

This document is so, so critical to the successful development of the feature/module/system. It should be the first document you create and the last one you save before actually starting implementation. I’m not messing around on this one! Skip this step and you’ll regret it 😉

Conclusion

The key point that I’m trying to get across here is that juniors jump right into coding and make mistakes. Seniors take time to think about the code they’re going to write before writing it. The difference is that the seniors will have a fully-mapped-out mental model for the system prior to building it, and the build takes infinitely less time than the scrappy, build-as-you-go model that is favored among those with less XP.

That’s all for now. If you have links to cool SDD’s that you can share, by all means drop it in the comments!