4 ms·

I'm a Software Architect who made a progressive move to that role after being a Sr. Software Engineer for almost a decade. I see the distinction as pretty simpl

by ztjio 7y ago

I'm a Software Architect who made a progressive move to that role after being a Sr. Software Engineer for almost a decade. I see the distinction as pretty simple. We do the same things, but, we specialize in terms of time spent and breadth of awareness and contact in the business. As far as skills go I expect to maintain my coding skills and as far as what I know more about than other SE's is not about skill as much as it is about practicality of time spent. We need the devs to be writing code/implementing every day and the architects spend more time on the, well, architecture as well as business interfacing and planning side. So that's basically it, the difference is where we spend our time and focus. It's more about roles and needs of the group than about the skill set. At least, that's what I'd hope. Anyone thinking they are a Senior level engineer who can't understand the concepts of software architecture needs to rethink their position and maybe broaden their skill set a bit, imho.

Retric 7y ago
Good Software Architects can make a huge positive impact over time. But, people often fail to live up to the role. The most common issue in my experience is Software Architects who don’t spend ~10 to 25% of their time actually working with the code base are largely ignored. You get things like two layers that are both 100% 1:1 mappings of the layer below them. It’s not about coding skills, but software is complex enough people quickly lose touch without regular feedback. Resulting in people spending a lot of time solving non problems.
- crimsonalucard 7y ago
  I think "architect" is code for manager who is slightly technical enough to make high level decisions about a system. You get layers that are 1 to 1 mappings from engineers? Gee only software architects have the innate ability to notice an issue like that. An isomorphic layer more than likely exists as a translation layer to make composition with another layer easier even though entities are bijective. So you think an engineer is unable to comprehend anything about a layer that is basically an identity morphism in disguise? Wow. Please tell me about some other architect things that an engineer is unable to comprehend. I would like to learn more from great architects who have super powers like "big picture thinking"
  - Retric 7y ago
    To clarify, someone with a PHD and architect title came up with a system that had 8 layers server side. The actual programmers coded up two of them on top of each other as simple 1:1 mappings using objects with different prefixes, and a third layer on top of that which was usually 1:1, but occasionally not. They did plenty of other odd stuff like stored all values as a string rather than using any database data types on the off chance they would port or a different database. Anyway, I worked for the same company and very occasionally helped some friends on the team, but was not really directly involved day to day or even most months.
    - crimsonalucard 7y ago
      A PHD does not make you an "architect." There's no formal design theory around "layers" "patterns" or "software architecture" so a person with a PHD does not have a definitive answer to good design or bad design. It is unlikely that anything he studied in school is relevant because such a science or theory doesn't even exist. His answer could be just as good or just as terrible as an engineer. Every architecture or pattern you here about is NOT theory OR Science, it is opinion and opinion only. I don't have context on what those programmers did, nor do I know whether the 8 layer server side design was good. But I do know that how good a design is, is not influenced by a PHD or a software architect title. That being said, an 8 layer design points to 8 things that want to be re-used. Typically you just need 3 layers (letters represent types, arrows represent a conversion process from one type to another.): IO input -> A A -> B B -> IO output I have rarely seen a business case that necessitated 8 layers: IO input -> A A -> B B -> C C -> D D -> E E -> F F -> G G -> IO output From my experience those 8 layers are probably garbage and unnecessary. You just need A -> G. You might break A -> G into several components but 8 is overkill. Likely the architect and the software engineers both don't know what they are doing. I'll go further to say that no architect will ever reason about "layers" the way I just did because my break down of the design layers above isn't some science. I made it all up, it's basically my opinion and most architects you meet will have either canned opinions from some book or have their own made up reasoning on how it all goes together. An engineer can easily come up with his own opinions and read an "architecture" book as well (which is again basically reading someones opinion). The "architect" title is a BS title that implies an "architect's" "opinions" are better than an engineers. It's not and from what I've seen in the industry an architect rarely has better design chops then an engineer. It's all relatively equal. That being said there is some formal theory on network topology and graph theory that can say something definitive like this graph has faster output than another graph but rarely is it used or applicable in most web apps.

by ztjio 7y ago

Retric 7y ago

Good Software Architects can make a huge positive impact over time. But, people often fail to live up to the role. The most common issue in my experience is Software Architects who don’t spend ~10 to 25% of their time actually working with the code base are largely ignored. You get things like two layers that are both 100% 1:1 mappings of the layer below them. It’s not about coding skills, but software is complex enough people quickly lose touch without regular feedback. Resulting in people spending a lot of time solving non problems.

crimsonalucard 7y ago
I think "architect" is code for manager who is slightly technical enough to make high level decisions about a system. You get layers that are 1 to 1 mappings from engineers? Gee only software architects have the innate ability to notice an issue like that. An isomorphic layer more than likely exists as a translation layer to make composition with another layer easier even though entities are bijective. So you think an engineer is unable to comprehend anything about a layer that is basically an identity morphism in disguise? Wow. Please tell me about some other architect things that an engineer is unable to comprehend. I would like to learn more from great architects who have super powers like "big picture thinking"
- Retric 7y ago
  To clarify, someone with a PHD and architect title came up with a system that had 8 layers server side. The actual programmers coded up two of them on top of each other as simple 1:1 mappings using objects with different prefixes, and a third layer on top of that which was usually 1:1, but occasionally not. They did plenty of other odd stuff like stored all values as a string rather than using any database data types on the off chance they would port or a different database. Anyway, I worked for the same company and very occasionally helped some friends on the team, but was not really directly involved day to day or even most months.
  - crimsonalucard 7y ago
    A PHD does not make you an "architect." There's no formal design theory around "layers" "patterns" or "software architecture" so a person with a PHD does not have a definitive answer to good design or bad design. It is unlikely that anything he studied in school is relevant because such a science or theory doesn't even exist. His answer could be just as good or just as terrible as an engineer. Every architecture or pattern you here about is NOT theory OR Science, it is opinion and opinion only. I don't have context on what those programmers did, nor do I know whether the 8 layer server side design was good. But I do know that how good a design is, is not influenced by a PHD or a software architect title. That being said, an 8 layer design points to 8 things that want to be re-used. Typically you just need 3 layers (letters represent types, arrows represent a conversion process from one type to another.): IO input -> A A -> B B -> IO output I have rarely seen a business case that necessitated 8 layers: IO input -> A A -> B B -> C C -> D D -> E E -> F F -> G G -> IO output From my experience those 8 layers are probably garbage and unnecessary. You just need A -> G. You might break A -> G into several components but 8 is overkill. Likely the architect and the software engineers both don't know what they are doing. I'll go further to say that no architect will ever reason about "layers" the way I just did because my break down of the design layers above isn't some science. I made it all up, it's basically my opinion and most architects you meet will have either canned opinions from some book or have their own made up reasoning on how it all goes together. An engineer can easily come up with his own opinions and read an "architecture" book as well (which is again basically reading someones opinion). The "architect" title is a BS title that implies an "architect's" "opinions" are better than an engineers. It's not and from what I've seen in the industry an architect rarely has better design chops then an engineer. It's all relatively equal. That being said there is some formal theory on network topology and graph theory that can say something definitive like this graph has faster output than another graph but rarely is it used or applicable in most web apps.