Clojurians Log v2

It may just be a way of recognizing "this is someone who's been around for a while and others look up to, technically speaking" When you've been working for 20+ years you go from developer->engineer->senior engineer->staff engineer/architect/? (disclosure: I am an "architect")

So what do you do all day? 😄

I’ve had the title of architect for some time, both front and backend. Doesn’t mean I sit in a tower and design grand design, just that I might have the final say if we’re in disagreement of some direction, and that aim responsible for making sure the codebase evolves in the direction we want.

Think about how we can have the right things in place so our application can scale with new business, design frameworks and patterns in the code base to make in easier to plug in new functionality, PR reviews and feedback, pair with and mentor junior developers, talk through designs for new features, write code 🙂

All day, I do a lot of things, but I think I’d wish I’d just be coding, slowly evolving our codebase while not being tied up in feature work.

^ this

I try to steal time to work on things that make our codebase better and isn't necessarily feature work

Another way to frame it is that you do the important, non-urgent work.

To me that’s a tech lead

I definitely am and want to remain technical, but I also get asked to write Secure Engineering policies for compliance and whatnot

Yes, they overlap. And I’ve held both titles at the same time.

But we have several teams, each with their tech leads, but only one architect.

Got it, so Architect = Grand Wizard Tech Lead

Yes.

Ultimately there's no rhyme or reason to titles in our industry. I was a Principal Engineer at one company, and when I interviewed with another a Principal was like a director level position which was not a fit for me. Technically my role is "Architect" not "Software Architect" so I guess I could also design the new office building? 🤣

I’m currently a Director of Platdorm Engineering which is a truly dope title.

Sometimes Staff is higher than Principal, sometimes the other way around. Sometimes Architect is a different track. 🤷‍♂️

The only thing that was on my mind right after reading the OP.

I've seen the architect role at several companies I've been at, both small and large. The biggest project (150 devs, 2 year span) even had a separate architect team. But yeah, I guess when you reach "enterprise" there will be architects.

Architecture aside, nothing beats Scaled Agile Framework (SAFe) 😁

> I am an "architect" I'm sorry, but this just makes me think of https://www.youtube.com/watch?v=rl2Jv4dzFqg&list=RDrl2Jv4dzFqg

I have never understood the desire to get some new, fancier title. It often seems like the boost is illusory: you aren't actually getting any more money, more responsibility, or anything else, just a new label that people have a harder time understanding what it actually means.

It’s not about titles, I’d be perfectly happy having “dev” as my title. However, I do tend to care very deeply about the codebases that I work on, and it helps me to have been given the authority to make the final decision if that’s needed. One way to tell the rest of the org that I have that authority is to give the title architect. There are also other ways.

Yeah, I am simply making the observation that in many corporate roles, there is a trend of people and companies who tend to get a little too caught up in the title, whether for personal ego reasons or something else. As far as software itself goes, I don't have a particularly strong opinion, but I think maybe "architect" has the potential to give someone the wrong idea in the same way as "engineer" does: properly speaking, the average software developer, no matter their experience level, are neither of those things. But I am aware that has been amply debated elsewhere and is not strictly the subject of this thread. Anyway.

I've had "architect" in my job title for about 25 years. That started with Macromedia: "Senior Architect (IT)" was a specific role they hired me into, and I had a team of architects working for me who specialized in different areas (data design, database, web, infrastructure, etc). We were usually involved from early C-level meetings about new initiatives all the way through deployment, for any "large" project, and especially for any project that spanned divisions. When Adobe bought us, my role disappeared -- Adobe "doesn't have architects", I was told. You also couldn't be "Director"-level if you didn't have any direct reports (with a reorg as part of the acquisition, my team was disbanded so I no longer had direct reports), so I was demoted one or two levels... to fit in with Adobe's much more rigid hierarchy. After Adobe, I worked for several startups where I could basically choose my title but one of them considered me C-level so my semi-joking title there was Chief Software Architect -- working alongside the CTO but with no direct reports (the Dir. Eng. managed the engineers and reported to the CTO). For the past 15 years, I've been "Senior Software Architect" -- which is amusing since there are no other architects in the company. The common factor of all those various roles is that I've provided overall technical guidance for projects, and tried to ensure there are common standards and a common vision for technology and integration as the company moves forward. And as some have noted above, the architect generally has the final say when consensus cannot be reached on an approach or technology or...

(I had about 20 years experience in industry before I became an architect, for the first time, at Macromedia)

@bhlieberman93 It often comes with more responsibility at no or barely higher pay 😂

In Canada, being an engineer means you are part of the engineering order which you pay for each year. It's a regulated order where they attest your credentials basically. You can only work on safety critical projects if you are licensed in that order, or there has to be someone that signs off on the work that is. Sometimes you can have a personal liability insurance along with it as well for (errors and ommissions).

I have worked with / work with someone who used to be an "Architect" and MS, but we don't have that title at my workplace.

it's always some combination like that, I don't pretend to understand it

I just see some pretty zany titles out there

Maybe everyone should henceforth be known as Software Developer X where X is the number of GitHub stars you've accumulated

Now you're just shaming people

Including myself

