From time to time I read articles or tweets or watch talks from @hillelogram or @pressron or @sebmarkbage (in no particular order) and realize that...
For further actions, you may consider blocking this person and/or reporting abuse
Experience is the main thing you need to be an software architect. You must have the battle scars of being in the office at 3am trying to fix a solution that has been broken all day. You need to know both good and bad solutions. And you have to take ownership of a project that is failing due to your architecture.
To answer this I need to define what is "experience" first. Oxford dictionary defines it as - the knowledge or skill acquired by a period of practical experience of something, especially that gained in a particular profession.
Experience is not measured in time. Some people tend to say phrases like, "I have more than 10 years of experience in the industry" (guilty myself). In reality, it doesn't matter how much time is spent, what matters is how this time spent. People with 2 years of experience can be more knowledgable than people with 10 if they spent it doing active research, right?
Like in cooking temperature and time matters, the higher the temperature the smaller time you need to cook the thing. The more productive you spend time the less time you need to gain experience.
So my question is how to gain experience most effectively? How to spend as less as possible time and gain as much as possible experience.
Build stuff is how to gain experience. Read articles and observe the opinion of others. You will become a architect when others recognize you as one.
Sounds like a lottery - buy a ticket every day and eventually you will win.
I'm not blaming, I did it myself in the past (and maybe doing it right now), but this is not the most effective way from my POV. If I have no idea how to achieve something I would ask for advice, search mentor, try to do something else to "reset" my brain and maybe then I can come up with a plan.
Honestly, I think achieving architect status means that you've earned the right amongst your peers. Or you've earned the title by proving yourself within a job interview.
I don't think its winning the lottery. And to be honest, I don't think having the title "architect" really means anything either. I think as a developer,
Let me ask you this, why is it important for you to be an architect?
I guess we get confused somewhere in the middle. My question never was about a title. I asked how to gain knowledge (or experience) in most effective way and what kind of knowledge people consider to be most valuable (in sense of giving most insight).
Build stuff my friend. That’s it. Gain the knowledge by building stuff and leading teams. See what works and what doesn’t.
Seems like you want a simple answer like, if you read book X or blog post Y, it will tell you how to be a software architect. It takes real experience in the field of software development. You cannot skip all the hard work it takes to earn the badge.
It seems to me that this is a good definition of a senior engineer, not an architect.
Software architects usually interact with the clients and stakeholders of a project. They - ideally - will need to be involved in figuring out exactly what kinds of requirements the client is looking for, being able to make sure the requirements are business requirements and not just "make this page have a floating top menu bar."
Total aside: Yes, I've been on a project where we literally spent hours of meetings with CEOs of two large insurance companies just to decide whether to use a floating top menu on the web site 😜. It happens...
Anyways, the architect needs to make sure that the technical direction of the project is viable/feasible give the business needs.
So there are two primary parts:
Knowing multiple programming languages, paradigms, etc. as mentioned in the "question" of this post are helpful because every language and paradigm solve specific and different kinds of problems.
If you have a business, for example, who needs a system that will be developed and maintained by hundreds of developers, then you need to know that there are specific patterns for building these kinds of systems (DDD, Microservices, etc.)
Imagine the need for an e-commerce site which needs to keep the data of all user interaction with the site (via products ordered, products added to cart, products removed for cart, etc.) so they can do analytics in the future (I.e. predictive analysis, etc.). Knowing that Event Sourcing can solve that problem would be applicable here.
So, a big part of being a good architect means your knowledge is broad enough that you at the very least know what technologies are available to solve which problems. And you can figure out what business problems map to which technological problems and solutions.
Much of being a software architect (and especially CTO) is the ability to slap nontechnical stakeholders (up to and including your own CEO) back to reality, in a way they they respect you for. I can give an example from my time with a startup whose CEO had ADHD (and ultimately was a cheapskate and a BS artist, which is why I'm not around to build the product), and lost a major client by flying off the rails with ideas unrelated to what we were doing.
Basically, we were trying to stir up interest from potential corporate customers in running product pilots. He got an exec from a major big box electronics retailer (yes, that one) on a pitch call by himself, after I had already told him he should get me involved to keep the discussion technologically grounded in reality (rather than the all-too-typical sales routine of making promises on which we couldn't deliver without significant additional work and eaten costs). His pitch went swimmingly, but then the exec asked him what our 5 year plan was re: market saturation, expanding into new verticals, etc. This is where he went off the aforementioned rails, throwing out ideas which had absolutely nothing to do with our current core product and no conceivable (or attractive) way to integrate them: VR, facial recognition, and other buzzwords.
When he told me, I reiterated that this was why I should have been involved. The answer was easy: Since we would already need to integrate with the APIs of customers' existing systems from other vendors, we could study their strengths and weaknesses while doing so and eventually offer competing products more tightly integrated with the core product.
I would say this is not quite the definition of software architect
Yes, but as well as many other people like a business analysts, managing developer, tech lead, product manager. This is not unique to architect, this is not a distinctive feature.
Well this is sounds like a manger or tech lead or director of engineering or CTO to me.
Sounds like business analysts or managing developer or architect.
I mean those all are good and valuable things, but they don't give you any deep insight, for example how functional paradigm and OOP can be viewed as two sides of the same coin. RIght? I mean at which point of talking to product owner about requirements you pause and "Ah now I see how Y-combinator relates to McCarthy's eval".
UPD Maybe title is a bit confusing, but I extended actual question in the text. I asked more about how to get deep understanding.
Thank you for the answer. This is for sure good career advice. But I would say this is not quite an answer to my question about deep insight.
I know it's an old topic but I still want to say. The confusion is not in the title, but in the fact that architects are different.
Jorge Castro is talking about Solution Architect. And what interests you is the Application Architect. These are different areas, which is why you are talking about slightly different things.
I agree with Jorge Castro in this point of view. Even you have the deepest knowledge of coding and software architecture, without those you cannot be a good software architect.
As a software architect (Martin Fowler for example, not about any job role), you must understand requirement in order to match you solution. Over engineering or under engineering is both not good.
In a small team, software architect is the same as CTO in a big company. CTO cannot decide everything for every team. Even if you are just developer in that team, knowing your teammates capabilities will help you give more properly suggestions.
In the modern engineering methodology, evolution design is the top choice as it improves agility of the project. Every developer has to know how to model the business, why software project failed (to not repeat it), why we should do this and not do that...
Yes and no. Things that help you have a holistic view of things help, things that deepen your knowledge about something specific will just help with that topic.
I always recommend aosabook.org/en/index.html rather than some specific tech or technique although any would also help expanding your knowledge.
It's good to first know what you're asking for. A "software architect" position usually refers to the job in an enterprise setting. This clarification may be useful.
What you're describing as examples is more about people who are actively engaged with the programming community, present and past, with a very specific set of questions:
So once you have been through this many times you look at a new library, framework, or language, and can quickly categorize most of it. Usually you can categorize all of it, in which case it's interesting only insofar as you may have to use it to get paying work done. Sometimes it remains interesting because of interactions that you haven't seen tried before (e.g., Scala trying to wed the Java type system with Hindley-Milner type systems, and experiment that I feel was a failure). Occasionally there's an interesting piece of something and you spend a few hours or a few days beating on it, trying to find what's there.
When you're just starting out, you can flail at the usual suspects and get a lot of mileage. A short list of things that I guarantee will not be a waste of your time:
SICP is a wonderful book. If you enjoy it, go to it. Branch prediction is worth understanding. If you know probability, it should take you about half an hour to understand how it's supposed to work. There's no reason to understand it at a silicon level unless you're designing chips or fighting with truly bizarre performance problems. Likewise, Types and Programming Languages is more machinery than you probably need right now. If you find yourself building type systems or programming languages, then you will read it cover to cover and it will seem like the most wonderful, applied advice ever. If you aren't in that game, you're better off getting the basics down so you can understand how various type systems differ and what the experts mean when they argue about them, and then moving on to something else. Remember, your time is finite.
Yeah, I guess title is confusing, that is why I also wrote extended body to explain the question. I wasn't able to pick better title, like "how to gain deep insight in development" or "how to become @hillelogram". So I decided to name those people architects and explain question in the text.
I like your explanation (of my question) you got it right. And thanks for suggestions 🦄
At MIT, (the school I went to), there is a class called 6.033 Computer Systems Engineering.
ocw.mit.edu/courses/electrical-eng...
It is basically a sophmore level introduction class for knowledge/skills for software architect.
Wow! OS, Networking, DIstributed systems, Security. This indeed looks quite insightful. Thanks
Yep. If you want to have a structured course, this is one the best, there is no text book, but I believe course materials (lecture notes, recommended readings, homework and assignments) are all online.
After this class, there is classes that goes into each topic in more depth, but this is course that tells you how things fit together. Given it has a lot of topics already, so it can't cover everything. I would recommend understand database also, how database works, and differences between some key databases designs such as sql vs nosql.
First, read books, blog, articles. Depends on your field, find some reviews to know which book you should read. Code Complete is definitely one you have to read first.
Knowledge without practice is the dead knowledge. Just practice everyday, apply your knowledge in your work, your hobby project,...
Practice without observing is like driving a car without knowing where to go. Observe your result, people’s results, learn from them.
Doing all those things alone is like a silo. Everyone has his/her own point of view. People talk differently about the same subject. Talking, discussing with open mindset help you to see things different ways and understand the nature of things. Do not object other views too soon, which will make you a big silo.
I once heard a quote about being a software architect (sadly I can't recall by whom):
True software architects are developers, and not just any developers, they are the best of the best. You can't become a good architect without being an outstanding developer first. You need to be present at the team, you need to be open, supportive, willing to teach others and never stop improving. That's what being a good software architect is all about.
I could not agree more.
Yeah, the question as well could be "how to become outstanding developer", it was about knowledge and deep understanding. I wasn't able to find better title at the moment of writing.
No worries. My point was only that nobody should start their career as a Software Architect. You start as developer and collect lots of experience first. How to become a good developer... have a project (reading alone will get you nowhere without practice), read all the books you can get your hands on, listen to talks on Youtube, visit conferences and meetups, share your knowledge, have a blog, and bring tons of patience.
Software architect is a job title, meaning if you want to become one: start acting like one!
Someone already mentioned knowing the requirements and doing business related conversations but that's part of the software architect role.
There are many other important stuff as well:
An end-to-end knowledge about building/testing/deploying systems.
Given point #1, you will be the focal point in your team, so you will help the others with anything that comes up.
By anything, I do mean it literally; it could be designing the database, or could be fixing a deployment pipeline, or even showing a frontend dev how to fix a UI bug.
Knowing various programming languages, programming paradigms, design patterns, software design approaches (ddd, tdd, bdd... all kind of D's), and a handful of architectural styles and patterns.
Practical knowledge of distributed systems and its related parts, like: networking, service oriented architecture, and caching.
Willing to learn all the above on a daily basis!
I believe CS courses won't really help as much as learning from exceptional devs, some names that come up to my mind: Martin Fowler, Uncle Bob, Greg Young, and Udi Dahan.
What I'm doing are two things:
Useful discussion you started, by the way, thanks. 😉
Hi,
It depends on where you want to head to. Pure software architect or enterprise architect ?
Being myself an IT senior architect, I can tell that some concepts or insights can only be acquired by experience.
My advice is to not focus only on computer languages. During my MD's degree in computer science, I learned how to build a compiler, to code in Pascal or Lisp, but also Topology and Numerical Analysis. Those fields I didn't use a lot during my career.
Then at work, I studied CPU architectures, C language, IBM mainframes, Oracle & Sybase DBMSs, Linux, networks, Windows but also SOA architecture, enterprise bus, software engineering etc. Being a good architect means a lot of IT techniques to master, a vision to acquire, and fields to comprehend.
So explore and read, experiment, learn.
Hope this helps ;-)
If you see this diagram from TOGAF - pubs.opengroup.org/architecture/to...
These are the steps required to be performed while setting up Enterprise Architecture (EA). So there comes the first architect - Enterprise Architect.
An EA might not be able to perform all the steps. He takes help of Business Architect- They mostly have complete understanding of the business domain and the how the business functions.
Information Systems Architect - The level which helps in Blue printing your applications. They have two flavors here - Data Architect and Application Architect.
Technical Architect - This is where it comes to actual implementation level, where the person in an expert in the technology.
Solutions Architect - This is where, architect focuses on developing solutions using their tools and software for client problems. This is not under TOGAF.
Change Management Architect - This is where an Architect uses his Change Management skills. More details you can find here - iasaglobal.org/itabok/capability-d...
So apart from coding or knowledge in specific software an Enterprise Architect is required to have skills in all these areas.
I like your answer, even though stereobooster had something different in mind. Your answer matches pretty good what the role of a software architect is about in the company I work. It's not a software company. This is probably the major reason for the focus on mediating between business and IT.
I think if you only one Programming paradigm, that's a great place to start. I've never met a good architect who only knew one.
You mean to learn all of them? Something like this info.ucl.ac.be/~pvr/VanRoyChapter.pdf?
I recently found this pearl matt.might.net/articles/what-cs-ma...
Actually @hillelogram kind of answers this question in this thread