Comment by snapetom | Hacker News Reader

Comment by snapetom | Hacker News Reader

In my first real dev job, we had a team of architects that were rockstar developers. One of their jobs was to write libraries for use throughout the enterprise. Their other job was to decide on technology used throughout the company. Those guys were great. They were smart, and good people skills were essential. This model worked well when it's a few expensive, good devs, and a lot of meh devs that were cheap and just generate code without question.

Over time, with Agile and I as I worked in smaller companies, I ran into fewer architects, and the people I did meet were basically senior-senior devs - People who had been at the company for a while. It was more of a reward and respect for them. Same as before though - really good devs.

This article is good at narrowing the requirements, but I think it's still a bit vague and abstract for this age. My last job, a large hospital, we had an architect that I constantly butted heads with. He hadn't coded in decades (not sure if ever) and was obsessed with picking technologies based on the wrong criteria. He thought of himself as this high level, European academic-type that was too busy with big issues. This style basically made him out of touch with anything going on in modern tech.

He had a knack for picking old, dying technologies. I got a particular kick out of sending former colleagues the post here on HN last month about Apache Drill, which he advocated for, being discontinued.

My argument to our CDO was that if he walked outside and yanked any senior engineer from Amazon, they could do a better job than this guy. His job, picking tech, is less important these days with Agile and modern applications, well, architecture. From what I've seen in my career, the expectations for an architect are far more "hands in the dirt" as time goes on.

My first lead position, I was hired with money saved by firing an architect who was all talk (on a small team, like this one, that becomes glaringly apparent very quickly). They wanted someone with rudimentary architecture chops who could grow into a lead role, but who was hands-on. I obliged.

Over the years, I've found the most productive way to go is for the leads to share the responsibility, with input, tie-breaking, and the occasional veto by a technically literate project manager ("yes that sounds neat but it's antagonistic to our business goals so pick something else").

Architecture as a responsibility, not a title. It's harder to prioritize - there is no point person - but the payoffs if you do manage it are not to be sneezed at.

You trust people with skin in the game, who suffer along with you when the 'right decision' results in near-term pain. Some guy who barely writes code lecturing you about how you're doing it wrong? Nobody respects that guy, except to their face, when the bosses are around.

I believe that everybody in an engineering organisation, no matter how senior, should at least spend half a day per week on programming tasks.

Take a ticket and deploy a solution to production. Such a rule takes peoples' heads out of the clouds and connects them with reality. Time and again, I perceive programming as a humbling experience.

> Time and again, I perceive programming as a humbling experience.

Truth. At every job I start, I manage to say, "Wow, I am way behind these guys on what I know." That's not a bad thing because it's pushed me to grow.

Some of the most vicious arguments on Blind are about senior ICs with conspicuously empty commit histories. This is a great rule - half a day per week preserves the “other things are more important than coding” aspect while preventing the “couldn’t even do my job, why should I listen to him” angle.

> in an engineering organisation

This is a key point, but People might say "software is eating the world", but many organizations are not yet at this point. You can find modern healthcare or pharma organizations which are doing real engineering, but this is still the exception in many places.

What you find is organizations which can still survive on old technology and the processes which got them there. At some point modernization will also have meant outsourcing tech to the lowest bidder. You have an organization which is unfit for engineering in the current state and the architects are more familiar with managing this process work than doing what folks here would consider real engineering.

These organizations are ripe for modernization. They have aging tech and tenured teams which can only make very incremental improvements. As market conditions change, leadership may decide that they really need to make changes and these people will be cast aside. It's a somewhat double-edge sword because the old folks do have value in that they understand all of the details of their business processes which are apparent to even a really good engineering and product team replacing them.

You pretty much described that last job. They outsourced a lot in the past decade, but now the issue is that to do what they want to do, they can't because of outdated tools and infrastructure. They don't have the expertise in-house. They keep talking about "leading" and "pioneering" work, but by definition, if you're buying off the shelf products that solves a problem, it's not pioneering.

The problems they want to solve require an engineering culture. There are no ways around that.

Like many hospitals, they've been hit hard by COVID-19. They recently announced golden handshakes for people close to retiring. It's painful for people now, but hopefully someone will see it as an opportunity to change the culture.

This is especially viable if you do pair programming.

Even an out of touch manager can contribute to and/or observe the state of the code base while pairing with someone who works on it full time.

Disclosure: I've had an architect title for nearly a decade.

