Off topic, but you know the person doesn't play chess when (this is very common) they think that a chess master can spot a mate-in-1 and nobody else can. Mate in 1s are fairly easy to spot if you've been playing chess for, let's say, 2 years. In reality, a chess master would spot something like "bishop to queen whatever, rook takes bishop, pawn to whatever, rook takes pawn, queen to whatever and then you have mate in 2"
I'm only whining about this because it's too common a cliché in popular culture.
Yes, yes a thousand times yes. In fact just the fact that mate is invariably imminent in movies and TV is annoying. Also the board seems to have the wrong orientation more than 50% of the time which basically violates not only statistics and probability basics but fundamental principles of the universe.
You would think there wasn't chess clubs all over the world where you can walk in and find people who know something about chess and copy their game. Just copy a game two ~1700s play in a friendly match and have your characters play that exact game - you will have your choice of games so you can choose who wins. Get the best player in the club to advise you if you want the characters to talk about something - it isn't hard to get this right with a little expert help.
The term I think is important to mention with your example is “forced mate” wherein the moves force the opponents next move with absolutely no choice except to play the rest of the game down a significant number of points.
The first time I saw grandmaster level play in person was a queen sacrifice which led to bishops mating the king in short order.
A forced mate is _forced_. There are no options except to be mated.
If there was a way to not be mated it'd be referred to as "Tactics" or just "A Combination".
And further annoying pedantry: there's no points in chess outside of match or tournament score. Pieces have _possible_ pawn-equated values that someone can use for evaluation, but those are very loose. It's possible to have a naive material evaluation that is not in your favour and still be in a significantly winning position. Better players think in terms of a pieces ability to control squares, how soon it might control squares, the importance of those squares, the potential value of reducing another player's board control, the ability to create tactical threats etc... there's a couple dozen potential evaluative concepts that are often more important than piece value.
Funny enough, your example of a queen sacrifice demonstrates this ;)
Here's my understanding: a piece's value is dynamic, and it depends on the type of piece and its position on the board. Positioning leads to all other aspects you listed: controlled squares, to-be controlled squares, tactical threats, and so on... (hence the popularity of "positional" chess where there's no concrete threat or plan behind a move, only improving the position of your piece, which may create opportunities later). I believe this is also how Stockfish chess engine evaluates a position, and it has higher elo rating than any human player.
Having all those said, the type of piece is still the bigger factor in deciding the value of the piece. You don't often see a queen-knight trade for example. Queen sac is definitely something you don't see every game.
You aren't wrong, but there's a nuance that I was trying to clarify on.
Regarding the idea that you rarely see trades of uneven values: that is largely because positions where such complications are likely tend to be avoided by most players. There are notable examples of players that make/made such trades disproportionately often. Morozevich, Tal, Shirov, Tate, Shabalov, Speelman, etc..
Playing in that manner is largely unusual because it is mentally fatiguing, risky and easily avoided with modern theory.
To go a step further, no chess player younger than their 60s would use descriptive notation. Algebraic notation is the norm for anyone in the chess world.
Bishop-D4 (bd4), Rook takes C5 (rxc5), h3 etc... would be used.
Even older players that are still active use algebraic notation. You'd have to find someone out of the chess world for quite a while before you ended up with someone that used descriptive notation as a hard default.
You know, this is true even in countries where (my luck) old editions of chess books are printed without updating the notation to algebraic. Turns out people buy and read the books, but when they talk about chess, they use algebraic.
PS. it's changed a bit in the past few years, since the older books aren't being reprinted as much.
Yeah, when I was playing as a teen (with a lot of free time) I on occasion would plan up to say 12 moves ahead (with pruning on less promising paths), and I was definitely far away from being a grandmaster.
Any master against me can call mate in 40 and be right.
I did remove grandmaster though. Grandmaster is a lifetime title, while master is something earned and taken away. Thus former great can earn grandmaster and then go senile and play at a level below me - well at least in theory, I don't know if any exist but I'd love to play one just so I can say I beat a grandmaster.
I doubt any grandmaster will have any problem in forcing mate in less than 40 against me. Many real games don't get beyond 40 against opponents who are not nearly at that level.
You are still ignoring what multiple people have tried to explain to you.
"Mate in X" is not a show of bravado about how quickly a grandmaster things he can beat _you_ specifically. It's a mathematical property about a position. It doesn't matter if Carlsen or a chimp are sitting on the opposite side of the board, "Mate in X" means the same thing.
Well, that's helpful and a good use of everyone's time.
We have the lingo because while chess is not solved, "mate in ___" are situations where there is a definitive, provably optimal solution all the way through the end of the game. Calling "mate in 40" at the beginning is not one of them, no matter the relative strengths of the players involved.
Let me tell you about the time I was called in as an architect to a technical meeting. Two teams were baffled why their systems weren't integrating properly, and each was heatedly pointing the finger at the other.
Annoyed, I pulled up the code for the system call that was failing, and within a few minutes I found an int64 that was getting truncated incorrectly.
I pointed it out to the team in the room. The shouting match suddenly grew very quiet, and I strolled out the door in satisfaction.
Sometimes, on rare occasions, it is a mate-in-one.
I had something similar but unlike you I was freshly in the company and it was a room full of people close to retirement.
When I saw the suspected error before the meeting I spoke to one of the guys. He said I absolutely cannot mention the issue right away. He helped me workout a couple of questions I could ask to nudge them in the right direction.
When the meeting started the Director of Infrastructure, some people of the accounting department and a couple of the IT people supporting them were shouting at each other and trying to find the one responsible for the fault(this bug actually cost them a couple of millions).
I interrupted them by saying I don't care who's responsible and asking the questions I rehearsed. The director of infrastructure who was supporting the accounting people then found the issue(he retired a year later and yes weird structures in that company).
Anyway, the guy was really proud and the accounting department was praising him and the blame each other games stopped until ...
... I had my 1on1 a while later and the CIO told me that he heard I was yelling at people in that meeting.
Yeah, but sometimes it gets you fired. Different company, different situation. Careful with this kind of advice.
People like to think that the world is this magical place where in the end you get what you deserve when you collect enough good karma and do the right thing, but it isn't really the case.
I noticed that oftentimes software developers on senior levels (and "architects" too) when faced with a problem, would start speculating about solutions without gathering the necessary information about the problem first. They would theorize that the problem is likely caused by something or maybe something else, then the solution should be some other thing, etc, etc. And they can go on and on along that path, because they have enough experience to do so. But in reality, all such speculations are bullshit. They should have realized that they missed some key information and instead of speculating, gathered the missing information first. Doing so would have saved them a lot of time and unnecessary meetings. I consider this a skill: to understand that there is a missing key information/knowledge without which all speculations are of little value, and what needs to be done to obtain that missing knowledge.
Obviously there was dysfunction here, but not just with the managers. It was the engineers in this case, on both sides, that were convinced the other engineers had screwed things up, and they were kicking in their heels as hard as they could rather than trying to debug it.
If the argument the blog is trying to make is Architects can't know everything then it's a bad article to submit.
On the other hand, if the argument is a boss should not expect someone called Architect or senior engineer etc. to be able to troubleshoot based on experience I have a problem with that.
If someone can't be air dropped and they have a title that is intended by the business as code for a senior level software person who can think of how to build systems and can also build them themselves, then I am not sure what they bring to the table.
This is the problem with development for, forever. Most of the time, people are tasked with: Here's the spec/user story/loose idea/unrealistic wishlist, and can you be done before this weekend at least?
What's the problem again? The facilitation of foundational discussions and exploration is seen as waste. So the business spends X months building the wrong idea, without any feedback and adjustments along the way whatsoever instead.
To air-drop someone senior to set things straight. What a great way to sabotage organisational learning and simplification. Not that anybody gives a rats ass about eachother anyways, right?
There are a lot of problems in the industry but the experienced helping the inexperienced on demand in response to a crisis doesn't seem like one that is nearly as serious as others.
I am old enough to have been on XP teams and to have become a certified scrum master in its first few years. It's gotten out of hand. Being agile and blasting to an MVP is fine for people who think Netflix or sending dick picks is mission critical but with IOT and AI scenarios emerging that allow all the little software napoleans to fuck up something serious or inadvertently create a universal spying machine it might be time to put the breaks on for at least a class of problems.
No industry hates old people as much as tech and that industry has people all over it like an idiot on another thread who clearly had no idea who Brian Kernighan was when they wrote their post. Young programmers have always been arrogant idiots. I was one myself. But it astounds me that many programmers today don't even know a ton of stuff that would make their job easier since it is shit that is already figured out or is shit the science says can't be figured out.
I hate people that wallow in history as much as the next person with an ounce of inclination to independent thought but for fucks sake learn some basics before applying that code golf to 20,000 cores because that shit costs money you free food demanding little jack ass.
As for building what the customers need or want? The more time I spend around programmers the less inclined I am to want them deciding anything for anyone in terms of features.
If you're blessed enough to be great at programming and picking things people actually want or need then you'll be too rich soon to bother with stuff like being told to help a team fix their shit anyways.
I think you are saying you want the industry to be better. I support that. But until we get there, the need for people who can airdrop is going to be there. Sometimes you may be dealing with a fortune 50 like customer with lots of $$$ in play or a smaller customer who needs to get something running or they are in deep trouble of going under. It's not so much about looking inwards sometimes as it is about helping customers who depend on the crap that was built to get past the bugfest the industry seems comfortable selling all to often.
Senior/Architect level here. This. And, much of the time, the architect's drop-in approach has been considered and rejected by management already. Sometimes for good reason, sometimes not.
The reason is most of the time not that the manager expect the architects to solve the problem but to get a clear picture from someone they trust, communicate it management friendly and then make the tough decision the developers are often afraid to do or to sell their managers.
There is no problem solving in these situation. Just assessments and peer reviewing of the stuff the developers do.
I know people who are good at architecture but I always get skeptical when people have the title “architect”. If they don’t keep working in the weeds I feel they often get out of touch soon. They may be good at doing nice presentations but their designs become more and more unrealistic.
Any software "Architect" who can't build what they say to build should have to get a new job.
Any programmer of less experience who continues to argue with the "Architect" after they have met the challenge of proving their ideas can be done should also have to get a new job.
Many less senior programmers are better at the every day idioms of a given language or tools used in daily programming. Many senior people have to do more than just code. But most senior people who can still practice if called upon are much better problem solvers in part because they have already failed so many times and each new batch of programmers keep re-inventing the same mistakes.
Generally true but some architecture jobs have you designing solutions across multiple technologies that you just can’t be expected to master. Sometimes you need to rely on experts, including devs or other architects. The job then becomes finding a workable rough outline and then checking it heavily (and iterating) in areas you don’t fully understand. You don’t spring fourth a design so much as collaborate one into life.
I like people who want the right answer more than those who want to be right.
If I take your comment to mean collaborating is good and some people are better than others at parts of a solution because they are currently specialized I agree. The "right" answer is often difficult in practice especially when you depend on many other teams as dependencies and need to get something out the door.
On the other hand if you're drawing diagrams of things you haven't personally made sure could work well together at even a trivial POC level then I am not a fan because that is precisely why some devs hate anyone who is called an Architect.
> if you're drawing diagrams of things you haven't personally made sure could work well together
If you're producing work products that don't accomplish their job, then you're probably just not good at your job, architect or no.
In this case, the diagrams are to guide development toward an acceptable conclusion, but if they instead impede or misdirect development then you failed.
Fortunately, there _are_ lots of ways to validate a technical design, among them toys & POCs, but also rtfm, reference works, etc...
The architect needn't rough things out in code all the time, though.
What toxic pit do you work in where junior programmers are ARGUING with senior architects and the senior devs aren’t mentoring, reviewing and empowered to make key decisions in another room before junior developers ever see a spec? And how do I avoid working there?
A1) Your typical mega corp that is too big to be one thing and filled with geniuses around every corner. So some parts are a pit and some parts aren't. It depends.
A 20 year old "startup"/feature factory where all the original talent left years ago and everyone in an IT management position has been with the company less than 6 years. The majority of developers(200+) here are hired fresh out of school, or only had 1 previous employer.
Now the CEO spends all day courting the "institutional investors" so he can secure his retirement.
I've seen this in a couple of places. Junior dev assigned to design new system. Senior dev assigned to mentor junior dev. Senior dev encourages junior dev based on experience. Junior dev ignores everything senior dev says. Manager listens to whatever junior dev says and sidelines senior dev. Senior dev goes on vacation. System explodes.
I've been at a mega-corp that let newly hired developers to build new stuff while senior devs are busy putting out customer fires that in many cases, were caused by those junior devs in the first place. "We want to make sure the junior devs have interesting things to work on so they stick around."
Not really. A new system means it is not in production yet, so if something goes wrong there is little impact. Breaking the working system doing maintenance can cause lots of problems, so it is seniors who are tasked with changing it.
Your manager should be called a practice lead and they should have recently been a senior dev. They should have been picked by other senior devs as the obvious choice since he’s the guy who spends more time on lunch and learns than writing code.
I used to joke that the term "business-to-engineering psychologist" was more descriptive than "software architect". You had to know how to get people to agree a lot more than how to get technology to work together, especially in "larger organizations". It's politics, pure and simple - most of the conflict isn't technical.
And then you go another level deeper and see everything is actually just different ways of doing the same old Linux and/or Java. I feel especially in Ops people can see that all the time. For instance just today I saw someone debug a NO_PROXY topic in Kubernetes. Kubernetes is super cool and works different than the old LAMP stacks or even Openstack. But still they deal with NO_PROXY not being standardized problems. Also shows that the same, actually hard problems (like standardizing something that is "out there" for more than a decade already) are never really solved. Each shiny new tool comes with its own way of doing things, but what they do with your input is in the end always the same. Mounting, multiprocessing, sockets, string parsing, memory management, log searching, etc.
So yes, I think there's a way to become a chess master. You just need to go one level deeper and accept that there might be multiple topics that each will need half a decade to learn good enough to be useful.
I enjoy this line of thinking, having domain knowledge is always critical to success. Being invested is always ideal.
I would like to counter with the delivery transformations I have been apart of, the role of the architect has dried up.
I do predict for most large enterprises the role of a manager will start to become more full stack and becoming that invested visionary technical leader and mentor. At least that's what I hope for...
The interesting thing about grandmasters is their ability to recognise a winning position regardless of working out the moves yet, something AlphaZero (chess engine) seems to take to the extreme of recognising winning patterns that it can intuit will lead to winning games without hard calculation.
Maybe the architect equivalent is someone explaining the structure of a system and instantly knowing roughly where the problems are before inspecting the individual parts. Like the grandmaster the architect will intuit better than most where the problems likely are given a high level overview.
The fact is that the architectural mindset is a very distinct and recognizable mentality and most certainly not the byproduct of a "process".
I suggest one first try their hand at defining what is "architecture" and if one has trouble with that, suggestion is to not venture to the subsequent topic of "what is an architect and how does one recognize this rare [1] animal?"
[1]: it is definitively a talent and a rare one at that.
I've long had the notion that taste is secretly the most important quality of a good developer or worker in computing technology more generally, and we only pretend other things matter so much because taste is hard to measure in an interview, difficult to quantify, and no-one knows how to teach it reliably.
Taste works well when you are in a position to receive a large amount of work that can be organised in a hierarchy according to the work's quality. We will need a lot of that in a few years.
Working up from first principles, staying on time to produce a large quantity of stuff and discovering new facts are valuable methods too. You can't get to useful work from tasting without an ocean of work to receive.
I wonder if the analogy "software architect" isn't being stretched too thin.
What are the essential or characteristic traits of the architect as a professional and of architecture as an enterprise that translate or have direct equivalents in the software world? Are trained architects expected to be better sofware-architects than trained physicists or... chess masters?
