I am in the early years of my career, and I know my goal but I'm still working out how to get there. If you have insight into one of the varied career paths that lead to Software Architect, I'd love to hear it.
To be clear, I know there's no "do XYZ and you've made it!" I am looking to collect stories and experiences to serve as points of reference as I move forward in my career and evaluate things like skills, languages, and tools to learn and use. I appreciate your input!
Top comments (14)
This post gets you up to the point where I started programming professionally. The TLDR is that I took a long time to finish school and worked in between. I developed some web apps, but didn't like programming. I was more interested in ops and networking. But my first job after graduating college turned into full-time programming after about a year.
I got to do interesting work in my first full-time programming job. I built a system to collect and validate records from all the two-year colleges in the state, so the state could meet reporting requirements. The fun part was the back-end service to pull and process those records and run validations. It was multi-threaded so it would process multiple kinds of data at the same time. But some of the data was dependent on others. So, I essentially got to write a multi-threaded, dependency-aware queue system. It ran on a schedule, but a college could also trigger the data to be re-imported ad-hoc. I also did the web UI with logins for colleges and state. At some point I found out I was drastically underpaid, but I was having a blast and learning a lot so I stayed anyway.
Eventually, it worked well enough that they stopped letting me play with the back-end and the only work I had was writing reports. This is misery for my builder personality, but before I figured that out I did a lot of yak shaving and exploring other techs to quell the boredom. I was the first full-time dev there, but eventually more were hired for other projects. So I did a few lunch n' learn sessions on techs that we weren't familiar with. I researched a lot of design principles too. (Though inexperience blinded me to the value of some of the good stuff initially, or sidetracked me into wasting time on niche tactics.) Eventually, I figured out the source of misery. I asked to be moved to another project, but apparently all the programming work they had available was reports and more reports.
About midway through my 6 years there, I had the inkling that I would like to get more deeply into software architecture. By the time I left, my resume cover statement was "Turning the corner from coder to architect." I knew I wasn't there yet, but I had a strong interest in that direction.
My next job was as a lead in modernizing a business-critical internal legacy app. It was my first time working in a team of 4 and using scrum, and I was leading the modernization effort. So my boss took a risk on me, but she said she was glad to have done so. Turns out I'm not too bad in a team (a pleasant discovery for me as well, being an introvert), and I ended up incrementally rewriting the majority of the system in under 2 years. The other dev mostly specialized in other things, but she waded in there too at times. I got to try some design and architecture bits and bobs along the way. And I never stopped pressing forward on learning architecture and design, often in my spare time.
I was also very fortunate to be co-located with the UX department. Not only were they fun people, but I really latched onto user experience as an important feature of any application.
Eventually the rewrite was done "enough" and the business wanted to switch focus on a deep integration effort with another product. I really liked my team, and I was not looking for another job. Nonetheless, I was asked to come back to a place I had previously worked in college. It was to help modernize their legacy system -- a monster which I had helped create years ago. Only this time I would have carte blanche on technology, architecture, whatever I wanted. I declined the offer at least once. But ultimately I made the really tough decision to leave, after 2 years and change. And initially the plan was to leave for a few years to help out that company and then go back to my previous company. (Believe me, I asked to make sure that was a thing.) That brings us to where I work now.
When I first came back on board 4 years ago, the plan was to do a big bang rewrite of the system. In the back of my mind I knew it was a bad idea, but there was general agreement that it was the best plan. It was also a siren song to start the architecture with a clean slate. However, since I had been gone the system had become pretty sprawling with a lot of apps integrated through a database. As I developed the new system, it became harder and harder to understand how we could possibly migrate to it from what we had. Eventually, the executives got tired of not getting business value from my expensive salary, and directed me to fix some really painful issues in the legacy app for a while. It was after that point, my manager and I agreed to abandon the rewrite. Instead we started implementing the good things we learned from the rewrite into the existing system. We made a lot of positive changes to ease pain for various users. (And we still have a lot of work to do, but we can at least see a path forward.)
The next series of events is pretty fascinating. I was really yearning to get more architecture experience. To recap: I was only supposed to be here a limited time. The original reason I came fell by the wayside. So, I figured they would let me go to hire a less expensive person to keep working on the system. I even told the director that at my next job I was ready to lead a team as architect. Not long after, several customers independently began asking us to develop a new product that wasn't directly related to our core business. My (hindsightedly stupid) advice to the director was "No, we aren't a software dev shop." But they persisted and we agreed. I picked the tools we used, and designed the multi-tenant architecture for the cloud. I hired 2 devs with no experience and trained them (mostly giving them time to explore). We lost one dev to greener pastures after a couple of months, but made our first MVP release in 6 months. Almost a year and a half from the start, we have a pretty decent offering, and we are talking about making it publicly available (so far we have gotten business through person-to-person pitches to industry contacts, and word of mouth). I'm getting around to implementing arch changes that I had planned but lacked time to do initially -- especially to enable scaling the infrastructure and our team. Other products are already in the works... looks like we might turn into a dev shop yet, and I might never leave.
We've used some of the same tooling and infrastructure from that to rewrite or add to some of our internal apps as well. Making them worlds better in function, stability, and appearance. These changes have been a big hit with our users and customers.
Of course, that's the sunshine and rainbow highlights. There's also the overwhelming stress of being responsible for the success or failure of the technical aspects. The nights and weekends reanalyzing your decisions for holes or researching for that next step or that missing piece you haven't nailed down yet. Sometimes I want to quit and go dig ditches for a living. :) And I by no means consider myself a seasoned architect. Although I studied the research and theories surrounding it for years, I've only made a beginning in the practical application.
Hope that helps.
wait i already do this - "The nights and weekends reanalyzing your decisions for holes or researching for that next step or that missing piece you haven't nailed down yet" 😬 heh.
thanks so much for sharing, this is a very colorful path and had some unexpected pieces in it. i love that your company worked its way to abandoning the rewrite, and incorporated what you had learned into improving what you had. rewrites have their place, but replacing sprawling legacy apps is a lot tougher than people give it credit for!
I'm not sure about your situation. But for me, I never got the opportunity to be a "junior" developer and have someone else be ultimately responsible. There was no one else available but me in most places I worked. So, I also felt this way throughout my career... that if I didn't get it working, the effort would fail. It's not so bad as a solo developer on a single app here and there, but I find the stress much greater when my decisions play a part in company strategy and people's careers. To be honest, I find myself in paralysis sometimes... endlessly researching to get a picture of how every corner of the architecture works together before I even take a step. In particular, I try to thought-experiment each detail to uncover the obvious trade-offs as early as possible. But time being finite, I often have to move forward with my best guess. I need to rediscover the playful attitude with which I approached this stuff earlier in my career to make it more fun. Although it remains intensely satisfying to have created something that works well and meets a need.
I believe that large spaghetti systems make it nearly impossible to justify a big bang rewrite. There is just no way to account for all the side effects that are baked into the system. (e.g. App A depends on App B setting some data, but only sometimes.) The new system will miss a lot of edge cases because they look like accidents and noise. Therefore the cost of creating the new system also extends to adding missed edge cases for a while after it is first deployed. And that only gets you back where you were before the rewrite, with maybe a few new things added. Plus your users are angry with so much change at once. The right way is to carve off pieces of the system. That gives you a chance to dig into that area and talk to your users. Then you can not only modernize things, but you can also add value while you do it, and let users adjust in small increments. That piece gets deployed separately and its responsibility removed from the legacy system. Rinse and repeat. Smaller is easier to throw away and rewrite.
this is similar to my experience so far. at my last job i was a team of one. i had people i could pester with questions, but they were on a different team (read: under a different cost-center in the company) so questions were definitely not encouraged.
at my current job, i'm largely independent again (although my team is fantastic!). i'd love to be in a situation with more expected collaboration. so maybe these experiences can actually be good things :)
Damnnn. Great comment.
What a story!
I dropped out of college for a startup job where I discovered an aptitude for and an interest in SQL and wound up designing databases and developing data access layers and application frameworks. Relational algebra and object-orientation are very different ways of thinking about systems, which made for an early introduction to working in broader contexts. It definitely didn't hurt matters any that we used a data mapper instead of an object-relational mapper which attempts to hide more of the inner workings of the database. Also helpful: I was responsible for managing the build server.
I've had more jobs and learned more languages and frameworks and worked with more databases and build tools since then, but that's what I started with. Getting a broader view is useful, but there's more to it than just adding keywords to your resume. Each and every new technology you learn is a new way of modeling something, a state or a process or both (and if it's only one, that's making significant implications about the other aspect). Software architecture is about understanding these models, getting a sense for how to use them effectively, and putting them together to achieve your own goals. The best stuff I've read on the subject has been about semiotics and meaning-making and so on, not about programming languages or design patterns.
love this "Each and every new technology you learn is a new way of modeling something."
this is really helpful, thank you for sharing.
After a degree in electronics I spent a lot of time in my early programming career challenging my technical ability, trying to do 'hard' things (and failing occasionally!), like writing Win95 VXDs, or IPX network emulation (don't ask). This taught me the value of asking for help from both colleagues and experts elsewhere (in my case Usenet, it was the 90s). Usenet taught me empathy and giving back too, once the flaming died down a bit!
At the time I was working for a large org, and didn't feel responsible for very much. That all changed when I moved into a start up and challenged my overconfident ego as the 'lead developer' of a commercial video gaming service with demanding users, no longer backed up by 1000 ops guys, I was on call! Now I would define the role as 'architect' but it wasn't a common term then. This taught me pragmatism, the value of home life (by not having one!), and exposed me to real business needs, mostly short term survival, but needs all the same.
The start up crashed and burned (not my fault I promise), and I joined a consultancy firm, taking on smallish project development under contract or staffing technical leadership roles in other organisations. This was another exposure to business and contract negotiations, I also saw a number of development methodologies come and go, and the birth of agile. My interest moved from purely technical to include teams and people, I started questioning why work happens in certain ways and if technology can help or hinder that, I developed a more questioning philosophy and became more comfortable with the grey areas.
Another career change saw me working as a security analyst / reverse engineer, an excellent way to see lots (millions of lines) of other people's code, take it apart and understand it, sometimes better than they ever did. I also had to work with a wide range of languages, operating systems and hardware. This broadened my technical ability a great deal, as did working with and being mentored and challenged by superb colleagues.
Most recently I've been working as a 'Technical Architect' (aka, not an Enterprise Architect :), my first role with an architect title, enjoying the wide-ranging challenges within a business that is growing up from medium to large, providing as much mentoring, communication and technical support as I can, while still learning about architectural thinking from good communicators such as Martin Fowler and Kelsey Hightower (to name but two) and attempting to put the saner stuff into practice, such as Evolutionary Architecture, Consumer Driven Contracts, etc.
hmm i have not yet considered the different types of architects (enterprise vs technical, etc). thanks for mentioning that.
how are you finding the transition from medium-to-large company so far? i've only ever worked with small-to-medium companies. mostly under 100 people, although there was that one that was in the 500-1000 range. do you manage a team in some capacity in your role? if not, what is your relationship to peers and people you report to or who you depend on for work?
Personally I would be careful with salami slicing the role of an architect, I mentioned Enterprise Architect in passing as it's typically the only non-technical use of the title, and sometimes derided as such (my apologies to any EAs reading!). Here's a nice take on what architecture looks like from Brian ONeill: brianoneill.blogspot.co.uk/2014/01...
The transition from medium (<100 technical staff in one building) to large (300+ globally) has growing pains, mostly around growing financial accountability still being managed using 100 year old structures, while we try to adopt more agile working processes, an excellent series of blog posts on this difficulty by Leon Tranter: extremeuncertainty.com/category/ma...
I don't line manage a team (I turned that role down, not my idea of fun!), however I do mentor anyone interested in areas where I am the local 'expert', including hopefully my own role so I can retire in the next few years! My relationship with other people across the business is pretty much how Brian describes it: "the role of 'architects' is to collect, cultivate and champion a common architectural approach". So I focus on communication, being directly involved in technical work (code review, security design, etc.), building my reputation and trust with teams who are then happy to share their experiences, good & bad. My colleagues & I can collect and consider these experiences (in working groups, guilds with all interested parties), before championing what we believe are the good things. Hopefully the groundwork pays off and teams will trust us, working for the common good of the business, and everybody gets their pension payments. Sometimes I think I'm engineering people more than technology :)
When I realized I wanted to become a Software A̶r̶c̶h̶i̶t̶e̶c̶t̶ Custodian. Trying to sweep together the best ideas from all sources.
Excellent background from Brian O'Neill
Software Architect = "management/product says we want this, so just make it happen"
At some point people trust you but don't understand you. That is the senior level. Your accountability is to the project, timeline, budget, and personnel involved.
Other valued skills include coaching, interviewing, leading, speaking, etc.
yes to the "other valued skills" part! in considering career goals, i knew i didn't want to into "pure" management - i wanted to stay technical. at the same time, i do have strong skills in leading, speaking, and coaching. i see a software architect as a way i can advance in my craft using both my technical and non-technical skills.