I feel the "architect" title has a lot of connotations to it. Lots of people feel it's pretentious and joke that it's the people who spend their time writing UML that nobody ever looks at. Today I think principal or staff is more popular, same job, but they don't carry the same pretentiousness because nobody knows what staff or principal means lol. In practice, I would say, once you are leading projects that spans more than one team is when these titles come in. It's not team lead, because it's more than one team. And since there aren't always such projects, the people in those roles end up having to fill their time with guidance, coaching, assessment, and recommendations, they'll also heavily be involved in planning the next big business initiatives which might necessitate work from the teams they oversee. They can provide early estimate/feasibility analysis to the product teams to help decide what to pursue next, and they can point to what engineering team would need to be involved and in what capacity before any of those teams are even contacted about it. Finally, you have some exceptions where critical initiatives might have as a team lead a person of this title, and that's just because they consider the work so critical they want someone with even more experience/know-how than your average team lead, so might assign the work to a "architect/staff/principal", etc.

Eh, I think architect is kind of misleading when compared to "staff" or "principal" which while certainly not obvious or common words, at least are used in other contexts to connote seniority, for instance, a "staff officer" in the military, or a "principal lecturer" at a university

Whereas architect kinda just means one thing everywhere in the most literal sense: you design buildings. Other applications of the term, including to software, immediately become metaphorical

I've really enjoyed my various architect roles. I've gotten to be involved with projects that I would never otherwise have had the chance to work on -- that crossed division boundaries -- and some of them have had major, positive impact on the company as a whole (particularly two of my big projects at Macromedia). I've also enjoyed the C-level access that came with that role at some of those companies. I've gotten to mentor and guide a wide range of developers and teams. I've gotten to build some fun p.o.c. to show that my "vision" would work. It's been very varied work. But I also recognize I've been pretty lucky with several of those roles. And I'm not ashamed of the UML I used to write 🙂

@bhlieberman93 I mean the others are also metaphorical. Staff was meant to be like a support stick to a person walking (like a cane). So you are a "staff" to others, and you operate a support role in a metaphorical sense. And staff also referred to power, authority figures often carried symbolic staffs. So it became a word for the high ranking individuals who support the leaders. The principal kind of makes more sense as the "first in rank" or the "primary person", but then it's not really explanatory in what function that person has. Architect roots means "Chief Builder". So honestly that one actually makes a lot of sense too, it later became more known as the person in charge of what/how to build a building. But it's not so far fetched to apply it to software as the person in charge of what/how to build a software feature or product.

I think the falling of grace of "architect" as a title/role for software is the traditionally tight coupling it had with waterfall methodology. The idea that a person or a group of people, ahead of time, in silo, would design a full schematic and plan that others would just follow and implement as specified in a later phase. And with the arrival of DevOps, the implementers often feeling like those architects had no skin in the game, as they would not have to worry about maintaining or further evolving the resulting code. And due to the waterfall approach, once you entered the implementation phase, there was no easy way to get feedback from the implementers back to the architect to influence the design and specification.

@didibus Sure, you can always keep peeling layers off the onion. It seems to me that because "staff" or "principal" plays the role of a modifier, it has less of the character of metaphor to it, when viewed directly. But I feel we are going down a rabbit hole that will not produce anything fruitful lol

To be honest, I'm not sure "architect" is metaphorical at all when you take the meaning of the word as "Chief Builder" -- Software Chief Builder.

If you take it as like, it's like an architect but for software. Then it might appear metaphorical. But I'm not sure this metaphor is what was taken when the title was introduced. Seems more likely the etymology was used.

Perhaps, I see your point. I take it to be metaphorical in the same way that Software Engineer is also metaphorical, you know, someone who is not an engineer by training or certification or even necessarily mindset, but uses that title because it provides a frame of reference

I think that this stuff, insofar as it matters at all, matters because the seemingly undeniable locus of software development is in the United States, where frighteningly unqualified people bandy about labels for themselves and others that are supposed to be a yardstick for authority

so it's nice to discuss these things now and again to assess the situation

I wasn't around back then, but I believe the use of the term "architect" in software began around the Design Pattern movement, which was somehow fascinated by Christopher Alexander. As I understand it, the "Gang of Four" saw themselves as doing for software engineering what Alexander did for architecture. So "software architect" became a prized title as design patterns gained popularity, then that popularity eroded over time as doubts began to creep in about the (over)use of patterns, then later on waterfall and OO. There was also a in-my-opinion-very-unhealthy obsession with comparing software development with building construction. I think the title mostly lost its lustre when https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/. Perhaps people di go overboard with design patterns and UML, too, and it didn't help that some architects moved on after delivering the UML and never saw the resulting code.

architect is the guy you blame if you can't get work done because the schemas and interfaces keep changing and you are stuck playing catch up to make your microservice stay up to date with the other services in the product

Since being exposed to spec/datomic/pathom etc, those types of "aggregate-first" APIs feel oppressive to me and are unfortunately the norm

I’m reminded of Rich’s “do you care about what’s in the delivery truck other than what you ordered? No.” The map has an extra entry? Boo frigging hoo. I find myself caring about the things these APIs wants me to care about slightly more at the edges of the app. When I send stuff off for storage I do care if there’s extra stuff in there, because I’ll be paying for it every time I want it back. And other than that, just the death by specificity in everything. Is it a dog? Not if there’s a fly sitting on it, then it’s a DogWithFly

See https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html.

probably no more than reading a book about it. Having some understanding of an industry only goes so far if it’s not deep knowledge. And a cert will definitely be surface level

a cert will look good on a resume, but you'll need to do the work yourself to be able to actually speak to the topics in an interview or on the job

I would say, no probably not

In a previous role we did looked to hire engineers with payments experience on top of engineering skills (even if they didn't have specific Clojure experience). A certification wouldn't have been interesting to us. Every company is different though with many different motivations. Check a companies job spec to see what else you can do to appear relevant.