I actually don't think half a day is nearly enough. BUT I also don't think that this needs to happen every week. Sometimes, there are periods of exploration and discovery - whether it be with new technology, new approaches within the company, or coming up with some more grand long-term vision to align the tech org towards.

However, when you're out of discovery mode, you need to be in the weeds writing prolific code, feeling the impact (good or bad) of your decisions and course correcting as you go. Moreover, you need to see how other people are feeling about your decisions. At the end of the day, you're working in service of them, helping a team, teams, or the overall tech org to be successful, which in turn will (hopefully) help make the business successful. Often times when I hear disparaging stories about architects, they aren't fulfilling that tenet - either because they don't have the skill to do so or they believe everyone else just needs to keep up with their brilliance.

I've been in too many situations where once the "architecture" was done, the project was to be tossed to some engineers while I work full time on something else. Unless you have some awesome leads that are in lock step with the architect, then that is a recipe for disaster.

The last thing I'll say is that everyone writing code is an architect. You're inevitably making decisions about the way things will be built, no matter how small. Virtually all software has an architecture - but too often it's incidental architecture rather than intentional architecture. Make conscious decisions about your code, reflect on those decisions, and keep an open mind - whether you're just starting out or have decades of experience.

> half a day per week on programming tasks

You probably mean on average, and yeah, I agree. But the literal reading of programming half a day per week feels horrible.

Sorry, but the ticket will never get done, once you stop coding, your skills start getting rusty very quick.

So there are a lot of tickets that are trivial, or a bullshit job, or just really not fun but still need to get done and a manager/architect is perfectly capable of doing any of these. They SHOULD NOT be doing the big/hard/risky ones because that's not their job; they'll block the team or worse, steal the most rewarding work from those who deserve it. Senior non-ICs and BS tasks are a match made in heaven (for many reasons!)

But do you think they would work on those "trivial tickets" :-)

Idk. I've slung about 2M lines of C over the years, and it doesn't take much time to get back into it...

Do you know of any organizations that do this?

I have worked all my life in organizations producing software, never once was this true: there was always some level in the organization were people stopped all programming tasks (with all the bad side effects of that, that the head does not really understand the capabilities of the organization, what is feasible and what is not...).

I agree with you, I just have not had the luck to see it.

Our current head architect is proud that he doesn't know any technical stuff. He has developers for that.

Ugh. Being proud of not knowing things, in any field or subject, is not a virtue.

Why do you still work there?

I'm going to try to answer that, even if only for myself.

Partially, because the organization is a lot bigger than 1 man. I'm working close to my home in a company that respects work/life balance. Pay is reasonably good, especially as i don't have a multi-hour commute anymore. I wont be fired from one day to the next. I'm pretty sure the organization is all in all doing good work helping people forward. There are a lot of people with great technical and other expertise. Also good, nice, solid people. My work is appreciated. I have a good amount of freedom. There are enough layers of management that I don't have to deal much with the architects.

And the weird thing is, it is working with him as head architect. He is the kind of person that can sell anything to anyone, even turning around people that were disgusted of him a few months before. I'm pretty sure he makes technological choices by reading Garner slides and doesn't really understand what they are or what the results will be. Even so, he manages to get things moving and agreement built in a very complex organization. He causes change, others give that change a usefull direction, and the net result is, well, usefull results. Strange but true.

All good reasons to like your job and very understandable.

However, it sounds like your architect is more of project manager than an architect.

That even partly fits to something the article alludes to, and maybe should have been stated more explicitly: that it's about communication: so getting the people talk to each other and be motivated and try to solve a problem in a specific, commonly agreed way - that is more important than the used technology (which can be overhyped crap)

i don't think this is the message you're trying to convey, but seriously i'm reading so many stories in this post about how non-technical people can get into these (presumably) high-paying architect jobs where they are not expected to do any coding... how do i apply for those jobs? i have 2 degrees, business and computer science, but i hate coding. so far, the most value i could have leveraged out of my CS degree without having to do coding is working as a technical project manager, but i know architects get paid WAY more. how do i find those jobs?

Way to strive for the prize.

is there something wrong with my approach? i'm a hard worker, i just want to be paid the maximum i can get for my work that's all.

> From what I've seen in my career, the expectations for an architect are far more "hands in the dirt" as time goes on.

As it should be, I'm an architect, worked for Central banks (equiv of the FED), working for crypto startups, and also medium size enterprise... I don't respect architects that can't "do". That said It's an important function IMO.

This sounds like what is called a staff/principal engineer these days.

Reply on news.ycombinator.com