Ryan's Blog

Like Twitter, but longer


Perspectives on code

I’m a developer, sort of. I spend my day working on software products at different levels. My perspective varies from low-level poking around with lines of code to high-level drawing pictures of how applications will talk to each other.

1. Code – writing and reviewing code

I review code, I spend a lot of time in bitbucket’s pull request interface or in an IDE looking at code that someone on my team has written. I also spend time (less) writing code.

2. System Design - how to write the code

As Technical Architect I have some responsibility in what our codebase looks like. I try to delegate this to my team, it’s an important skill to learn (and probably the responsibility of a senior developer). A lot of the time, the low-level system design (class & function naming for example) actually gets done as part of a pull request. Don’t write the application like this, do it like that instead. This is probably a flaw in our process. As a team we’re working on fixing it.

3. Project Planning - when to write the code

I lead a team. We practice SCRUM (sort of). Every 2 weeks we have a planning session where we review what went before and plan what goes ahead. I need to make sure that the team has enough work to do and that our customers and colleagues know when their feature is getting delivered. This means creating JIRA issues, getting them estimated and story-pointed, sub-tasked and scheduled. It means writing reports and producing statistics.

4. Product design - what code to write

Possibly not product design, what I do here is develop user requirements, plan the technical implementations of them and persuade people (developers, customers, senior colleagues) that my approach is the right one.

It’s all programming

The end result is a piece of software. Each level is important and requires attention, but differing amounts and at different times.

The writing code bit of step 1 is fun, the reviewing code is less fun. Step 2 is fun, but would be more fun if it involved less code reviewing and more discussion beforehand. Step 3 is hideous and something to be avoided if possible (it’s not). Step 4 is where the magic happens.