What Software Architects Do That Programmers DON'T
Вставка
- Опубліковано 30 тра 2024
- How does being a software architect differ from a typical programmer? In this episode, I share the 10 aspects I've approached software architecture from that I learned over 20 years of doing it.
I was promoted to be a software architect at just 20 years old, and while I was qualified with some aspects of software engineering - I didn't really know what I was getting myself into. Being a great software architect takes a variety of skills that a typical software developer will also benefit from, but are actually essential to software architecture.
Yes, using coding patterns, knowing how to interview as a software architect, and making technology selections are required. But there are also other things that if you don't focus on, can hamper your ability to pursue a software architect role either at your current job, or the next one.
I hope this episode helps you understand that while there is some overlap between a software architect and a programmer, the less "fun" aspects of the job are actually essential to being a really great one.
Get free access to TechRolepedia here:
jaymeedwards.com/access-techr...
Download my free Career Guide here:
jaymeedwards.com/developer-ca...
Need help with your career? Learn about career coaching:
jaymeedwards.com/services/sof...
CHAPTER MARKERS
0:00 Introduction
0:51 10 Aspects of Being a Software Architect
1:03 1. Zoom In / Zoom Out
2:17 2. Domain Sensitive
3:07 3. Understand Tradeoffs
4:02 4. Selfless Decision Maker
5:02 5. Embrace Change
5:44 6. Communicative Mastery
6:26 7. Infrastructure Aware
7:40 8. Strategic Coder
8:50 9. Consider Scale
10:28 10. Cost Sensitive
11:49 Episode Groove
#softwarearchitecture #programming #softwaredevelopment - Наука та технологія
![[柴犬ASMR]曼玉Manyu&小白Bai 毛发护理Spa asmr](http://i.ytimg.com/vi/0TsXQ7z2Dh4/mqdefault.jpg)
Do you agree or disagree with these aspects of Software Architects? What other aspects are important?
►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → jaymeedwards.com/access-techrolepedia/
Chapter markers / timelinks
0:00 Introduction
0:51 10 Aspects of Being a Software Architect
1:03 1. Zoom In / Zoom Out
2:17 2. Domain Sensitive
3:07 3. Understand Tradeoffs
4:02 4. Selfless Decision Maker
5:02 5. Embrace Change
5:44 6. Communicative Mastery
6:26 7. Infrastructure Aware
7:40 8. Strategic Coder
8:50 9. Consider Scale
10:28 10. Cost Sensitive
11:49 Episode Groove
Awesome video. Thank you for this, man.
I mostly agree with your list. I guess it depends on company but being "Strategic Coder" as you described here may not work for a smaller companies - there might not be enough architecture to focus solely architect job and in that case, a great software architect would navigate the problem space and choose sensible tasks to speed up the development. However, you have to be careful to not lock yourself into too big projects so that you have enough time for the architecture work as needed.
And I would have included hardware costs to the cost sensitive part of the video. If you write code in managed languages, the runtime performance will be lower and depending on the user count and who pays for the hardware and electricity, sometimes you should go with higher performance language such as C, C++ or Rust to reduce runtime hardware costs.
If you're creating a mobile app and end users are paying for the hardware (e.g. their own smartphones), then you can have more focus in getting things out fast. If you're running AI systems on your own systems for a big amount of users, then you need all the optimization you can get because computational efforts are insane no matter which language you use.
Or one could argue that most of this actually belongs to understanding tradeoffs. I think it's the single most important bit on your list.
@MikkoRantalainen I mentioned hardware in the infrastructure point, yes that’s definitely important.
You're right about the "strategic coder" point. There are companies I've worked with as a consultant before, and they have architects, but I wonder "why"? They didn't have enough need for a dedicated role just as you described. It really does depend on the organization and their needs.
I see what you’re saying about so much of this really boiling down to tradeoffs! You’re probably right.
Good video! Being able to understand large complex systems in detail is a skill I think has contributed to my success over the past few decades. It’s related to the zoom-in/zoom-out point but you need to be able to understand the implications of a particular coding decision on systems that are either upstream or downstream from where you’re “zoomed-in”. In other words, you need to be thinking about the little and big pictures at the same time.
First time I heard about software architect.
That is a solid list. One big item which is missing is "Saying No".
"No. We don't need to rewrite that in Go. It works fine the way it is."
"No. We should not write our own authentication server. Just use a 3rd party."
"No. This feature the Product Owner wants doesn't fit the product and we will never get the bugs out of it if we try."
"No. We our current DB is fine. Just leave it alone We would need 10x more users before it even became an issue."
I think the tradeoff section covers that as well
@@MrGilsteiner right, but is useful to state it like that as saying _NO_ is the most difficult thing. Even more now that Scrum rules software shop. This means, there's feature-itis (a short-sighted obsession with releasing features for the sake of it) and obsession with short-term itself. Meaning, if it CAN be done now, it MUST be done now. If it CAN'T be done now, it MUSTN'T be done, Instead of caring of what's actually NEEDED despite it takes more or less time.
idk I'm on the fence about this one- definitely in my career I have defended hotly statements like "we already have a pattern for that" or "we already have a service for that" but I don't drive so hard at that now mainly because I think a practical lesson is way better than an argument for a good developer who is on the path to becoming a great developer.
If you're trying to optimise for maximum developer output with no waste- sure, maybe you're in a startup, maybe you're at a place where tech isn't front and center and is instead on the side, seen as "a cost" rather than the source of all revenue but if you're in a place that is doing well and has some cash to spare and doesn't _really_ need whatever you get from shipping something in 2 weeks vs shipping something in a month then giving the developers some freedom to learn and make mistakes can be a great outcome
Say you've got some great developers in your team but your platform has become a bit "dull"; if your sharp developers wants to try cool new tech xyz, they'll be a bit annoyed if you take the hard stance and say "no, we've got runs on the board with Django, we're doing more Django"- best case they eventually see the value in it, worst case they think "this place sucks, that guy sucks" and your talent has walked out the door
If important outcomes aren't on the line, in my opinion the learning and the outcome (and interesting experience) is a far better outcome for the developers because there's a good chance they'll still learn the lesson but the best way (through hard work and failure) and furthermore they'll feel heard, maybe feel loyal as a result of it- ideally you get to keep your strong engineers in your team so you have access to them when That Big Thing finally comes off.
Don't wanna be stuck with a stack of juniors who have learned how to be effective entirely within the framework you've created without ever wondering about the grass on the other side- because now (overly simplified of course) you can mostly only be as successful as your current framework allows.
@@errrzarrr That's right. Learning to say No is an important skill and not an easy one because it can make you unpopular and most people like to avoid anything which looks like a conflict. But often it is the right thing to do to keep the software/product healthy for the long term.
In reality there is usually a bit more to back up a No. For example: "No, we can't do that. You forgot about XYX." or "I love the idea, but No. I won't be able to sell this idea to management." or "No, but if these conditions XYZ become true, then we could do it."
I agree being able to say no so they will listen is really useful!
There’s an older episode on the channel about that which may have some helpful tips if you haven’t seen it already here:
ua-cam.com/video/gGTOPoxVFsE/v-deo.htmlsi=kKf96zhAChRisSgN
My first job as a software architect fell into the first trap you mentioned: I was simply a developer with a fancy title. And nobody else in the entire department cared about architecture, besides the head of the Ops team. I left the company as I saw no opportunity to grow any further, and the Ops team head became the lead architect in the company.
Good books to read on this topic:
- Just enough software architecture (risk driven design)
- Fundamentals of Software Architecture
- Clean Architecture
- The Software Architect Elevator
- Domain-Driven Design
- Building Microservices
All of these taught me something. As an architect you sell options. Different solutions. You are a good communicator. Know that people will challenge your decisions. Office politics play a part in this. Learn the architecture ilities. Some upfront design to any project is okay. DDD gives you another perspective into designing code.
Then you can slap in a few DevOps + Agile books in there to understand continuous improvement and iterative development, and spread those ideas around.
Thanks for sharing your story, and all these books! 👍 Super helpful.
I have been developing professionally for 30+ years, and I am currently in a systems architect role. I think the list is spot on, those are all very important skills to have in this role. Knowing how to push back on the client/stakeholder is also an essential skill.
Speaking as a software architect, you did a fantastic job summarizing the responsibilities. One thing I'll add is the ability to deconstruct abstractions presented by the business, and use them to create concrete requirements for senior devs. I know a lot of very talented engineers who recognize the architect role is not for them because of that. It's the "just tell me what you want" vs. "I'll help you decide what you want" mentality.
Ooh that's a good one, for sure.
Test-ability: A big one that is often missed. How a tester will test the solution and/or its parts is important for rapid releases and the bottom line. If the solution lends itself to automated vs manual testing is also an important consideration.
I approve.
That's true, but there are also tradeoffs. I have seen abominations done in the name of testability, just as you can find abominations in the name of performance, reusability, scalability, etc... Everyone knows that testability (and performande, are reusability, and scalability, ...) is a good thing, but good architects know the tradeoffs and what is the right amount for the project.
I've been fighting this exact battle for my entire career (now going on 35 years).
@@gubx42 I am interested in an example where building for testability became a problem. A few points (sign-posts) to watch out for would be very helpful.
@@queenstownswords Making a function testable generally requires some level of abstraction so that you can create a mock environment. Dependency injection is popular choice for that. The problem is that it adds complexity, sometimes doubling the amount of code even before writing the tests. It also makes harder to follow the execution path. All that is not bad, but as always adding an abstract interface just to make a 5 line function testable, especially if it can be tested in other ways is just too much. The worst is when you consider tests before even thinking about whether or not a piece of code should exist in the first place.
Something I would add is that a great Software Architect takes a risk-driven approach to coding, i.e. he will be aware of the technical and other risks surrounding a project and try to nail the biggest risks down first. That means that he will do performance and scalability tests early in the project if that is expected to be an issue, or mock-up user interfaces to verify their design with actual users, or make a proof-of-concept, design-space exploration, etc, etc, etc. In systems design, he will be aware that the plans other teams make have risks in them and help them nail their risks as quickly as possible. For example by mocking a robot's control software so that it can be put through a realistic movement scenario early on in prototyping.
A colleague of mine did that to find that a vacuum pump was under-dimensioned, something that would have put the project back several months had it been discovered later on.
(note that "he will make" usually means: "he/she will let the team make")
Enjoying your videos man.
Realizing I've been doing lots of different job roles under my one job role is a bit of an eye opener.
Interesting how strongly material and human costs feature in this video and your recent one on tech stacks. It feels like that's one of the aspects of leadership that's easily overlooked in technical roles?
I guess as I got further in my career, I realized I was focused mostly on my experience alone with work. The more I worked with business people as a consultant, and the other roles in software (product management, QA, executives, operations etc.) it seemed like I needed to care about the human side more to really get through to people when I wanted support.
I would say that any kind of leadership position means caring about people. Being a software architect is a kind of leadership position and if you don’t care about people you will make enemies. If you care about people you can bring everyone along for a great ride on a successful project. Loads of people seem to think that tech isn’t about people and yet the our best way of working (Agile) is all about people. People lose sight of that and think that scrum, XP, etc. are just a way of making you do more code in less time. Those can be great tools to use but agile is all about people no matter what way of working you choose. Without living the values of the manifesto and the principles those tools won’t deliver what people really want. Worse still, they will blame you for not being any good because the tools are clearly perfect so it’s your fault. To me this video, the agile manifesto and all my experience tells me that as an industry we really need to care more about people and I hope we can go back in that direction. Sadly many managers seem to sabotage us from going that way.
Love your guitar tone!
Very insightful video as usual.
The list is without a doubt a good one. It's hard to have each skill individually (I'm not talking about all 10 at the same time, and certainly not at 23 years old). But as a reference point (like a road map), it is very useful. In fact, all these skills are the result of a high level of awareness when meta-knowledge about knowledge emerges.
You are incredibly on point here, all of it is so true. I have been an architect for 8-10 years now, and you just listed all the things I do without knowing them. Good work 😊
First one you listed is a golden nugget as far as im concerned, I have had that problem so many times before, I'm the dev that is too bogged down in the details, many times i've paid the price for it, I've put too much importance on some small thing I was working on when the bigger picture barely even required it
When I was an architect I found myself having to ironically fight against developers using different design patterns that brought 0 value to the project. The most notorious one was CQRS. I hate seeing that pattern used so often when it's NOT NEEDED!!!!
But honestly I wasn't a great architect, mostly a coder with more responsibility and desicion making power about libraries and patterns... I did enjoy the role though.
I feel you, microservices in general are a problem
props for acknowledging being more dev than architect! In general, people need to realize its perfectly ok if you lack the skills for the position. You can build them up over time. I was promoted to senior before I even felt like one. It took time for me to grow into that role and accept that I was one instead of being self-critical.
Let me guess, that was .NET / C# project
And i hate that many projects will start as microservices with no need adding more complications and difficulties.
@@gppsoftware "Convinced that their Mongo database was accurate until I imported it into SQL Server and started adding foreign keys.". I am not sure but this statement as it does not proved anything about "SQL good NoSQL bad". It will always feel like you are trying to compare apple and oranges or forcing the concept of relation to every data. I agree that one should not try to use NoSQL solution in everything but it has its own benefits and use cases where SQL can be considered an overkill.
Part of the difficulty I think is also selecting for / incentivising architectural thinking in juniors. All too often recruiters and to some extent tech influencers talk about pure code perf or the faang-type algorithm questions.
Which yes, these have their place, but it's a little weird not putting solid architecture first and foremost. My last employer straight up tells me that, while at some point he wants to move over to Go or Rust as the product matures, for now the main bottleneck is actually just getting things across the network.
So throwing out rapid application development in python, much less trying to make long or fucky code 'for performance', simply isn't on the table yet.
This has been the best explanatory video that describes the role and expectations of an architect, of all the videos i have seen so far. I am aspiring to be one and since I am not in a tech field yet, this video really sets the tone and bar for me.
The thought process/ability to zoom in and out of any part of project is very well said. Also the ability to map the project end to end or from business process to fine technical details/solution, plus the ability to simplify everything to as simply as possible.
This is a great list. I think the only thing I would expand upon is an awareness and sensitivity to how both requirements and context will change over time. Engineers are often inclined to focus on building new things and think less about maintenance costs and ongoing QA processes... over the course of my career, I feel the costs of standing still have skyrocketed, given our growing dependency on evolving third-party libraries, frameworks, and APIs...
From my many years being an architect, this was great advise and can confirm of what you listed. Thank you for making this video and I hope many will learn from it.
Glad you enjoyed it!
Though I thought that this is how every experienced software engineers operate, one important thing I'm missing is that they are good at asking questions and they dare ask questions. My experience is that a lot of times people don't ask enough questions. Sometimes because the answer seems obvious (i.e. they think they do know the answer), somtimes because they think that they should know the answer so it would look bad, etc. But, in my experience, more often than not, at least one out of 5-10 such questions will result in a valuable/surprising/unexpected answer or it will point out that the other party (say the stakeholders) are not really sure themselves maybe haven't even thought about that specific issue. (BTW, it works pretty well outside of software as well.)
I’ve found that usually people are thinking about things completely differently, are not on the same page at all, and don’t ask enough questions to validate and find that out. Also it doesn’t help that most people massively overcomplicate what they’re trying to communicate and it takes multiple rounds of pointed questioning and simplification to get down to the actual requirements.
It is how experienced programmers operate. Software Architect is a corporate title created to provide the appearance of a promotion along with an increase in pay. Obviously consultants like the idea of giving themselves a fancy title too.
Very very good discussion. I prioritize TCO a lot, KISS, simple stack and documentation. I like making internal web apps which don't have lot of users and tend to be complicated, so I actually make videos for the users describing the system and how to use it.
I had a larger project I made as a Windows Service that got moved to AWS Cloud as a lambda by this brilliant guy. After seeing his code, I complimented him on how clean his code was and apologized for how messy and full of notes mine was. He said "Oh no, without your notes I could never have figured out what the application needed".
Another great video. Your content is down to earth and always relatable.
Hey Jayme,
I just wanted to drop by and express my sincere gratitude for your fantastic video, Your insights were incredibly enlightening, and I appreciate how you condensed such complex concepts into easily digestible points.
Your emphasis on the importance of experience in shaping a successful software architect really hit home for me. It's clear that your two decades of expertise have provided invaluable wisdom that aspiring architects like myself can learn from.
From zooming in and out to understanding tradeoffs and embracing change, your breakdown of key skills was spot on. Your insights have given me a fresh perspective on what it takes to excel in this field.
Thank you for your humility in sharing your knowledge and for being such an inspiration to the software development community. Looking forward to more of your insightful content!
Best regards, from Colombia
Duber Lopez
Glad you enjoyed it Duber! Thanks for the kind words and the encouragement.
There is a nice video on UA-cam where Dave Farley interviews Gregor Hohpe, on the "architecture elevator" concept, which is similar to the zoom in-out that you described.
I would add to the "humble" aspect, the willingness to be wrong, and be aware of the ego traps that come with the title.
😂 I Can totaly relate to “ ego trap” with the title. I am a new architect, after have been developer for 12 years.
Thanks Jayme for the input, it will help me in my decision of recruiting a CTO/architect for my startup.
Best of luck. I can imagine that's an uneasy hire. Hopefully you two are able to collaborate well.
This is very accurate. I've been in these tyoes of roles, mostly in startups, for over 20 years. This tracks well with my experience
I really like your points, but want to add one: mastery of shielding and guiding toward new tech/frameworks. Enthusiastic developers tend to try to introduce into the system new shiny things they read or heard. Big conferences are big drivers of such conversations. In most cases, you have to shield this off without conflict. Sometimes, through discussions, guide the enthusiast towards valuable insights and solutions that end up in the code.
I like it, good twist on some of the things I've covered here.
This is important, but not an Architecture job per se. More like a Lead Developer / Senior Developer. But if there is no-one else who will push back, the Architect definitely should.
Good point. Just not swaying too much in the wind in general. Young developer tech fads, product tries to get over their skis chasing trends too. Management get buzzword infections. Architect needs to steady all that and maintain the integrity of the totality
thank you for this video!
Love this channel
I like the guitar intermezzos. Subbed.
Welcome to the channel!
Busting out the guitar in transition
Another pattern I have observed in architect is that understanding any given problem and creating a simplied model of the problem by removing redundant dimensions
Love the transitions with the guitar . Good stuff
I love your channel, you should do a video on how to handle having a project you fathered gets gutted or shelved.
Hey there, I've got a few videos that may help with that.
This first one is about my first software project, where I was swindled off the project I started: ua-cam.com/video/d4hFQyuKVhs/v-deo.html
The second one is about a project we designed that never got built: ua-cam.com/video/4E9TnpVBA6k/v-deo.html
The third one is about coping with a project you know is going to fail: ua-cam.com/video/occRAArkZqc/v-deo.html
Not sure if any of these are directly scoped to your original question, but they do have some nuggets of things I've learned that you may relate to. Hopefully that helps.
I have always said that it’s to do all the boring tasks as well. Budgets, spreadsheets, solution documentation and helping sales. Booooring
Also the dealing with [architecting] 'people' side of the deal.
Have a look at Clarke Ching's Rolling Rocks book [software business novel] to help grasp some of the "It's technology, but not as we know it" aspects.
Good analysis 👍
5:45 is particularly important for this role.
The most important skills of my current job (SE on a dedicated architecture team) have been diplomacy and evangelism. Listening, learning, and persuading people in ways that they care about and understand, guided by the end goal of making the product better and making the lives of the team members better.
Try to put yourself in the position of the team as often as possible, as if you were on call too, and everyone is as human as you are - they all have lives and feelings to be curious about too.
Would love to see you do a video on "Competitive over engineering".
I like the piece of music at the beginning of your video - the one that goes with the title. Did you compose it yourself?
I think thec communication mastery is kind of lacking in a lot of education so maybe another video on that part will greatly help as well. Since alot of technical decisions or work has be discussed and by not having that communication skill. You run the risk of not meeting expectations or taking on more than you can chew.
Sweet guitar work!
Nice playing!
What i'm getting from the majority of these points is someone with tech and code chops but more importantly specfically for this role is deep emotional intelligence in the broadest sense. Also sounds like you're the Team Mom type keeping the peace between all the different departments coordinating everyone and making sure everyone ends up at the soccer game at the right time.
IMO , good list, I would add:
innovation element- item one and eight free up time, that free time is spent with innovation across all elements of software systems eg external frameworks and techniques, technology demonstrators, experiments and lab work.
and as an extension of innovation,
continuous learning - always on the lookout for new technologies, tools, techniques and skills to bring in to the organization, these may come from surprising sources, not necessarily just within the software. Then using item 4 (low ego) and 6, (great communicator), be able to teach those new learnings. In the process of teaching you get to a much deeper understanding.
Would love to hear some thoughts around the Architect role's responsibility towards assuring dev capacity is allocated to advancing knowledge. Often times I find dev is too busy in the throws of their day-to-day work, and if they would be granted time for their own development it would pay immediate dividends to the quality of the SLDC. It's risky to leave this to happenstance.
Embrace change: for decisions always add the expected obsolescence date (especially where the competition [of all sorts] will take over from that of the decision). It's part of planning what you'll be looking at next year (or whenever) ;-)
I think you could mention that picking the platform for communication is highly critical component to communication. Will the architecture and technical aspects be communicated over email, sharepoint, or pen and paper? These are critical choices in communicating for the lifetime of the engineering effort.
Hard to overstate communication, it can kill your architectural effectiveness, and not just written comms but presentations, team/group, individual, etc. Also related to selfless decision making is consensus building. There is no better way to get a team to buy into the architecture then by building consensus and involving them in the decision making too. Social/soft/emotional intelligence, whatever you want to call it, these skills are at least as important as any tech skills you have.
Mastery of communication is really a key, as I have experienced from my very limited professional experience as architect. I have been so challenged by this and still am, but I can feel the improvement.
Great video 👍
Glad you enjoyed it!
If I may ask advice. I'm a Senior Front End Developer with around 9 years commercial experience in large scale web applications. I'm really good zooming out, making sure code is modular with minimal dependencies on other components with dry declarative code almost completely abstracting away imperative code where logic is performed to make the code more readable, I have no problem zooming in when I'm working on something and have to stop myself from over engineering (by removing things and abstracting not adding), but if I need to scope a project the micro code functionality is barely a consideration, I tend to quickly look at what the code does abstract that into a chart and zoom back out which is where I tend to prefer to be. Do you think they are the credentials to look to advancing to another level, I'm approaching 40 and I can't be a programmer forever but love the rush I get from thinking about the ideas of how things go together.
If you’ve got 9 years of experience there are a lot of directions you could go. The main thing you’ll probably need to ask yourself if you want to go to the next level, is how willing you are to learn more skills that have less to do with code, and more to do with empathy and communication.
I’d have to speak with you personally to understand your history and desires better (hit the coaching page on my website if you need any help) but I don’t see any reason why you can’t move up if you’re willing to get out of your comfort zone a little!
I'm exactly like that. "Can't be a programmer forever" is the thing that I am worried about. But this comment sums up everything I love about what I'm doing now. I'm not that close to 40 but I hope I can do this for as long as possible. I like to help smoothen communication and bring people together but I like to talk about user requirements and best practices/ education/ frameworks/ design patterns more than end-to-end architectures. I think the key thing he said here that confirmed for me I should not go into software architecture is I don't have any interest in cloud frameworks beyond how can we make them cheaper and more reliable AND can someone else explore it if I find a solution. haha
@csy897 some companies have "platform architects" or "systems engineers" who focus on the cloud. Whereas there can be a pure "application architect" role that's more about the web/business/mobile application and its services - more at the framework and domain level. Not sure how your company is setup, or what you want to do, but it's definitely possible to move into architecture and not focus on cloud. You will of course be limited to companies that have that structure (or aren't using cloud services in a complicated manner - which can be perfect depending on their scale!).
11. All great software architects play guitar!
12. Get feedback from the developers including devops and DBAs Looking for design/implementation, problems and potentially new technologies to investigate.
This feels right on point.
It seems like an unreasonable burden to suggest that architects should know every detail of every project. That person is basically just a super-developer and you might as well just have them write all the code while they’re at it, and put them on a one-way trip to Burnoutville.
There probably has to be some happy middle ground between “knows everything about the codebase” and “hopelessly out-of-touch astronaut”. In theory, the architects are the ones making good long term decisions that prevent the application from starting that long slide into legacy spaghetti hell, and I’m not sure that they really need to do anything else beyond that. Of course, this means they also need to have a pretty good understanding of where the code currently is, and they also need to be pretty persuasive and able to communicate clearly to the rest of their technical staff. But fundamentally, their main scope is keeping the codebase from falling apart.
That’s a really good point. Thanks for offering me an opportunity to clarify. There’s subtlety in what I said there I can probably be clearer.
When I talk about “zooming in and zooming out”, I’m not saying an architect has to know every detail of the codebase. I’m saying they need to have the technical ability to understand the details when they need to.
For example, if someone I’ve provided architectural support to is having a problem, I need to be capable of going deep to understand the problem so I can understand if I might need to change the architecture to help them out. But that doesn’t mean I need that level of understanding for all the code across their project.
Hopefully that helps a bit. Thanks for the feedback! 👍
@@HealthyDev Fair enough, thanks for the clarification and I agree! It's absolutely a problem if an architect doesn't have the *ability* to dig into a part of the system and understand the nuts-and-bolts of what's happening.
I work in a codebase right now that has a substantial amount of business logic buried within SQL stored procedures that are in some cases 15+ years old and more than 5,000 lines long. It's pretty prohibitively difficult to fully understand the entire flow of code constructed in that way, but it's certainly possible to claw your way through bits and pieces of it on-demand.
Well put. I wanted to be an architect at some point in my career and I am really good at all those points. But the problem for me was that I have a language barrier with an Austrian company and I know I will not be able to communicate well enough. I would add that as number 11 ;)
At least I can be architect on a smaller company and product, but at least after 5 years of constant development I had a preety good results. Due to the size of the project I do spend around 20% of my time for actual development.
Thank you for the video!
Have you considered a pronunciation coach? I suggest this for some of my clients who don't speak the native language.
@@HealthyDev I did, but at the end I have decided to keep my position as a lead dev. I am ok with that because I am moving into homesteading slowly. Much less stress :)
Btw, English is also not my first language but I really do not like German so it would be even harder to learn it. 12 years of German in school did not help either ...
@@matjazkranjc3511understandable. I had 4 years of German in high school, but it was pitiful at best. Completely forgotten now.
Monsieur vous êtes excellent! Merci
A software architect must also understand and know the programming paradigm at the different tier-levels- such as data persistent-tier, business-tier & presentation- tier
I looked at one of your videos from one year ago, and am now looking at this one: I notice that you are now using a sort of "haze" effect that makes the video look like slightly aged film/vhs, or as if the gamma has been adjusted. I have noticed this effect in House of the Dragon, Andor, and The Batman. Can you (or anyone) tell me if this look has a formal name? It looks very, very cool and I'd like to use it in Adobe Premiere or After Effects, Davinci Raw, or any other video editor I can get a hold of.
Hey there. I thought some of my videos looked a little dark, so I raised the shadows by 10 in this one (using Davinci Resolve). I actually didn't like it, I thought it was too much. I do use a Tiffen black pro mist filter in every video however, and do a little minor color grading as well, so you might be seeing that more than the shadows being raised.
It's resulted in a very nice look!@@HealthyDev
Thanks Jayme!
You're very welcome. Glad you got some value out of it!
Curious about opinions on this. Do you think that Software Architect should be a goal for every engineer? Or is it one of many branches at a certain career tier?
Just my opinion (I’m interested in others too), but at least in my experience software architect doesn’t need to be the goal for every engineer.
Plenty of people stay at senior, become product managers, get into consulting, shift to people management etc.
The more you know yourself and what you do and don’t like about what each tech role requires (and there are many!) the more successful you’ll probably be.
No and yes. Some engineers are twiddling bits for their entire career and end up well paid and respected, with a job they love, others switch to something else entirely, like sales. Architect is an interesting career path because it is kind of a middle ground between leadership/management positions and purely technical jobs like coding, but it is far from being the only option.
Ive been a dev for over 30 years and I can relate to all of these points
1-Knowing how to push back from PO asking non-sense and 2-Pushing back management from hiring junior developers for important projects.
1 is arguably more of a Team Lead or Lead Dev responsibility (or even a whole-team responsibility) rather than something specific to an architect. 2 is also, IMO, more of a Team Lead/Lead Dev responsibility. Architect _can_ potentially push back as well, but generally speaking I think that focusing on team composition is beyond the scope of an Architect's core responsibilities.
yeh don't hire jr devs we don't want to train a new workforce right? your gen is so selfish f boomers
I think an architect can rarely make those decisions. As soon as you stop using the tools you're preaching you make bad decisions or get out of touch with your devs.
Especially in software dev. I would have no idea what tools work great if I stop coding for 5 years and only Design stuff.
Thanks for the feedback. Maybe the way I communicated this could use some improvement, or because I didn’t explicitly address your point it left you with a certain conclusion.
I’ve dealt with “ivory tower architects” - people who design and make decisions, but never implement.
I’ve also been in situations where a client wants me to do architecture work, but ends up trying to get me to do the heavy lifting on features of a code base.
In my experience, when I make a technology selection, define a pattern, or select a tool, I’m going to be using it over the lifetime of the projects that use it to enhance the architecture and help people when they get stuck.
So it’s not a “set it and forget it” situation where I fall completely out of touch with whatever architectural assets I provide.
At the same time, it doesn’t help me provide the highest value I can as an architect if I don’t get to do it very often because I’m mostly writing code for features, and only doing architecture on the side.
There’s a range of ways to define the role between more defining of architecture, and reusing it to be sure. Since I’m encouraging people to be a healthy software developer, I’ll probably always err more towards not doing both. I’ve experienced too much burnout when I do that, and from speaking with other coaching clients, I’m not alone.
You definitely bring up an important issue with the role and one people have to probably wrestle some with on their own to figure out what’s going to be best for their specific needs and situation.
I agre e110% here. So we got the team leader who dev 5-10 years ago and now only manages.. but yet wants to be giving input about design/code etc. They are out of touch whats going on in dev space.
OK I see what you're dealing with. Thanks for the context. Yeah, that's definitely frustrating to the team. It's hard too because the manager probably is genuinely trying to help, but doesn't understand how far their skills may have been drifting. If you have enough trust with them, it might be possible to help them understand how their input is not helpful, but it's probably going to have to be prefaced with some big compliments about other things they do that developers can't.
@@jvz6790 They only real solution to that from my experience has been to change jobs or find a way to change teams that are not in the power of that type of manager. They are not out of touch because they haven't coded for 5 years, they are out of touch because they have always been out of touch, and you can't help people like that, no matter how genuine they are.
I lost all my respect when I heard our architect does not write/review code anymore and just focus on high level design. I don’t know how someone can make good architectural decisions if they don’t even know the details/limitations of the system. 🤷
This is an excellent list. I also really enjoy your guitar playing. Is that an Eastman?
Yes sir! I bought it in 2018 before the prices started to go really nuts. It’s a 12 fret OO size with a mahogany back and sides, and Adirondack spruce top. The strings haven’t been changed in about 3 years. I like them dead on this guitar, I only use it for finger style. It sounds horrible strummed with a pick but great with the fingers!
@@HealthyDev well it sounds fantastic! 00s are definitely made for gentle playing and I prefer dead strings too (I like to hear the wood, not the strings). I have either Thomastik-Infeld flatwounds or very dead Martin silk and steel strings on my acoustics. Love your channel and look forward to the musical interludes :)
@@r0bophonicthanks man. I’ve had a few comments that people don’t like it, but way more that do. I have fun with it!
As an enterprise level software architecture, in my experience you also need to know how systems are connected through core routers, access routers, firewalls, load balancers, VLANs, etc. If the network architect asks for your network requirements, you need to at least somewhat know what you need. If for example you have no idea what a VLAN is, or if you haven't considered high availability options, for your microservices, for the servers they run on, for storage and connections between servers, that's just silly. Software is only part of the design. Same with security...
I would consider that a systems architect. The difference is that a software architect creates/works on a (more or less) single software system, but if the architecture includes other (external or internal) systems, then you are a systems architect.
I share this with those close to me. When it get really confusing, it only comes down to 2 things, read and write.
Thank you for making the channel I wanted to make but didn't have the time
Hello. I work as an architect. And some time ago I thought that I could make a useful video on this topic. But it turned out that I was too lazy. Your video is exactly what I would say in mine. but actually I think a lot of it will only be understandable if you've been through the same experience.
How do you start this? Or how do you the transition from a dev? How do you apply for an architect role for the first time?
In my experience, it's very hard to apply for an architect role without doing it first. You get promoted into it after doing an excellent job in a senior dev or tech lead role. YMMV
Hey Jayme, do you think that your experience in the field of music has influenced or enhanced your capabilities as a software architect?
You know that's a really good question. I read an article back in the late 90s that there was some correlation between the need for musicians to recognize patterns, harmony, etc. that could translate to software, but I'm really not sure. I wouldn't be surprised that it has had some impact, but any conclusion would be purely anecdotal.
@@HealthyDev Interesting because a week ago someone ask my what I do as compsuter scientist. My answer was: "I look for patterns in data and reveal them to other people".
That person responded: "Oh cool I do the same as a musician 🙂"
@@dickwansha! Awesome answer.
Hey @HealthyDev, Could you manage a episode for new entrepreneurs, not specifically who has funded by VC and all but small software companies and how to go about managing it specifically for developers who trying to get into entrepreneurship.
Hey there. I've got 12 videos planned for next year about solopreneurship, but not specifically managing other people in this situation. It's just not something I personally have experience with at this point of my business. Hope that makes sense.
Looking forward to it!
Great points, one thing that's worth discussing is how the term of software architect has been bastardized in every way possible by companies and programmers alike. I know many programmers that call themselves now architects just because they have the freedom to decide how to implement the applications they're working on, and I've also seen job descriptions where the architect roles were nothing more than glorified project managers. I've also seen job roles where the architect list of requirements fit more a team lead than an architect. This goes counter to the process of the industry maturing, but I think is a consequence of it being inundated by all sorts of opportunists without any real technical skills that succeed in managerial roles, and bring along with them a culture that is detrimental to an environment where proper software development is practiced or encouraged. I often like to say that if some of the companies I've worked for were to have their main object of activity software development, they would have been out of business a long time ago.
As sad as it is, I would have to say I agree with many of your points.
This is because architect is not really a position that's needed. Programmers can do the design. They can make the trade-off recommendations. In fact pretty much everything mentioned in this video is easily done by programmers. It isn't maturity to manufacture a job out of nothing just to create the appearance of a promotion path. And that is exactly what the architect position is.
@@loganmedia1142 i disagree, but that’s a popular perspective and I understand it. All developers are capable of these things, but in my experience very few are actually good at all of them. Organizations need someone who is responsible for technology not turning into a ball of mud as the complexity grows. That is something I’ve never seen done well purely democratically.
@@loganmedia1142 While there are some programmers that can do this - and they are called software architects btw, it is the same reason that an orchestra needs a conductor... not required, but nice to have. I hope the constructors are not thinking in the same terms about Frank Lloyd.
Everything you said sound perfect however the reality is different. At least my reality working with different architects is that most of them don't know how to code or code well. It is all about abstractions to them and not getting sunk into the details of the implementation. They throw a bunch of diagrams on you with some technologies options and ask you to take and run with it... I had an architect asking me to decide between a few frameworks to use for the project... Also many of them don't have a strong or deep enough domain knowledge about the product so they suggest some solution that the tech lead who is intimate with the product/code knows that it won't work...
Contractors can wear all the hats. If you are a contractor, and not an employee, then you have less leverage and ability to say no. So, contractors can design the code, then literally switch to project management, and also be a co-developer, and communicate with the end customer, write CI, and acceptance testing. Especially if there is a huge offshore development team. As a contractor, you are a tool, and part of that, for example, is to write the Detailed Design Documents.
spon on. you nailed it
I am possibly being promoted to software architect at my company. I feel like I practice most of these things you listed, but I don't consider myself very well versed in the aspects of system design. I'm not sure if I should be promoted and take the dive. At what point does a person say "I'm good enough" and just go for it? Awesome video btw!
Well, I was 23 when I got promoted (see my video about the project with inconceivable politics in the "my stories" playlist). So sink or swim is possible. Almost anyone is going to do better than I did there lol.
@@HealthyDev thanks very much! I would like to say that you are a blessing and the Lord is using your story. You are in my prayers, and please pray for me. God bless you, man!
@@furious2563thank you! Appreciate your prayers more than you know.
I think being an architect is a trait that you either are born with or not. If you cannot think big, it's not something that's easy to learn. I am like that. When my colleagues are talking about solutions on bigger scale, I just sit there and listen. But when it comes down to single modules or classes, I start having opinions on what is good code and what is not.
It can be learned through experience imo. I’m not at that level yet either, but sitting now mid career, I’ve noticed changes in myself in that direction. Hopefully not just blind optimism 😂
I hope you realize your job will be replaced soon with the AI tools
@@ChrisAthanas no it won't :)
Roy from the IT Crowd has leveled up to SW Architect? Neat!
No offense intended. Just a joke that's probably been uttered before, on your physical resemblance with Chris O'Dowd.
Thanks for the video and keep up the good work. I'm gonna check your list of videos, so I too may someday level up.
I've decided that there is some sort of crossover between music and software. Most of the musicians I know are also developers.
Hi,
I am interested in the software engineer course.
What coding language should i dive into ?
JavaScript or Python ?
Please advise.
Hello there. This channel isn't really helpful for selecting technology directions personally. You might check out some other UA-camrs for that.
Like Jayme mentioned in his other excellent vids, it doesn't matter what language to learn. What determines your main development toolkit will be your employer's toolkit-of-choice. So, just pick one you think is right for you today. Worry about learning that "new" language when you get that job offer. Good luck and enjoy coding!!
I totally agree with your list except for a small side point: microservices are the answer to a problem that does not exist 😅
Ha! The area where I see them as useful is if a team intends to deploy an individual service on a separate timeline from deploying the rest of a product, or deploying the entire product together takes too long.
Unfortunately like scrum, machine learning, AI, and most other buzz worthy technologies people want to use it mostly to say they’ve done it, or because some cloud vendor or thought leader/author convinced them it’s the way to go.
Total independence is the key. So it can probably solve team communication problems, by adapting the team structure to architecture or architecture to the team structure.
@@BartoszRybacki0 the problem is that microservices are almost always dependent to each other, but instead of calling them using code, you use the network. You think that they are independent, the reality is that you have to agree on a protocol. And a protocol is much harder than a method call. And much slower too.
I agree, it is harder, but It can solve real problems. Sometimes.
You can scale them independently (such scaling is cheaper, since you only scale parts that need a resize, one hour you serve 10 transactions/s, next hour 10000 t/s), you can deploy them independently from each other. You fix a bug, and 5 minutes later it is in PROD. Assuming the protocol did not change.
You only communicate with other teams when your change spans multiple services. With well written monolith you have nice independent modules, where the module API is the protocol. But, It is so easy to cross the boundary and bypass that API or expose module internals as an API for temporary solution ... I have seen it happen.
The thing with Network being slower than method call is true, and if done naively it can make the service a few orders of magnitude slower. But if you need to call storage, you can also call external service. Unfortunately at some point in time you might need to add batching/caching and it complicates system, adds new parts that can brake. So I think, a microservice (I have this word, it is a service) can be a local optimization of complexity at the cost of complexity of the whole system.
It is always a tradeoffs game. @@AntonioPetrelli
@@BartoszRybacki0 these words are the same that microservices evangelists say. The truth is that microservices scaling is only word of mouth and nobody ever tried to scale them and do a comparison between microservices and monoliths to show the benefits.
So sincerely I don't believe it.
how to add a structure for oyur projects
I consider that all devs should have the architect thinking you are saying, this are all good practices in the field
I am a developer at my company and I think my architect spends too much time coding. He usually codes the most complicated pieces of code which is a shame because this strips the developers nice opportunities to learn and challenge themselves. It also shows that he doesn't trust his developers enough.
He’s more than Architect if he’s doing all the heavy lifting too. He’s a doer.
He’s problably the main reason the company/product/your job exists. If it wasn’t for him the investors would still be holding dreams and ideas.
Let me know if I’m wrong.
You seem to think the company hired you to grow you not itself and the product. That’s only true when the company will ditch the architect for you while still keeping your salary lower than his.
Probably because in reality architect is an artificial job that doesn't really need to exist. Everything mentioned in this video can be done by other people and usually was.
Wow, I've worked with pretty crappy software architects. Literally every point you made, they did the opposite of that.
* Telling people what frameworks to use for every little detail, and going in and changing the small bits themselves.
* Problem domain? Pff! That's Product. We're Technology. We create technology and it's Product's job to extract value from it.
* Trade-offs? Yeah, but only as long as they lead into:
* the technology that I want to play with. Nothing else matters. We gotta keep that CV colorful, don't we?
* Change? No. Our decisions from the past were the best ever, and should never be revised.
* Communication? You mean making sure that everybody else in the room feels stupid once I whip out my techno-jargon I've gathered from all the conferences and blogs? I'm gonna give you more patterns than on my grandma's wallpapers!
* Scale? Yeah for sure we'll be FAANG-sized, so even with a total of 0.5 active users per month (I'm not making this number up even), let's split the color of T-Shirts into a separate microservice from the size of t-shirts, because it's a whole different domain, and let's have them exchange data over kafka, where each type of clothing has its own topic with 9 partitions with round-robin, but items get changed multiple times per second. Updates are processed in incorrect order? How could that BE?! (we're not selling clothes, but I'm just translating into a more common domain).
* Cost? Yeah, let's host every single database in-house, let's hire people to be the DBA for them, when they can't even set up TSL certificates for connections and restrict traffic to dev services to only be within the internal network.
That's it, I've had it! I've been ignored with my concerns for far too long, and the "architects" they do end up hiring after all of those got fired, start telling "have you tried using that tool to solve all your problems that I don't quite understand?"
Yipes, I definitely did not mean to make upset you with this one. Just trying to share what I think is important to the job, but not trying to make people feel bad if the architects they work with don't care about these things. I can understand your frustration, that's got to be hard.
I often have to deal with compromise when it comes to working with other people. It's up to each of us to decide what we're willing to put up with.
Not trying to invalidate your feelings if you are upset thinking about this stuff - it's understandable.
@@HealthyDev no, I'm sorry my half joking comment came out as criticism of you. I'm actually resigning, because after years of resources spent on this, still didn't get things to work. I'm one of the closest things to a de facto architects, but the best I can offer is opinions and they are rarely followed. We did get one real architect consult our business for a while. He has a track record of many successful companies. He worked pretty much how you described (a role model for me), and what he proposed was quite different from everything else, and was actually achievable, but he was ignored, and now we still have an event driven architecture written by people who aren't even familiar with problems surrounding concurrency or latency - most of them are just inexperienced. And the data and user base we're supposed to manage could literally fit on the smallest SSD you can buy today, and of course it's mostly not working.
So I do have anger and resentment, and your video only confirmed what I already knew. I'll need a lot of such videos and talks to combat all the gaslighting that has happened to me.
The main thing I had to teach myself as an enterprise architect is to stop fussing about details. Once your landscape contains 900 applications you cannot get lost in the details. Yet you still need a lot of knowledge to know when someone is trying to sell you bullshit.
I should clarify this video was aimed more at application architects, or platform architects. Yeah, Enterprise Architect has some unique challenges the others don't!
Produce good estimates over the time and help the team to do the same.
Inspire the team to produce quality software and make smaller decisions autonomously.
Ability to handle politics (applies to all roles in an engineering team)
Yup! But it can be a challenge if you see bad code or wrong technology and try to explain that to existing programmers. Does not always work.
The team members are the only ones producing estimates. Managers and/or agile coaches do the inspiration and help less mature teams learn to make decisions for themselves.
Either your mic or audio encoding is not good enough. I am listening on mobile and not enjoying the audio. However you speak every word very clearly.
It is all about the cost. I see every day that decisions are made based on assumption that hardware is cheap, storage is cheap and linux is free. And it constantly backfires. Sometimes I win, and nothing bad happens, sometimes people above me don't listen and have to deal with surprise bills from the cloud or extra licenses, because they assumed that everything running on linux is free.
TOGAF takes consideration of the users and people using the workflow.
Software architecture is primarily an exercise is SOCIAL engineering. Software architecture is primarily a people and politics problem. Communications is only a part of it. Decision making over trade-offs are always exercise in negotiation. Think of your video about the value of confidence in a programmer over technical chops, as the same thing applies to architects as well. Architecture too frequently becomes an exercise in fashion.
I think you should be the Japanese Jaguar XHR with manual gear box swap coder first to know all the code and be able to describe the task to anybody else not getting deep into that VSCode, but possibly you or your work competition work with metal junk all day so need some new fresh faces Nigh Cop Chase for QA search query.
what chord progression are you playing?
Hey there, all the guitar parts in my videos are things I've written over the years. Some are parts from songs, some are just little "ditties" I've written.
I'm surprised there are companies that still have this as a job title. There's nothing here that programmers can't do. It was really just a title created in bigger companies before they recognised the value of having more pay levels for programmers. Basically you'd hit a sealing and your only option to move higher was software architect. I found it really weird the first time I worked at a company that had dedicated architects.
While that's true, when I see every developer regardless of experience level try to take on all these things, it creates inconsistency. Some of the worst IT messes I've ever encountered were companies that grew and never gave anyone responsibility over architecture. A culture of "everyone choose your own architecture" is great in theory, but doesn't work as you scale.
I've been a lead developer right now for a few years. I have made some very successful projects under my hood (project estimates were correct, no overworking, ecstatic customer, almost no regressions and we had a 95% test coverage), so I thought I would have the best papers to become architect. I did help other teams with projects that did not go well and was puzzled in what terrible state it was. I did not think this person was worthy of a leads role. Guess what: they made this lead the new software architect.
And the next new project I started in was so big, that the company thought we needed an architect in this project, so I had to address everything with him while I saw no reason that I would need an architect with my current project history. The project did not go well, which was a first for me. Eventually I left the project because I got a child. A different lead worked with him and 'succeeded' the project by just working 60 hours in a week and lots and lots of meetings how the project should work and also much past the estimated deadline.
So what did I learn from it:
- You can not make someone an architect if this person is not having respect from the team. The project is doomed to fail.
- I can not work more than 40 hours a week because I have kids. To me overworking means you have not estimated your project well or you get easily intimidated. If the company thinks otherwise, then it makes sense they'd rather have me as a lead then an architect
- i'm good in seeing the entire picture of a project, but I can improve in communicate it with non-technical people
- the reason they made this person the architect was because the company wanted to switch to kubernetes and I have zero knowledge on it. So I should look more careful at what the business could use on a technical level and communicate this
I’m not sure I agree with the specialized technology expert part. From my experience, there was never a new technology I couldn’t pick up within a week. And when I hire devs, I don’t expect them to have any specific knowledge about any technology, but instead be able to learn anything. Any devs that are React devs or web devs or mobile devs, are not actually that good.
I agree completely that a learning culture at companies (which is what you describe) is optimal. I find that to not exist in the vast majority of cases, so I tend to give pragmatic advice on the channel. Hope that makes sense.
I landed here to prepare a new video for my channel with the title "how much time should a sw architect spend in coding?". What's your ideal percentage? BTW, great video I agree with you for points.
That's a good question, but I'm not sure I can offer a blanket answer. It kind of depends on the type of architect role, and what your specific responsibilities are at the company. Wish I could offer something more concrete!
Jayme, what I feel like - employers are not looking and not interested in our opinions as developers. :) They want us to do what they want us to do. :)
Unfortunately some companies really do treat us like code monkeys! Luckily not all. Finding those healthy cultures is hard. We also have some things we can probably get better at to persuade people to listen!
I think it is good for a software architect to care about the cost but realistically you should have another role for that. Even for accounting you have an international tax accountant to come in and ensure the company is only paying the taxes they have to. Similarly, if your application is costly enough, you would likely benefit from having an expert who knows the market to offer alternatives and ensure that cost is kept at a minimum while the software architect determines whether the alternatives are sufficient for their purpose. I'm not a software architect but I feel like a lot of money would have been saved if governance was involved in cost as well.
I think I get the gist of what you're saying.
By saying the software architect should be cost sensitive, I mean we are often in the best position to know when selecting a technology whether one will be higher effort than the other, cause more troubleshooting to be done, etc.
If involved in cloud architecture, we should probably also be capable of estimating the costs to use various services with usage fees (though that's a bit of a black art in itself and never right the first time!).
I'm definitely NOT saying we need to forecast those costs to the level of detail of a CPA or accountant. I hope that helps a little.
@@HealthyDev Yup I feel like the black art part is the part that needs to be covered. We can't always get it right the first time but we need to have accountability on how we should change the architecture as the app grows. And in my company, there is no one covering that. I'm not sure if a software architect is responsible to look into this but it doesn't feel like that where I'm at?
For example, I worked with my tech lead to suggest a change to the architecture that would save us 150k a year (and more going forward), but no one was willing to give us the resources to make that change.
As a junior dev I built a method on one of the libraries that we use that would essentially cache some apis that would save 80% of those api calls but it was not implemented until this year when we reached a breaking point.
If we had a technical person governing just that there would be much more accountability.
@@csy897 ah I see. The tricky part there is, does the business want a 150k a year savings more than other stuff? Are 80% less of API calls something that's going to get them brand recognition, new customers, or save money? If you can't put it in terms that can be prioritized against other things the business is focused on, they probably won't care.
@@HealthyDev Well said. Spending 1 dev day to save 150k sounds like a no brainer, except in the big picture there is the option to spend 30 days to get a 10mil$ customer. This is something that most new devs have a hard time accepting, that technical debt is only debt for them. For the business it's very low on the priority goal, sometimes dangled as a carrot in the interview to entice eager devs, but in reality is very far down in the priorities of the org. Both sides have their fair points, but only one side controls the money.
Yep. Sounds like you have a pretty sober grasp on the situation. It's a hard lesson for many to learn.
i think titles are given too freely to less experienced developers. id expect a software architect to have considerably more years of experience behind them. it's laughable and doesn't do our industry credit when i see 25 year olds with the title of senior software engineer let alone architect. That said, great insights - thanks for sharing...
For sure. I was promoted way too early.
I talked about that in the story of my first software project. You may have seen this one already.
ua-cam.com/video/d4hFQyuKVhs/v-deo.htmlsi=HggTUDTv7-3sAsFP
I don't like this gatekeeper ageist mentality. If someone knows enough about a business to understand the pains and provide solutions, they can be an architect, age or experience doesn't matter that much if the drive and intellect is there. They will probably fail, like most of us do, but they will also learn and improve, like we did, and that doesn't make it laughable.
We work in an amazing industry that empowered us to start learning from childhood, something as trivial as messing with an .xml file to "hack" a game or running your own online server for a game can be a enlightening moment. We should know better than to spout this bullshit that "25" is too young.
You want to talk about doing this industry credit, how about we value people based on their merit, not their age or "pick an arbitrary number" years of experience in X tech.
@@cristi724 you make a valid point with regard to merit… I concede a perspective I had not taken into account…
@@cristi724fully agree, there are 17 year old geniuses building their own virtualization stacks from scratch, and 35 years old "React developers". age means nothing. it's your brain power, passion and endless nights of hard work that matter.