For those who might want to make the leap from Developer to Architect

The last two weeks, actual work has conspired to keep me away from the blog. How rude. I miss "the beach" already.

It seems only fair to summarise the lessons I have learnt whilst masquerading as an architect on a short consulting stint with Marc McNeill. Simon Brown at Coding the Architecture is much better at talking about this stuff than I am, but I need to update the blog with something!

1. Ask dumb questions

Someone's called you in because they want your help, and presumably if their problem was simple they would have fixed it already. You're not there to know everything out of the box, you're there to find out what's going on and summarise it. That means asking questions, even the dumb ones. That's something I learnt off my previous boss.

2. Draw lots of pretty pictures

As a developer, I like to think in code, I like to poke around it to find out what's going on. But if you want to get a feel for the bigger picture, not having access to the code, or even the documentation, could be better. It forces you to look beyond the detail. Sketch things out on the whiteboard to help get the picture of the domain and the systems in your head.

Of course, there's always the worry that your pictures aren't the reality. That's why you need to...

3. Check your theories/pictures/numbers with everyone

In the first week of the engagement I made some assumptions based on the information I had gathered so far. Once I'd run those past the architects and developers really working on the code, I found they were only half the story. The feedback from those guys helped evolve the picture of the current state of play, and shaped the future direction.

4. Take notes

Especially of acronyms used and people's names and roles.

This is probably more a "me" thing. My memory works as an index, so I need the detail somewhere - I can remember I wrote something about something, and where I wrote it, but I won't remember the details. I also find that simply writing things down helps to get it straight in my head. I probably didn't use 50% of my notes, but all that information was in my head.

5. Buy your own whiteboard pens!

I've worked in a lot of places, as a consultant and a permanent employee. And one thing you can almost guarantee is that the pens in your meeting room will not work. Or they'll be permanent.

I also bought a board rubber and spray cleaner, but that's probably my OCD....

At the end of an intense two weeks we had delivered:

  • A picture of the existing architecture
  • Pictures of three phases of future architecture
  • An approximate roadmap for delivery
  • Guide estimates for the stories discovered
  • ...and pages and pages of supporting diagrams and information.

The air in Les Alpes must've helped get the brain moving! Of course, I took my camera on my little jaunt to France.

It was a great first role for me at ThoughtWorks. I worked my socks off and thoroughly enjoyed it.


  • Trisha Gee

    Trisha is a software engineer, Java Champion and author. Trisha has developed Java applications for finance, manufacturing and non-profit organisations, and she's a lead developer advocate at Gradle.

    View all posts