4 ms·

Yes, there is a risk to be boastful. But the risk is shared by many positions and roles. It's not enough to say I'm an architect or a full stack developer or UX

by dwenzek 12y ago

Yes, there is a risk to be boastful. But the risk is shared by many positions and roles. It's not enough to say I'm an architect or a full stack developer or UX designer, there are a lot of skills and attitudes to have along the days to fill plainly the role in a team. It's why, I totally agree the post. To fulfill the architect role, you have to be on a daily basis with the team, to design, develop and debug with them. This is not about being a Rockstar, but yes, this requires some broader and smarter vision on how the whole system is being developed. And this implies responsibilities too and even a bit of humility when things do not go like expected: it is at these difficult times that we can judge whether you deserved the role. Besides, titles have their importance. This is maybe a pity, but, for sure, you don't have the same audience from the management when you are introduced as a software architect rather as a developer. Same thing, when you are looking for a job. I'm a freelance developer with 20 years of experiment and I introduce myself as a software architect even if I'm looking for contracts where I will be plainly involved in development tasks. Each time I failed to do so, I put myself in situation with no chances to use my skills and to help the project at the level I could have. On the contrary, with an architect hat, I have been often welcome with some suspicion ("how can this guy fix the mess we're in?"), but this gave me the opportunity to work effectively with all team members and to truly help them.

keithnoizu 12y ago
Nice description. On a side note but related, I really think one of the major difference between a developer versus an architect is having strong grasp of how components can fit together and impact overall costs, quality and timelines for a project even if you aren't familiar with the specific details of those components. For example if you need to design out something highly distributed you don't necessarily need to be proficient in erlang, or scala + akka, or clojure before you start but you do need to understand the pros and cons of each system, the underpinning philosophy on how they work and basic behaviors of the solutions in terms of speed to develop, benchmarks, known scaling problems, trouble spots etc. Sometimes you need to use the right tool for the job even if you don't know the tool yet. Sometimes that means taking a deep dive to get to know the technology, talking to experts on the technology and fitting their feedback into the overall picture of what the system needs to do. Which is a very different skill set then being able to pack as much functionality as possible into an MCU, or improve average performance on an algorithem, or being able to rapidly construct a component. Which is why I advertise myself as architect and not as systems developer, or ux guy or full stack engineer. It's the type of work I enjoy doing, and it's the work that clients get the most bang for their buck out of me for their retainers. It doesn't mean I think I'm a better developer than non architects. In a lot of ways I'm not, but I does mean that I think (rightly or wrongly) that I am often better at sleuthing out the rough behavioral characteristics of components or technologies needed for a project and knowing how to leverage that high level understanding together for designing or improving a project.

by dwenzek 12y ago

keithnoizu 12y ago

Nice description. On a side note but related, I really think one of the major difference between a developer versus an architect is having strong grasp of how components can fit together and impact overall costs, quality and timelines for a project even if you aren't familiar with the specific details of those components. For example if you need to design out something highly distributed you don't necessarily need to be proficient in erlang, or scala + akka, or clojure before you start but you do need to understand the pros and cons of each system, the underpinning philosophy on how they work and basic behaviors of the solutions in terms of speed to develop, benchmarks, known scaling problems, trouble spots etc. Sometimes you need to use the right tool for the job even if you don't know the tool yet. Sometimes that means taking a deep dive to get to know the technology, talking to experts on the technology and fitting their feedback into the overall picture of what the system needs to do. Which is a very different skill set then being able to pack as much functionality as possible into an MCU, or improve average performance on an algorithem, or being able to rapidly construct a component. Which is why I advertise myself as architect and not as systems developer, or ux guy or full stack engineer. It's the type of work I enjoy doing, and it's the work that clients get the most bang for their buck out of me for their retainers. It doesn't mean I think I'm a better developer than non architects. In a lot of ways I'm not, but I does mean that I think (rightly or wrongly) that I am often better at sleuthing out the rough behavioral characteristics of components or technologies needed for a project and knowing how to leverage that high level understanding together for designing or improving a project.