RHT: How to Become a Software Architect

by Jacques Daniels  Robert Half Technology
May 6, 2014


Becoming a software architect requires more than just the technical skills to do the job.

The future for software architects looks positive. According to this article, demand is increasing. But how do you become a software architect?
Whether you’re a recent IT graduate interested in breaking into the field, or an experienced software developer who wants to make the transition to software architect, this interview is for you.

I met Jerry Clinesmith, software architect at Koen Health in Dallas, earlier in my software development career, and he’s been in the IT field for close to 20 years. I had the pleasure of working with him and owe him a great amount of gratitude for mentoring me. He’s one of the best software developers and software architects in the business.

Our interview is divided into two parts: In part one, we discuss making the transition from software developer to software architect. In part two, Jerry offers some software architecture best practices. If you have any questions, don’t hesitate to ask in the comments.

Q: How did you get your start in programming?
In middle school, my parents gave me a Commodore 64 with a modem and I got really into bulletin board systems. I wanted to run my own, but I liked GBBS, which only ran on an Apple II. I was able to get a BBS package for the Commodore and decompile it back into BASIC. BASIC is straight-forward enough to teach yourself, which I did. I spent an entire summer modifying the software and put up a BBS that looked like it ran on GBBS.

After this experience, I was hooked! I took the one programming class offered in high school, and majored in engineering/IT in college where I was exposed to COBOL, Java and Visual Basic.

Q: What’s the largest software team you have worked on?
Not that large – probably 15 members with project managers, business analysts, developers, QA, documentation/training and operations/support. It was a multi-year waterfall project and became a bit of a death march at the end. After this experience, I definitely favor small, coordinated teams – they can generally react to change faster and be more productive because of the lower overhead of coordinating so many people.

Q: What are your favorite programming languages?
This changes over time, but currently:

1. Ruby: It’s the most expressive language I’ve ever used, and a pleasure to read and write.
2. Go: It has some quirky syntax, but it’s great at concurrency and very quick to write and run. It’s small and compact and good fit if you’re working “in the cloud.”
3. C#: If it had been written to support other operating systems besides Windows from the start, I think it would have surpassed Java.

Q: How did you decide to become a software architect?
It wasn’t something I decided, per se. I kept pushing to get better, learn more and take on more responsibility. One day my title changed to architect, but I felt like I was doing the same job I had already been doing for years.

Q: What tips do you have for others who want to become software architects?

• Try to work with people better than yourself. Read their code, look at their designs, question their decisions and absorb as much information as you can. Keep looking for mentors: in-person is best but books, blogs and social media also are great ways of finding mentors.
• Teach others. If you want to learn something really well, teach it to someone else. Blogging,pair programming and whiteboard design sessions are all good ways of teaching. It’s counterintuitive, but you’ll receive way more than you give.
• Be willing to take responsibility. When the next project comes up, ask to take the lead. It shows you have initiative and that you’re willing to do more. Learn the strengths of the people on your team, and work to make them succeed.

Q: What new processes did you have to learn?
Technical skills:

• Be able to model your ideas. Whether a UML document or the back of a napkin, you need to be able to describe the major components of a system and explain them to a 10-year-old. If you can do that, you can describe it to a team of developers or your CEO who’s never seen an IDE.
• Lead by example. If you’re still coding, work responsibly. Follow coding conventions, write tests and document your work. I’ve seen architects who take the “fun” parts for themselves, and throw scraps to the rest of the team. Remember everyone wants to be proud of their work and learn, and it’s your responsibility to help them do that.

Non-technical skills:

• Be able to communicate ideas to both technical and non-technical people. I’ve worked with amazing engineers who simply can’t explain what they’re working on in a simple, straightforward manner.
• Strive for empathy. Put yourself in the other person’s shoes, and try to focus on solving the problem in front of you. Too many developers feel “superior” to non-technical colleagues, and they come off like immature and inconsiderate. Educate without being condescending, and listen to what others have to say. The best ideas can come from anyone in the room. This is a good article on the subject.
• Watch presentations. Attend conferences, or watch them online (YouTube, InfoQ andConfreaks are great sources). Notice how the best speakers make the talk interesting. They’re not just reading the slides; they’re engaging the audience and telling a story. An architect has to “sell” their vision to the company’s leaders – and they tend to be people with little time and short attention spans.

Q: What advice would you give to a mid-level programmer whose eventual goal is to become a systems architect?
If you’re the smartest person on the team, seek others to work with. Look for talented developers/architects that are willing to mentor and absorb as much as possible. Also:

• Read code. Open source has made this so easy – find projects you’re interested in and study the code. Look at how things are broken into classes, access patterns and overall structure of the project.
• Write code. The only way to get better at coding is doing it. I’ve found that a good practice is to take a single idea and rewrite it using different styles, languages and techniques. Write it once using classes, another in a purely functional manner and as many ways you can think of. You’ll learn what works best and how to solve problems in different ways.
• Build bigger things. Look for projects that challenge your current skills. It’s easy to do what you know, but it won’t help you grow. An architect needs a wide variety of skills: front-end, back-end, distributed systems, operations and all the options around data storage. Test new technologies thoroughly before bringing them into projects – it’s easy to follow the latest fad, but make sure it’s really going to help your project.
• Meet people. Attend local user groups and conferences, talk to other developers about what they’re working on. You never know where the next opportunity could come from.
• Have a side project. Make a website out of your favorite board game, or just build something that you wish existed. It’s nice to have a project that you can go to for trying out ideas, new languages, frameworks, etc. The best (and worst) part of software development is that there’s always something new to try.
• Be open-minded. Constantly question what you know and look for ways to improve.

Have you made the transition from software developer to software architect? Share your tips on how you made the change in the comments.

Also be sure to look for part two of my interview with Jerry – he’ll give some best practices for software architects and talk about the development process.



— Jacques Daniels

Jacques Daniels wrote his first program at the age of twelve, and that’s when he decided he wanted to be a programmer. He worked at IBM his last two years of high school, where he honed his computer and programming skills. He is a Robert Half Salaried Professional who has spent over 13 years developing .NET applications for companies in a variety of industries.