Software architects are typically considered the apex of a software developer’s career. In order to understand what they do, it helps to trace an architect’s journey from the beginning.
But like any other profession, it can be a long and arduous journey. And in many cases, it may not be the desired career goal for many software engineers.
As the old saying goes, “the journey of a thousand miles begins with a single step.”
There are various stages a person usually must go through in order to reach that pinnacle of software architect … assuming that is the final goal.
If I had to break it down into discrete milestones, I’d probably break it down to the following:
- Apprentice programmer
- Senior programmer
- Technical Lead
- Software architect
Of course, there are many synonyms and alternate job classifications than the ones I’ve listed here, but the concept I’m trying to convey here it takes increased TIME, EXPERIENCE, KNOWLEDGE, RESPONSIBILITIES and last and certainly not least, SOFT SKILLS, to attain that final career milestone of software architect.
The apprentice programmer is generally the starting point of a software developer’s career.
It may seem a little strange, but even as it’s considered the most junior and least experienced programming position, it’s probably one of the most challenging positions to acquire.
I’m referring to the “getting your foot in the door” syndrome. That is, getting your first professional programming job.
It happens in many ways. Lots of students who graduate with classical computer science degrees, get grabbed right after receiving their diplomas, to big companies like Microsoft and Google.
Others take advantage of company internships sponsored at many companies, which in turn, become full time programming positions for these interns.
Still others, like myself, get our “foot in the door” in other ways. I started out in a tech support type position, doing customer support for internal corporate employees. The technical and soft skills I acquired in that position, helped me land an entry level programming position within that same company.
Apprentice/entry level programmers have an exciting journey ahead of them. First, there is the newness of learning your way into your technical domain. You probably have already acquired book learning of your particular programming language(s), but your first programming job is where the rubber actually hits the road, so to speak.
Entry level programmers begin to apply what they’ve learned in school and books to real programming duties. It’s here where the art of learning to work with others, both technical and non-technical, come into play.
Junior programmers often work in tandem with a more senior programmer or programmers, who guides the junior programmer.
It was a very heady time for myself. There was always something new to learn at every corner.
If there’s one thing I’ve learned from this phase in my programming career, it’s to strive to maintain the passion and sense of wonder I possessed when everything was fresh and new.
The Senior Programmer
Assuming a junior apprentice programmer sticks it out and decides programming is a career goal, given enough time, the junior programmer eventually becomes a senior programmer.
The difference between junior versus senior programmers isn’t just a matter of seniority.
The senior programmer is expected to have a firm grasp of their technical expertise. Senior programmers are also expected to know the business domain where they work as well.
Senior programmers will often work closely with either product owners (if the organization they work for, practices agile/scrum) or business analysts (if the organization practices waterfall development methodology).
In general, the senior programmer is expected to “step up their game”. The learning never stops either. Senior programmers continue to strengthen their technical skills, keeping abreast of the latest development in software development, programming languages and frameworks.
The Team Lead
The technical team lead raises the expectations of a senior developer. The technical team lead, just as the title suggests, is actively involved in leading other team members of a software development team.
Not only is the technical lead responsible for her own work obligations and duties, they are also responsible for making sure their immediate team is successful as well.
That can mean helping other developers out when they need technical assistance.
The software architect is just about the end of the line for someone who wants to stay on the technical track.
The architect is responsible for worrying about technical needs of the entire company or organization she works for, and less about any one specific team.
Technical needs on the organizational level usually transcend specific project needs at a team level.
Things like what kind of programming language and framework should the organization use? .NET? Java? LAMP stack? MEAN stack?
What kind of database? Relational? NoSQL?
If there’s going to be mobile development, what mobile platform? iOS? Android? Microsoft?
In an enterprise business environment, software architects often wrestle with INTEGRATION.
What I mean when I refer to integration is connecting disparate systems and applications together to work as a whole.
Over time, companies either build or acquire existing software systems that help the company achieve their business goals and strategies. The problem is not all the software and systems are compatible with each other.
Architects often get involved in figuring out the best way to connect incompatible systems together. Often this involves the use of REST APIs or SOAP XML type web services. The trick, especially in enterprise environments with heavy data traffic, is to create the necessary hardware and software infrastructure to be able to handle the load.
On top of integration, architects are also involved in trying to standardize technologies that EVERY software team can use, without needing to reinvent the wheel.
It’s been a problem at my own company where different divisions of our company keep “reinventing the wheel”, and create things that should be handled at the software architect team level.
For instance, every programmer needs to use a logging system to track activity happening within their application. For instance, when a database query is executed. Or when someone logs into their system. Or a myriad of other activity that is essential to track, when the need to debug the application arises.
Enterprise architects help to create or recommend common libraries and frameworks that the rest of the developer teams can reuse in their own applications. That way, there aren’t a dizzying sea of technologies to have to support.
Things like logging, application security, data reporting, databases, and many other common needs can be centralized.
Many software programmer aspire to end up being software architects. However, there are some notes of caution to moving up the career ladder to software architect.
If you love “being in the trenches”, doing active project development and coding, moving up to the level of software architect may actually move you away from active software development.
Architects often think and work at a higher abstracted level than a heads down coder. They simply don’t have the time or resources to concentrate on a single application or project. They are responsible for technical needs of the entire organization.
Many developers, including myself, aren’t fond of meetings. Yes, they are absolutely necessary, but they often pile high enough to literally take your entire day to attend. That leaves little to no time to actually code software.
Architects have no choice but to attend frequent meetings with product owners, business analysts, executive management, and other business oriented people, in order to thoroughly understand the business needs of the organization, before recommending the technical approach to those business needs.
An architect’s core responsibilities don’t leave much room for actual coding.
That’s not to say an architect’s job isn’t desirable or worthy of striving for. But it’s important to understand what exactly an architect’s core duties and responsibilities are.
If you enjoy heads down coding, you may want to think twice about the architect career track. If you enjoy thinking about software at a higher level than individual projects, then the software architect track may be right up your alley.